Previous: 6.12 Фильтрация на входе сети: Отражение атак DoS, которые используют подмену IP-адреса отправителя (RFC-2827)
UP:
6 Сетевая безопасность |
6.13 Правила безопасности для пользователей
Семенов Ю.А. (ГНЦ ИТЭФ)
В 1997 году одна из подгрупп IETF выпустила справочник Site Security Handbook (RFC-2196). В нем содержатся рекомендации системным администраторам по разнообразным вопросам защиты сети, правилам использования и методике работы. Этот документ предлагает включить в правила следующие разделы:
В правилах для пользователей необходимо регламентировать следующие вопросы:
Примером соглашения для доступа к компьютерам может служить документ такого рода для факультета информатики университета Мельбурна. Смотри также http://www.admin.com.
Я, нижеподписавшийся, настоящим объявляю, что буду придерживаться приведенных ниже правил:
Обратите внимание на неоднозначные слова о честности, порядочности и необходимости беречь репутацию университета. Подобные требования общего характера помогают охватить вопросы, которые трудно описать строгими детерминированными правилами. И хотя юридическая сила таких требований невелика, все же полезно их включить во внутренние правила компании или учреждения. Заверенная расписка пользователя о согласии следовать перечисленным правилам является юридическим документом и может использоваться в суде. Обязательно нужно проинформировать всех пользователей, что сам факт использования учетной записи, равносилен согласию соблюдать установленные правила. Должно быть известно, где можно ознакомится с правилами. Следует иметь в виду, что не имеющие юридической силы и противоречивые правила - хуже, чем их отсутствие.
Здесь нет ни слова об использовании программ сканирования, рассылки сообщений содержащих “троянских коней” или вирусы, попыток взлома защиты серверов и пр. Это все преступления, которые обычно регламентируются уголовным кодексом. И следует учитывать, что оправдания типа, я решил просто посмотреть, как работает такая программа из любопытства и т.д., не могут служить оправданием. Полагаю, никто не воспримет серьезно оправдание вроде: “Я хотел лишь проверить, работает ли этот гранатомет, у меня и в мыслях не было разносить вдребезги эту бензоколонку…”
Не нужно думать, что права системных администраторов не ограничиваются ничем. Если системный администратор злоупотребляет своими полномочиями, им следует подобрать другую работу. Если специфика работы требует наличия нескольких администраторов, пароль root помещается в конверт, а конверт в сейф. Администраторы же пользуются программой sudo. Если в какой-то момент времени кому-то потребуется пароль root, конверт извлекается из сейфа, и после завершения операции пароль заменяется.
Рекомендуется помещать в файл /etc/motd (сообщение дня) предупреждение о действующих у вас правилах. Предупреждение должно содержать перечень мер, которые будут предприняты, при несоблюдении правил (удаление учетной записи, размер штрафа или уголовная ответственность).
Следует решить заблаговременно вопрос о том, кто должен руководить работами в экстремальной ситуации, определить субординацию. Имена и телефоны должностных лиц также как базовые IP-адреса следует хранить вне системы. Возможно, там (вне сети) следует держать и конфигурационную базу данных. Обычно руководитель ВЦ для этих работ не пригоден. Должно быть известно, где хранятся последние backup-копии жизненно важных частей ОС (помимо файла /etc/dumpdates). Для случай взлома WEB-сервера известной компании, нужно тщательно продумать тактику контакта со средствами массовой информации, клиентами. Это все настолько важно, что стоит подумать о необходимости специальных учений. Часто в таких ситуациях поток запросов серверу может резко возрасти (многие любопытные пытаются проверить слух об аварии, а слухи в сети распространяются как снежная лавина). Если ваш сервер не в полной мере восстановлен и излишняя загрузка для него губительна, позаботьтесь о передаресации избыточной части запросов на другой сервер, который будет уведомлять: “Извините, узел перегружен и в данный момент мы не можем обработать ваш запрос”. Рекомендуется использовать программу tripwire, чтобы согласовать действия системных администраторов, особенно если разные группы администраторов отвечают за разные аспекты работы одной ЭВМ. Например, “заплаты” СУБД Oracle и ОС могут конфликтовать друг с другом. В результате одна группа, поставившая “заплату” может и не подозревать, что текущая проблема является следствием действий другой группы. Программа tripwire идентифицирует, что и когда изменялось, и помогает доказать администраторам, что именно их действия явились причиной неполадок.
Previous: 6.12 Фильтрация на входе сети: Отражение атак DoS, которые используют подмену IP-адреса отправителя (RFC-2827)
UP:
6 Сетевая безопасность |