Аудит входа в систему windows server 2016

При расследовании различных инцидентов администратору необходимо получить информацию кто и когда заходил на определенный компьютер Windows. Историю входов пользователя в доменной сети можно получить из журналов контроллеров домена. Но иногда проще получить информацию непосредсвенно из логов компьютера. В этой статье мы покажем, как получить и проанализировать историю входа пользователей на компьютер/сервер Windows. Такая статистика поможет вам ответить на вопрос “Как в Windows проверить кто и когда использовал этот компьютере”.

Настройка политики аудита входа пользователей в Windows

Сначала нужно включить политик аудита входа пользователей. На отдельностоящем компьютере для настройки параметров локальной групповой политики используется оснастка gpedit.msc. Если вы хотите включить политику для компьютеров в домене Active Directorty, нужно использовать редактор доменных GPO (
gpmc.msc
).

1. Запустите консоль GPMC, создайте новую GPO и назначьте ее на Organizational Units (OU) с компьютерами и / или серверами, для которых вы хотите включить политику аудита событий входа;
2. Откройте объект GPO и перейдите в раздел Computer Configuration -> Policies -> Windows Settings -> Security Settings –> Advanced Audit Policy Configuration -> Audit Policies -> Logon/Logoff;
3. Включите две политики аудита Audit Logon и Audit Logoff. Это позволит отслеживать как события входа, так и события выхода пользователей. Если вы хотите отслеживать только успешные события входа, включите в настройках политик только опцию Success;
4. Закройте редактор GPO и обновите настройки политик на клиентах.

Поиск событий входа пользователей в журнале событий Windows

После того как вы включили политики аудита входа, при каждом входе пользователя в Windows в журнале Event Viewer будет появляться запись о входе. Посмотрим, как она выглядит.

1. Откройте оснастку Event Viewer (
   eventvwr.msc
   );
2. Разверните секцию Windows Logs и выберите журнал Security;
3. Щелкните по нему правой клавишей и выберите пункт Filter Current Log;
4. В поле укажите ID события 4624 и нажмите OK;
5. В окне события останутся только события входа пользователей, системных служб с описанием
   An account was successfully logged on
   ;
6. В описании события указано имя и домен пользователя, вошедшего в систему:

   New Logon:
   Security ID: WINITPROa.khramov
   Account Name: a.khramov
   Account Domain: WINITPRO

Если полистать журнал событий, можно заметить, что в нем присутствуют не только события входа пользователей на компьютер. Здесь также будут события сетевого доступа к этому компьютеру (при открытии по сети общих файлов или печати на сетевых принтерах), запуске различных служб и заданий планировщика и т.д. Т.е. очень много лишний событий, которые не относятся ко входу локального пользователя. Чтобы выбрать только события интерактивного входа пользователя на консоль компьютера, нужно дополнительно сделать выборку по значению параметра Logon Type. В таблице ниже перечислены коды Logon Type.

При удаленном подключении к рабочему столу компьютера по RDP, в журнале событий появится записи с Logon Type 10 или 3. Подробнее об анализе RDP логов в Windows.

В соответствии с этой таблицей событие локального входа пользователя на компьютер должно содержать Logon Type: 2.

Для фильтрации события входа по содержать Logon Type лучше использовать PowerShell.

Анализ событий входа пользователей в Windows с помощью PowerShell

Допустим, наша задача получить информацию о том, какие пользователи входили на этот компьютер за последнее время. Нам интересует именно события интерактивного входа (через консоль) с
LogonType =2
. Для выбора события из журналов Event Viewer мы воспользуемся командлетом Get-WinEvent.

Следующий PowerShell скрипт выведет история входа пользователей на текущий компьютер и представит ее в виде графической таблицы Out-GridView.

$query = @'
<QueryList>
<Query Id='0' Path='Security'>
<Select Path='Security'>
*[System[EventID='4624']
and(
EventData[Data[@Name='VirtualAccount']='%%1843']
and
EventData[Data[@Name='LogonType']='2']
)
]
</Select>
</Query>
</QueryList>
'@
$properties = @(
@{n='User';e={$_.Properties[5].Value}},
@{n='Domain';e={$_.Properties[6].Value}},
@{n='TimeStamp';e={$_.TimeCreated}}
@{n='LogonType';e={$_.Properties[8].Value}}
)
Get-WinEvent -FilterXml $query | Select-Object $properties|Out-GridView

Если нужно выбрать события входа за последние несколько дней, можно добавить pipe с таким условием:

|Where-Object {$_.TimeStamp -gt '5/10/22'}

Командлет Get-WinEvent позволяет получить информацию с удаленных компьютеров. Например, чтобы получить историю входов с двух компьютеров, выполните следующий скрипт:

'msk-comp1', 'msk-comp2' |
ForEach-Object {
Get-WinEvent -ComputerName $_ -FilterXml $query | Select-Object $properties
}

Как настроить политики аудита Windows таким образом, чтобы охват мониторинга SOC был полноценным? Рассмотрим оптимальный список политик, а также выделим самое необходимое, отсеяв лишнее.

1. Введение
2. Знакомство с расширенным аудитом Windows
3. Настройка политик аудита
4. Усиление цифровой обороны
5. Выводы

Введение

Все мы любим заворожённо читать про очередное расследование инцидента, где шаг за шагом распутывается клубок: как проник злоумышленник, какие инструменты он использовал и когда, что за процессы создавались на скомпрометированном хосте, что происходило в сети и, конечно же, кто виноват и что делать.

На практике ответы на эти вопросы находятся не всегда. Зачастую при расследовании специалисты отделов ИБ сталкиваются с тем, что аудит не настроен, логи перезаписались, отсутствует единая система хранения и анализа журналов, «перезалит» заражённый хост (популярное решение всех проблем).

Ниже мы разберём один из самых важных этапов, который нужен для того, чтобы расследование не завершилось ещё в самом начале: сбор и хранение журналов аудита. Будут рассмотрены возможности расширенного аудита ОС 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. Категории и подкатегории аудита

Теперь вместо включения аудита «Доступ к объектам» мы можем очень тонко настроить его по подкатегориям. Например, мы не будем включать аудит событий «платформы фильтрации 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

После включения описанных политик у вас будут все необходимые события для мониторинга и расследования инцидентов.

Усиление цифровой обороны

Для максимальной отдачи необходимо выполнить ещё одну настройку — включить логирование «командной строки процесса». Тогда на рабочих станциях и серверах, к которым применяется этот параметр политики, сведения из командной строки будут заноситься в журнал событий «Безопасность» (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.

The ability to audit events in your environment is crucial for the discovery and investigation of security incidents. Therefore, it is important to know the best practice for configuring the Windows Server 2016/2019 audit policy.

Collecting events generated in your environment is required not only for maintaining security, but also to meet compliance standards, especially for large enterprises or public companies that need to adopt CIS or similar standards.

If malicious activity occurs, proper security logs help you to detect the activity and identify its source. Without the logs, you will most likely never know that something happened, or it will be discovered after it is too late.

For example, if you have an employee who copies sensitive corporate data to a USB stick and gives it to your competition, but the action is not logged or stopped by a data loss prevention system (DLP), it will be impossible to identify the user and prove the incident occurred. But if you have a proper event recorded, with username and filenames, it will be hard for user to deny such activity.

Security log configuration

A properly configured audit policy will generate quite a lot of events, especially on servers such as domain controllers or file servers that are frequently accessed. Audit events are written to the Windows Security log. The default maximum log size, which is 128 MB, can only store a few hours’ worth of data on a frequently used server. Be sure to configure the maximum size large enough to give you at least few days’ worth of events. Ideally, the best practice is to forward specific events to systems such as SCOM, SysLog, or other SIEM tools.

Another item to configure is the retention method. The default option, if not defined by GPO, is Overwrite events as needed. With this configuration, you can be sure that events are always recorded and the log will not run out of space. On the other hand, if you do not forward events, they will be lost once overwritten.

With the other two options, you need to make sure the log can store a specific number of days or manually take care of the clearing.

Audit policy vs advanced audit policy

Configuration of the audit policy was the only option available prior to Windows Server 2008 R2.

The capabilities of the audit policy were limited, so Microsoft introduced the advanced audit policy. The advanced audit policy enables more granularity with regard to the events that should be collected. There are 10 categories with more than 50 options to configure.

The rule of thumb here is only to configure the advanced audit policy, as configuring both can lead to unexpected events.

Let’s take a look at each category and the best practice for its configuration. The convention is:

Name of the setting: recommended value

Account logon

Audit Credential Validation: Success, Failure

Allows you to audit events generated by validation tests on user account logon credentials. For domain accounts, the event is generated on the domain controller. Causes a high volume of events.

Account management

Account management settings allow administrators to track changes and events to detect malicious, authorized, or accidental activities.

Audit Application Group Management: Success, Failure

Audit Distribution Group Management: Success, Failure

Audit Security Group Management: Success, Failure

These settings enable corresponding group management activities, such as security group creation, adding or removing users, and so forth.

Audit Computer Account Management: Success, Failure

Audit User Account Management: Success, Failure

Audit computer and user account management, such as user account creation, password reset attempts, account was disabled, and SID history changes.

Detailed tracking

Audit PNP Activity: Success

Event is recorded when a plug-and-play device (such as a USB stick) is detected by the system. Email or other notification can be sent to IT staff to alert unapproved devices usage.

Audit Process Creation: Success

Audits when a new process is created, such as a user starting Wireshark to capture network traffic.

DS access

The two settings below are valid only for domain controllers and record any access or changes to objects having a system access control list (SACL) in Active Directory.

Audit Directory Service Access: Success, Failure

Audit Directory Service Changes: Success, Failure

Event 5136 shows my modification to the Domain Admins group (Object) when my account, named leos (Attribute), was added (Operation).

Logon/Logoff

Audit Account Lockout: Success, Failure

Records events for accounts that were locked due to bad password attempts.

Audit Group Membership: Success

Records the groups in which a user was a member at the time of logon. For domain accounts, the event is logged on domain controllers; for local accounts, it is logged on the local computer.

Audit Logoff: Success

Audit Logon: Success, Failure

These two options report user logon or logoff from the system. An event is logged on a local computer if the access is interactive or on a remote computer if the access is over a network (access to a shared folder).

Audit Other Logon/Logoff Events: Success, Failure

Audits events such as Remote Desktop session reconnect, workstation lock and unlock, etc.

Audit Special Logon: Success

Records logon events with administrator-equivalent privileges.

Object access

Audit Other Object Access Events: Success, Failure

Audits events related to COM+ objects and Task Scheduler jobs (job created, updated, or deleted).

Audit Removable Storage: Success, Failure

Audits access to removable drives, as mentioned in the example at the beginning of this post (data being copied to USB and given to the competition).

Policy change

Audit Policy Change: Success, Failure

Reports changes to system audit policy changes, such as enabling DS access auditing.

Audit Authentication Policy Change: Success

Audits changes such as domain trust creation, modification, or removal, as well as granting user rights to allow logon locally, via Remote Desktop Services or as a batch job.

Audit Authorization Policy Change: Success

Audits changes not covered in the Authentication Policy Change, mentioned above, such as changes to the Encrypted File System policy or SeCreateTokenPrivilege (create a token object).

Privilege use

Audit Sensitive Privilege Use: Success, Failure

Creates a log event when a user (or a service account) uses any of the following sensitive privileges:

• Acts as part of the operating system
• Backs up files and directories
• Creates a token object
• Debugs programs
• Enables computer and user accounts to be trusted for delegation
• Generates security audits
• Impersonates a client after authentication
• Loads and unloads device drivers
• Manages auditing and security log
• Modifies firmware environment values
• Replaces a process-level token
• Restores files and directories
• Takes ownership of files or other objects

Note that this kind of configuration will create a high volume of events. However, it might be really useful to discover malicious activity.

System

Audit IPsec Driver: Success, Failure

Reports multiple events generated by IPsec driver activity, such as integrity checks, incorrect security parameter index (SPI), and so on.

Audit Other System Events: Success, Failure

Captures all kinds of events related to the Windows Firewall service.

Audit Security State Change: Success

Captures events related to the system security state, such as Windows startup, shutdown, or system time change.

Audit Security System Extension: Success, Failure

Includes events such as service installation in the system or loading of a security package by the Local Security Authority.

Audit System Integrity: Success, Failure

Captures events related to system integrity, such as an invalid hash value of a system image file. This might indicate corruption or an unauthorized change to the file.

Subscribe to 4sysops newsletter!

Conclusion

Over the years, Microsoft has integrated really powerful auditing capabilities into Windows Server systems. As you can see, it is possible to audit pretty much everything. Please be aware that, as always with security, you need to find a working balance for your environment. If you configure the audit policy as mentioned in this article, but your security log maximum size is only 256 MB with no event forwarding, you will find yourself just a couple of hours of logs, which is pretty much useless.

Уважаемые друзья, в предыдущих публикациях мы говорили об основах информационной безопасности, законодательстве по защите персональных данных и критической информационной инфраструктуры, безопасности в кредитно-финансовой сфере, а также провели анализ основных стандартов по управлению рисками информационной безопасности и обсудили системы класса IRP, предназначенные для автоматизации реагирования на инциденты ИБ. Как мы знаем, при обработке инцидентов детальный анализ событий безопасности с устройств является одним из ключевых этапов. В данной публикации мы рассмотрим настройку подсистемы аудита ОС Windows, принципы анализа и централизованного сбора журналов аудита с Windows-устройств и их пересылку в SIEM-систему IBM QRadar, а также покажем, как можно с помощью штатных средств Windows и утилиты Sysmon настроить простейшую систему реагирования на инциденты ИБ. Вперед!

Для решения задачи обработки инцидентов ИБ логично рассуждать, что чем больше данных (логов, событий безопасности) мы собираем, храним и анализируем, тем проще нам будет в дальнейшем не только оперативно среагировать на инцидент, но и расследовать обстоятельства произошедших атак для поиска причин их возникновения. При этом большое количество данных для обработки имеет и очевидный минус: нас может просто «засыпать» сообщениями, алертами, уведомлениями, поэтому необходимо выбрать самые значимые с точки зрения ИБ события и настроить соответствующие политики аудита. Microsoft предлагает использовать бесплатный набор утилит и рекомендаций (Baselines) в своем наборе Microsoft Security Compliance Toolkit, в котором в том числе приведены и рекомендуемые настройки аудита для контроллеров домена, рядовых серверов и рабочих станций. Кроме рекомендаций вендора можно обратиться еще к документам CIS Microsoft Windows Server Benchmark и CIS Microsoft Windows Desktop Benchmark, в которых, в числе прочего, указаны рекомендуемые экспертами политики аудита для, соответственно, серверных и десктопных версий ОС Windows. Однако зачастую выполнение абсолютно всех рекомендаций неэффективно именно по причине потенциального появления большого количества «шумящих», малозначительных с точки зрения ИБ событий, поэтому в настоящей статье мы сначала приведем список наиболее полезных и эффективных (с нашей точки зрения) политик аудита безопасности и соответствующих типов событий безопасности ОС Windows.

Напомню, что в ОС Microsoft Windows, начиная с Microsoft Windows Server 2008 и Vista, используется достаточно продвинутая система аудита, настраиваемая при помощи конфигурирования расширенных политик аудита (Advanced Audit Policy Configuration). Не стоит забывать о том, что как только на устройствах будут включены политики расширенного аудита, по умолчанию старые «классические» политики аудита перестанут быть эффективными, хотя данное поведение может быть переопределено в групповой политике «Аудит: принудительно переопределяет параметры категории политики аудита параметрами подкатегории политики аудита (Windows Vista или следующие версии))» (Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings).

Политики аудита Windows

Пройдем последовательно по настройкам, эффективным для решения задач аудита ИБ и выработки целостной политики аудита безопасности.

Кроме описанных выше настроек, имеет смысл также контролировать появление в журнале безопасности события с EventID=1102, которое формируется сразу после очистки журнала безопасности, что может говорить о вредоносной активности. Более того, разумно будет включить в каталоге «Конфигурация компьютера — Конфигурация Windows — Параметры безопасности — Локальные политики — Параметры безопасности» политику «Сетевая безопасность: ограничения NTLM: исходящий трафик NTLM к удаленным серверам» в значение «Аудит всего». После этого EventID=8001 в журнале Microsoft-Windows-NTLM/Operational будет содержать информацию об автоматической аутентификации на веб-ресурсах с учетной записью пользователя. Следующим шагом станет allow list с перечнем веб-ресурсов, которые легитимно могут запрашивать учетные записи, а указанную политику можно будет перевести в режим блокировки. Это не позволит вредоносным ресурсам получать NTLM-хэши пользователей, которые кликнули на ссылку из фишингового письма.

Обратим внимание и на то, что подсистема журналирования Windows весьма гибка и позволяет настроить аудит произвольных папок и веток реестра — следует лишь выбрать критичные для ИТ-инфраструктуры объекты аудита и включить данные опции.

Настройка Windows Event Forwarding, интеграция с IBM QRadar

Настроив необходимые параметры аудита, перейдем к решению вопроса автоматизации сбора журналов аудита и их централизованного хранения и анализа. Штатный механизм Windows Event Forwarding, который работает из коробки с Microsoft Windows Server 2008 / Vista и старше, позволяет осуществлять централизованный сбор журналов аудита на устройстве-коллекторе (не ниже Windows Server 2008 и Vista, но все же рекомендуется использовать выделенный Windows Server 2012R2 и старше) с устройств-источников с применением функционала WinRM (Windows Remote Management, использует протокол WS-Management) и использованием т.н. «подписок» на определенные события (набор XPath-выражений, о которых мы поговорим далее, для выбора интересующих журналов и событий на источнике). События с удаленных устройств могут быть как запрошены коллектором (режим Pull/Collector initiated), так и отправлены самим источником (режим Push/Source computer initiated). Мы рекомендуем использовать последний режим, поскольку в режиме Push служба WinRM слушает входящие соединения только на коллекторе, а на клиентах-источниках WinRM не находится в режиме прослушивания и лишь периодически обращается к коллектору за инструкциями, что уменьшает поверхность потенциальной атаки на конечные устройства. По умолчанию для шифрования трафика от источников к коллектору, принадлежащих одному Windows-домену, используется Керберос-шифрование SOAP-данных, передаваемых через WinRM (режим HTTP-Kerberos-session-encrypted), при этом HTTP-заголовки и соответствующие метаданные передаются в открытом виде. Другой опцией является использование HTTPS с установкой SSL-сертификатов на приемнике и источнике, при этом они могут не принадлежать одному домену. При дальнейшем изложении будем считать, что мы работаем в одном домене и используем настройку по умолчанию.

Рассмотрев концепцию пересылки логов с Windows-устройств, перейдем непосредственно к настройке нашей связки: источник событий -> сервер-коллектор -> утилита IBM WinCollect -> SIEM-система IBM QRadar.

Для включения сервиса сбора логов следует выполнить нижеописанные шаги:

 1. На сервере-коллекторе выполнить команду winrm qc, ответить согласием на оба последующих вопроса (включение службы WinRM и прослушивание порта TCP:5985 для входящих соединений от источников). Следует учесть, что выполнение команды winrm qc одновременно включает Windows Remote Shell (WinRS) и разрешает принимать входящие соединения для удаленного управления через функционал WinRS. Отключить WinRS можно либо через политику «Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Удаленная оболочка Windows / Разрешить доступ к удаленной оболочке -> Запретить» (Computer Configuration / Administrative Templates / Windows Components / Windows Remote Shell / Allow Remote Shell Access -> Disabled), либо командой winrm set winrm/config/winrs @{AllowRemoteShellAccess=»false»}

2. На сервере-коллекторе выполнить команду wecutil qc, согласиться на включение службы «Сборщик событий Windows» (Windows Event Collector). При этом в Windows Firewall создается разрешающее правило для входящих соединений на коллектор по TCP:5985.

3. На источниках событий следует включить службу WinRM: установить «Тип запуска» в значение «Автостарт» и запустить «Службу удаленного управления Windows» (Windows Remote Management (WS-Management)).

4. Проверить состояние службы WinRM на сервере-колекторе можно командой winrm enumerate winrm/config/listener, в результате выполнения которой отобразятся настройки порта и список локальных IP-адресов, на которых прослушиваются соединения по TCP:5985. Команда winrm get winrm/config покажет подробные настройки службы WinRM. Переконфигурировать настройки можно либо непосредственно через утилиту winrm, либо через групповые политики по пути «Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Удаленное управление Windows» (Computer Configuration / Administrative Templates / Windows Components / Windows Remote Management).

5. На источниках событий требуется предоставить доступ к журналам аудита службе WinRM путем включения встроенной учетной записи NT AUTHORITYNETWORK SERVICE (SID S-1-5-20) в локальную группу BUILTINEvent Log Readers («Читатели журнала событий»). После этого необходимо перезапустить «Службу удаленного управления Windows» (WinRM) и службу «Журнал событий Windows» (EventLog).

6. Затем следует создать и применить конфигурацию групповой политики для источников, в которой будет указана конфигурация и адрес сервера-коллектора. Требуется включить политику «Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Пересылка событий / Настроить адрес сервера…» (Computer Configuration / Administrative Templates / Windows Components / Event Forwarding / Configure the server address…) и указать адрес сервера-коллектора в следующем формате:

Server=http://servername.domain.local:5985/wsman/SubscriptionManager/WEC,Refresh=60

где 60 – частота обращения (в секундах) клиентов к серверу за новыми инструкциями по пересылке журналов. После применения данной настройки на устройствах-источниках следует сделать перезапуск службы WinRM.

7. Далее создаем и применяем конфигурацию подписки на сервере-коллекторе: открываем оснастку управления журналами аудита (eventvwr.msc) и находим внизу раздел «Подписки» (Subscriptions). Нажимаем правой кнопкой мыши и выбираем «Создать подписку», задаем имя подписки. Далее выбираем опцию «Инициировано исходным компьютером» (Source Computer Initiated, это означает предпочтительный режим Push). Нажимаем на кнопку «Выбрать группы компьютеров» (Select Computer Groups), выбираем из Active Directory те устройства или их группы, которые должны будут присылать логи на коллектор. Далее, нажимаем «Выбрать события» (Select Events) и вводим XPath-запрос (пример для сбора журналов Security):

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">*</Select>
  </Query>
</QueryList>

8. В итоге, клиенты должны иметь активные сетевые соединения по TCP:5985 с сервером-коллектором. На сервере-коллекторе в eventvwr.msc в свойствах «Подписки» можно будет увидеть список клиентов-источников, а пересланные события будут находиться в разделе «Журналы Windows – Перенаправленные события» (Windows Logs – Forwarded Events) на сервере-коллекторе.

9. Далее решаем задачу пересылки собранных на сервере-коллекторе логов с источников в SIEM систему IBM QRadar. Для этого нам потребуется установить на сервере-коллекторе утилиту IBM WinCollect.

Рекомендуем использовать управляемый (Managed) режим работы WinCollect для упрощения его администрирования. Для того, чтобы отправляемые через WinCollect агрегированные события корректно обрабатывались в IBM QRadar, нам следует воспользоваться рекомендациями IBM и на сервере-коллекторе с установленной утилитой WinCollect перевести формат пересылаемых событий в RenderedText, а также сменить их локаль на EN-US командой wecutil ss SubscriptionName /cf:RenderedText /l:en-US  (где SubscriptionName — имя подписки, заданное в п.7 выше). Кроме того, необходимо обеспечить сетевую доступность между сервером-коллектором с установленным WinCollect и нодами IBM QRadar по TCP:8413 и TCP/UDP:514.

10. После установки утилиты WinCollect на сервер-коллектор, в самой SIEM-системе IBM QRadar нужно будет добавить этот сервер в список источников (тип источника Microsoft Security Event Log, в поле Target Destination в выпадающем списке лучше выбрать вариант с TCP-syslog-подключением, отметить check-box Forwarded Events).

После применения указанных настроек новые события и устройства-источники, пересылающие Windows-логи на сервер-коллектор, появятся в консоли IBM QRadar автоматически. В итоге, после внедрения SIEM-системы данные в ней и регистрацию событий информационной безопасности можно будет легко обогатить журналами аудита Windows, собранными описанным способом с различных устройств в инфраструктуре компании.

Утилита Sysmon

Кроме задействования штатного функционала подсистемы журналирования, можно воспользоваться и официальной бесплатной утилитой Sysmon из пакета Microsoft Windows Sysinternals, которая существенно расширяет и дополняет возможности мониторинга ОС. Данная утилита дает возможность проводить аудит создания файлов, ключей реестра, процессов и потоков, а также осуществлять мониторинг загрузки драйверов и библиотек, сетевых подключений, WMI-событий и именованных каналов. Из особо полезных функций отметим возможность утилиты показывать родительский процесс и командную строку процесса, отображать значение хэш-сумм при событиях создания процесса и загрузки драйверов и библиотек с указанием наличия и действительности цифровой подписи. Несложным путем можно автоматизировать сравнение полученных хэш-сумм с индикаторами компрометации (IoCs, Indicator of Compromise) из данных фидов CyberThreat Intelligence, а также использовать приложение QVTI для IBM QRadar, с помощью которого хэши запускаемых файлов автоматически проверяются через сервис VirusTotal. Еще одной приятной опцией является возможность создания XML-конфигураций, в которых можно предельно четко указать объекты контроля и настройки работы Sysmon. Одними из наиболее продвинутых и детальных вариантов XML-конфигураций, с нашей точки зрения, являются конфиги  https://github.com/ion-storm/sysmon-config и https://github.com/SwiftOnSecurity/sysmon-config .

Установка Sysmon предельно проста и также может быть легко автоматизирована:

1. Дистрибутив скачивается с https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon

Все исполняемые файлы подписаны.

2. Создается или скачивается по приведенным выше ссылкам xml-файл с конфигурацией Sysmon.

3. Установка sysmon для x64 производится командой:

C:foldersysmon64.exe -accepteula -i C:foldersysmonconfig-export.xml , где sysmonconfig-export.xml – файл конфигурации, sysmon64.exe  –  файл-установщик.

Поддерживается запуск установки из сетевой папки.

4. После установки создается журнал Microsoft-Windows-Sysmon/Operational , размер которого мы сразу рекомендуем увеличить как минимум до 100 Мб.

Перезапуск устройства не требуется, Sysmon работает в виде сервиса, его исполняемый файл находится в C:Windowssysmon64.exe . По нашим подсчетам, footprint на конечной системе даже при использовании максимально детального конфига Sysmon не превышает 5-10% ЦПУ и около 100 Мб ОЗУ.

XPath-запросы

Наконец, выполнив необходимые настройки файлов журналов Windows, перейдем непосредственно к поиску интересующей информации. Заметим, что в случае включения всех рекомендованных политик аудита ИБ сами журналы событий становятся достаточно объемными, поэтому поиск по их содержимому может быть медленным (этих недостатков лишены специализированные решения, предназначенные в том числе для быстрого поиска информации — Log Management и SIEM-системы). Отметим также, что по умолчанию не все журналы Windows отображаются к графической оснастке (eventvwr.msc), поэтому в данной оснастке следует перейти в меню «Вид» и отметить check-box  «Отобразить аналитический и отладочный журналы».

Итак, поиск по журналам аудита будем осуществлять с помощью встроенного редактора запросов XPath (XPath queries). Открыв интересующий нас журнал, например, журнал безопасности Windows (вкладка «Журналы Windows» -> «Безопасность» / Security), нажатием правой кнопки мыши на имени журнала выберем пункт «Фильтр текущего журнала». Нам откроется графический редактор поисковых запросов, при этом для наиболее продуктивной работы следует открыть вторую вкладку открывшегося окна с названием XML, отметив внизу check-box «Изменить запрос вручную». Нам будет предложено изменить XML-текст (по сути, XPath запрос) в соответствии с нашими критериями поиска.

Результат запроса будет также представляться в различных формах, но для лучшего понимания и получения детального контента в конкретном событии рекомендуем переключиться на вкладку  «Подробности», а там выбрать radio-button  «Режим XML», в котором в формате  «ключ-значение» будут представлены данные события безопасности.

Приведем несколько полезных XPath запросов с комментариями.

1. Поиск по имени учетной записи в журнале Security — возьмем для примера имя Username:

<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">*[EventData[Data[@Name='TargetUserName']='Username']]
</Select>
</Query>
</QueryList>

 2. Поиск по значению конкретного свойства события в журнале Sysmon — возьмем для примера поиск событий, в которых фигурировал целевой порт 443:

<QueryList>
  <Query Id="0" Path="Microsoft-Windows-Sysmon/Operational">
    <Select Path="Microsoft-Windows-Sysmon/Operational">*[EventData[Data[@Name='DestinationPort'] = '443']]</Select>
  </Query>
</QueryList>

3. Произведем поиск сразу по двум условиям — возьмем для примера событие входа с EventID=4624 и имя пользователя Username:

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
*[System[(EventID=4624)]] 
and 
*[EventData[Data[@Name='TargetUserName']='Username']]
</Select>
  </Query>
</QueryList>

4. Поиск по трем условиям — дополнительно укажем Logon Type = 2, что соответствует интерактивному входу в ОС:

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
*[System[(EventID=4624)]] 
and 
*[EventData[Data[@Name='TargetUserName']='Username']] 
and
*[EventData[Data[@Name='LogonType']='2']]
</Select>
  </Query>
</QueryList>

5. Рассмотрим функционал исключения из выборки данных по определенным критериям — это осуществляется указанием оператора Suppress с условиями исключения. В данном примере мы исключим из результатов поиска по фактам успешного входа (EventID=4624) все события, которые имеют отношения к системным учетным записям (SID S-1-5-18/19/20) с нерелевантным для нас типам входа (Logon Type = 4/5), а также применим функционал задания условий поиска с логическим оператором  «ИЛИ», указав не интересующие нас имя процесса входа (Advapi) и методы аутентификации (Negotiate и NTLM):

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">*[System[(EventID=4624)]]</Select>
<Suppress Path="Security">*[EventData[(Data[@Name='TargetUserSid'] and (Data='S-1-5-18' or Data='S-1-5-19' or Data='S-1-5-20') and Data[@Name='LogonType'] and (Data='4' or Data='5'))]]
or
*[EventData[(Data[@Name='LogonProcessName'] and (Data='Advapi') and Data[@Name='AuthenticationPackageName'] and (Data='Negotiate' or Data='NTLM'))]]
</Suppress>
  </Query>
</QueryList>

IRP-система штатными средствами Windows

Как мы увидели, встроенный функционал подсистемы журналирования Windows позволяет весьма гибко осуществлять поиск по зафиксированным событиям аудита ИБ, комбинируя различные условия поиска. Однако, у Windows есть еще одна интересная «фишка», которая позволяет использовать сформированные описанным выше образом правила поиска событий — мы говорим про создание задач с определенным триггером в «Планировщике заданий» Windows, что также является штатным функционалом ОС.

Как мы знаем, задачи в ОС Windows могут выполнять совершенно разные функции, от запуска диагностических и системных утилит до обновления компонент прикладного ПО. В задаче можно не только указать исполняемый файл, который будет запущен при наступлении определенных условий и триггеров, но и задать пользовательский PowerShell/VBS/Batch-скрипт, который также будет передан на обработку. В контексте применения подсистемы журналирования интерес для нас представляет функционал гибкой настройки триггеров выполнения задач. Открыв  «Планировщик заданий» (taskschd.msc), мы можем создать новую задачу, в свойствах которой на вкладке  «Триггеры» мы увидим возможность создать свой триггер. При нажатии на кнопку  «Создать» откроется новое окно, в котором в drop-down списке следует выбрать вариант  «При событии», а в открывшейся форме отображения установить radio-button  «Настраиваемое». После этих действий появится кнопка  «Создать фильтр события», нажав на которую, мы увидим знакомое меню фильтрации событий, на вкладке XML в котором мы сможем задать произвольное поисковое условие в синтаксисе XPath-запроса.

Например, если мы хотим выполнять некоторую команду или скрипт при каждом интерактивном входе в систему пользователя Username, мы можем задать в качестве триггера задачи следующее поисковое выражение, уже знакомое нам по примеру выше:

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
*[System[(EventID=4624)]] 
and 
*[EventData[Data[@Name='TargetUserName']='Username']] 
and 
*[EventData[Data[@Name='LogonType']='2']]
</Select>
  </Query>
</QueryList>

 Другой пример: оповещение администратора при подозрительном обращении к системному процессу lsass.exe, который хранит в своей памяти NTLM-хэши и Керберос-билеты пользователей Windows, что может говорить об использовании утилиты Mimikatz или аналогичных ей:

<QueryList>
  <Query Id="0" Path="Microsoft-Windows-Sysmon/Operational">
    <Select Path="Microsoft-Windows-Sysmon/Operational">
*[System[(EventID=10)]] 
and 
*[EventData[Data[@Name='TargetImage']='C:WindowsSystem32lsass.exe']] 
and 
*[EventData[(Data[@Name='GrantedAccess'] and (Data='0x1010' or Data='0x1038'))]]
</Select>
  </Query>
</QueryList>

 Таким образом, при условии работоспособности системы журналирования событий Windows можно не только детально и глубоко анализировать все произошедшее на устройстве, но и выполнять произвольные действия при появлении в журнале ОС событий, отвечающих условиям XPath-запроса, что позволяет выстроить целостную систему аудита ИБ и мониторинга событий безопасности штатными средствами ОС. Кроме того, объединив рекомендованные политики аудита информационной безопасности, утилиту Sysmon с детально проработанными конфигами, запрос данных из TI-фидов, функционал XPath-запросов, пересылку и централизацию событий с помощью Windows Event Forwarding, а также настраиваемые задачи с гибкими условиями выполнения скриптов, можно получить фактически  бесплатную (по цене лицензии на ОС) систему защиты конечных точек и реагирования на киберинциденты, используя лишь штатный функционал Windows.

Обновлено 01.12.2018

Добрый день! Уважаемые читатели и гости блога pyatilistnik.org. Если вы еще не превратились в Шерлока Холмса в вашем домене, то теперь самое время. Ежеминутно в системах происходят тысячи изменений, которые требуется отследить и запротоколировать. Чем больше размер и сложность структуры, тем выше вероятность появления ошибок в администрировании и раскрытия данных. Без постоянного анализа изменений (удачных или неудачных) нельзя построить действительно безопасную среду. Системный администратор всегда должен ответить, кто, когда и что изменил, кому делегированы права, что произошло в случае изменений (удачных или неудачных), каковы значения старых и новых параметров, кто смог или не смог зайти в систему или получить доступ к ресурсу, кто удалил данные и так далее.

Аудит изменений стал неотъемлемой частью управления IT инфраструктурой, но в организациях не всегда уделяют внимание аудиту, часто из-за технических проблем. Ведь не совсем понятно, что и как нужно отслеживать, да и документация в этом вопросе не всегда помогает. Количество событий, которые необходимо отслеживать, уже само по себе сложность, объемы данных велики, а штатные инструменты не отличаются удобством и способностью упрощать задачу отслеживания. Специалист должен самостоятельно настроить аудит, задав оптимальные параметры аудита, кроме того, на его плечи ложится анализ результатов и построение отчетов по выбранным событиям. Учитывая, что в сети запущено нескольких служб – Active Directory/GPO, Exchange Server, MS SQL Server, виртуальные машины и так далее, генерирующих очень большое количество событий, отобрать из них действительно необходимые, следуя лишь описаниям, очень тяжело.

Как результат, администраторы считают достаточными мероприятия резервного копирования, предпочитая в случае возникновения проблем просто произвести откат к старым настройкам. Решение о внедрении аудита часто принимается только после серьезных происшествий. Далее рассмотрим процесс настройки аудита Active Directory на примере Windows Server 2008 R2, все действия описанные в статье будут применимы и к более новы редакциям Windows Server.

Кто должен заниматься аудитом домена Active Directory

Всегда самым насущным вопросом, остается в чей зоне ответственности находится сбор и анализ событий безопасности, которые происходят в домене организации. Как правило в большинстве компаний России, в виду того, что они:

• Маленькие
• Не имеющие достаточного количества денег, чтобы нанимать лишний персонал
• Нет необходимости

то для них аудит Active Directory, файловых сервером, почты вообще не актуален, оно становится нужным, только тогда когда действительно в этом появится нужда в виде инцидента, который произошел и требует серьезного разбирательства. В компаниях среднего звена и высшего, уже как правило аудит событий налажен и его разбирательством занимается либо системный администратор, либо же у компании есть отдельный отдел безопасности, главой которого чаще всего пристраивают пожилого предпенсионного дядьку, которого уже выперли на пенсию из гос органов. У нас же правительство, ой как радеет, чтобы пенсионеры жили хорошо и богато.

Аудит Active Directory средствами операционной системы

В операционных системах семейства Windows Server 2008 R2 и выше, по сравнению с предшественниками, такими как Windows Server 2003 обновлены возможности подсистемы аудита, настраиваемые через политики безопасности, а количество отслеживаемых параметров увеличено на 53. В старых ОС существовала только политика Аудит доступа к службе каталогов, контролировавшая включение и отключение аудита событий службы каталогов. Теперь управлять аудитом можно на уровне категорий. Например, политики аудита Active Directory разделены на категории, в каждой из которых настраиваются специфические параметры:

• Directory Service Access (доступ к службе каталогов);
• Аудит входов в систему
• Аудит системных событий
• Отслеживание процессов
• Аудит использования привилегий
• Управление учетными записями и группами
• Directory Service Changes (изменения службы каталогов);
• Directory Service Replication (репликация службы каталогов);
• Detailed Directory Service Replication (подробная репликация службы каталогов).

При включении глобальной политики аудита Аудит доступа к службе каталогов автоматически активируются все подкатегории политики служб каталогов.
Система аудита в Windows Server 2008 R2 отслеживает все попытки создания, изменения, перемещения и восстановление объектов. В журнал записывается предыдущее и текущее значения измененного атрибута и учетная запись пользователя, выполнившего операцию. Но если при создании объектов для атрибутов использовались параметры по умолчанию, их значения в журнал не заносятся.

Включение политики аудита в домене Active Directory

Логично, что домен AD изначально был придуман, для более удобного управления его объектами по всем аспектам, и аудит информационной безопасности предприятия тут не исключение. Все настройки системный администратор будет производить на уровне всего домена или леса, через групповые политики, которые будут применяться как к компьютерам, так и к контроллерам домена. Я могу выделить из инструментов участвующих в этом, вот такие:

• глобальной политики аудита (Global Audit Policy, GAP);
• списка управления доступом (System access control list, SACL) — определяет операции, для которых будет производиться аудит;
• схемы – используется для окончательного формирования списка событий.

По умолчанию для клиентских систем аудит отключен, для серверных активна подкатегория «Доступ к службе каталогов Active Directory», остальные отключены. Для включения глобальной политики “Аудит доступа к службе каталогов” (Audit directory service access) необходимо вызвать «Редактор управления групповыми политиками» перейти в ветку Параметры безопасности/Локальные политики/Политика аудита, где активировать политику и установить контролируемые события (успех, отказ).

Так же есть дополнительный, более тонкий и избирательный режим аудита AD, его можно найти так же в политике:

В нем вы обнаружите разделы:

1. Вход учетной записи
2. Управление учетными записями
3. Подробное отслеживание
4. Доступ к службе каталогов (DS)
5. Вход/выход
6. Доступ к объектам
7. Изменение политики
8. Использование привилегий
9. Система
10. Аудит доступа к глобальным объектам

Второй вариант реализации, это использовать для настройки утилиту командной строки auditpol, получить полный список GAP с установленными параметрами. При помощи auditpol достаточно ввести команду:

Как видите, результатом команды auditpol, стало отсутствие настроек по аудиту, каких либо событий безопасности.

Активируем политику “directory service access”, через команду:

Подробные сведения о команде можно получить, запустив ее в виде auditpol /h

Чтобы не ждать, обновим политику контролера домена:

Подкатегория политики аудита Доступ к службе каталогов формирует события в журнале безопасности с кодом 4662, которые можно просмотреть при помощи консоли Просмотр событий (Event Viewer) вкладка Журналы Windows – Безопасность.

В качестве альтернативного варианта просмотра событий можно использовать командлет Get-EventLog оболочки PowerShell. Например:

Командлет Get-EventLog может принимать 14 параметров, позволяющих отфильтровать события по определенным критериям: After, AsBaseObject, AsString, Before, ComputerName, EntryType, Index, InstanceID, List, LogName, Message, Newest, Source и UserName.

Кроме этого, регистрируется ряд других событий 5136 (изменение атрибута), 5137 (создание атрибута), 5138 (отмена удаления атрибута) и 5139 (перемещение атрибута).
Для удобства отбора определенных событий в консоли Просмотр событий используют фильтры и настраиваемые представления, а также подписку, позволяющую собирать данные журналов и с других серверов.

Коллекторы событий

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

• Лично у меня для аудита Active Directory используется перенаправление всех событий с нужных мне серверов на один, так называемый сервер-коллектор, в его задачи входит агрегирование логов со всех серверов, что я настроил. Данная функциональность, так же является рядовой, у меня лично сборщик перенаправляемых логов реализован на Windows Server 2016, но это не принципиально.

• Вторая реализация, это система мониторинга Zabbix. Она полностью бесплатна, но вам придется слегка попотеть, чтобы ее должным образом настроить, но когда вы это сделаете, то получите в свое управление, очень удобный инструмент по ведению аудита в домене Active Directory. Вот пример реализации одного из тригеров, он будет выводить информацию, о событии «Вход с учётной записью выполнен успешно», ниже вы узнаете, что за это отвечает ID с номером 4624 (Более подробно читайте на https://habr.com/post/215509/)

• Еще одним замечательным решением, будет внедрение продукта Netwrix Active Directory Change Reporter. Это мега крутой комбайн для аудита безопасности информационных систем и доменной инфраструктуры Active Directory. Данный продукт разворачивается буквально за 30 минут и готов к выполнению своих задач (Более подробно вы можете почитать вот тут http://itband.ru/2011/09/audit-adds/).

Список событий аудита событий Active Directory в Windows Server 2008 R2

Ниже я постарался вам выписать самые распространенные и более используемые события, которые необходимы при аудите безопасности информационных систем, если вы хотите изучить абсолютно все доступные, то советую вам посетить портал компании Microsoft, посвященный расширенному аудиту, вот сама ссылка https://docs.microsoft.com/ru-ru/windows/security/threat-protection/auditing/event-4723

Проверка учетных данных

1. 4774 Учетная запись была сопоставлена для входа в систему.
2. 4775 Не удалось сопоставить учетную запись для входа в систему.
3. 4776 Предпринята попытка проверить учетные данные для учетной записи контроллера домена.
4. 4777 Не удается проверить учетные данные для учетной записи контроллера домена.

Управление учетной записью компьютера

1. 4741 Создана учетная запись компьютера.
2. 4742 Изменена учетная запись компьютера.
3. 4743 Удалена учетная запись компьютера.

Управление группами рассылки

1. 4744 Создана локальная группа с отключенной проверкой безопасности.
2. 4745 Изменена локальная группа с отключенной проверкой безопасности.
3. 4746 Добавлен пользователь к локальной группе с отключенной проверкой безопасности.
4. 4747 Удален пользователь из локальной группы с отключенной проверкой безопасности.
5. 4748 Удалена локальная группа с отключенной проверкой безопасности.
6. 4749 Создана глобальная группа с отключенной проверкой безопасности.
7. 4750 Изменена глобальная группа с отключенной проверкой безопасности.
8. 4751 Добавлен пользователь к глобальной группе с отключенной проверкой безопасности.
9. 4752 Удален пользователь из глобальной группы с отключенной проверкой безопасности.
10. 4753 Удалена глобальная группа с отключенной проверкой безопасности.
11. 4759 Создана универсальная группа с отключенной проверкой безопасности.
12. 4760 Изменена универсальная группа с отключенной проверкой безопасности.
13. 4761 Член добавлен к универсальной группы с отключенной проверкой безопасности.
14. 4762 Удален пользователь из универсальной группы с отключенной проверкой безопасности.

Другие события управления учетными записями

1. 4739 Изменена политика домена.
2. 4782 Хэш пароля учетной записи доступа к нему.
3. 4793 Был вызван API проверку политики паролей.

Управление группой безопасности

1. 4727 Создана глобальная группа с включенной безопасностью.
2. 4728 Добавлен пользователь к глобальной группе с включенной безопасностью.
3. 4729 Удален пользователь из глобальной группы с включенной безопасностью.
4. 4730 Удалена глобальная группа с включенной безопасностью.
5. 4731 Создана локальная группа с включенной безопасностью.
6. 4732 Добавлен пользователь в локальную группу с включенной безопасностью.
7. 4733 Удален пользователь из локальной группы с включенной безопасностью.
8. 4734 Удалена локальная группа с включенной безопасностью.
9. 4735 Изменена локальная группа с включенной безопасностью.
10. 4737 Изменена глобальная группа с включенной безопасностью.
11. 4754 Создана универсальная группа с включенной безопасностью.
12. 4755 Изменена универсальная группа с включенной безопасностью.
13. 4756 Добавлен пользователь к универсальной группе с включенной безопасностью.
14. 4757 Удален пользователь из универсальной группы с включенной безопасностью.
15. 4758 Удалена универсальная группа с включенной безопасностью.
16. 4764 Изменен тип группы.

Управление учетными записями пользователей

1. 4720 Учетная запись пользователя создана.
2. 4722 Учетная запись пользователя включена.
3. 4723 Изменен пароль учетной записи.
4. 4724 Сброс пароля пользователя.
5. 4725 Учетная запись пользователя отключена.
6. 4726 Учетная запись пользователя удалена.
7. 4738 Изменена учетная запись пользователя.
8. 4740 Учетная запись пользователя заблокирована.
9. 4765 Журнал SID был добавлен к учетной записи.
10. 4766 Не удалось добавить журнал SID учетной записи.
11. 4767 Учетная запись пользователя была разблокирована.
12. 4780 Список управления Доступом был установлен на учетные записи, которые являются членами группы администраторов.
13. 4781 Было изменено имя учетной записи.
14. 4794 Была предпринята попытка задать режим восстановления служб каталогов.
15. 5376 Диспетчер учетных данных: учетные данные были сохранены.
16. 5377 Диспетчер учетных данных: учетные данные были восстановлены из резервной копии.

Другие события

1. 1102 Очищен журнал безопасности
2. 4624 Успешный вход в систему
3. 4625 Не удачный вход в систему

В ветке Политика аудита также активируются и другие возможности (см.рис.1): аудит входа/выхода в систему, аудит управления учетными записями, доступ к объектам, изменения политик и так далее. Например, настроим аудит доступа к объектам на примере папки с общим доступом. Для этого активируем, как рассказано выше, политику Audit object access, затем выбираем папку и вызываем меню Свойства папки, в котором переходим в подпункт Безопасность и нажимаем кнопку Дополнительно. Теперь в открывшемся окне “Дополнительные параметры безопасности для ..” переходим во вкладку Аудит и нажимаем кнопку Изменить и затем Добавить и указываем учетную запись или группу, для которой будет осуществляться аудит. Далее отмечаем отслеживаемые события (выполнение, чтение, создание файлов и др.) и результат (успех или отказ). При помощи списка “Применять” указываем область применения политики аудита. Подтверждаем изменения.

Теперь все указанные операции будут отображаться в журнале безопасности.
Чтобы упростить настройку аудита при большом количестве объектов, следует активировать флажок Наследование параметров от родительского объекта. При этом в поле Унаследовано от будет показан родительский объект, от которого взяты настройки.
Больший контроль событий, записываемых в журнал, достигается применением политики детализированного аудита (Granular Audit Policy), которая настраивается в Параметры безопасности/Локальные политики/Advanced Audit Policy Configuration. Здесь 10 подпунктов:

• Вход учетной записи – аудит проверки учетных данных, службы проверки подлинности Kerberos, операции с билетами службы Kerberos, другие события входа;
• Управление учетными записями – аудит управления группами приложений, учетными записями компьютеров и пользователей, группами безопасности и распространения;
• Подробное отслеживание – событий RPC и DPAPI, создания и завершения процессов;
• Доступ к службе каталогов DS – аудит доступа, изменений, репликации и подробной репликации службы каталогов;
• Вход/выход – аудит блокировки учетных записей, входа и выхода в систему, использования IPSec, сервера политики сети;
• Доступ к объектам – аудит объектов ядра, работы с дескрипторами, событий создаваемых приложениями, служб сертификации, файловой системы, общих папок, платформой фильтрации;
• Изменение политики – изменения политики аудита, проверки подлинности, авторизации, платформы фильтрации, правил службы защиты MPSSVC и другие;
• Использование прав – аудит прав доступа к различным категориям данных;
• Система – аудит целостности системы, изменения и расширения состояния безопасности, драйвера IPSec и других событий;
• Аудит доступа к глобальным объектам – аудит файловой системы и реестра.

Активация аудита управления учетными записями пользователей позволит отслеживать: создание, изменение, удаление, блокировку, включение и прочие настройки учетных записей, в том числе пароль и разрешения. Посмотрим, как она работает на практике — выбираем подкатегорию User Account Management и активируем. Команда для auditpol выглядит так:

Система аудита в консоли Просмотр события сразу покажет событие с номером 4719 Изменение параметров аудита, в котором показаны название политики и новые значения

Чтобы создать событие, откроем консоль Active Directory – пользователи и компьютеры и изменим один из параметров любой учетной записи — например, добавим пользователя в группу безопасности. В консоли Просмотра события сразу будут сгенерировано несколько событий: события с номером 4732 и 4735, показывающие изменение состава группы безопасности, и добавление учетной записи новой группы безопасности (на рис.8 выделены фиолетовым).
Создадим новую учетную запись – система генерирует несколько событий: 4720 (создание новой учетной записи), 4724 (попытка сброса пароля учетной записи), несколько событий с кодом 4738 (изменение учетной записи) и, наконец, 4722 (включение новой учетной записи). По данным аудита администратор может отследить старое и новое значение атрибута — например, при создании учетной записи меняется значение UAC.

Недостатки штатной системы аудита

Штатные инструменты операционной системы часто предлагают лишь базовые наборы средств анализа. Официальная документация (http://technet.microsoft.com/ru-ru/library/dd772623(WS.10).aspx) очень подобно расписывает возможности самого инструмента, практически мало помогая в выборе параметров, изменения которых необходимо отслеживать. В итоге решение этой задачи целиком ложится на плечи системного администратора, который должен полностью разбираться в технических аспектах аудита, и зависит от уровня его подготовки, а значит, велика вероятность ошибки. Кроме того, на его плечи ложится анализ результата, построение разнообразных отчетов.
Для удобства выбора определенных событий интерфейс консоли Event Viewer позволяет создавать фильтры и настраиваемые представления. В качестве параметров для отбора данных можно указать: дату, журнал и источник событий, уровень (критическое, предупреждение, ошибка и т.д.), код, пользователя или компьютер и ключевые слова. В организации может быть большое количество пользователей, объединенных в группы и подразделения, для которых аудит необходимо настроить персонально, но данная возможность в интерфейсе не предусмотрена.

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

Но, опять же, реализация оповещений, в частности выбор событий, полностью лежит на администраторе.
В случае необходимости отката измененного атрибута к предыдущему значению это действие выполняется вручную – консоль лишь показывает значение параметров.

Некоторые стандарты безопасности требуют хранения данных, собранных в процессе аудита, в течение продолжительного времени (например, SOX до 7 лет). Системными средствами реализовать это можно, но очень сложно. Размер журнала безопасности (как и других) ограничен 128 Мб, и при большом количестве событий данные могут быть перезаписаны (т.е. утеряны) уже через несколько часов. Чтобы этого избежать, необходимо вызвать окно свойств журнала в Event Viewer, где увеличить размер журнала и активировать его архивацию, установив флажок в “Архивировать журнал при заполнении. Не перезаписывать события”.

Но теперь необходимо будет решить проблему поиска событий во множестве архивов. Также стоит отметить, что к недостаткам штатной системы аудита относятся ограниченные возможности мониторинга групповых политик. При том, что факт этого изменения штатными средствами можно отслеживать, не фиксируются значения измененных параметров и, таким образом, нельзя ответить на вопрос, что же именно было изменено и каким стало новое значение. В некоторых ситуациях этого достаточно, но назвать это полноценным аудитом затруднительно. С вами был Иван Семин, автор и создатель IT блога Pyatilistnik.org. Остались вопросы, пишите их в комментариях.

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

«Аудит событий входа в систему» отслеживает как локальные, так и сетевые входы. При каждом входе определяется учетная запись пользователя и время, в которое состоялся вход. Также вы сможете узнать, когда пользователь вышел из системы.

Включаем «Аудит входа в систему»

Во-первых, откройте «Редактор локальной групповой политики» – откройте меню «Пуск», в поисковую строку введите gpedit.msc и нажмите Enter.

В левой части окна проследуйте по следующему пути: Конфигурация компьютера -> Конфигурация Windows -> Параметры безопасности -> Локальные политики -> Политика аудита.

Дважды кликните по политике «Аудит событий входа в систему» в правой части окна. В диалоговом окне «Свойства» отметьте галочкой параметр «Успех» для того, чтобы позволить отслеживание успешных входов в систему. Также вы можете включить параметр «Отказ» – так вы позволите отслеживание неудачных попыток входа.

Просматриваем события входа в систему

После включения этого параметра, Windows начнет регистрировать (в журнал безопасности) все события входа в систему, в том числе имя пользователя и время. Чтобы увидеть эти события, запустите инструмент «Просмотр событий» – откройте меню «Пуск», в строку поиска введите текст «Просмотр событий» и нажмите клавишу Enter.

Далее перейдите в «Журналы Windows» и выберите категорию «Безопасность». Нас интересуют события с кодом 4624 – это события успешного входа в систему.

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

Если вы хотите, чтобы в журнале безопасности отображались исключительно события входа, нажмите на кнопку «Фильтровать текущий журнал», которая расположена в боковой панели справа и в появившемся окне отфильтруйте события как на скриншоте ниже:

Отличного Вам дня!

С помощью аудита событий безопасности администратор может получать достоверную информацию обо всех событиях в системе, контролировать действия пользователей, и использовать информацию для выявления уязвимых мест в системе безопасности сервера или 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