13.3 Безопасность на уровне домена и локальная безопасность

Приобретая дополнительную функциональность, система безопасности NT-станции после вхождения в домен все же продолжает подчиняться локальным установкам. Изменения в программе User Manager for Domains не оказывают никакого влияния на политики локальных пользователей или их систему прав. Например, когда с помощью User Manager for Domains для какого-либо пользователя назначается право Logon locally, данный пользователь получает право локальной регистрации с консоли любого контроллера домена. Но если нужно, чтобы он мог регистрироваться локально на любой станции — члене домена, нужно на данной станции предоставить такое право с помощью программы User Manager.

Политика учетных записей и политика аудита, установленная для DC, никак не влияют на аналогичные локальные установки станций — членов домена. Например, предположим, что, зарегистрировавшись в домене, мы открыли User Manager for Domains и установили минимальную длину пароля. Это действие никак не отразится на локальной базе SAM сервера или рабочей станции, принадлежащей домену, поэтому при слабой локальной политике наша станция становится менее защищенной. Хакеры не особенно разборчивы: чем локальная учетная запись хуже доменной для взлома системы?

Поэтому лучше стараться не создавать большое количество локальных учетных записей. Вместо этого стоит создать для каждого пользователя одну доменную учетную запись, которой можно будет воспользоваться на любом компьютере домена. Если все же на станции уже создано много локальных учетных записей, лучше провести реконфигурацию SAM в удаленном режиме. Для этого следует просто скопировать на свой компьютер программу User Manager for Domains (usrmgr.exe) с любого сервера NT. Запустив программу, нужно выбрать User, Select Domain, но не вводить имя домена. Вместо этого следует ввести два обратных слеша и имя удаленной станции (т. е. при реконфигурации SAM компьютера Kramer надо ввести \\kramer). Чтобы убедиться, что открыта база SAM удаленной станции, а не домена, обратите внимание на заголовок окна, в котором должно присутствовать введенное имя и два обратных слеша.

Итак, система безопасности NT не является централизованной, как может показаться на первый взгляд. Каждый компьютер имеет дискретную конфигурацию из сотен настроек, которые требуют внимания со стороны администратора системы. Даже в домене централизованными можно признать только учетные записи пользователей и группы — при условии, что администратор старается не создавать локальные учетные записи на станциях — членах домена. Следовательно, знание основ настроек системы безопасности NT — краеугольный камень для построения безопасной сети в целом.

14. Безопасность в unix

14.1 Система идентификации и аутентификации в unix-подобных ос

Рассмотрим стандартную процедуру идентификации и аутентификации пользователя в ОС UNIX.

Для организации авторизованного доступа к системе и определения учётной записи пользователя используется совокупность входного имени пользователя (login), при помощи которого осуществляется идентификация пользователя, и секретного пароля (passwd), при помощи которого осуществляется аутентификация пользователя. Система ищет входное имя пользователя в файле /etc/passwd и, если пользователь идентифицируется, то аутентификация заключается в сравнении введенного пароля с паролем, который хранится в зашифрованном виде.

Пароль - наиболее важная часть обеспечения UNIX безопасности. Если злоумышленник узнает пароль пользователя, он может работать с правами этого пользователя, в том числе и суперпользователя (root).

По этой причине для безопасности UNIX систем чрезвычайно важны правила выбора безопасных паролей. Для реализации правил использования безопасных паролей в UNIX (в SCO Release 5.0 в частности) существуют следующие средства:

1. Задание администратором учета пользователей и терминалов определенных требований на пароли:

- ограничение минимальной длины вводимого пользователем пароля;

- требование наличия в пароле обязательного минимального количества букв нижнего регистра, букв верхнего регистра, цифр и специальных символов;

- запрещение пользователю введения собственных паролей; разрешение вводить только пароли, сгенерированные системой.

2. Задание администратором временных ограничений по частоте сменяемости и времени жизни паролей. При этом для удобства пользователя возможно задание интервала между началом требования смены пароля и окончанием срока его действия.

3. Автоматическое блокирование пользователя по входу в систему по старости пароля, по числу неуспешных попыток входа.

4. Задание количества и номеров терминалов для входа в систему для каждого пользователя.

5. Проверка системой паролей пользователей при их вводе на стойкость (вхождение идентификатора, имени пользователя, повторяемость символов и т.д.).

6. Хранение зашифрованных паролей не в /etc/passwd, как в старых версиях, а в закрытом от доступа отдельном файле.

7. Получение статистической информации по времени работы пользователя в системе, его блокировки, номере терминала и т.д.

8. При установке класса защиты С2 невозможность администратором регистрации пользователя без пароля (guest).

9. Существует возможность блокирования по числу неуспешных попыток входа не только пользователя, но и терминала. При этом можно задать интервал времени, который должен пройти между попытками регистрации. Также предусмотрено ведение записей об успешных и неуспешных попытках входа в систему.

Хорошо себя зарекомендовало использование командного интерпретатора rsh (restricted). При его использовании на действия пользователя накладываются следующие ограничения:

• не может перейти никуда из своего домашнего справочника;

• может использовать только команды из тех справочников, которые определены в переменной окружения PATH. При этом изменить значение переменной окружения PATH пользователь не может;

• не может задавать полные имена программных файлов и перенаправлять потоки ввода-вывода.

Можно еще больше ограничить действия пользователя путем введения в его стартовый командный файл (.profile) определенной команды (системы, приложения), которая будет вызываться через команду ехес. В этой ситуации если в стартовый командный файл добавить команды trap и exit, то пользователь сможет работать только с заданной ему командой (системой).

Очевидно, что успешно реализовать любую защиту, в том числе и парольную, можно только с соблюдением организационных мер. При этом реальной угрозой преодоления парольной защиты является нарушение такой организационной меры защиты, как оставление без присмотра терминала, на котором пользователь уже зарегистрировался. В этом случае, необходимо проводить работу с пользователями, чтобы они использовали команды блокирования терминала (lock, xlock). Существуют средства автоматического блокирования терминала по истечению определенного периода времени. Такие средства встроены в некоторые командные интерпретаторы или графические оболочки. Однако использование этих средств нецелесообразно из-за опасности внедрения программы, имитирующей блокирование экрана и считывающей пароль пользователя. В системе должен быть обязательно определен список терминалов, с которых не могут входить администраторы.

Парольная защита также применяется для того, чтобы обезопасить удаленный вход пользователей по каналам связи, подключаемым к последовательным портам. В этом случае возможна установка отдельного пароля на каждое используемое для удаленного входа устройство (специальный файл). При вводе неправильного пароля с удаленной системы работа с UNIX системой становится невозможной.

Корректная реализация администратором средств парольной защиты, представляемых системой UNIX, позволяет гарантировать целостность парольной защиты при соблюдении организационных мер безопасности. Особо следует отметить, что на сегодняшний день во всех коммерческих версиях зашифрованный пароль не хранится в файле /etc/passwd, поскольку этот файл открыт для чтения всем пользователям.