Анализируем журнал безопасности Windows NT

Существует три основные категории такого аудита — это аудит сеансов работы пользователей, аудит доступа к объектам системы и аудит выполняющихся задач. Эти категории дают основную информацию при наблюдении за действиями пользователей. Системная политика аудита настраивается в меню Policies-Audit-Audit Policy, вызываемом из программы User Manager (см. Экран 1). Данное диалоговое окно позволяет выбрать, какие из семи категорий фиксировать в локальном журнале безопасности, а какие нет.

Сеансы работы пользователей

ЭКРАН 1. Настройка аудита системы.

Многие администраторы просматривают журнал безопасности Windows NT и видят события входа пользователей в систему и выхода из нее, однако часто не могут правильно оценить увиденное. Здесь следует обращать внимание на отдельные параметры событий. Так, событие успешной регистрации пользователя в системе имеет номер (ID) 528 (см. Рисунок 1). При отказе в регистрации пользователя фиксируется событие с другим номером, который зависит от причины отказа. Полный список событий можно найти в документе Microsoft «Описание событий аутентификации» (см. http://support.microsoft.com/support/kb/articles/q174/0/74.asp). Событие с номером 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 «Аудит аутентификации пользователей» (см. http://support.microsoft.com/support/kb/articles/q174/0/73.asp).

Аутентификация в Windows NT имеет распределенную природу. Особенно ярко это проявляется при слежении за входом в систему и выходом из нее. Зачастую аудит на рабочей станции, имеющей учетную запись в домене, воспринимается уже как «вход в домен», вместо настоящего момента входа в домен или же входа на контроллер домена с использованием учетной записи домена. Аудит на рабочей станции означает лишь регистрацию на рабочей станции. Но поскольку используется учетная запись домена, сама рабочая станция не может аутентифицировать пользователя. Рабочая станция лишь посылает сведения о пользователе на контроллер домена по протоколу NTLM (NT LAN Manager). Контроллер домена проверяет правильность пароля и сразу же забывает о пользователе. Сеанс работы пользователя поддерживает сама рабочая станция до самого момента выхода из системы. Разумеется, именно рабочая станция и записывает в свой журнал системы безопасности информацию о сессии пользователя.

Для получения общей картины работы пользователей домена зачастую можно обойтись без анализа журналов безопасности на всех без исключения рабочих станциях. Дело в том, что сразу же после успешного входа пользователя обычно выполняется автоматическое подключение сетевых дисков, расположенных на файл-серверах. Именно журналы безопасности файл-серверов и следует просматривать, отслеживая события входа в систему с типом 3. Из-за отсутствия централизованной фиксации входов в систему для домена бывает трудно отследить попытки несанкционированного доступа. Однако, хотя контроллеры домена и не фиксируют все неудавшиеся попытки входа, они записывают все блокировки учетной записи (событие номер 644), которые являются следствием нескольких безуспешных попыток входа подряд. Подробнее о блокировках учетных записей рассказано в документе Microsoft «События при блокировках учетных записей хранятся в журнале безопасности контроллера домена» (см. http://support.microsoft.com/support/kb/articles/q182/9/18.asp).

Необходимо отслеживать использование локальных учетных записей на отдельных системах. Входящие в домен рабочие станции и обычные серверы аутентифицируют пользователей на контроллерах доменов, а также ведут собственные локальные базы пользователей (SAM). И пользователи, и взломщики могут задействовать эти локальные учетные записи, чтобы попытаться войти в систему локально или через сеть. Во всех системах существует встроенная административная учетная запись Administrator. О том, как предотвратить нежелательные попытки ее использования, рассказано в мартовском номере Windows NT Magazine/RE в статье Франклина Р. Смита «Защитим права администратора!».

Для эффективного наблюдения за сеансами работы пользователей нужно хорошо знать, что и где проверять. Для отслеживания входа в систему в первую очередь следует просматривать журналы безопасности на рабочих станциях и простых серверах и искать в них события с номерами 528 и 538. Возможные попытки незаконного проникновения в систему отслеживаются среди событий с номерами от 529 до 537, а также 539 на всех потенциально доступных для нападения компьютерах.

Доступ к объектам системы

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

Аудит доступа к объектам ведется в журнале событий, а не в журнале транзакций. Поэтому Windows NT не фиксирует, что именно сделал пользователь с объектом, а указывает только тип доступа к данному объекту. Так, например, можно проследить, что пользователь Иванов открыл файл Зарплата.xls для чтения, записи, выполнения и удаления, однако совершенно невозможно выяснить, внес ли он какие-то изменения, а если да, то какие именно. К тому же при аудите доступа к объектам в журнал может быть записано неоправданно много событий. Так, при активизации двойным щелчком текстового файла из программы Windows Explorer происходит запуск программы WordPad. При этом фиксируется более 20 событий, связанных с доступом к данному файлу и к каталогу, где он находится.

Аудит объектов обычно используется применительно к обычным приложениям, которые работают с отдельными файлами, например к приложениям из комплекта Microsoft Office. Специальные клиент-серверные приложения, такие, как SAP, работают с таблицами, расположенными в нескольких больших файлах базы данных SQL Server. Аудит таких файлов обычно сводится к записи одного события при запуске информационной службы и одного — при ее остановке. При этом не остается сведений о том, какой пользователь выполнял те или иные транзакции или в каких таблицах он менял данные. Эту информацию могут сохранять только сами приложения. Зато аудит таких монолитных файлов помогает выяснить, не пытался ли кто-то заменить файлы базы данных в тот момент, когда SQL Server был остановлен. Это вполне возможно, а перезапущенная прикладная служба не способна заметить подмену.

РИСУНОК 2. Событие номер 560.

Основные два события аудита доступа к объектам: object opened и handle closed. Первое фиксирует открытие объекта (номер 560) , а второе — его закрытие (событие 562). Это взаимодополняющие друг друга события, подобные событиям входа и выхода из системы. Успешное событие номер 560 (см. Рисунок 2) записывает информацию об открытом объекте, а также имя пользователя и название приложения, которое воспользовалось объектом, тип доступа и дескриптор Handle ID.

Handle ID является уникальным кодом для контроля операционной системы за каждым объектом. Он напоминает описанный выше номер сессии пользователя. Найдя пару событий открытия и закрытия (560 и 562) с одним и тем же значением Handle ID, можно выяснить время работы пользователя с данным объектом. Вместе с этим дескриптором событие номер 560 записывает и номер сессии пользователя (см. Рисунок 2), что позволяет выяснить, в какой именно сессии тот обращался к объекту.

События хранят информацию о двух пользователях — об основном и о клиенте. При открытии файла на локальном компьютере с помощью обычного приложения, такого, как Microsoft Word, существенна только информация об основном пользователе. Однако при доступе к объекту из клиент-серверных приложений, которые разграничивают доступ к данным на основе базы пользователей системы, фиксируются оба типа пользователей: основной — соответствует учетной записи клиент-серверного приложения, а клиентский — соответствует пользователю, от имени которого работает сервер. Типичным примером является доступ к файловым ресурсам сервера. Так, при доступе к файлу на другом компьютере через сеть служба Workstation обращающегося к файлу компьютера соединяется со службой Server компьютера с предоставляемым ресурсом, при этом происходит тип 3 входа в систему. Перед обработкой любого запроса сервер аутентифицирует пользователя и записывает события доступа к объекту с указанием основного пользователя и клиента. В этом случае основным пользователем будет SYSTEM, поскольку именно под данной учетной записью запускается служба Server. Информация о клиенте соответствует имени пользователя, которое применялось для доступа к ресурсу; обычно это одна из учетных записей пользователей домена.

Поле типа доступа Accesses в событии номер 560 хранит вид использованного метода доступа к объекту. Значения этого поля соответствуют возможным типам полномочий доступа к объектам ACL. Так, при редактировании текстового файла в редакторе WordPad Windows NT фиксирует событие 560 с типом доступа для чтения ReadData, записи WriteData и добавления AppendData.

Событие 560 также сохраняет информацию о номере процесса Process ID. Этот номер позволяет определить, какая именно программа обратилась к объекту. Например, можно точно выяснить, использовалось ли при редактировании текстового файла приложение Word, WordPad или Notepad. Однако это при условии, что редактировался локальный файл. Если же пользователь обращался к объекту через сеть, фиксируется номер процесса, соответствующий серверному приложению.

Третьим важным событием в категории аудита объектов является событие номер 564, удаление объекта — object deleted. Оно записывает только дескриптор и номер процесса. Чтобы разобраться, какой именно объект и каким пользователем был удален, необходимо отыскать по значению Handle ID соответствующее событие 560 открытия объекта. В событии номер 560 есть вся необходимая информация о пользователе, так что событие 564 удаления объекта следует связывать именно с ним.

Аудит и анализ доступа к объектам представляется очень мощным средством. Однако анализ — процесс весьма трудоемкий, а аудит может снизить быстродействие системы при активном использовании и большом количестве регистрируемых объектов. Не следует злоупотреблять этим типом аудита. Кроме защиты особо важных ресурсов он часто используется службой безопасности предприятия для сбора сведений о неблагонадежных пользователях. Известны случаи, когда аудит ставился на специально подбрасываемые пользователям файлы типа Зарплата.xls только лишь с целью выявить потенциальных злоумышленников. Подобный подход требует строгой проработки. Ну и, конечно, не надо забывать включать аудит доступа к объектам системы в приложении User Manager на той системе, где эти объекты находятся, а не только на рабочей станции пользователя.

Аудит выполняющихся задач

РИСУНОК 3. Событие номер 592.

Эта категория аудита в приложении User Manager называется аудитом выполняющихся задач — process tracking, а в документации по Windows NT и в программе Event Viewer используется термин «детальный аудит» — detailed tracking. Как бы то ни было, данная категория позволяет проследить за тем, какие именно программы были запущены на рабочей станции и какие программы выполнялись на сервере. В этой категории также существуют два основных события — создание нового процесса, событие номер 592, и завершение процесса, событие номер 593. Найдя пару событий 592 и 593, имеющих один и тот же номер процесса Process ID, можно определить общее время работы того или иного приложения. Поле названия исполнительного модуля Image File Name хранит имя файла, соответствующего приложению. Так, при запуске WordPad это поле будет содержать значение WORDPAD.EXE (см. Рисунок 3). К сожалению, событие не записывает полный путь, и судить о точном размещении исполняемого файла нельзя. В поле имени пользователя User Name хранится информация о том, кто запустил приложение. Кроме того, по значению поля номера сеанса Logon ID пользователя можно отыскать соответствующее событие номер 528 и выяснить все подробности о сеансе, в котором запускалось приложение. С помощью поля номера запустившего приложение процесса Creator Process ID можно найти соответствующее событие номер 592, из которого выяснить, какая программа инициировала запуск нового процесса.

Аудит выполняющихся задач может оказаться очень полезным на рабочих станциях, в особенности при изучении активности тех или иных пользователей. Если при этом задействовать аудит доступа к объектам на серверах, то можно построить довольно четкую картину работы пользователей.

Аудит сеансов работы пользователей, аудит доступа к объектам системы и аудит выполняющихся задач являются тремя важнейшими категориями в журнале безопасности Windows NT. Можно связать сеансы работы пользователей, процессы и доступ к объектам и построить точную картину деятельности пользователей (см. Рисунок 4). К сожалению, Event Viewer не способен фильтровать события по значениям их параметров, так что использовать номера Logon ID, Process ID и Handle ID весьма трудно. Однако можно применить функцию поиска по значению параметра и вручную составить необходимые цепочки событий. Можно также воспользоваться другими программами обработки журнала безопасности Windows NT, которые позволяют отфильтровывать события по различным критериям.

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