Дополнительные категории аудита

Такие категории аудита, как аудит использования привилегий, аудит изменения политики и аудит управления учетными записями, позволяют отслеживать действия тех, кто выполняет администрирование системы.

Анализ использования привилегий позволяет проследить, как сотрудники на деле используют свои полномочия.

Замечание: В терминологии Windows слова «привилегия» (privilege) и «полномочие» (right) имеют разные значения.

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

Когда пользователь пытается применить полномочия и пользователю разрешено использовать привилегии, то регистрируются успешные события 577 (вызов привилегированной службы) или 578 (привилегированная операция с объектом) типа success_audit (аудит успеха). Если же пользователь пытается применить полномочия и пользователю запрещено использовать привилегии, то регистрируются неудачные события 577 или 578 типа failed_audit (аудит неудач). Может регистрироваться и события с номером (ID) 576 − использование специальной привилегии, предоставленной новой учетной записи

В описании событий данной категории обычно указываются следующие поля:

- поле списка привилегий (Privileges) описания события из категории «Использования привилегий» определяет, какие полномочия были использованы (успешно или нет).

- п оле имени основного пользователя и поле имени клиента ( Primary User Name и Primary Domain Name ) определяют, кто именно воспользовался полномочием (локальный пользователь или удаленный компьютер). Имя клиента существенно только тогда, когда пользователь работает с удаленной системой через сеть. Если пользователь подключается к Windows по сети и меняет, например, системное время, поле имени основного пользователя будет содержать имя той учетной записи, под которой запущено серверное приложение (в данном случае служба Server), а поле имени клиента зафиксирует имя подключенного к системе пользователя. В журнале событий фиксируется также номер сеанса пользователя, что позволяет определить конкретный сеанс его работы.

- поле номера процесса Process ID события с ID 578 идентифицирует процесс, непосредственно вызвавший событие. Например, при просмотре журнала безопасности процесс Services от имени администратора использует полномочие SeSecurityPrivilege.

Неверное изменение системного времени может нарушить нормальную работу приложений. Чтобы менять системное время, пользователь должен обладать правом Change system time, и это можно отследить с помощью категории Audit privilege use. Затем следует отыскать событие с ID 577 (Privileged Service Called), в описании которого указывается SeSystemTimePrivilege.

Как уже говорилось, Windows контролирует одни полномочия по службам (ID 577), а другие - по объектам (ID 578): использование некоторых привилегий связано с обращением к определенным объектам (привилегированным). Так, например, привилегированная операция SeSecurityPrivilege выполняется каждый раз, когда с помощью программы EventViewer от имени администратора открывается журнал безопасности. При работе с любым привилегированным объектом записывается событие 578, которое фиксирует все использованные привилегии.

Анализ событий с учетными записями (Audit account managemen t) помогает следить за изменениями в учетных записях пользователей, группах и политиках в домене Windows, а также в локальных базах учетных записей безопасности SAM рабочих станций и автономных серверов домена. Она позволяет контролировать действия администраторов и пользователей, наделенных полномочиями операторов учетных записей при работе их с пользователями и группами (локальными и глобальными) пользователей. Windows фиксирует в журнале безопасности, какая учетная запись или группа была изменена, добавлена или удалена и кем именно.

Замечания:

1) Следует помнить, что события этой категории аудита записываются на той системе, где хранится учетная запись. Так, при создании новой учетной записи в локальной базе SAM отдельного сервера (рабочей станции) Windows записывает соответствующие события в журнал безопасности данного сервера (рабочей станции), а при изменении учетной записи пользователя домена – в журнале на контроллере PDC (первичный контроллер домена) этого домена.

2) Единственная возможность обнаружить попытку сокрытия следов атаки путем модификации (подмены, очистки) журнала безопасности на атакованном компьютере состоит в сравнении локального журнала аудита и централизованного хранилища (SecretNet ведет (хранит) на сервере SN) таких документов. Предполагается, что централизованное хранилище лучше защищено (и размещен сервер обычно не там, где рабочие станции), чем рабочие станции.

Категория аудита Audit account management отслеживает операции создания, удаления и изменения учетных записей и групп пользователей. События данной категории имеют различные ID для каждой ситуации. В Таблице ниже перечислены идентификационные номера событий и их значения. Лучше всего использовать эту категорию на контроллерах домена (DC) для отслеживания изменений в AD, но можно задействовать ее и на рабочих станциях и автономных серверах для учета изменений локальных SAM.

ID событий категории Audit account management для конкретных операций.

Здесь: локальная группа имеет права тольк в пределах конкретного компьютера

глобальная группа имеет права в домене

универсальная группа имеет права во всей системе

В первую очередь нужно отслеживать события с ID 642 (User Account Changed – Изменена учетная запись пользователя), это позволяет наблюдать за изменением статуса учетной записи пользователя или пароля. Поскольку событие с данным ID включает в себя практически все типы изменений учетной записи пользователя, детали выполненных изменений содержатся в описании события.

Событие с ID 642

Описание события с ID 642 объясняет смысл выполненных изменений, будь то сброс пароля или активизация учетной записи.

Событие с ID 624 (User Account Created – Создана учетная запись пользователя) позволяет отследить появление новой локальной учетной записи, поэтому событие с ID 624 может помочь при работе с локальными учетными записями SAM и обнаружении несанкционированных действий.

Еще одно событие управления учетной записью, которое регистрируется при создании учетной записи пользователя, – событие с ID 628 (удачная попытка изменения пароля). Если событие с ID 628 следует немедленно за созданием учетной записи пользователя (ID 624), то оно просто отражает назначение начального пароля для учетной записи. Во всех остальных случаях событие с ID 628 можно использовать для отслеживания изменений пароля. Поля Target Account Name, Target Domain и Target Account с ID идентифицируют владельца данного пароля. Поля Caller User Name и Caller Domain указывают, кто изменил пароль. С помощью Logon ID можно связать изменение пароля с соответствующим событием регистрации с ID 528 или событием с ID 540. Если имена Target Account Name и Caller User Name совпадают, то можно сделать вывод, что пользователь изменил свой собственный пароль. В противном случае событие означает, что пароль был изменен другим лицом. Отслеживая событие с ID 628, можно контролировать работу службы поддержки и сотрудников, меняющих забытые пароли.

Несколько событий с ID 627 (Неудачная попытка изменения пароля) позволяют установить факт подбора пароля.

Чтобы обнаружить случаи удаления учетных записей пользователей, надо искать события с ID 630, которые используют те же поля Target и Caller, что и событие с ID 642.

Изменение статуса учетной записи пользователя – еще одна важная операция, отслеживаемая категорией Audit account management. Если Windows блокирует учетную запись пользователя в результате неудачной попытки регистрации, в журнал заносится событие с ID 644 (учетная запись пользователя блокирована). Target Account Name и Target Account с ID указывают пользователя, чья учетная запись была блокирована. Поле Caller Machine Name позволяет определить, с какого компьютера была сделана неудачная попытка регистрации. В журнале безопасности событию с ID 644 должно предшествовать несколько событий с ID 675 и с ID 681 (события с ID 675 и с ID 681 сообщают о неудачной аутентификации: ID 675 - неудачная аутентификация Kerberos, а ID 675 - неудачная аутентификация NTLM).

Если Windows регистрирует событие с ID 644, в журнале может появиться дополнительное событие с ID 642 с описанием User account locked («учетная запись блокирована»). Когда учетная запись пользователя активизируется или блокируется, Windows регистрирует только событие с ID 642 с описанием Account enabled или Account disabled.

Наблюдение за группами и особенно за добавлением новых членов различные группы тоже очень важная задача. Для наблюдения за группами и их составом служат события с ID 631 – 641. Событие с ID 632 (Security Enabled Global Group Member Added – Пользователь добавлен в глобальную группу) и событие с ID 636 (Security Enabled Local Group Member Added – Пользователь добавлен в локальную группу) помогут идентифицировать момент появления в группах новых членов. В приведенных выше событиях (632 и 636) указываются группа, новый член, а также пользователь, выполнивший данное изменение. На рис. ниже показано событие с ID 632, из описания которого следует, что пользователь rsmith добавил учетную запись Guest в глобальную группу Domain Admins.

Событие с ID 632

Если необходимо отслеживать появление несанкционированных компьютеров, нужно использовать событие с ID 645 (Computer Account Created), с помощью которого можно зафиксировать момент добавления нового компьютера в домен.

Анализ изменений политик. Надо не забывать про Контроль изменений политики учетной записи домена (пароль, блокировка и политика Kerberos). Он необходим, так как эти политики влияют на безопасность всего домена. Их конфигурацию можно задать в любом GPO, связанном с корнем домена (в Computer Configuration, Windows Settings, Security Settings, Account). Поскольку эти параметры относятся к уровню домена, их изменение в объектах GPO, связанных с OU и узлами, не влияет на домен. Если изменить политику назначения паролей или политику Kerberos, то Windows регистрирует событие с ID 643 с описанием Domain Policy Changed: Password Policy modified («изменилась политика домена: обновление политики пароля»). Если изменить политику блокирования, то описание события с ID 643 примет вид Domain Policy Changed: Lockout Policy modified. Однако поле Caller User Name не идентифицирует администратора, изменившего политику, поскольку политика домена не изменяется напрямую; для этого требуется отредактировать GPO. При следующем обновлении групповой политики контроллер обнаруживает изменение и применяет его для локальной конфигурации в рамках своих полномочий. Поэтому, чтобы выяснить, кем были сделаны изменения в политике домена, необходимо исследовать предыдущие записи журнала и отыскать изменения, касающиеся Group Policy.

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

1) сообщается, когда были изменены назначенные привилегии (не путать с категорией «Отслеживание использования привилегий»). Когда администратор предоставляет пользователю полномочия, Windows регистрирует событие с ID 608 (пользователю назначены полномочия). В поле User Right перечислены сокращенные имена (типа SeSystemTimePrivilege) назначенных полномочий (одного или нескольких). Поле Assigned to идентифицирует пользователя или группу, которой администратор назначил полномочия. Поля User Name, Domain и Logon ID под заголовком Assigned By явно указывают, кто назначил полномочия.

2) если привилегии пользователя отменены, то в следующий раз, когда Windows применит групповую политику, будет зарегистрировано событие с ID 609 (отмена привилегий пользователя). Поле Removed From указывает пользователей и группы, лишенные одного или нескольких полномочий.

3) Windows регистрирует событие с ID 612 (изменение политики аудита) всякий раз, когда применение Group Policy приводит к изменению политики аудита компьютера. Поле New Policy данного события указывает, какие категории аудита были активизированы (или наоборот выключены) для регистрации успешных и неудачных действий.

Категория событий аудита Системные события (Audit system events) содержит несколько полезных событий. Всякий раз при начальной загрузке Windows регистрирует события:

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

- с ID 513 - завершение работы Windows

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

- c ID 515 (запуск процесса WinLogon), т.е. процедуры входа в систему (Logon).

- с ID 514 (запуск пакета аутентификации) для аутентификации пользователя при входе (пакеты аутентификации разработаны для различных протоколов аутентификации, таких, как Kerberos, NT LAN Manager (NTLM) и Secure sockets Layer (SSL).

С событиями 515 и 514 связано событие с ID 528 - успешный вход в систему.