Замечание к документу "Alex, Вам интересно продолжение этого трейда? До всего приходится доходить своими мозгами, и просто приятно обсудить некоторые вещи с другими людьми (+)" >>>
Сообщение:
Более того, сейчас задача выхода в веб для меня стала
весьма актуальна, со всеми вытекающими...
Признаюсь раньше я зачастую практиковал для своих серверов потушенную
http task и наглухо закрытый 80 порт.
Хотя web в моем случае мог бы облегчить жизнь.
Но времена меняются и сейчас взялся за задачу привязки к сайту
контента который живет в парочке Notes баз.
В принципе я для себя решил так - пока попробую генерить по
базе html и перекладывать на Апач.
Когда созреем до взрослой динамики перейдем на colocation и на
втором сервере будет только http одна база с выборочной репликацией.
>Ваше удивление по поводу того, что немногие читают рассылку Bugtraq >вполне адекватно, но за всем как-то трудно уследить...
Согласен. Пока сам не словил cеръезную оплеуху не обращал внимания.
>По логину - Насколько снижает угрозу включение опции Use more secure >Internet password?
Насколько я помню никак, т. к. это просто включает более сильное
кодирование введенного пользователем пароля при хранении в адресной
книге.
>Какие же рекомендации можно предложить администраторам (в том числе, >и начинающим) по преодолению той ситуации, которую Вы описываете >черными ;-))) красками?
Возможно я действительно сгустил краски, но я повидал множество
пользователей которые очень халатно относились к паролю...
Вообще, я тут пофантазировал и свое виденье я подробно изложил в письме Степану Карандину. Посмотрим, может Lotus обрадует чем нибудь в Domino 6?
>Путь и название почтового файла...
>Может просто создавать файлы в каталоге не mail, как это >предполагается по умолчанию, а usermail, mboxes или что-то в этом >роде?
>Насколько это снизит угрозу? Или все-таки рекомендовать использовать >неинтуитивные имена файлов почтовых ящиков?
Я попробовал сделать не интуитивными название ящиков.
Хотя конечно нужно делать не интуитивным и путь, но я в последний момент решил не эксперементировать - времени было в обрез
и боялся(уверен что абсолютно безосновательно) наступить на
какие нибудь грабли если ящики будут не в \mail.
А потом просто тупо заменил в homepage.nsf титульную страничку с перечислением пользователей и поставил Ananymous=No access
Теперь юзер заходит, логинится, попадает на homepage кликает на своей фамилии и переходит в свой ящик.
>И по паролю...
>1. Не давать пользователям самим менять Internet-пароль
>2. Изменить дизайн адресной книги так, чтобы встроить механизм >проверки "живучести" пароля или, во всяком случае, сообщение >администратору о факте смены пароля
Дописать проверку вводимого пароля было бы неплохо,
а еще лучше наверное написать шедульного агента для сканирования логов
и отлавливания неудачных попыток авторизации.
Еще бы руки до этого дошли...
>Тут еще один момент... Как только мы подключаем администратора, >получаем, что он знает пароль, что он ответственен за >пользовательский пароль...
>Насколько выигрышно получится такое решение?
IMHO это зависит от конкретной ситуации.
Безусловно играет роль количество пользователей,
и то в какой зависимости они от админа (или наоборот).
Когда я работал в госструктуре там все было просто - все пароли
распределялись централизовано. Инициатива от пользователей
пресекалась. У такого варианта свои плюсы и свои минусы - главное
не усложнять пароль и подбирать его повозможности "легко усваиваемым" каждому пользователю индивидуально. Потому как если перегнуть палку легко добится обратного эффекта - его пароль смогут узнать все сослуживцы,так как он приклеит стикер с ним себе на монитор :)
Да и всегда в целях повышения бдительности можно напомнить ему что
он госслужащий...