Last Updated on December 26, 2024 by Satyendra
One of the best ways to know what is happening within your organizational environment is through auditing. Windows Server 2012 Active Directory provides the option to monitor operations performed on the domain and log such information in the Event Viewer. It can log both the successful and failure operations, depending on the audit configuration. As an administrator, you can audit these logs to understand what action was performed by whom and when.
Audit Account Management provides the option to audit operations (Create, modify, delete etc.) on accounts like user, groups, computer etc. Directory Service access is to monitor and audit user accessing active directory object. Auditing Account Management and Directory service access can be configured easily using Group policy object (GPO). Windows Server 2012 GPO provides two options: Traditional Audit policy and Advanced audit policy.
Traditional Audit policy is available at ‘Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Audit Policy’ and it only provides the option to audit success and failure operations. Once enabled – refer figure1, it audits every account management and directory option performed on the domain and traditional audit policy does not provide much granular option to audit only specific operation.
Figure 1. Traditional Audit policy
Advanced audit policy provides more granular option and allows us to enable only specific type of operation to be audited. They are available at Computer ‘Configuration\Policies\Windows Settings\Security Settings\Advanced Audit Policies’. Advanced Account management audit policy and advanced Directory service access allows administrators to enable auditing for specific operation to log both success and failure status.
Advanced Account Management audit policy
Audit Application Group Management: It allows auditing events generated by changes made to application groups such as when an application group is created, changed, deleted or member is added or removed from group.
Audit Computer Account Management: It allows auditing events generated by changes made to computer accounts such as when a computer account is created, changed, or deleted.
Audit distribution Group management: It allows auditing events generated by changes made to distribution groups such as when a distribution group is created, changed, deleted or member is added/ removed from a distribution group or distribution group type is changed.
Audit Security Group Management: It allows auditing events generated by changes made to security groups such as when a security group is created, changed, deleted or a member is added/ removed from a distribution group or the distribution group type is changed.
Audit User Account Management: It allows to audit changes to user accounts when
- User account is created, changed, deleted; renamed, disabled, enabled, locked out
- Unlocked or user account’s password is set or
- Changed or security identifier (SID) is added to the SID History of a user account
- Directory Services Restore Mode password is configured or
- Permissions on administrative user accounts are changed or
- Credential Manager Credentials are backed up or restored.
Audit other Account management Events: It allows auditing events like
- The password hash of a user account was accessed. This typically happens during an Active Directory Management Tool password migration.
- The Password Policy Checking API was called. Calls to this function can be part of an attack when a malicious application tests the policy to reduce the number of attempts during a password dictionary attack.
- Changes to the Default Domain Group Policy under the following Group Policy paths:
- Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy
- Computer Configuration\Windows Settings\Security Settings\Account Policies\Account Lockout Policy
Figure 2. Advanced Audit Policies Account Management
Advanced DS Access
Audit Detailed Directory Service Replication: It allows auditing events generated by detailed Active Directory Domain Services (AD DS) replication between domain controllers.
Audit Directory Service Access: It allows auditing events generated when an Active Directory Domain Services (AD DS) object is accessed which provide the same functionality as the traditional directory service access. Audit is only generated for objects that have system access control lists (SACL) specified, and only if the type of access requested (such as Write, Read, or Modify) and the account making the request match the settings in the SACL.
Active Directory Domain Services Object Changes: It allows auditing events generated by changes to objects in Active Directory Domain Services (AD DS). Events are logged when an object is created, deleted, modified, moved, or undeleted.
Audit Directory Service Replication: It allows auditing replication between two Active Directory Domain Services (AD DS) domain controllers.
Figure 3. Advanced DS Access policy
Auditing plays a major role in securing the IT environment but enabling all the audits consume resources and can overwrite the audit logs quite soon. Make sure to configure bigger event logs size and enable only those audit logs which are necessary as per the organization’s requirement, since it consumes considerable amount of resources.
You can also try Lepide Active Directory Auditor for auditing all Active Directory changes.
- Active DirectoryAuditingWindows Server
Любой администратор Active Directory рано или поздно сталкивается с необходимостью аудита изменения в Active Directory, и этот вопрос может встать тем острее, чем больше и сложнее структура Active Directory и чем больше список лиц, кому делегированы права управления в том или ином сайте или контейнере AD. В сферу интересов администратора (или специалиста по ИБ) могут попасть такие вопросы как:
- кто создал/ удалил пользователя или группу AD
- кто включил / заблокировал пользователя
- с какого адреса был изменен / сброшен пароль пользователя домена
- кто создал / отредактировал групповую политику и т.д.
В ОС семейства Windows существуют встроенные средства аудита изменений в различных объектах, которые, как и многие другие параметры Windows, имеют возможности управления с помощью групповых политики.
Разберем на конкретном примере методику включения аудит изменений параметров пользователей и членства в группах Active Directory (согласно данной методики можно включить отслеживание и других категорий событий).
Содержание:
- Расширенные политики аудита Windows
- Настройка аудита изменений учетных записей и групп Active Directory
- Основные недостатки встроенной системы аудита Windows
Расширенные политики аудита Windows
Создадим новый объект GPO (групповую политику) с именем «Audit Changes in AD». Перейдите в раздел редактирования и разверните ветку Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Configuration. В данной ветке групповых политик находятся расширенные политики аудита, который можно активировать в ОС семейства Windows для отслеживания различных событий. В Windows 7 и Windows Server 2008 R2 количество событий, для которых можно осуществлять аудит увеличено до 53. Эти 53 политики аудита (т.н. гранулярные политики аудита) находятся в ветке Security Settings\Advanced Audit Policy Configuration сгруппированы в 10 категориях:
- Account Logon – аудит проверки учетных данных, службы проверки подлинности Kerberos, операций с билетами Kerberos и других события входа
- Account Management – отслеживание изменений в учетных записей пользователей и компьютеров, а также информации о группах AD и членстве в них
- Detailed Tracking – аудит активности индивидуальных приложений (RPC, DPAPI)
- DS Access – расширенный аудит изменений в объектах службы Active Directory Domain Services (AD DS)
- Logon/Logoff – аудит интерактивных и сетевых попыток входа на компьютеры и сервера домена, а также блокировок учетных записей
- Object Access – аудит доступа к различным объектам (ядру, файловой системе и общим папкам, реестру, службам сертификации и т.д.)
- Policy Change – аудит изменений в групповых политиках
- Privilege Use — аудит прав доступа к различным категориям данных
- System – изменения в настройках компьютеров, потенциально критичных с точки зрения безопасности
- Global Object AccessAuditing – позволяют администратору создать собственное списки ACL, отслеживающие изменения в реестре и файловой системой на всех интересующих объектах
Естественно, чтобы не перегружать систему лишней работой, а журналы ненужной информацией, рекомендуется использовать лишь минимально необходимый набор аудирумых параметров.
Настройка аудита изменений учетных записей и групп Active Directory
В данном случае, нас интересует категория Account Management, позволяющая включить аудит изменений в группах Audit Security Group Management) и аудит учетных записей пользователей (политика Audit User Account Management). Активируем данные политики аудита, задав отслеживание только успешных изменений (Success).
Осталось прилинковать данную политику к контейнеру, содержащему учетные записи контроллеров домена (по умолчанию это OU Domain Controllers) и применить эту политику (выждав 90 минут или выполнив команду gpupdate /force).
После применения данной политики информация обо всех изменения в учетных записях пользователей и членстве в группах будет фиксировать на контроллерах домена в журнале Security. На скриншоте ниже отображено событие, фиксирующие момент удаления пользователя из групп Active Directory (в событии можно увидеть кто, когда и кого удалил из группы).
По умолчанию журнал отображает все события безопасности, попавшие в лог. Чтобы упростить поиск нужного события, журнал можно отфильтровать по конкретному Event ID. В том случае, если нас интересуюсь только события, например, качающиеся сброса пароля пользователя в домене, необходимо включить фильтр по id 4724.
Ниже приведен список некоторых ID событий, которые могут понадобиться для поиска и фильтрации событий в журнале Security практике:
ID событий, в контексте изменений в группах AD:
4727 : A security-enabled global group was created.
4728 : A member was added to a security-enabled global group.
4729 : A member was removed from a security-enabled global group.
4730 : A security-enabled global group was deleted.
4731 : A security-enabled local group was created.
4732 : A member was added to a security-enabled local group.
4733 : A member was removed from a security-enabled local group.
4734 : A security-enabled local group was deleted.
4735 : A security-enabled local group was changed.
4737 : A security-enabled global group was changed.
4754 : A security-enabled universal group was created.
4755 : A security-enabled universal group was changed.
4756 : A member was added to a security-enabled universal group.
4757 : A member was removed from a security-enabled universal group.
4758 : A security-enabled universal group was deleted.
4764 : A group’s type was changed.
ID событий, в контексте изменений в учетных записей пользователей в AD:
4720 : A user account was created.
4722 : A user account was enabled.
4723 : An attempt was made to change an account’s password.
4724 : An attempt was made to reset an account’s password.
4725 : A user account was disabled.
4726 : A user account was deleted.
4738 : A user account was changed.
4740 : A user account was locked out.
4765 : SID History was added to an account.
4766 : An attempt to add SID History to an account failed.
4767 : A user account was unlocked.
4780 : The ACL was set on accounts which are members of administrators groups.
4781 : The name of an account was changed:
4794 : An attempt was made to set the Directory Services Restore Mode.
5376 : Credential Manager credentials were backed up.
5377 : Credential Manager credentials were restored from a backup.
Основные недостатки встроенной системы аудита Windows
Однако у штатных средств просмотра и анализа логов в Windows есть определенные недостатки.
Естественно, консоль Event Viewer предоставляет лишь базовые возможности просмотра и поиска информации о тех или иных событиях в системе и не предполагает возможностей сложной обработки, группировки и агрегации информации. По сути эта задача целиком зависит от способностей и уровня подготовки системного администратора или инженера ИБ, который с помощью различных скриптов (например, powershell илл vbs) или офисных средств может разработать собственную систему импорта и поиска по журналам.
Также не стоит забывать, что с помощью встроенных средств Windows сложно объединить журналы с различных контроллеров домена (можно, конечно, воспользоваться возможностью перенаправления логов в Windows, но этот инструмент также недостаточно гибкий), поэтому поиск нужного события придется осуществлять на всех контроллерах домена (в рамках больших сетей это очень накладно).
Кроме того, при организации системы аудита изменений в AD с помощью штатных средств Windows нужно учесть, что в журнал системы пишется огромное количество событий (зачастую ненужных) и это приводит к его быстрому заполнению и перезатиранию. Чтобы иметь возможность работы с архивом событий, необходимо увеличить максимальный размер журнала и запретить перезапись, а также разработать стратегию импорта и очистки журналов.
Именно по этим причинам, для аудита изменений в AD в крупных и распределенных системах предпочтительно использовать программные комплексы сторонних разработчиков. В последнее время на слуху, например, такие продукты, как NetWrix Active Directory Change Reporter или ChangeAuditor for Active Directory.
Как настроить политики аудита Windows таким образом, чтобы охват мониторинга SOC был полноценным? Рассмотрим оптимальный список политик, а также выделим самое необходимое, отсеяв лишнее.
- Введение
- Знакомство с расширенным аудитом Windows
- Настройка политик аудита
- Усиление цифровой обороны
- Выводы
Введение
Все мы любим заворожённо читать про очередное расследование инцидента, где шаг за шагом распутывается клубок: как проник злоумышленник, какие инструменты он использовал и когда, что за процессы создавались на скомпрометированном хосте, что происходило в сети и, конечно же, кто виноват и что делать.
На практике ответы на эти вопросы находятся не всегда. Зачастую при расследовании специалисты отделов ИБ сталкиваются с тем, что аудит не настроен, логи перезаписались, отсутствует единая система хранения и анализа журналов, «перезалит» заражённый хост (популярное решение всех проблем).
Ниже мы разберём один из самых важных этапов, который нужен для того, чтобы расследование не завершилось ещё в самом начале: сбор и хранение журналов аудита. Будут рассмотрены возможности расширенного аудита ОС Windows и его настройка.
Знакомство с расширенным аудитом Windows
Речь пойдёт о настройках для систем Microsoft Windows Vista / Server 2008 и выше. Начиная с указанных операционных систем компания Microsoft сделала шаг вперёд в понимании аудита и управления им. Так появился расширенный аудит. Теперь администраторы и специалисты по информационной безопасности могут управлять аудитом на уровне не только категорий, но и подкатегорий.
Давайте подробнее остановимся на них. Откроем оснастку локальной групповой политики, используя команду «gpedit.msc» (или через «secpol.msc»). Для групповых политик всё будет аналогично, только все действия будут выполняться через «gpmc.msc».
Полный путь к настройкам аудита выглядит следующим образом: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Локальные политики / Политика аудита (Computer Configuration / Windows Settings / Security Settings / Local Policies / Audit Policy).
Рисунок 1. Политика аудита
Расширенный аудит, в свою очередь, находится здесь: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Конфигурация расширенной политики аудита (Computer Configuration / Windows Settings / Security Settings / Advanced Audit Policy Configuration).
Рисунок 2. Конфигурация расширенной политики аудита
Ниже на рисунке видно, как они коррелируют между собой.
Рисунок 3. Корреляция аудита и расширенного аудита
В общей сложности нам доступны 10 политик и 60 подкатегорий.
Таблица 1. Категории и подкатегории аудита
| Категория (Category) | Подкатегория (Subcategory) | |
| Вход учётной записи (Account Logon) | Аудит проверки учётных данных (Audit Credential Validation) | |
| Аудит службы проверки подлинности Kerberos (Audit Kerberos Authentication Service) | ||
| Аудит операций с билетами службы Kerberos (Audit Kerberos Service Ticket Operations) | ||
| Аудит других событий входа учётных записей (Audit Other Account Logon Events) | ||
| Управление учётными записями (Account Management) | Аудит управления группами приложений (Audit Application Group Management) | |
| Аудит управления учётными записями компьютеров (Audit Computer Account Management) | ||
| Аудит управления группами распространения (Audit Distribution Group Management) | ||
| Аудит других событий управления учётными записями (Audit Other Account Management Events) | ||
| Аудит управления группами безопасности (Audit Security Group Management) | ||
| Аудит управления учётными записями пользователей (Audit User Account Management) | ||
| Подробное отслеживание (Detailed Tracking) | Аудит активности DPAPI (Audit DPAPI Activity) | |
| PNP-действие аудита (Audit PNP Activity) | ||
| Аудит создания процессов (Audit Process Creation) | ||
| Аудит завершения процессов (Audit Process Termination) | ||
| Аудит событий RPC (Audit RPC Events) | ||
| Проверка изменений прав маркера (Audit Token Right Adjusted) [Windows 10 / Server 2016 и выше] | ||
| Доступ к службе каталогов DS (DS Access) | Аудит подробной репликации службы каталогов (Audit Detailed Directory Service Replication) | |
| Аудит доступа к службе каталогов (Audit Directory Service Access) | ||
| Аудит изменения службы каталогов (Audit Directory Services Changes) | ||
| Аудит репликации службы каталогов (Audit Directory Service Replication) | ||
| Вход / выход (Logon / Logoff) | Аудит блокировки учётных записей (Audit Account Lockout) | |
| Аудит заявок пользователей или устройств на доступ (Audit User / Device Claims) | ||
| Аудит расширенного режима IPsec (Audit IPsec Extended Mode) | ||
| Аудит основного режима IPsec (Audit IPsec Main Mode) | ||
| Аудит быстрого режима IPsec (Audit IPsec Quick Mode) | ||
| Аудит выхода из системы (Audit Logoff) | ||
| Аудит входа в систему (Audit Logon) | ||
| Аудит сервера политики сети (Audit Network Policy Server) | ||
| Аудит других событий входа и выхода (Audit Other Logon / Logoff Events) | ||
| Аудит специального входа (Audit Special Logon) | ||
| Доступ к объектам (Object Access) | Аудит событий, создаваемых приложениями (Audit Application Generated) | |
| Аудит служб сертификации (Audit Certification Services) | ||
| Аудит сведений об общем файловом ресурсе (Audit Detailed File Share) | ||
| Аудит общего файлового ресурса (Audit File Share) | ||
| Аудит файловой системы (Audit File System) | ||
| Аудит подключения платформы фильтрации (Audit Filtering Platform Connection) | ||
| Аудит отбрасывания пакетов платформой фильтрации (Audit Filtering Platform Packet Drop) | ||
| Аудит работы с дескрипторами (Audit Handle Manipulation) | ||
| Аудит объектов ядра (Audit Kernel Object) | ||
| Аудит других событий доступа к объектам (Audit Other Object Access Events) | ||
| Аудит реестра (Audit Registry) | ||
| Аудит съёмного носителя (Audit Removable Storage) | ||
| Аудит диспетчера учётных записей безопасности (Audit SAM) | ||
| Аудит сверки с централизованной политикой доступа (Audit Central Access Policy Staging) | ||
| Изменение политики (Policy Change) | Аудит изменения политики аудита (Audit Policy Change) | |
| Аудит изменения политики проверки подлинности (Audit Authentication Policy Change) | ||
| Аудит изменения политики авторизации (Audit Authorization Policy Change) | ||
| Аудит изменения политики платформы фильтрации (Audit Filtering Platform Policy Change) | ||
| Аудит изменения политики на уровне правил MPSSVC (Audit MPSSVC Rule-Level Policy Change) | ||
| Аудит других событий изменения политики (Audit Other Policy Change Events) | ||
| Использование привилегий (Privilege Use) | Аудит использования привилегий, не затрагивающих конфиденциальные данные (Audit Non Sensitive Privilege Use) | |
| Аудит других событий использования привилегий (Audit Other Privilege Use Events) | ||
| Аудит использования привилегий, затрагивающих конфиденциальные данные (Audit Sensitive Privilege Use) | ||
| Система (System) | Аудит драйвера IPsec (Audit IPsec Driver) | |
| Аудит других системных событий (Audit Other System Events) | ||
| Аудит изменения состояния безопасности (Audit Security State Change) | ||
| Аудит расширения системы безопасности (Audit Security System Extension) | ||
| Аудит целостности системы (Audit System Integrity) | ||
| Аудит доступа к глобальным объектам (Global Object Access Auditing) | Файловая система (File system) | |
| Реестр (Registry) |
Теперь вместо включения аудита «Доступ к объектам» мы можем очень тонко настроить его по подкатегориям. Например, мы не будем включать аудит событий «платформы фильтрации Windows», потому что он генерирует крайне большое количество событий (всё сетевое взаимодействие хоста), которые к тому же лучше отслеживать на специализированном оборудовании, таком как межсетевые экраны, маршрутизаторы, прокси- и DNS-серверы.
Включим аудит файловой системы, реестра, съёмного носителя и других событий доступа к объектам, а всё остальное оставим в выключенном состоянии (параметр «Не настроено»).
Рисунок 4. Пример настройки аудита доступа к объектам через подкатегории
События аудита могут иметь значение «Успех и отказ», изображённое на рис. 4, или поддерживать только одно из двух состояний. Например, аудит создания процессов (Event ID 4688: A new process has been created) может быть только «успешным» (рис. 5).
Рисунок 5. Аудит создания процессов регистрирует успешные события
Если вы не знаете, нужна ли вам та или иная политика аудита, то ознакомиться с их описанием тоже очень легко. Оно есть на вкладке «Пояснение» соответствующей политики.
Рисунок 6. Вкладка с описанием политики
Для некоторых политик аудита дополнительно нужно настраивать системные списки управления доступом (SACL). Это в первую очередь касается файлового аудита и аудита реестра (альтернатива — использовать весьма специфичную политику «Аудит доступа к глобальным объектам»).
Например, чтобы отслеживать изменения в файле «hosts», откроем его свойства и перейдём в настройки аудита: «Безопасность» -> «Дополнительно» -> «Аудит». Добавим субъект аудита: выбираем группу «Все». Тип аудита — «Успех». Ставим галочки напротив записи данных, удаления, смены разрешений и смены владельца.
Рисунок 7. Настройка SACL
Если в вашей компании уже существуют различные групповые политики с настройками аудита, но вы хотите начать использовать расширенный аудит и подкатегории, то для этого случая Microsoft учла и ввела новую политику, которая называется «Аудит: принудительно переопределяет параметры категории политики аудита параметрами подкатегории политики аудита (Windows Vista или следующие версии)» (Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings). По умолчанию она включена. Проверить состояние политики можно здесь: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Локальные политики / Параметры безопасности (Computer Configuration / Windows Settings / Security Settings / Local Policies / Security Options).
Рисунок 8. Принудительное переопределение параметров политики аудита
Дополнительно вы можете управлять политиками аудита через инструмент командной строки «auditpol.exe».
Рисунок 9. Использование инструмента auditpol
Настройка политик аудита
Очень часто можно услышать совет: «давайте включим все политики». Это, конечно, — «путь джедая», но, как показывает практика, не все джедаи добрались до финала.
Для большинства сценариев мониторинга нет острой необходимости включать всё. Это излишне. Включая все политики, вы можете получить гигантский поток событий, в котором очень легко «утонуть». В большой инфраструктуре с несколькими тысячами Windows-хостов поток событий может исчисляться десятками тысяч EPS (событий в секунду). Это порождает другую, не менее сложную задачу: как этим управлять, где это хранить, как обрабатывать.
Предлагаем рассмотреть оптимальный список политик, который может вам понадобиться. Также стоит обратить внимание на то, что фактически настроек две (и, соответственно, существуют две различные GPO). Первая — исключительно для контроллеров домена, так как часть событий (например, ID 4768: A Kerberos authentication ticket (TGT) was requested) фиксируется исключительно на них. Вторая — для рядовых серверов и АРМ пользователей.
Таблица 2. Рекомендуемые настройки аудита Windows
| Категория | Подкатегория | Включить | Хост (DC, сервер, АРМ) | Категория (успех / отказ) |
| Account Logon | Audit Credential Validation | + | DC, сервер, АРМ | Успех и отказ |
| Audit Kerberos Authentication Service | + | DC | Успех и отказ | |
| Audit Kerberos Service Ticket Operations | + | DC | Успех и отказ | |
| Audit Other Account Logon Events | — | |||
| Account Management | Audit Application Group Management | + | DC | Успех и отказ |
| Audit Computer Account Management | + | DC | Успех | |
| Audit Distribution Group Management | + | DC | Успех | |
| Audit Other Account Management Events | + | DC, сервер, АРМ | Успех | |
| Audit Security Group Management | + | DC, сервер, АРМ | Успех | |
| Audit User Account Management | + | DC, сервер, АРМ | Успех и отказ | |
| Detailed Tracking | Audit DPAPI Activity | + | DC, сервер, АРМ | Успех и отказ |
| Audit PNP Activity | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Process Creation | + | DC, сервер, АРМ | Успех | |
| Audit Process Termination | — | |||
| Audit RPC Events | — | |||
| Audit Token Right Adjusted | — | |||
| DS Access | Audit Detailed Directory Service Replication | + | DC | Успех и отказ |
| Audit Directory Service Access | + | DC | Успех и отказ | |
| Audit Directory Services Changes | + | DC | Успех и отказ | |
| Audit Directory Service Replication | + | DC | Успех и отказ | |
| Logon/Logoff | Audit Account Lockout | + | DC, сервер, АРМ | Отказ |
| Audit User / Device Claims | — | |||
| Audit IPsec Extended Mode | — | |||
| Audit IPsec Main Mode | — | |||
| Audit IPsec Quick Mode | — | |||
| Audit Logoff | + | DC, сервер, АРМ | Успех | |
| Audit Logon | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Network Policy Server | — | |||
| Audit Other Logon / Logoff Events | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Special Logon | + | DC, сервер, АРМ | Успех | |
| Object Access | Audit Application Generated | — | ||
| Audit Certification Services | — | |||
| Audit Detailed File Share | — | |||
| Audit File Share | — | |||
| Audit File System | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Filtering Platform Connection | — | |||
| Audit Filtering Platform Packet Drop | — | |||
| Audit Handle Manipulation | — | |||
| Audit Kernel Object | — | |||
| Audit Other Object Access Events | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Registry | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Removable Storage | + | DC, сервер, АРМ | Успех и отказ | |
| Audit SAM | — | |||
| Audit Central Access Policy Staging | — | |||
| Policy Change | Audit Policy Change | + | DC, сервер, АРМ | Успех |
| Audit Authentication Policy Change | + | DC, сервер, АРМ | Успех | |
| Audit Authorization Policy Change | + | DC, сервер, АРМ | Успех | |
| Audit Filtering Platform Policy Change | — | |||
| Audit MPSSVC Rule-Level Policy Change | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Other Policy Change Events | — | |||
| Privilege Use | Audit Non Sensitive Privilege Use | + | DC, сервер, АРМ | Успех и отказ |
| Audit Other Privilege Use Events | — | |||
| Audit Sensitive Privilege Use | + | DC, сервер, АРМ | Успех и отказ | |
| System | Audit IPsec Driver | — | ||
| Audit Other System Events | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Security State Change | + | DC, сервер, АРМ | Успех | |
| Audit Security System Extension | + | DC, сервер, АРМ | Успех | |
| Audit System Integrity | — | |||
| Global Object Access Auditing | File system | — | ||
| Registry | — |
После включения описанных политик у вас будут все необходимые события для мониторинга и расследования инцидентов.
Усиление цифровой обороны
Для максимальной отдачи необходимо выполнить ещё одну настройку — включить логирование «командной строки процесса». Тогда на рабочих станциях и серверах, к которым применяется этот параметр политики, сведения из командной строки будут заноситься в журнал событий «Безопасность» (Security) с ID 4688.
Рисунок 10. Журналирование командной строки процесса
Требования к версии ОС: не ниже Windows Server 2012 R2, Windows 8.1. Данная функциональность также доступна и на ОС Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012 после установки обновления KB 3004375.
Путь к политике: Конфигурация компьютера / Административные шаблоны / Система / Аудит создания процессов (Computer Configuration / Administrative Templates / System / Audit Process Creation). Имя: «Включать командную строку в события создания процессов» (Include command line in process creation events).
Рисунок 11. Путь к аудиту создания процессов
Включаем политику, выставив соответствующее значение, и нажимаем «Применить» (Apply).
Рисунок 12. Настройка «Включать командную строку в события создания процессов»
После включения этой политики в журнале событий «Безопасность» (Security) в событиях с кодом 4688 появится дополнительное значение «Командная строка процесса» (Process Command Line), где будет отображаться тело исполняемой команды.
В примере ниже демонстрируется, как это поможет заглянуть чуть глубже. На первый взгляд в событии происходит запуск легитимного процесса «opera_autoupdate.exe», но вот строка «Process Command Line» больше похожа на запуск утилиты «mimikatz». Без активированной политики «Включать командную строку в события создания процессов» мы этого не зафиксируем.
Рисунок 13. Детектирование mimikatz
Укрепим нашу оборону и полным журналированием работы самого мощного инструмента ОС Windows — PowerShell. Для этого необходима версия PowerShell 5.0 или выше.
PowerShell 5.0 / 5.1 предустановлен в Windows 10, Windows Server 2016 и Windows Server 2019. Для остальных операционных систем необходимо обновить модуль Windows Management Framework.
Список поддерживаемых ОС:
- Windows Server 2012 R2
- Windows Server 2012
- Windows Server 2008 R2 SP1
- Windows 8.1
- Windows 8
- Windows 7 SP1
Скачайте с сайта Microsoft соответствующую версию, выполните установку и перезагрузку хоста. Также обязательным требованием является наличие Microsoft .NET Framework 4.5 или выше.
Включим регистрацию блоков сценариев PowerShell через соответствующую политику. Она находится по следующему пути: Административные шаблоны / Компоненты Windows / Windows PowerShell (Administrative Templates / Windows Components / Windows PowerShell). Имя: «Включить регистрацию блоков сценариев PowerShell» (Turn on PowerShell Script Block Logging)
Рисунок 14. Путь к аудиту Windows PowerShell
Включаем политику и нажимаем «Применить» (Apply). При этом устанавливать галочку напротив поля «Регистрация начала или остановки вызова блоков сценариев» (Log script block invocation start / stop events) не нужно. Данная функция увеличивает количество регистрируемых событий, которые не несут полезной информации.
Рисунок 15. Включить регистрацию блоков сценариев PowerShell
После включения этой политики PowerShell будет регистрировать в журнале событий трассировки Microsoft-Windows-PowerShell/Operational с кодом события 4104 все блоки сценариев, в том числе — путь, тело скрипта и все используемые командлеты.
Рисунок 16. Пример регистрируемого события 4104
Хорошей практикой является увеличение размера самих журналов, даже если вы используете SIEM или сервер сборщика событий (Windows Event Collector). Например, журнал «Безопасность» (Security) по умолчанию имеет размер 20 МБ. При настроенном аудите на типичном АРМ этого объёма хватит на журналирование нескольких дней, на сервере — нескольких часов, а на контроллере домена 20 МБ не хватит ни на что.
Рекомендуем для всех основных журналов следующие объёмы:
- журнал «Установка» (Setup) — не менее 10 МБ,
- журнал «Система» (System) — не менее 50 МБ,
- журнал «Приложение» (Application) — не менее 50 МБ,
- журнал «Безопасность» (Security) — не менее 200 МБ (для контроллера домена — не менее 500 МБ).
При этом оставляем функцию перезаписи старых событий (по умолчанию она активирована).
Рисунок 17. Настройка хранения журналов аудита
Выводы
Настройка необходимых для мониторинга политик аудита, локальное долговременное хранение журналов, протоколирование запуска процессов и команд PowerShell позволит не упустить важные события безопасности и тщательно расследовать инциденты. Это — один из ключевых этапов в построении процессов непрерывного мониторинга, снижения рисков ИБ и повышения уровня защищённости.
В дальнейшем важно будет обеспечить централизованный сбор и хранение журналов в SIEM-системе, настройку корреляционных правил, киберразведку (Threat Intelligence), проведение активных испытаний безопасности в формате Red / Blue Team.
С помощью аудита событий безопасности администратор может получать достоверную информацию обо всех событиях в системе, контролировать действия пользователей, и использовать информацию для выявления уязвимых мест в системе безопасности сервера или AD. В Windows такие события записываются в журнал Security операционной системы. В этой статье мы покажем, как настраивать политики аудита безопасности в Windows на примере настройки аудит доступа к файлам и папкам.
Для настройки политик аудита в Windows используется консоль настройки групповых политик. Если вы настраиваете политики для компьютеров/серверов домена, используйте Group Policy Management Console (gpmc.msc). При настройке политики аудита на отдельном сервере можно использовать консоль Local Group Policy Editor (gpedit.msc).
В консоли GPO есть две секции, в которых находятся политики аудита базовая и расширенная.
Базовая политика аудита находится в разделе Computer Configuration –> Windows Settings -> Security Settings -> Local Policies -> Audit Policy. В ней доступны следующие категории событий:
- Audit account logon events
- Audit account management
- Audit directory service access
- Audit logon events
- Audit object access
- Audit policy change
- Audit privilege use
- Audit process tracking
- Audit system events
Расширенные политики аудита находятся в секции: Computer Configuration -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration. Здесь находится 60 различных политик аудита, разделенные на 10 категорий:
- Account Logon
- Account Management
- Detailed Tracking
- DS Access
- Logon/Logoff
- Object Access
- Policy Change
- Privilege Use
- System
- Global Object Access Auditing
В большинстве случаев нужно использовать политики аудита из секции Advanced Audit Policy Configuration. Они позволяют настроить аудит более тонко и исключить ненужные события безопасности.
Прежде чем включать политики аудита в Windows рекомендуем увеличить максимальный размер журнала Security со 128 Mb (по-умолчанию в Windows Server)
Запустите консоль Event Viewer (eventvwr.msc), разверните Windows Logs и откройте свойства журнала Security. Увеличьте значение в поле Maximum log size (KB).
Теперь нужно настроить политику аудита доступа пользователей к файлам и папкам в сетевой папке. Перейдите в секцию Advanced Audit Policy -> Object Access. Откройте свойства подкатегории Audit File Share и Audit File System.
Включите политику: Configure the following audit events.
Укажите, какие события нужно записывать в журнал Security:
- Success – успешный доступ пользователя к объектам в сетевой папке
- Failure – события неуспешного доступа к папкам.
В нашем случае достаточно вести аудит только Success событий.
Теперь нужно назначить политику аудита к сетевой папке (создать системные списки управления доступом – SACL).
Откройте свойства сетевой папки, перейдите на вкладку Security -> Advanced -> Auditing tab -> Continue.
Нажмите кнопку Add -> Select a principal и добавьте субъекты – это пользователи или группы (локальные или из Active Directory), чьи действия нужно аудировать. Я добавил группы Domain Users или Everyone (это значит, я буду вести аудит доступа к сетевой папке для всех пользователей).
Далее в секции Permissions укажите, какие действия пользователей нужно записывать в журнал. Я выбрал события из категории Delete.
Сохраните изменения и обновите политики на компьютере с помощью команды:
gpupdate /force
Теперь, если любой пользователь удалит файл или папку в вашей сетевой папке, в журнале Security появится событие c EventID 4660 от источника Microsoft Windows security с Task Сategory File System: An object was deleted.
В событии указан пользователь, который удалил файл (Account Name).
Не рекомендуется включать много событий аудита сразу – это может вызвать повышенную нагрузку на компьютер. Кроме того, в большом количестве событий безопасности сложно искать.
Также вы можете управлять политиками аудита через утилиту командной строки auditpol.exe.
Чтобы вывести информацию о всех включенных политиках аудита, выполните:
auditpol /get /category:*
Чтобы включить определенную политику аудита, используется такой синтаксис:
auditpol /set /subcategory:"Registry" /success:enable
Для сброса политик аудита в исходное состояние, используется команда:
AuditPol /clear
WinSecWiki > Security Settings > Local Policies > Audit Policy > Account Management
The Audit account management events policy, which you can use to monitor changes to user accounts and groups, is valuable for auditiing the activity of administrators and Help Desk staff. This policy logs password resets, newly crated accounts, and changes to group memebership. On DCs, the policy logs changes to domain users, domain groups, and computer accounts. On member servers, it logs changes to local users and groups. We have not observed any failure events in this category.
The following is an exerpt from my book, The Windows Security Log Revealed:
The Account Management security log category is particularly valuable because you can use it to track maintenance of user, group, and computer objects in AD as well as to track local users and groups in member server and workstation SAMs. This category is also very easy to use because Windows uses a different even ID for each type of object and operation.
For a list of Event IDs generated by this category, see the Security Log Encyclopedia.
Bottom Line
- Windows XP, 2000 and 2003: I recommend enabling this policy for success and failure on all computers including workstations.
- Windows Server 2008 and Vista: I don’t recommend managing audit policy at this level because too much noise is generated. Use subcategories instead. See Audit Category: Account Management (Windows Server 2008 and Vista).
Child articles:
- User Account Management
- Computer Account Management
- Security Group Management
- Distribution Group Management
- Application Group Management
- Other Account Management Events
Back to top
|