Сеансы работы пользователей
ЭКРАН 1. Настройка аудита системы.
Многие администраторы просматривают журнал безопасности Windows NT и видят события входа пользователей в систему и выхода из нее, однако часто не могут правильно оценить увиденное. Здесь следует обращать внимание на отдельные параметры событий. Так, событие успешной регистрации пользователя в системе имеет номер (ID) 528 (см. Рисунок 1). При отказе в регистрации пользователя фиксируется событие с другим номером, который зависит от причины отказа. Полный список событий можно найти в документе Microsoft "Описание событий аутентификации" (см. ). Событие с номером 538 означает завершение сеанса, начало которого зафиксировано событием 528. Событие номер 528 имеет несколько очень важных дополнительных параметров. Имя пользователя и домен определяют вошедшего в систему пользователя или то, чья учетная запись была при этом задействована. Номер сеанса пользователя Logon ID - это уникальный для системы код, присваиваемый любому активному сеансу работы пользователя с системой. Именно он будет записан в событии завершения сеанса. Это позволяет определить общее время работы пользователя при анализе событий 528 и 538 с одним и тем же номером сеанса.
РИСУНОК 1. Событие номер 528.
Событие входа в систему также фиксирует информацию о типе входа Logon Type, т. е. то, как пользователь вошел в систему. Тип входа 2 соответствует интерактивному входу с консоли, например, с помощью монитора и клавиатуры. Если пользователь подключается к диску на другом компьютере или как-либо еще использует сетевой ресурс, то выполняется сетевой вход с типом 3. Так, если был зафиксирован тип входа 2, то кто-то вошел в систему с локальной консоли именно этого компьютера, а если тип 3, значит, кто-то подключился к системе по сети. Тип входа 5 фиксируется при запуске службы с указанием конкретной учетной записи пользователя. При использовании планировщика задач производства независимых компаний, например Argent Queue Manager компании Argent Software, система фиксирует событие номер 528 с типом входа 4, что соответствует заданию на выполнение командного файла.
При разблокировании рабочей станции записывается событие с типом входа 7.
Фиксируются также все неудачные попытки входа в систему Logon Failure. При этом чаще всего записывается системное событие 529, соответствующее указанию неверного имени пользователя или пароля - Unknown user name or bad password.
ЭКРАН 2. Выбор рабочих станций, с которых пользователь имеет право войти в систему.
Если учетная запись пользователя недоступна или заблокирована, то попытка входа отвергается, и записывается событие с номером соответственно 531 или 539. Событие номер 530 указывает, что пользователь пытался войти в систему в недозволенное ему время или день недели. Если учетная запись пользователя просрочена или устарел пароль, то фиксируется соответственно событие 532 или 535. Если пользователь ограничен входом лишь на некоторые рабочие станции (см. Экран 2), а он пытается войти с другого компьютера, то запишется событие номер 533. Можно ограничить права пользователя на выполнение определенных типов входа в различные системы. Если пользователь, которому запрещен доступ к какому-то компьютеру по сети, все же пытается обратиться к его ресурсу или реестру, то он получит отказ, а в журнал безопасности запишется событие с номером 534. Такое же событие будет зафиксировано при попытке пользователя войти в систему с консоли, если это ему запрещено. При попытке запустить службу с использованием учетной записи пользователя, не имеющей права на запуск служб (права Logon as a service), также будет зафиксировано событие номер 534. Кроме того, событие 534 запишется и при попытке запуска задания с исполнением командного файла от имени учетной записи без права Logon as a batch job. При всех других отказах в аутентификации фиксируется событие с номером 537, т. е. An unexpected error occurred during logon - отказ по неизвестной причине. Тип входа фиксируется при всех попытках входа в систему, независимо от их результата. Более подробную информацию можно найти в документе Microsoft "Аудит аутентификации пользователей" (см. ).
Аутентификация в Windows NT имеет распределенную природу. Особенно ярко это проявляется при слежении за входом в систему и выходом из нее. Зачастую аудит на рабочей станции, имеющей учетную запись в домене, воспринимается уже как "вход в домен", вместо настоящего момента входа в домен или же входа на контроллер домена с использованием учетной записи домена. Аудит на рабочей станции означает лишь регистрацию на рабочей станции. Но поскольку используется учетная запись домена, сама рабочая станция не может аутентифицировать пользователя. Рабочая станция лишь посылает сведения о пользователе на контроллер домена по протоколу NTLM (NT LAN Manager). Контроллер домена проверяет правильность пароля и сразу же забывает о пользователе. Сеанс работы пользователя поддерживает сама рабочая станция до самого момента выхода из системы. Разумеется, именно рабочая станция и записывает в свой журнал системы безопасности информацию о сессии пользователя.
Для получения общей картины работы пользователей домена зачастую можно обойтись без анализа журналов безопасности на всех без исключения рабочих станциях. Дело в том, что сразу же после успешного входа пользователя обычно выполняется автоматическое подключение сетевых дисков, расположенных на файл-серверах. Именно журналы безопасности файл-серверов и следует просматривать, отслеживая события входа в систему с типом 3. Из-за отсутствия централизованной фиксации входов в систему для домена бывает трудно отследить попытки несанкционированного доступа. Однако, хотя контроллеры домена и не фиксируют все неудавшиеся попытки входа, они записывают все блокировки учетной записи (событие номер 644), которые являются следствием нескольких безуспешных попыток входа подряд. Подробнее о блокировках учетных записей рассказано в документе Microsoft "События при блокировках учетных записей хранятся в журнале безопасности контроллера домена" (см. ).
Необходимо отслеживать использование локальных учетных записей на отдельных системах.
Входящие в домен рабочие станции и обычные серверы аутентифицируют пользователей на контроллерах доменов, а также ведут собственные локальные базы пользователей (SAM). И пользователи, и взломщики могут задействовать эти локальные учетные записи, чтобы попытаться войти в систему локально или через сеть. Во всех системах существует встроенная административная учетная запись Administrator. О том, как предотвратить нежелательные попытки ее использования, рассказано в мартовском номере Windows NT Magazine/RE в статье Франклина Р. Смита "Защитим права администратора!".
Для эффективного наблюдения за сеансами работы пользователей нужно хорошо знать, что и где проверять. Для отслеживания входа в систему в первую очередь следует просматривать журналы безопасности на рабочих станциях и простых серверах и искать в них события с номерами 528 и 538. Возможные попытки незаконного проникновения в систему отслеживаются среди событий с номерами от 529 до 537, а также 539 на всех потенциально доступных для нападения компьютерах.
