Расширенный аудит событий windows

Как настроить политики аудита 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. Политика аудита

Картинка с сайта: www.anti-malware.ru

Расширенный аудит, в свою очередь, находится здесь: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Конфигурация расширенной политики аудита (Computer Configuration / Windows Settings / Security Settings / Advanced Audit Policy Configuration).

Рисунок 2. Конфигурация расширенной политики аудита

Картинка с сайта: www.anti-malware.ru

Ниже на рисунке видно, как они коррелируют между собой.

Рисунок 3. Корреляция аудита и расширенного аудита

Картинка с сайта: www.anti-malware.ru

В общей сложности нам доступны 10 политик и 60 подкатегорий.

Таблица 1. Категории и подкатегории аудита

Теперь вместо включения аудита «Доступ к объектам» мы можем очень тонко настроить его по подкатегориям. Например, мы не будем включать аудит событий «платформы фильтрации Windows», потому что он генерирует крайне большое количество событий (всё сетевое взаимодействие хоста), которые к тому же лучше отслеживать на специализированном оборудовании, таком как межсетевые экраны, маршрутизаторы, прокси- и DNS-серверы.

Включим аудит файловой системы, реестра, съёмного носителя и других событий доступа к объектам, а всё остальное оставим в выключенном состоянии (параметр «Не настроено»).

Рисунок 4. Пример настройки аудита доступа к объектам через подкатегории

Картинка с сайта: www.anti-malware.ru

События аудита могут иметь значение «Успех и отказ», изображённое на рис. 4, или поддерживать только одно из двух состояний. Например, аудит создания процессов (Event ID 4688: A new process has been created) может быть только «успешным» (рис. 5).

Рисунок 5. Аудит создания процессов регистрирует успешные события

Картинка с сайта: www.anti-malware.ru

Если вы не знаете, нужна ли вам та или иная политика аудита, то ознакомиться с их описанием тоже очень легко. Оно есть на вкладке «Пояснение» соответствующей политики.

Рисунок 6. Вкладка с описанием политики

Картинка с сайта: www.anti-malware.ru

Для некоторых политик аудита дополнительно нужно настраивать системные списки управления доступом (SACL). Это в первую очередь касается файлового аудита и аудита реестра (альтернатива — использовать весьма специфичную политику «Аудит доступа к глобальным объектам»).

Например, чтобы отслеживать изменения в файле «hosts», откроем его свойства и перейдём в настройки аудита: «Безопасность» -> «Дополнительно» -> «Аудит». Добавим субъект аудита: выбираем группу «Все». Тип аудита — «Успех». Ставим галочки напротив записи данных, удаления, смены разрешений и смены владельца.

Рисунок 7. Настройка SACL

Картинка с сайта: www.anti-malware.ru

Если в вашей компании уже существуют различные групповые политики с настройками аудита, но вы хотите начать использовать расширенный аудит и подкатегории, то для этого случая 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. Принудительное переопределение параметров политики аудита

Картинка с сайта: www.anti-malware.ru

Дополнительно вы можете управлять политиками аудита через инструмент командной строки «auditpol.exe».

Рисунок 9. Использование инструмента auditpol

Картинка с сайта: www.anti-malware.ru

Настройка политик аудита

Очень часто можно услышать совет: «давайте включим все политики». Это, конечно, — «путь джедая», но, как показывает практика, не все джедаи добрались до финала.

Для большинства сценариев мониторинга нет острой необходимости включать всё. Это излишне. Включая все политики, вы можете получить гигантский поток событий, в котором очень легко «утонуть». В большой инфраструктуре с несколькими тысячами Windows-хостов поток событий может исчисляться десятками тысяч EPS (событий в секунду). Это порождает другую, не менее сложную задачу: как этим управлять, где это хранить, как обрабатывать.

Предлагаем рассмотреть оптимальный список политик, который может вам понадобиться. Также стоит обратить внимание на то, что фактически настроек две (и, соответственно, существуют две различные GPO). Первая — исключительно для контроллеров домена, так как часть событий (например, ID 4768: A Kerberos authentication ticket (TGT) was requested) фиксируется исключительно на них. Вторая — для рядовых серверов и АРМ пользователей.

Таблица 2. Рекомендуемые настройки аудита Windows

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

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

Для максимальной отдачи необходимо выполнить ещё одну настройку — включить логирование «командной строки процесса». Тогда на рабочих станциях и серверах, к которым применяется этот параметр политики, сведения из командной строки будут заноситься в журнал событий «Безопасность» (Security) с ID 4688.

Рисунок 10. Журналирование командной строки процесса

Картинка с сайта: www.anti-malware.ru

Требования к версии ОС: не ниже 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. Путь к аудиту создания процессов

Картинка с сайта: www.anti-malware.ru

Включаем политику, выставив соответствующее значение, и нажимаем «Применить» (Apply).

Рисунок 12. Настройка «Включать командную строку в события создания процессов» 

Картинка с сайта: www.anti-malware.ru

После включения этой политики в журнале событий «Безопасность» (Security) в событиях с кодом 4688 появится дополнительное значение «Командная строка процесса» (Process Command Line), где будет отображаться тело исполняемой команды.

В примере ниже демонстрируется, как это поможет заглянуть чуть глубже. На первый взгляд в событии происходит запуск легитимного процесса «opera_autoupdate.exe», но вот строка «Process Command Line» больше похожа на запуск утилиты «mimikatz». Без активированной политики «Включать командную строку в события создания процессов» мы этого не зафиксируем.

Рисунок 13. Детектирование mimikatz

Картинка с сайта: www.anti-malware.ru

Укрепим нашу оборону и полным журналированием работы самого мощного инструмента ОС 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

Картинка с сайта: www.anti-malware.ru

Включаем политику и нажимаем «Применить» (Apply). При этом устанавливать галочку напротив поля «Регистрация начала или остановки вызова блоков сценариев» (Log script block invocation start / stop events) не нужно. Данная функция увеличивает количество регистрируемых событий, которые не несут полезной информации.

Рисунок 15. Включить регистрацию блоков сценариев PowerShell

Картинка с сайта: www.anti-malware.ru

После включения этой политики PowerShell будет регистрировать в журнале событий трассировки Microsoft-Windows-PowerShell/Operational с кодом события 4104 все блоки сценариев, в том числе — путь, тело скрипта и все используемые командлеты.

Рисунок 16. Пример регистрируемого события 4104

Картинка с сайта: www.anti-malware.ru

Хорошей практикой является увеличение размера самих журналов, даже если вы используете SIEM или сервер сборщика событий (Windows Event Collector). Например, журнал «Безопасность» (Security) по умолчанию имеет размер 20 МБ. При настроенном аудите на типичном АРМ этого объёма хватит на журналирование нескольких дней, на сервере — нескольких часов, а на контроллере домена 20 МБ не хватит ни на что.

Рекомендуем для всех основных журналов следующие объёмы:

• журнал «Установка» (Setup) — не менее 10 МБ,
• журнал «Система» (System) — не менее 50 МБ,
• журнал «Приложение» (Application) — не менее 50 МБ,
• журнал «Безопасность» (Security) — не менее 200 МБ (для контроллера домена — не менее 500 МБ).

При этом оставляем функцию перезаписи старых событий (по умолчанию она активирована).

Рисунок 17. Настройка хранения журналов аудита

Картинка с сайта: www.anti-malware.ru

Выводы

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

В дальнейшем важно будет обеспечить централизованный сбор и хранение журналов в SIEM-системе, настройку корреляционных правил, киберразведку (Threat Intelligence), проведение активных испытаний безопасности в формате Red / Blue Team.

Время на прочтение7 мин

Количество просмотров62K

Технические специалисты, которые, расследуя ИБ-инциденты или устраняя неполадки при траблшутинге, хоть раз пытались найти в логах операционных систем семейства Microsoft Windows реально важную для них информацию, знают, что в журналы аудита событий попадает далеко не все, что нужно. Можно ли исправить эту ситуацию без дополнительных финансовых вложений с использованием инструментов, гарантированно совместимых с Windows-средой? Разумеется, можно!

Картинка с сайта: habr.com

Примечание: мы продолжаем серию публикаций полных версий статей из журнала Хакер. Орфография и пунктуация автора сохранены.

Сразу оговоримся, что за рамками настоящей статьи останутся вопросы осознанной чистки логов или «кривой» настройки политик аудита в домене (Audit Policy). Здесь мы поговорим только о том, как повысить информативность и расширить возможности функции аудита событий, используя утилиту System Monitor (Sysmon) в Windows-среде (от Windows 7 для клиентских узлов и от Windows Server 2008 R2 для серверов).

Sysmon

Утилиту можно загрузить с веб-сайта Microsoft Docs, из раздела Windows Sysinternals download. В составе Windows Sysinternals от Марка Руссиновича и Со есть еще много полезных утилит, так что найди время и «пощупай» их. Плюс загляни в подборку материалов на GitHub materials.
Но для данной статьи мы возьмем специальную готовую сборку с GitHub download, включающую файл конфигурации Sysmon Threat Intelligence Configuration от ION-STORM. Она ориентирована именно на выявление инцидентов ИБ и может выступить качественной основой для создания твоих собственных файлов конфигурации.

Утилиту можно установить точечно на каждое рабочее место либо с использованием групповых политик (Group Policy) в домене.

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

    <Image condition="is">C:\Program Files\OpenVPN\bin\openvpn-gui.exe</Image>
    <ImageLoaded condition="contains">C:\Program Files (x86)\Notepad++</ImageLoaded>

Таким образом, в конкретной ИТ-инфраструктуре это может потребовать определенного тюнинга, так как, например, согласно корпоративной политике программы могут устанавливаться на диск D:\, а не на C:.

Инструментарий настолько гибкий, что можно задавать любые конструкции, нацеленные на то, чтобы отслеживать определенные действия или исключать их из твоего поля зрения.
После установки получишь новый журнал (Channel) Microsoft-Windows-Sysmon/Operational, в котором Sysmon выделяет 18 категорий задач (Task Category), среди них: Process Create, Network Connect, Driver Load, ProcessAccess, File Create.

Аудит сетевого взаимодействия

Перейдем к практическому применению Sysmon.

Представь сетевое взаимодействие между двумя узлами сети: узел А обращается к узлу Б, и это обращение не является легальным, то есть возникает подозрение на ИБ-инцидент. Искать следы данного сетевого взаимодействия в операционной системе будут в самый последний момент, а начнут именно с активного сетевого оборудования.
Что нам скажет межсетевой экран или маршрутизатор, если он контролирует это сетевое взаимодействие?

    <190>%ASA-6-302014: Teardown TCP connection 2047052539 for outside:IP_1/60307 (DOMAIN\USER_NAME) to dmz-0:IP_2/22 duration 0:00:16 bytes 5675 TCP FINs (USER_NAME)

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

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

Картинка с сайта: habr.com

Мы видим, кто, куда и, если очень повезет, то с помощью чего, то есть в данном случае PuTTY.
Но здесь нет ни места установки приложения, ни имени исполняемого файла, ни когда он был создан. В случае PuTTY это может показаться надуманными атрибутами, но если ты ищешь следы несанкционированных действий и/или вредоноса, то это уже важные вещи. Плюс вредонос может «представиться» легальным приложением и подтолкнуть тебя закрыть данный ИБ-инцидент как ложное срабатывание (false positive), приняв решение только на основании полученного из дампа сетевого трафика имени приложения.

Теперь посмотрим в канал Microsoft-Windows-Sysmon/Operational. В нем есть следующее событие:

    Network connection detected:
    UtcTime: 2018-02-08 11:33:49.672
    ProcessGuid: {4e1a728b-358a-5a7c-0000-00108901d000}
    ProcessId: 4636
    Image: C:\Users\USER_NAME\Desktop\putty.exe
    User: DOMAIN\USER_NAME
    Protocol: tcp
    Initiated: true
    SourceIsIpv6: false
    SourceIp: IP_1
    SourceHostname: COMP_NAME.DOMAIN
    SourcePort: 60307
    SourcePortName: 
    DestinationIsIpv6: false
    DestinationIp: IP_2
    DestinationHostname: 
    DestinationPort: 22
    DestinationPortName: ssh

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

    Process Create:
    UtcTime: 2018-02-08 11:33:30.583
    ProcessGuid: {4e1a728b-358a-5a7c-0000-00108901d000}
    ProcessId: 4636
    Image: C:\Users\USER_NAME\Desktop\putty.exe
    CommandLine: "C:\Users\USER_NAME\Desktop\putty.exe" 
    CurrentDirectory: C:\Users\USER_NAME\Desktop\
    User: DOMAIN\USER_NAME
    LogonGuid: {4e1a728b-268c-5a7c-0000-0020d3a20600}
    LogonId: 0x6A2D3
    TerminalSessionId: 1
    IntegrityLevel: Medium
    Hashes:     SHA256=7AFB56DD48565C3C9804F683C80EF47E5333F847F2D3211EC11ED13AD36061E1,IMPHASH=EFE162FD3D51DED9DD66FA4AC219BF53
    ParentProcessGuid: {4e1a728b-268d-5a7c-0000-001023de0600}
    ParentProcessId: 3632
    ParentImage: C:\Windows\explorer.exe
    ParentCommandLine: C:\Windows\Explorer.EXE

Видим, что создан процесс, в том числе определено хеш-значение файла — прародителя данного процесса.

Теперь ты можешь по хешу проверить этот файл:

• по корпоративным «белым спискам» разрешенного программного обеспечения;
• на соответствие эталону на веб-сайте производителя данного программного обеспечения;
• в рейтингах сервиса Threat Intelligence;
• на ресурсах типа VirusTotal.

Картинка с сайта: habr.com

Стоит отметить, что на тех узлах сети, где есть ограничения на установку средств антивирусной защиты (терминалы диспетчеров, технологические АРМ и тому подобное), анализ хешей — в том числе автоматизированный, путем сопоставления данных от сервисов Threat Intelligence, например в системе класса Security Information and Event Management (SIEM), — может выступать вполне действенной компенсирующей мерой для борьбы с вредоносным программным обеспечением.

Развивая тематику отслеживания действий, связанных с файлами, нужно отметить, что по умолчанию указанный файл конфигурации позволяет отслеживать создание в операционной системе файлов, которые могут быть потенциальным источником ИБ-инцидентов, например цифровых сертификатов, исполняемых файлов, файлов библиотек, PowerShell-файлов, RDP-файлов, файлов MS Office с поддержкой макросов, а также файлов, создаваемых в определенных каталогах файловой системы:

    File created:
    UtcTime: 2018-02-08 11:50:39.893
    ProcessGuid: {4e1a728b-283b-5a7c-0000-00107b384a00}
    ProcessId: 2780
    Image: C:\Program Files\Microsoft Office\Office15\WINWORD.EXE
    TargetFilename: C:\Users\USER_NAME\Desktop\Doc1.docm
    CreationUtcTime: 2018-02-08 11:50:39.893

Файлы или действия, которые ведут к изменению параметров реестра, также подлежат протоколированию. Например, ассоциация типа файла DOCM, который был впервые использован в операционной системе при создании файла Doc1.docm (см. пример выше), с приложением MS Word:

    Registry value set:
    EventType: SetValue
    UtcTime: 2018-02-08 11:50:40.550
    ProcessGuid: {4e1a728b-268d-5a7c-0000-001023de0600}
    ProcessId: 3632
    Image: C:\Windows\Explorer.EXE
    TargetObject: \REGISTRY\USER\S-1-5-21-1626002472-1445367128-3583509536-1113\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.docm\OpenWithList\a
    Details: WINWORD.EXE

Для безопасника это может представлять интерес, когда вредоносный файл производит переассоциацию легально закрепленных корпоративных приложений для определенных типов файлов и тем самым «навязывает» использование уязвимого приложения. Еще пример: изменение ключей реестра операционной системы, влияющих на параметры загрузки операционной системы, чтобы снизить уровень ее защищенности после очередной перезагрузки (отключение средств антивирусной защиты или других средств защиты информации).

Централизация сбора и хранения событий

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

1. Добавить пользователя, от имени которого будут собираться события «COLLECTOR», в локальную группу «Event log reader».
2. Выполнить от имени администратора (Run as) команду
   winrm quickconfig -quiet
3. Выполнить от имени администратора (Run as) команду
   wevtutil get-log Microsoft-Windows-Sysmon/Operational,
   Получить строку «channelAccess» DATA

Картинка с сайта: habr.com

1. Выполнить от имени администратора (Run as) команду
   wmic useraccount where name=’COLLECTOR’ get sid
   Получить UID_COLLECTOR
2. Выполнить от имени администратора (Run as) команду
   

   Картинка с сайта: habr.com

wevtutil set-log Microsoft-Windows-Sysmon/Operational /ca: DATA(A;;0x1;;;UID_COLLECTOR)

Получить расширенные права доступа к каналу Microsoft-Windows-Sysmon/Operational для учетной записи COLLECTOR.

1. Добавить данный узел в специально созданную подписку (Subscription) для централизованного сбора и хранения событий на выделенном узле с запущенной службой Windows Event Collector.

Заключение

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

Напоминаем, что это полная версия статьи из журнала Хакер. Ее авторы — Александр Кузнецов и Алексей Федоров.

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

Картинка с сайта: vmblog.ru

Расширенные политики аудита находятся в секции: 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

Картинка с сайта: vmblog.ru

В большинстве случаев нужно использовать политики аудита из секции Advanced Audit Policy Configuration. Они позволяют настроить аудит более тонко и исключить ненужные события безопасности.

Прежде чем включать политики аудита в Windows рекомендуем увеличить максимальный размер журнала Security со 128 Mb (по-умолчанию в Windows Server)

Запустите консоль Event Viewer (eventvwr.msc), разверните Windows Logs и откройте свойства журнала Security. Увеличьте значение в поле Maximum log size (KB).

Картинка с сайта: vmblog.ru

Теперь нужно настроить политику аудита доступа пользователей к файлам и папкам в сетевой папке. Перейдите в секцию Advanced Audit Policy -> Object Access. Откройте свойства подкатегории Audit File Share и Audit File System.

Включите политику: Configure the following audit events.

Укажите, какие события нужно записывать в журнал Security:

• Success – успешный доступ пользователя к объектам в сетевой папке
• Failure – события неуспешного доступа к папкам.

В нашем случае достаточно вести аудит только Success событий.

Картинка с сайта: vmblog.ru

Теперь нужно назначить политику аудита к сетевой папке (создать системные списки управления доступом – SACL).

Откройте свойства сетевой папки, перейдите на вкладку Security -> Advanced -> Auditing tab -> Continue.

Картинка с сайта: vmblog.ru

Нажмите кнопку Add -> Select a principal и добавьте субъекты – это пользователи или группы (локальные или из Active Directory), чьи действия нужно аудировать. Я добавил группы Domain Users или Everyone (это значит, я буду вести аудит доступа к сетевой папке для всех пользователей).

Далее в секции Permissions укажите, какие действия пользователей нужно записывать в журнал. Я выбрал события из категории Delete.

Картинка с сайта: vmblog.ru

Сохраните изменения и обновите политики на компьютере с помощью команды:

gpupdate /force

Теперь, если любой пользователь удалит файл или папку в вашей сетевой папке, в журнале Security появится событие c EventID 4660 от источника Microsoft Windows security с Task Сategory File System: An object was deleted.

В событии указан пользователь, который удалил файл (Account Name).

Картинка с сайта: vmblog.ru

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

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

Чтобы вывести информацию о всех включенных политиках аудита, выполните:

auditpol /get /category:*

Картинка с сайта: vmblog.ru

Чтобы включить определенную политику аудита, используется такой синтаксис:

auditpol /set /subcategory:"Registry" /success:enable

Для сброса политик аудита в исходное состояние, используется команда:

AuditPol /clear

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

Включить политику аудита доступа к объектам файловой системы Windows

По умолчанию в Windows отключен аудит событий доступа к файлам и папкам. Включить аудит можно с помощью групповой политики. На отдельностоящем сервере для настройки политика аудита используется консоль редактора локальной групповой политики (
gpedit.msc
). Если вам нужно включить аудит сразу на множестве компьютеров в домене AD, используйте консоль управления доменными GPO (
gpmc.msc
).

1. Откройте редактор GPO и перейдите в раздел Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> System Audit Policies -> Object Access;
2. Откройте политику Audit File System и укажите, что вы хотите сохранять в журнал только успешные события доступа к объектам файловой системы (Configure the following audit events -> Success);
   

   Картинка с сайта: winitpro.ru

3. Сохраните изменения и обновите настройки локальной групповой политики с помощью команды
   gpupdate /force
   .

Можно включить локальную политику аудита файловой системы из командной строки. Вывести доступные категории аудита:

AuditPol.exe /list /subcategory:*

Включить аудит успешных событий доступа к объектам файловой системы:

AuditPol.exe /set /subcategory:"File System" /success:enable

Вывести настройки категории аудита:

AuditPol.exe /get /category:"Object Access"

Картинка с сайта: winitpro.ru

Настройка аудита событий на файлах и папках Windows

Несмотря на то, что в Windows включена политика аудита доступа к файлам и папкам, фактически событий в Event Viewer еще не попадают. Администратор должен вручную настроить параметры аудита на файлах и папках, которые нужно отслеживать.

К примеру, вы хотите отслеживать события чтения, изменения и создания файлов в каталоге C:\Docs.

1. Откройте свойства папки и перейдите на вкладку Security -> Advanced -> Auditing;
   

   Картинка с сайта: winitpro.ru

2. Нажмите кнопку Add и в поле Principal выберите пользователя или группы, чью события доступа нужно отслеживать. Если нужно отслеживать доступ для всех пользователей, выберите Users (или Everyone, если нужно контролировать доступ системных процессов);
3. В списке Type укажите, что нужно отслеживать только успешные событий (
   Success
   );
4. В Applies to можно указать, нужно ли применить аудит для папки, файлов, вложенных объектов (по умолчанию выбрано This folder, subfolders and files);
5. В списке Advanced permissions выберите только те действия с файлами и папками, которые вы хотите отправлять в журнал аудита. Например: события чтения (List folder/read data) и изменения файлов (Create files or folders / write or append data)
6. Сохраните настройки аудита.

При настройке политик аудита файловой системы старайтесь включать аудит только для тех папок и файлов, которые вам нужны. Включайте аудит только для тех файлов и событий, который вам нужны. Большое количество объектов аудита файловой системы приводит к значительному росту журнала событий Event Viewer.

Можно включить аудит для каталога с помощью PowerShell:

$Path = "C:\Docs"
$AuditChangesRules = New-Object System.Security.AccessControl.FileSystemAuditRule('BUILTIN\Users', 'Delete,DeleteSubdirectoriesAndFiles', 'none', 'none', 'Success')
$Acl = Get-Acl -Path $Path
$Acl.AddAuditRule($AuditChangesRules)
Set-Acl -Path $Path -AclObject $Acl

Настройки аудита папки можно вывести с помощью PowerShell:

(Get-Acl "C:\Docs\" -Audit).Audit

Чтобы рекурсивно просканировать все каталоги и найти папки, на которых включен аудит файловой системы, воспользуйтесь таким скриптом:

$folders=Get-ChildItem "c:\docs" -Recurse |Where-Object {$_.PSIsContainer}
foreach ($folder in $folders)
{
$auditacl=(Get-Acl $folder.FullName -Audit).audit
if ($auditacl -ne "") {write-host $folder.FullName}
}

Просмотр событий аудита доступа к файлам и папкам в Windows

Теперь, если с файлами в указанной папке выполняются какие-то действия, политика аудита записывает их в Event Viewer. Чтобы просмотреть события:

1. 1. Запустите консоль Event Viewer (
      eventvwr.msc
      );
   2. Перейдите в раздел Windows Logs -> Security и отфильтруйте лог по источнику:
      Microsoft Windows security auditing
      , Task Category:
      File System
      ;
      

      Картинка с сайта: winitpro.ru

      .

   3. Откройте содержимое любого события. Например в событии с EventID 4663 (
      An attempt was made to access an object
      ) содержится информация:О пользователе, который произвел действие над фалйов:
      Subject: Account Name:
      
      Имя файла:
      Object Name:
      
      Тип операции (изменение файла в этом случае):
      Accesses: WriteData (or AddFile)
      

      Картинка с сайта: winitpro.ru

Однако из за ограниченных возможностей фильтрации и поиска в событиях Event Viewer, использовать эту консоль для поиска всех операции с определенным файлом довольно неудобно.

Для вывода всех событий, связанных с определенным объектом лучше использовть PowerShell. Следующий PowerShell скрипт выведет все события доступа, связанные с указанным файлом (для получения списка событий исопльзуется производительный командлет Get-WinEvent):

$fileName = "C:\\docs\\13131.txt"
$results = Get-WinEvent -FilterHashtable @{logname='Security'; id=4663,4659} |`
Where-Object { $_.message -match $fileName -and $_.message -notmatch "Account Name:\s*machine$*"}`
foreach ($result in $results) {
    $Account = $result.properties[1].Value
    $objectName = $result.properties[6].Value
    $accessMask = $result.properties[8].Value
    if ( $accessMask -like "*00000000-*") { $accessMask=$result.properties[9].Value}  
    $accessMask2 = $result.properties[9].Value
        $fileOperation = ""
        switch -Wildcard ($accessMask) {
            "*%%1538*" { $fileOperation = "READ_CONTROL" }
            "*%%4416*" { $fileOperation = "ReadData (or ListDirectory)" }
            "*%%4417*" { $fileOperation = "WriteData (or AddFile)" }
            "*%%4418*" { $fileOperation = "AppendData (or AddSubdirectory or CreatePipeInstance)" }
            "*%%4419*" { $fileOperation = "ReadEA" }
            "*%%4420*" { $fileOperation = "WriteEA" }
            "*%%4423*" { $fileOperation = "ReadAttributes" }
            "*%%4424*" { $fileOperation = "WriteAttributes" }
            "*%%4426*" { $fileOperation = "Delete" }
            "*%%4428*" { $fileOperation = "ReadControl" }
            "*%%4429*" { $fileOperation = "WriteDAC" }
            "*%%4430*" { $fileOperation = "WriteOwner" }
            "*%%4432*" { $fileOperation = "Synchronize" }
            "*%%4433*" { $fileOperation = "AccessSystemSecurity" }
            "*%%4434*" { $fileOperation = "MaximumAllowed" }
            "*%%4436*" { $fileOperation = "GenericAll" }
            "*%%4437*" { $fileOperation = "GenericExecute" }
            "*%%4438*" { $fileOperation = "GenericWrite" }
            "*%%4439*" { $fileOperation = "GenericRead" }
            "*%%1537*" { $fileOperation = "DELETE" }
            default { $fileOperation = "Unknown" }
        }
        Write-Host   $result.Id  $result.TimeCreated  $Account $objectName $fileOperation  
} 

Картинка с сайта: winitpro.ru

Вы можете отправлять собранные события аудита в вашу систему сбора логов, базу данных, текстовый лог файл или отправлять email уведомление через Send-MailMessage при доступе/модификации отслеживаемого файла.