Операционные системы -> Windows -> Все о журнале безопасности Windows 2000

Все о журнале безопасности Windows 2000

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

Контролировать выполнение программ можно с помощью категории Audit process tracking (аудит запуска процесса) Windows 2000. Могут пригодиться и категории аудита действий операционной системы Audit privilege use (аудит использования привилегий), Audit policy change (аудит изменения политики) и Audit system events (аудит системных событий). Наряду с другими категориями аудита, представленными в данной серии статей о журнале безопасности Windows 2000, эти события помогут понять, какие действия предпринимал взломщик, пытавшийся нарушить целостность сети.

Audit process tracking

Audit process tracking не отслеживает неудачных событий, но когда категория настроена на контроль успешных действий, то фиксируются два события: с ID 592 (создан новый процесс) и с ID 593 (процесс завершен). Категория Audit process tracking указана как Detailed tracking в списке Category оснастки Event Viewer консоли Microsoft Management Console (MMC).

Когда пользователь запускает исполняемый файл, такой, как Microsoft Excel, Windows 2000 регистрирует событие с ID 592. Данное событие указывает, какая программа была запущена и когда. Пример сообщения о событии показан на Экране 1; поля Time, User и Image File Name указывают, что пользователь Билл запустил Excel в 5 ч 51 мин пополудни. Следует обратить внимание, что Windows 2000 регистрирует полный путь к выполняемому файлу, в отличие от NT, регистрирующей только имя файла.

Поле Logon ID соответствует ID регистрации, который был назначен Биллу при входе в систему. Данный идентификатор позволяет связать событие создания процесса с событием успешной регистрации с ID 528.

Начиная новый процесс, Windows 2000 присваивает ему уникальный номер, Process ID. Этот номер показан в поле New Process ID события с ID 592. Обычно следующим действием после запуска приложения является открытие пользователем данной программы какого-либо файла. В статье <Аудит доступа к объектам> (опубликованной в предыдущем номере - прим. ред.) я отмечал, что в описании события с ID 560 также имеется поле Process ID, которое можно использовать для идентификации связанных событий с ID 560 и ID 592. Однако в событии с ID 592 Windows 2000 регистрирует иной ID процесса, нежели в событии с ID 560 или любом другом. Событие с ID 592 отображает ID процесса как десятизначное число, тогда как другие события (и закладка Processes диалогового окна Task Manager) показывают ID процесса как трех- или четырехзначное число. По некоторым сведениям, разработчики Microsoft устранили это противоречие в операционных системах Windows 2002 и Windows XP.

Для идентификации процесса, запустившего новый процесс, можно воспользоваться полем Creator Process ID события с ID 592. Достаточно отыскать предыдущее событие с ID 592 с идентификатором Process ID, совпадающим с полем Creator Process ID избранного события. Оба поля события с ID 592 имеют десятизначный формат.

В программе Event Viewer нет фильтра для сортировки событий журнала безопасности по ID регистрации или ID процесса, но можно отыскивать события с конкретным ID. Чтобы найти события, содержащие определенные ID, следует открыть оснастку Event Viewer, щелкнуть правой кнопкой мыши на журнале Security и выбрать пункты View, Find. Затем нужно ввести идентификатор в поле Description и щелкнуть на кнопке Find Next.

Когда пользователь закрывает приложение, Windows 2000 регистрирует событие с ID 593. Событие с ID 593 располагает полем Process ID, но, как указано выше, этот идентификатор не совпадает с ID процесса соответствующего события 592, зарегистрированного операционной системой, когда пользователь открыл прикладную программу.

Наряду с решением проблемы соответствия Process ID, пользователям предстоит связать события образования процессов, доступа к объектам и регистрации - с документом, учитывая необходимость проверки времени, когда пользователь зарегистрировался; приложения, открытого пользователем; файлов и других объектов, к которым пользователь обращался из каждого приложения. Найти связь между событиями нетрудно при работе на автономном компьютере, где пользователь регистрируется, запускает приложения и обращается к файлам только на одной системе. Но в реальной сети задача не столь проста. Windows 2000 регистрирует события образования процессов на компьютере, выполняющем программу (на локальной станции пользователя), а события доступа к объектам регистрируются на компьютере, на котором хранится объект. Например, если пользователь через сеть открывает файл на файл-сервере FS1, то служба Server открывает файл на FS1 от имени пользователя. Поэтому невозможно напрямую идентифицировать приложения, с помощью которых пользователь открыл файлы, хранящиеся на удаленном файл-сервере.

Например, пользователь регистрируется на рабочей станции, запускает Excel и редактирует электронную таблицу, расположенную на файл-сервере. Windows 2000 регистрирует событие с ID 592 в журнале безопасности рабочей станции, а событие с ID 560 - в журнале безопасности сервера. Идентификаторы процессов этих двух событий не совпадают (и не совпали бы, даже если бы Windows 2000 использовала один и тот же ID процесса для обоих событий). Необходимо отыскать событие с ID 592 в журнале безопасности рабочей станции, соответствующее событию с ID 560 в журнале безопасности сервера.

Активизация на сервере категории Audit process tracking не поможет получить дополнительные сведения о приложениях, выполняемых на рабочей станции пользователя. Однако благодаря событиям этой категории можно следит за использованием серверных программ, таких, как Microsoft SQL Server и Microsoft Exchange Server, и любых программ, исполняемых администраторами и операторами при локальной регистрации на сервере. Активизация данной категории создает нагрузку на ресурсы сервера, поэтому необходимо внимательно следить за ее влиянием на производительность.

Отслеживание процедур регистрации и использования процессов и объектов поможет контролировать действия вероятного взломщика. А наблюдая за попытками использования полномочий, можно вовремя заметить подозрительные действия. Подобные действия помогает обнаружить категория Audit privilege use.

Audit privilege use

Категория Audit privilege use отслеживает успешные и неудачные попытки использования полномочий, предоставленных пользователю (в статьях и документации Microsoft не выработано единой терминологии, и термины privileges и rights используются как равнозначные). Существует более 34 полномочий: от мощных, таких, как Act as part of the operating system (работать как часть операционной системы), до довольно безобидных прав, как Bypass traverse checking (обойти перекрестную проверку). После активизации категории Audit privilege use в журнале безопасности начинают регистрироваться три события: с ID 577 (вызов привилегированной службы), ID 578 (привилегированная операция с объектом) и ID 576 (специальная привилегия, предоставленная новой учетной записи).

Когда пользователь пытается применить полномочия, Windows 2000 регистрирует событие с ID 577 или ID 578, в зависимости от типа полномочий (Windows 2000 контролирует одни полномочия по службам, а другие - по объектам). В обоих случаях в поле Privileges указывается использованное полномочие. Windows 2000 регистрирует краткое имя полномочия, которое всегда начинается с Se и заканчивается на Privilege. Но эти краткие имена нельзя увидеть, оперируя полномочиями в оснастке MMC Group Policy Editor (GPE). Вместо них приводятся полные описания полномочий. Например, на Экране 2 показано событие с ID 577, зарегистрированное операционной системой, когда я перевел часы компьютера. Полномочие SeSystemtimePrivilege соответствует полномочию Change the system time в редакторе GPE.

Если пользователю разрешено применять полномочия, то операционная система регистрирует успешное событие с ID 577 или событие ID 578. Если пользователь пытается выполнить действие, не имея соответствующих прав, то Windows 2000 регистрирует неудачное событие. Для некоторых полномочий поля Primary User Name и Primary Domain Name идентифицируют пользователя, вызвавшего событие. Однако для полномочий, которые использует серверный процесс, эти поля соответствуют учетной записи данного компьютера. Отличительный признак таких полномочий - совпадение поля Primary User Name с полем Computer со знаком <$> в конце.

В таких случаях определить пользователя, применившего полномочие, можно по данным полей Client User Name и Client Domain. Поля Primary Logon ID и Client Logon ID соответствуют полю Logon ID события с ID 528 или ID 540, зафиксированного операционной системой при регистрации пользователя.

Поле Process ID события с ID 578 идентифицирует процесс, непосредственно вызвавший событие. Например, при просмотре журнала безопасности процесс Services от имени администратора использует полномочие Se-SecurityPrivilege (т. е. Manage auditing and security log). Соответствующий идентификатор процесса в событии с ID 578 принадлежит процессу Services.

Категория Audit logon events содержит специальные идентификаторы событий для действий при регистрации пользователей, поэтому по умолчанию Windows 2000 не записывает успешные и неудачные попытки применения полномочий на регистрацию. Эти полномочия - за исключением Access this computer from the network и Deny access to this computer from the network - начинаются словами Logon as или Deny logon. Windows 2000 также не заносит в журнал информацию о некоторых других полномочиях - например, SeBackupPrivilege (резервное копирование файлов и каталогов) и SeRestorePrivilege (восстановление файлов и каталогов), - вызываемых так часто, что они быстро переполнили бы журнал безопасности. Чтобы система выполняла аудит использования этих полномочий, следует изменить параметр реестра HKEY_LO-CAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa: Set the FullPri-vilegeAuditing, имеющий тип REG_DWORD, и присвоить ему значение 1.

Windows 2000 никогда не регистрирует использование полномочий SeAudit-Privilege (Generate security audits - генерировать проверку безопасности), SeCreateTokenPrivilege (Create a token object - создать маркерный объект), SeDebugPrivilege (Debug programs - отладка программ), SeChangeNotify-Privilege (Bypass traverse checking - пропуск проверки) и SeAssignPrimary-TokenPrivilege (Replace a process level token - изменить маркер уровня процесса). Но если регистрируется пользователь, обладающий одним или несколькими из этих полномочий, то Windows 2000 записывает в журнал событие с ID 576 (новой учетной записи назначены специальные полномочия; данное событие обычно близко следует за успешным событием регистрации с ID 528 или ID 540). Чтобы определить, какими полномочиями обладает пользователь во время регистрации, следует обратить внимание на поле Logon ID события с ID 576, которое идентифицирует пользователя, и поле Assigned, где перечислены краткие имена полномочий.

Audit Policy Change

С помощью категории Audit privilege use можно проследить, кто и когда использует полномочия, а категория Audit policy change позволяет узнать об изменениях, вносимых администраторами в назначенные полномочия. Данная категория обеспечивает контроль нескольких типов изменений политики.

Во-первых, Audit policy change сообщает, когда были изменены назначенные привилегии. Когда администратор предоставляет пользователю полномочия, Windows 2000 регистрирует событие с ID 608 (пользователю назначены полномочия). В поле User Right перечислены сокращенные имена назначенных полномочий (одного или нескольких). Поле Assigned to идентифицирует пользователя или группу, которой администратор назначил полномочия. На Экране 3 показано событие с ID 608, зарегистрированное Win-dows 2000, когда я назначил группе Administrators полномочия SeCreate-TokenPrivilege (Create a token object) и SeCreatePermanentPrivilege (Create permanent shared objects - создавать постоянные разделяемые объекты).

Поля User Name, Domain и Logon ID под заголовком Assigned By явно указывают, кто назначил полномочия. Но если администраторы NT назначают полномочия напрямую через User Manager, то администраторы Windows 2000 предоставляют или отзывают полномочия не прямо, а через объекты групповой политики (Group Policy Objects, GPO). В силу этих различий, а также поскольку локальная система пользователя читает Group Policy и вносит соответствующие изменения в назначенные полномочия, событие с ID 608 указывает в поле Assigned By учетную запись локального компьютера. Чтобы выяснить, каким образом администратор изменил полномочия, необходимо активизировать категорию Audit directory service для проверки изменений в объектах GPO в Active Directory (AD). Более подробная информация об аудите таких изменений приведена в статье <Заглянем в журнал безопасности Windows 2000>.

Если полномочия пользователя отменены, то в следующий раз, когда Win-dows 2000 применит групповую политику, будет зарегистрировано событие с ID 609 (отмена полномочий пользователя). Поле User Right этого события похоже на поле User Right события с ID 608. Поле Removed From указывает пользователей и группы, лишенные одного или нескольких полномочий. Поля User Name, Domain и Logon ID в разделе Removed By указывают учетную запись локального компьютера точно так же, как поля Assigned By события с ID 608. Оба события регистрируются на компьютерах, на которых был применен GPO, содержащий назначенные полномочия. Однако изменения, произведенные в объектах GPO, регистрируются на контроллере домена (DC), к которому подсоединялся администратор, редактировавший GPO.

Audit policy change позволяет отслеживать изменения в доверительных отношениях с другими доменами. Если администратор добавляет новый доверенный домен с помощью оснастки Active Directory Domains and Trusts, то Windows 2000 регистрирует два идентичных события с ID 610 (новый доверенный домен) на DC, к которому подсоединялся администратор. Поле Do-main Name события с ID 610 идентифицирует новый доверенный домен. Чтобы выяснить, кто установил доверительное отношение, нужно посмотреть на поля User Name, Domain и Lo-gon ID под заголовком Established By.

Windows 2000 также регистрирует на DC один экземпляр события с ID 620 (изменена информация о доверенном домене). Однако данное событие не содержит никакой дополнительной информации. При удалении доверенного домена Windows 2000 регистрирует два события с ID 611 (удаление доверенного домена). Данное событие содержит те же поля, что и событие с ID 610, но поля User Name, Domain и Logon ID находятся под заголовком Removed By вместо Established By.

В событиях с ID 610, ID 611 и ID 620 проявляется еще один изъян системы аудита Windows 2000: события регистрируются при удалении и добавлении как доверяющих, так и доверенных доменов. Событие говорит лишь о том, что было установлено или прекращено доверительное отношение, но не указывает, был ли домен доверенным или доверяющим.

Windows 2000 регистрирует событие с ID 612 (изменение политики аудита) всякий раз, когда применение Group Policy приводит к изменению политики аудита компьютера. Поле New Policy данного события указывает, какие категории аудита были активизированы для регистрации успешных и неудачных действий. Например, на Экране 4 показано, что активизирован аудит успешных и неудачных изменений политики. Как и в событии с ID 608, в полях User Name, Domain и Logon ID в подразделе Changed By события с ID 612 не указано, какой администратор изменил политику аудита, так как Windows 2000 не обнаруживает изменения до тех пор, пока групповая политика не применена. Тем не менее событие с ID 612 полезно для поиска изменений в политике аудита.

Категорией Audit policy change можно воспользоваться и для отслеживания некоторых других изменений политики. Событие с ID 617 свидетельствует об изменении политики Kerberos, определяющей срок действия и обновление билета. Windows 2000 не ограничивается регистрацией события с ID 617 при явных изменениях политики Kerberos, а записывает событие в журнал всякий раз, когда DC применяет Group Policy. При изменении раздела Encrypted Data Recovery Agents групповой политики, в котором определены лица, уполномоченные восстанавливать файлы, зашифрованные с помощью EFS (Encrypting File System), Windows 2000 регистрирует событие с ID 618 (изменение политики восстановления данных). И опять, в полях User Name, Domain и Logon ID в подразделе Changed By нет информации о том, кто в действительности изменил политику; в них просто указана учетная запись локального компьютера.

Администратор может контролировать изменения политики IP Security (IPSec) компьютера, однако существуют разночтения относительно событий, обеспечивающих эту возможность. В документации Windows 2000 (по адресу: http://www.microsoft.com/technet/security/monito.asp) приводится список событий аудита IPSec - с ID 615 и ID 616 - входящих в категорию Audit policy change, но Event Viewer относит эти события к Detail tracking (категория Audit process tracking). Кроме того, Windows 2000 регистрирует подобные события, даже если категории Audit policy change и Audit process tracking не активизированы. В любом случае, при назначении политики IPSec через GPO в AD или через локальный GPO компьютера, Win-dows 2000 заносит в журнал событие с ID 615. Если используется GPO в AD, то в описании события с ID 615 указывается: IPSec PolicyAgent Service: Using the Active Local Registry policy, as (i) there's no Active Directory Storage policy or (ii) the Active Directory Storage policy couldn't be applied successfully and there's no Cached policy (используется локальная политика Active Local Re-gistry, так как (i) не существует политики Active Directory или (ii) политика Active Directory не может успешно применяться и нет сохраненной политики). Если при применении политики Windows 2000 сталкивается с трудностями, она регистрирует событие с ID 616 (агент политики IPSec встретил потенциально серьезную проблему).

Контроль изменений в групповой политике - важное условие сохранения целостности сети. Но необходимо быть внимательным и при контроле за физическим доступом к системам по сети. Windows 2000 поможет решить эту задачу.

Audit system events

Категория Audit system events содержит несколько полезных событий. Всякий раз при начальной загрузке Windows 2000 регистрирует событие с ID 512 (начало работы Windows NT). С помощью данного события можно обнаружить несанкционированные попытки перезагрузки системы, которые потенциально опасны, так как Windows 2000 уязвима, когда работу завершают пользователи, имеющие физический доступ к машине.

В документации Windows 2000 указывается, что операционная система регистрирует событие с ID 513 каждый раз при завершении работы, но это утверждение неверно. Чтобы определить, как долго система была в нерабочем состоянии, нужно сравнить время и дату события с ID 512 и предыдущего события, зарегистрированного Windows 2000.

Windows 2000 отмечает в журнале событие с ID 517 (журнал аудита очищен) всегда, когда кто-нибудь очищает журнал безопасности. Windows 2000 записывает это событие в новом журнале. Событие с ID 517 может указать на взломщика, который пытался замести следы.

В процессе начальной загрузки Win-dows 2000 регистрирует и несколько других событий. Операционная система фиксирует событие c ID 515 (доверенный процесс Logon зарегистрирован в LSA) для каждой запущенной процедуры входа в систему (процедуры входа в систему обслуживаются процессом Logon, компонентом подсистемы безопасности Windows 2000). Windows 2000 также регистрирует событие с ID 514 (пакет аутентификации, загруженный LSA) для каждого пакета аутентификации, загружаемого операционной системой (пакеты аутентификации совместимы с различными протоколами аутентификации, такими, как Kerberos, NT LAN Manager (NTLM) и Secure sockets Layer (SSL)). Операционная система записывает событие с ID 518 (SAM загрузила пакет оповещения) для каждого пакета оповещения, загруженного Windows 2000; стандартные пакеты оповещения - scecli, kdcsvc и rassfm. Пакеты оповещения - это специальные DLL, которые проектируются и устанавливаются для синхронизации паролей с другими системами или реализуют специальные правила применения паролей. Однако взломщики могут использовать пакеты оповещения для кражи паролей. В любом случае к нестандартным пакетам оповещения следует относиться с осторожностью.

Полный арсенал

Windows 2000 предоставляет впечатляющий набор функций аудита, усовершенствованных по сравнению с возможностями Windows NT. Однако в системе аудита Windows 2000 имеются и значительные недостатки, а применение политик Group Policy не всегда позволяет идентифицировать пользователя, изменившего политику, так как администраторы более не изменяют политики напрямую. Хочется верить, что в дальнейшем разработчики Microsoft устранят подобные недостатки и обеспечат более полный аудит изменений политик, вносимых через GPO.

Автор: Рэнди Франклин Смит