Средства мониторинга Windows

Аудит Windows -- встроенный механизм операционной системы, который позволяет отслеживать и регистрировать события, связанные с безопасностью и активностью пользователей.

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

Способы настройки аудита

Локально аудит можно настроить с помощью оснастки локальных политик secpol.msc, утилитой auditpolили внося параметры непосредственно в реестр. На больших инфраструктурах рекомендуется это делать через групповые политики, средства управления инфраструктурой (SCCM, Ansible) или агенты EDR (если есть, то через функцию настройки политики аудита).

Локальная настройка аудита на узле

Локальная настройка аудита подходит для небольших сред или отдельных компьютеров.

Использование локальных политик безопасности

Нажмите Win + R, введите secpol.msc и нажмите Enter.

Использование командной строки

1. Включить аудит с помощью команды auditpol:

   • Пример:

     auditpol /set /category:"Logon/Logoff" /success:enable /failure:enable
     auditpol /set /category:"Object Access" /success:enable /failure:enable

2. Проверить текущие настройки:

   auditpol /get /category:*

Использование PowerShell

1. Включить аудит с помощью PowerShell:

   • Пример:

     Set-AuditPolicy -Category "Logon/Logoff" -Success "Enable" -Failure "Enable"
     Set-AuditPolicy -Category "Object Access" -Success "Enable" -Failure "Enable"

2. Проверить текущие настройки:

   Get-AuditPolicy

Можно настроить аудит, напрямую изменяя ключи реестра в Windows. Однако этот метод требует осторожности, так как неправильное изменение реестра может привести к нестабильной работе системы.

Централизованная настройка аудита в большой инфраструктуре

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

Использование групповых политик (GPO)

1. Откройте Групповые политики домена:

   • Нажмите Win + R, введите gpmc.msc и нажмите Enter.

2. Создайте новую политику:

   • Щелкните правой кнопкой мыши на домене или OU (организационной единице) и выберите Создать объект групповой политики.

3. Настройте аудит

4. Примените политику:

   • Свяжите политику с нужными OU или доменом.

   • Обновите политики на клиентских машинах:

     gpupdate /force

Либо

1. Создайте скрипт для настройки аудита:

   • Пример:

     Invoke-Command -ComputerName Server1, Server2 -ScriptBlock {
         auditpol /set /category:"Logon/Logoff" /success:enable /failure:enable
         auditpol /set /category:"Object Access" /success:enable /failure:enable
     }

2. Запустите скрипт на всех узлах:

   • Используйте также GPO, Task Scheduler или PowerShell Remoting для выполнения скрипта на множестве компьютеров

Некоторые агенты EDR предоставляют возможность централизлванно управлять настройками аудита.

Локальный анализ логов

Локальный анализ логов выполняется непосредственно на узле (компьютере или сервере) с использованием встроенных инструментов Windows или сторонних утилит.

Использование Event Viewer

1. Откройте Журнал событий (eventvwr.msc).

2. Перейдите в раздел:

   • Журналы Windows → Безопасность (для событий аудита).

   • Журналы Windows → Система (для системных событий).

   • Журналы Windows → Приложение (для событий приложений).

3. Используйте фильтры для поиска нужных событий:

   • Например, для поиска событий входа в систему используйте Event ID 4624.

   • Для поиска подозрительных процессов используйте Event ID 4688.

Использование PowerShell для анализа логов

1. Получите события из журнала безопасности:

   Get-WinEvent -LogName Security | Where-Object { $_.Id -eq 4624 }

2. Получите события из журнала системы:

   Get-WinEvent -LogName System | Where-Object { $_.Id -eq 6005 }

3. Экспортируйте логи в файл для дальнейшего анализа:

   Get-WinEvent -LogName Security -MaxEvents 1000 | Export-Csv -Path C:\Logs\SecurityLogs.csv

Использование WEC для централизованного сбора логов

Windows Event Collector (WEC) — это встроенный механизм Windows для централизованного сбора событий с множества компьютеров. WEC может использоваться для отправки событий в SIEM.

Преимущества использования WEC и SIEM

• Централизованный сбор логов:

  • Все события собираются на одном сервере, что упрощает анализ.

  • Логи могут быть отправлены в SIEM для дальнейшего анализа и корреляции.

• Масштабируемость:

  • WEC поддерживает сбор событий с тысяч компьютеров.

• Автоматизация:

  • Настройка WEC через групповые политики позволяет автоматизировать процесс сбора логов.

Настройка WEC

1. Настройка сервера WEC:

   • Откройте Службы (services.msc) и убедитесь, что служба Windows Event Collector запущена.

   • Настройте подписки на события:

     • Откройте Журнал событий (eventvwr.msc).

     • Перейдите в раздел:

       • Подписки → Создать подписку.

     • Укажите источники событий (клиентские компьютеры) и типы событий для сбора.

2. Настройка клиентских компьютеров:

   • Включите пересылку событий через групповые политики:

     • Откройте Редактор групповых политик (gpedit.msc).

     • Перейдите в раздел:

       • Конфигурация компьютера → Административные шаблоны → Компоненты Windows → Пересылка событий.

     • Включите политику "Настройка пересылки событий".

     • Укажите адрес центрального сервера WEC.

Пример XML для фильтрации событий в Windows Event Collector (WEC)

Windows Event Collector (WEC) позволяет настраивать подписки на события с использованием XML-фильтров. Эти фильтры определяют, какие события будут собираться с источников (клиентских компьютеров) и отправляться на сервер WEC.

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
      *[System[(EventID=4624)]] <!-- Успешный вход в систему -->
      and
      *[EventData[Data[@Name='TargetUserName']='Administrator'] <!-- Фильтр по имени пользователя -->
    </Select>
  </Query>
  <Query Id="1" Path="System">
    <Select Path="System">
      *[System[(EventID=6005)]] <!-- Запуск службы журнала событий -->
    </Select>
  </Query>
  <Query Id="2" Path="Application">
    <Select Path="Application">
      *[System[(EventID=1000)]] <!-- Ошибки приложений -->
    </Select>
  </Query>
</QueryList>

Эта конфигурация тут для примера. Она ужасна и не позволит в реальности обнаружить даже пентест. Если ваш вендор SIEM предоставляет рекомендованную конфигурацию - используйте ее. Вообще любую конфигурацию следует адаптировать под особенности вашей инфраструктуры и используемые правила обнаружения.

Описание XML-фильтра

• QueryList: Корневой элемент, содержащий список запросов.

• Query: Определяет запрос для конкретного журнала событий.

  • Id: Уникальный идентификатор запроса.

  • Path: Указывает журнал событий (например, Security, System, Application).

• Select: Определяет фильтр для событий.

  • Path: Указывает журнал событий (должен совпадать с Path в Query).

  • XPath-выражение: Используется для фильтрации событий.

Общие рекомендации по настройке аудита

1. Используйте стандартный аудит в сочетании с расширенным аудитом

   • Дополнительно настройте логирование командной строки

   • Настройте логирование Powershell

2. Контролируйте объем логов:

   • Включайте только те категории аудита, которые действительно необходимы для вашей среды.

   • Настройте максимальный размер журналов и срок ротации логов.

   • Отфильтруйте те события, которые не используются в ваших правилах обнаружения и не являются полезными при расследованиях и ретроспективном анализе.

   [Cheat Sheet] ТОП-10 событий для мониторинга - это необходимый, но недостаточный список

3. Используйте Sysmon для более детального мониторинга:

   • Sysmon предоставляет больше возможностей по регистрации событий, чем стандартный аудит Windows.

   Sysmon

4. Интегрируйте логи с SIEM:

   • Настройте отправку логов в SIEM-систему (например, Splunk, ELK, QRadar) для централизованного анализа.

   • Настройте мониторинг источников, чтобы в реальном времени видеть узлы с задержкой или отсутcвием событий.

Многие SIEM-системы лицензируются по EPS (Events per Second) - это не повод экономить на событиях, отсуствие важных событий = пропущенная атака. Но это повод оптимизировать сбор и отправку и избавиться от неинформативных событий.