Справочник по Wazuh: функционал SIEM, возможности и настройка

Что такое Wazuh

Для хранения событий в составе Wazuh используется другой продукт с открытым исходным кодом — OpenSearch, который позволяет хранить логи, искать и анализировать данные в реальном времени.

Ключевые преимущества

• Wazuh — open source-проект. Код открыт для изменений и аудита.
• Возможности уровня Enterprise. Полноценный SIEM, IDS, VM и SCA в одном продукте без вендорской зависимости.
• Гибкое развертывание. Можно использовать пакеты, Docker-контейнеры, Kubernetes.
• Активное сообщество. Проект может похвастаться регулярными обновлениями правил, интеграцией со сторонними продуктами, наличием подробной документации.
• Поддержка IdP. Интеграция с OIDC/SAML-провайдерами и LDAP из коробки.

Кроссплатформенность. Wazuh можно поставить на сервер с Windows, Linux, macOS, а также установить на сетевые устройства.

Архитектура Wazuh

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

Компонент	Роль	Особенности
Master Node	RESTful API, управление кластером и агентами	Только одна Master Node на кластер — репликация не поддерживается
Worker Node	Разбор событий (decoders), Применение правил (rules), Обогащение событий	Можно масштабировать горизонтально
Indexer	Хранение событий, Управление индексами	Поддерживает репликацию и кластеризацию
Dashboard	Веб-интерфейс,  Визуализация данных	Переработанный OpenSearch Dashboard
Agent	Сбор событий, Active Response, FIM, SCA, YARA, Инвентаризация	Устанавливается на контролируемые хосты

Agent

Легкий процесс на конечном устройстве. Минимально потребляет CPU и RAM, но умеет:

• собирать и отправлять логи на Worker Node;
• контролировать целостность файлов (FIM);
• выполнять Active Response, а именно блокировать IP через IPSet и сканировать образы Trivy/Grype;
• инвентаризировать хосты — ПО, пользователи, группы, процессы, сервисы, порты и другое;
• проверять соответствие политикам (SCA);
• сканировать файлы и процессы через YARA;
• отправлять webhook-уведомления.

Master Node

Централизует и координирует Worker Nodes, является единственной точкой управления кластером. Принимает и обрабатывает запросы на регистрацию / удаление агентов, создает и управляет группами конфигурации агентов, отвечает за обновления и дистрибуцию правила, декодеров, SCA-политик и CDB-списков.

При синхронизации файлы на Worker Node полностью перезаписываются данными с Master Node. Это напрямую влияет на конфигурацию агентов, CDB-списков, SCA-политик, декодеров и правил.

Wazuh Manager

Это отдельная «роль», которая может существовать на Master Node и/или Worker Node. Она состоит из следующих компонентов, каждый из которых реализован как отдельный демон:

Демон	Назначение
wazuh-analysisd	Движок анализа: декодирование событий, применение правил, генерация алертов
wazuh-remoted	Связь с агентами: прием событий, отправка конфигурации и команд
wazuh-authd	Аутентификация и регистрация агентов
wazuh-execd	Active Response: исполнение скриптов блокировки и реагирования
wazuh-logcollector	Сбор логов из файлов, journald, windows events
wazuh-syscheckd	FIM: обнаружение изменений файлов и директорий
wazuh-modulesd	SCA, Vulnerability Detector, инвентаризация, Docker-listener
wazuh-db	SQLite-менеджер БД агентов (инвентаризация, FIM, статусы)
wazuh-apid	RESTful API (JWT): управление кластером, агентами, правилами
wazuh-clusterd	Кластеризация: синхронизация между Master и Worker
wazuh-integratord	Интеграции: Slack, PagerDuty, VirusTotal и др.
wazuh-maild	Email-уведомления об алертах
wazuh-monitord	Мониторинг агентов, ротация лог-файлов сервера
wazuh-csyslogd	Пересылка алертов во внешние syslog-серверы
wazuh-agentlessd	Мониторинг без агента (SSH / telnet)
wazuh-dbd	Коннектор к внешним БД (MySQL, PostgreSQL)
wazuh-reportd	Генерация отчетов на основе алертов

Сбор логов

Агент собирает логи через модуль Logcollector (обычный Filebeat/Ingest Pipelines под капотом), сервер — анализирует их в реальном времени: декодеры разбирают (токенизируют) события, движок Analysisd сопоставляет их с правилами и создает алерты. Сбор логов осуществляется с помощью инструкции <localfile> в ossec.conf. 

Куда пишутся результаты обработанных событий

Все результаты обработанных событий сохраняются на Worker / Master Node. 

      # Алерты (события, сработавшие по правилам)
/var/ossec/logs/alerts/alerts.log
//6ef4e6a1-9d49-47ac-bfed-170f67a815cf.selcdn.net/var/ossec/logs/alerts/alerts.json


# Архив всех событий (все события, отправленные в Wazuh)
/var/ossec/logs/archives/archives.log
/var/ossec/logs/archives/archives.json

Сбор всех событий включается в ossec.conf тегами <logall> и <logall_json>. В продакшене обязательно отключайте опцию, иначе она быстро заполнит диск.

Конфигурации сбора логов

Локальная конфигурация (ossec.conf на агенте) — основной конфигурационный файл. Настройки применяются только к данному агенту.

ОС	Путь
Linux / Unix	/var/ossec/etc/ossec.conf
Windows	C:\Program Files (x86)\ossec-agent\ossec.conf
macOS	/Library/Ossec/etc/ossec.conf

Централизованная конфигурация (agent.conf на сервере) распространяет настройки сразу на группы агентов. Это полезно, например, если необходимо иметь разные конфигурации для dev/stage/prod-окружений. При этом agent.conf имеет приоритет над локальным ossec.conf на агенте.

Сбор логов и событий из файлов

Конфигурация описывается в блоке <localfile>. Агент поддерживает несколько способов указания путей.

Обычный файл (статический путь) — используется для сервисов с фиксированным именем лога.

      <localfile>
  <location>/var/log/app/app.log</location>
  <log_format>syslog</log_format>
</localfile>

Файл с датой в имени (strftime) — подходит, Если приложение создает новый файл каждые сутки (например, file-23-06-15.log).

       <localfile>
  <location>/logs/file-%y-%m-%d.log</location>
  <log_format>syslog</log_format>
</localfile>

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

      <localfile>
  <location>/logs/file*.log</location>
  <log_format>syslog</log_format>
</localfile>

Переменные окружения (только Windows) — позволяет использовать системные пути независимо от буквы диска или имени папки Windows.

      <localfile>
  <location>%WINDIR%\Logs\StorGroupPolicy.log</location>
  <log_format>syslog</log_format>
</localfile>

Поддерживаемые форматы и типы логов

Wazuh должен понимать структуру входящих данных.

• syslog — стандарт для текстовых логов, где одна строка отвечает за одно событие.
• json — самый эффективный формат. Если выбрать <log_format>json</log_format>, Wazuh автоматически распарсит поля. Создавать кастомный decoder в этом случае не требуется — данные сразу попадут в поиск в структурированном виде.
• multi-line — используется для многострочных логов, например Java Stacktrace или логи Oracle. Позволяет объединять строки в одно событие на основе регулярного выражения.
• command — позволяет превратить вывод любой CLI-команды в лог-событие (например, мониторинг свободного места на диске).

Обогащение данных через метки (Labels)

Метки позволяют добавить к каждому событию контекст, который упрощает фильтрацию в Dashboard. Это критически важно для большой инфраструктуры, чтобы понимать, из какого филиала, окружения (prod/dev) или от какого заказчика пришел лог.

      <labels>
  <label key="environment">production</label>
  <label key="project">payment-gate</label>
  <label key="region">eu-west-1</label>
  <label key="hidden-info" hidden="yes">internal-id-123</label>
</labels>

Используйте код с осторожностью.

• Обычные метки — добавляются в JSON-событие и видны в поиске.

Скрытые метки (hidden=”yes”) — используются только «внутри» сервера Wazuh для срабатывания правил (rules), но не сохраняются в индекс базы данных, экономя место в хранилище.

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

Если ваше приложение генерирует тысячи строк в секунду, агент может перегрузить процессор или сеть. Для защиты предусмотрен Client Buffer.

1. Лимит событий. Параметр events_per_second ограничивает интенсивность отправки.

Чтение с начала. По умолчанию агент читает только новые строки. Чтобы просканировать старый файл целиком при первом запуске, используйте параметр <only-future-lines>no</only-future-lines>.

Сбор логов из Systemd Journald

В современных Linux-системах большинство сервисов пишут логи не в текстовые файлы, а напрямую в бинарный журнал journald. Wazuh-агент умеет подключаться к нему напрямую, извлекая данные в структурированном виде и конвертируя их в формат syslog для сервера.

По умолчанию сбор из журнала часто уже включен в базовом конфиге:

      <localfile>
  <location>journald</location>
  <log_format>journald</log_format>
</localfile>

Чтобы не перегружать сервер Wazuh второстепенными событиями, в блоке journald можно использовать фильтры по конкретным полям юнитов или уровням важности (приоритетам).

1. Сбор логов только конкретного сервиса (например, SSH):

      <localfile>
  <location>journald</location>
  <log_format>journald</log_format>
  <filter field="_SYSTEMD_UNIT">^ssh.service$</filter>
</localfile>

2. Фильтрация по приоритету (на примере CRON):

      <localfile>
  <location>journald</location>
  <log_format>journald</log_format>
  <filter field="_SYSTEMD_UNIT">^cron.service$</filter>
  <filter field="PRIORITY">[0-6]</filter>
</localfile>

Здесь мы собираем логи планировщика, исключая отладочную информацию (Priority 7 — Debug), оставляя только события от 0 (Emergency) до 6 (Informational).

3. Мониторинг Docker-контейнеров:

      <localfile>
  <location>journald</location>
  <log_format>journald</log_format>
  <filter field="_SYSTEMD_UNIT">^docker.service$</filter>
</localfile>

Если Docker настроен на использование драйвера journald, вы можете собирать логи демона (или самих контейнеров) аналогичным образом, как показано в примере. При этом вам не нужно заботиться о правах доступа к файлам в /var/log или ротации логов — агент работает с системным API журнала, что гораздо надежнее.

Сбор логов через Event Channels (Windows)

Для ОС Windows сбор текстовых логов из файлов — вторичная задача. Основной поток данных идет из журнала событий (Event Viewer). Начиная с современных версий Windows, Wazuh использует формат eventchannel, который позволяет подписываться на конкретные каналы событий, включая системные, приложения и журналы безопасности.

      <localfile>
    <location>Microsoft-Windows-Sysmon/Operational</location>
    <log_format>eventchannel</log_format>
</localfile>


<localfile>
    <location>Microsoft-Windows-Windows Firewall With Advanced Security/Firewall</location>
    <log_format>eventchannel</log_format>
</localfile>

Сбор логов через Syslog (от устройств без агента)

Для сетевого оборудования (коммутаторы, роутеры, межсетевые экраны) и старых Legacy-систем, на которые невозможно установить агент, Wazuh может работать как классический Syslog-сервер.

В отличие от предыдущих примеров, эта конфигурация вносится в файл ossec.conf на стороне сервера (Wazuh Manager) в блоке <remote>:

      <remote>
  <connection>syslog</connection>
  <port>514</port>
  <protocol>udp</protocol>
  <allowed-ips>10.0.0.0/8</allowed-ips>
  <local_ip>WAZUH_MANAGER_IP</local_ip>
</remote>

Ключевые параметры

• <port>. Стандартный порт 514. Можно изменить на любой свободный, если на сервере уже работает другой syslog-демон, например rsyslog.
• <protocol>. Поддерживаются udp и tcp. Для сетевого оборудования чаще используется UDP.
• <allowed-ips>. Критически важная настройка безопасности. Укажите конкретные IP-адреса или подсети устройств, которым разрешено присылать логи. Это защитит сервер от лишнего шума и потенциальных атак.

<local_ip>. IP-адрес интерфейса сервера, на котором Wazuh будет ожидать входящие пакеты.

Декодеры (Decoders)

Декодеры — инструкции для Wazuh, как разобрать сырую строку лога на именованные поля. Без корректного декодера правило не сможет проверить конкретное значение в событии.

Как работает декодер

Когда лог попадает на сервер, за него принимается демон Analysisd. Его задача — превратить неструктурированную строку текста в набор именованных полей (например, srcip, user, status), по которым потом можно будет строить графики и фильтры.

Процесс разбора идет в два этапа.

1. Родительский декодер (Prematch). Движок ищет ключевое слово или паттерн, который идентифицирует программу (например, слово sshd или nginx). Если совпадение найдено, лог закрепляется за этим декодером.
2. Дочерний декодер (Child). Внутри найденного родителя запускаются уточняющие правила с регулярными выражениями. Они «вырезают» из строки конкретные данные: IP-адреса, имена пользователей или коды ошибок.

На выходе мы получаем JSON-объект, готовый для сопоставления с правилами (Rules).

Расположение файлов

В Wazuh строго разделены системные настройки и пользовательские правки. Это критично для корректного обновления сервера.

1. Встроенные декодеры (Ruleset): /var/ossec/ruleset/decoders/

Это огромная библиотека готовых парсеров для сотен систем (Windows, Cisco, Linux и др.). Никогда не редактируйте файлы в этой папке. При обновлении Wazuh до новой версии все изменения в этой директории будут стерты. И запомните: если системный декодер работает неверно, его не правят, а переопределяют в пользовательской папке.

2. Пользовательские декодеры (Local): /var/ossec/etc/decoders/

Здесь хранятся ваши собственные правила. Основной файл — local_decoder.xml, но вы можете создавать в этой папке любые .xml файлы. При этом при загрузке Wazuh сначала читает файлы из /etc/decoders/. Если он находит там декодер с тем же именем, что и в основной библиотеке, то будет использовать ваш вариант.

Структура декодера

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

      <!-- Родитель: просто опознает, что это лог нашего приложения -->
<decoder name="my-app">
  <prematch>^MyApp:</prematch>
</decoder>


<!-- Потомок: извлекает данные из строки, которая подошла родителю -->
<decoder name="my-app-detail">
  <parent>my-app</parent>
  <regex>user=(\S+) action=(\S+) src=(\S+)</regex>
  <order>user, action, srcip</order>
</decoder>

Тег	Назначение
<prematch>	Быстрая фильтрация строк по regex — только подходящие идут дальше
<parent>	Имя родительского декодера, создаёт иерархию
<regex>	Regex для извлечения данных (группы захвата)
<order>	Имена полей в том же порядке, что группы в <regex>
<type>	Тип: ossec, syslog, json, windows и др.
<plugin_decoder>	Встроенный плагин (JSON, Windows Events и т. д.)

Пример: декодер для CRON

Родительский декодер через prematch находит характерную метку \(\S+\) CMD, подтверждая принадлежность строки к сервису. Следом дочерний декодер, ссылаясь на parent, с помощью регулярного выражения regex извлекает имя пользователя и саму команду в соответствующие поля user и command. В результате вместо сырой строки в интерфейсе Wazuh появляются готовые фильтры для поиска запусков конкретных скриптов.

      <decoder name="cron">
  <prematch>\(\S+\) CMD</prematch>
</decoder>


<decoder name="cron-detail">
  <parent>cron</parent>
  <regex>\((\S+)\) CMD \((.+)\)</regex>
  <order>user, command</order>
</decoder>

Проверка через wazuh-logtest

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

      /var/ossec/bin/wazuh-logtest


# Вводите строку лога — получаете:
#   Phase 1: pre-decoding  — raw event
#   Phase 2: decoding      — какой декодер сработал и какие поля извлечены
#   Phase 3: rules         — какое правило сработало и почему

Правила (Rules)

Правила в Wazuh — это логический фильтр, который анализирует уже декодированные поля и решает, заслуживает ли событие внимания ИБ-специалиста. Каждому правилу присваивается уровень от 0 до 15. Уровни до 3 обычно считаются информационными и не отображаются в стандартных дашбордах, тогда как события с уровнем 12 и выше сигнализируют о критических инцидентах, требующих немедленной реакции. Такая шкала позволяет гибко настраивать систему оповещений: например, отправлять Email или уведомление в мессенджер только для событий выше 7 уровня.

Уровень	Описание
0	Игнорировать — используется для исключений
1–3	Информационные сообщения
4–7	Низкий приоритет, возможные ошибки конфигурации
8–11	Подозрительная активность, требует внимания
12–14	Критические события, высокий приоритет
15	Максимальный уровень — немедленная реакция

Расположение файлов

Как и в случае с декодерами, правила разделены на системные и пользовательские. Встроенный набор (/var/ossec/ruleset/rules/) покрывает большинство стандартных атак и системных событий, но защищен от редактирования. Все кастомные правила и логика исключений должны находиться в /var/ossec/etc/rules/, чаще всего — в файле local_rules.xml. При этом пользовательские правила имеют приоритет, что позволяет «перекрывать» стандартную логику, меняя уровень критичности или описание для конкретных событий под нужды вашей инфраструктуры.

      # Встроенные правила — не редактировать (можно переопределить)
/var/ossec/ruleset/rules/


# Пользовательские правила
/var/ossec/etc/rules/local_rules.xml

Структура правила и ключевые теги

Правило строится на комбинации фильтров. Самый простой вариант — проверка по имени декодера (<decoded_as>) или вхождению подстроки (<match>). Для более сложных сценариев используются композитные правила: связка тегов <frequency> и <timeframe> позволяет отслеживать повторяющиеся события — например, брутфорс. Тег <if_matched_sid> создает цепочки зависимостей, позволяя правилу сработать только в том случае, если перед этим было зафиксировано другое конкретное событие.

      <rule id="100001" level="5">
  <decoded_as>my-app</decoded_as>
  <match>action=login</match>
  <description>Вход в my-app</description>
  <group>authentication,</group>
</rule>


<rule id="100002" level="10">
  <decoded_as>my-app</decoded_as>
  <match>action=login_failed</match>
  <same_srcip />
  <frequency>5</frequency>
  <timeframe>60</timeframe>
  <description>5 неудачных входов за 60 с одного IP</description>
  <group>authentication_failed,</group>
</rule>

Тег	Назначение
<decoded_as>	Фильтр по имени декодера, который обработал событие
<match>	Простое совпадение строки в полном сообщении
<regex>	Regex для поиска в сообщении
<field name=”…”>	Проверка конкретного декодированного поля
<if_matched_sid>	Срабатывает, если ранее сработало правило с указанным ID
<frequency> + <timeframe>	N событий за T секунд — composite-правила
<same_srcip>	Группировать события по одному source IP
<group>	Теги классификации — используются в дашборде и Active Response
<options>no_log</options>	Не писать в лог алертов (для шумных событий)

Пример: правила для CRON

В данном примере мы разделяем обычное выполнение задач и административные действия. Первое правило фиксирует рядовой запуск процесса, присваивая ему низкий уровень приоритета (3), что полезно для общего аудита, но не создает лишнего шума. Второе — реагирует на ключевое слово RELOAD, которое указывает на изменение конфигурации или перезапуск сервиса. Это событие уже имеет уровень 8, так как несанкционированное изменение расписания задач может быть признаком закрепления злоумышленника в системе.

      <group name="cron,">

  <rule id="100010" level="3">
    <decoded_as>cron</decoded_as>
    <description>Задача CRON выполнена</description>
    <group>cron_job,</group>
  </rule>


  <rule id="100011" level="8">
    <decoded_as>cron</decoded_as>
    <match>RELOAD</match>
    <description>Cron-сервис перезапущен</description>
    <group>cron_restart,</group>
  </rule>

</group>

Отладка и диагностика с помощью wazuh-logtest

Утилита wazuh-logtest — это «песочница» для разработчика, которая позволяет мгновенно увидеть результат изменений в конфигах без риска уронить боевой сервер. Процесс тестирования прозрачен: на первой фазе система выделяет базовые метаданные вроде даты и имени программы. Вторая фаза подтверждает, что ваш регулярный паттерн корректно «раскидал» данные по полям. Финальная фаза показывает, какой уровень угрозы присвоен событию и сработало ли правило корреляции. Если вывод пуст или поля не заполнены, это четкий сигнал о том, что ошибка закралась либо в регулярное выражение декодера, либо в логику фильтра <decoded_as>.

Проще говоря, wazuh-logtest позволяет итеративно проверять разбор без перезапуска сервиса:

      /var/ossec/bin/wazuh-logtest


# Пример ввода:
2024-01-15T10:23:45 MyApp: user=admin action=login_failed src=192.168.1.100


# Пример вывода:
**Phase 1: Completed pre-decoding.
       full event: '2024-01-15T10:23:45 MyApp: user=admin ...'


**Phase 2: Completed decoding.
       name: 'my-app-detail'
       user: 'admin'
       action: 'login_failed'
       srcip: '192.168.1.100'


**Phase 3: Completed filtering (rules).
       id: '100002'  level: '10'
       description: '5 неудачных входов за 60 с одного IP'

Для тех, кто предпочитает графический интерфейс, аналогичный функционал доступен wazuh-logtest реализован прямо в браузере. В разделе Wazuh Dashboard → Tools → Ruleset Test можно вставить проблемный лог и получить детальный отчет о срабатывании. Это особенно удобно при совместной работе над правилами, так как позволяет быстро поделиться скриншотом разбора с коллегами.

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

Дополнительные возможности

Помимо сбора логов и корреляции событий, Wazuh предоставляет встроенные модули для комплексной защиты инфраструктуры. 

Security Configuration Assessment (SCA)

Проверяет конфигурацию хостов на соответствие политикам безопасности. Политики описываются в YAML и покрывают стандарты (CIS Benchmarks, PCI DSS, HIPAA) или собственные требования.Каждая проверка возвращает статус  passed  /  failed  /  not applicable . Результаты агрегируются на дашборде в виде итогового процента соответствия по каждому хосту.

Проверки SCA хранятся на каждом агенте в …/ossec/etc/shared/ — там же можно описывать свои Compliance-правила.

      ls -la /var/ossec/etc/shared


agent.conf                       cis_rhel5_linux_rcl.txt          cis_win2012r2_domainL1_rcl.txt   rootkit_trojans.txt
ar.conf                          cis_rhel6_linux_rcl.txt          cis_win2012r2_domainL2_rcl.txt   system_audit_rcl.txt
cis_apache2224_rcl.txt           cis_rhel7_linux_rcl.txt          cis_win2012r2_memberL1_rcl.txt   system_audit_ssh.txt
cis_debian_linux_rcl.txt         cis_rhel_linux_rcl.txt           cis_win2012r2_memberL2_rcl.txt   win_applications_rcl.txt
cis_mysql5-6_community_rcl.txt   cis_sles11_linux_rcl.txt                      win_audit_rcl.txt                merged.mg  
cis_mysql5-6_enterprise_rcl.txt  cis_sles12_linux_rcl.txt         rootkit_files.txt                win_malware_rcl.txt

File Integrity Monitoring (FIM)

Отслеживает изменения файлов: создание, модификацию, удаление, управление правами и владельцами — и директорий в реальном времени:. Реализован через  wazuh-syscheckd и работает на Linux, Windows и macOS.

Среди типичных сценариев — контроль системных файлов (/etc, /bin), обнаружение веб-шеллов, мониторинг конфигов приложений, соответствие PCI DSS и NIST.

Настраивается на каждом агенте в ossec.conf:

        <!-- File integrity monitoring -->
  <syscheck>
    <disabled>no</disabled>


    <!-- Frequency that syscheck is executed default every 12 hours -->
    <frequency>43200</frequency>


    <scan_on_start>yes</scan_on_start>


    <!-- Directories to check  (perform all possible verifications) -->
    <directories>/etc,/usr/bin,/usr/sbin</directories>
    <directories>/bin,/sbin,/boot</directories>


    <!-- Files/directories to ignore -->
    <ignore>/etc/mtab</ignore>
    <ignore>/etc/hosts.deny</ignore>
    <ignore>/etc/mail/statistics</ignore>
    <ignore>/etc/random-seed</ignore>
    <ignore>/etc/random.seed</ignore>
    <ignore>/etc/adjtime</ignore>
    <ignore>/etc/httpd/logs</ignore>
    <ignore>/etc/utmpx</ignore>
    <ignore>/etc/wtmpx</ignore>
    <ignore>/etc/cups/certs</ignore>
    <ignore>/etc/dumpdates</ignore>
    <ignore>/etc/svc/volatile</ignore>


    <!-- File types to ignore -->
    <ignore type="sregex">.log$|.swp$</ignore>


    <!-- Check the file, but never compute the diff -->
    <nodiff>/etc/ssl/private.key</nodiff>


    <skip_nfs>yes</skip_nfs>
    <skip_dev>yes</skip_dev>
    <skip_proc>yes</skip_proc>
    <skip_sys>yes</skip_sys>


    <!-- Nice value for Syscheck process -->
    <process_priority>10</process_priority>


    <!-- Maximum output throughput -->
    <max_eps>50</max_eps>


    <!-- Database synchronization settings -->
    <synchronization>
      <enabled>yes</enabled>
      <interval>5m</interval>
      <max_eps>10</max_eps>
    </synchronization>
  </syscheck>

Vulnerability Detector

Автоматически сопоставляет инвентаризацию ПО с базами CVE. По умолчанию загружает базы с cti.wazuh.com. Можно переключиться на собственные источники и подключить несколько баз одновременно:

      # Вариант со статичным файлом
  
  <vulnerability-detection>
    <enabled>yes</enabled>
    <index-status>yes</index-status>
    <feed-update-interval>12h</feed-update-interval>
    <offline-url>file:///cves/cves.zip</offline-url>
  </vulnerability-detection>
  
  # Вариант с http/https
  
  <vulnerability-detection>
    . . . 
    <offline-url>https://example.com/cves.zip</offline-url>
  </vulnerability-detection>

Дашборд отображает CVE-идентификатор, уровень (Critical / High / Medium / Low), затронутый пакет, наличие исправления:

MITRE ATT&CK

Wazuh автоматически сопоставляет правила с тактиками и техниками MITRE ATT&CK. Встроенные правила уже содержат маппинг, а для своих правил достаточно добавить:

      <rule id="100100" level="10">
  <decoded_as>my-app</decoded_as>
  <match>lateral_movement</match>
  <description>Признак бокового перемещения</description>
  <mitre>
    <id>T1021</id>   <!-- Remote Services -->
    <id>T1078</id>   <!-- Valid Accounts -->
  </mitre>
</rule>

IT Hygiene (инвентаризация)

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

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

Threat Hunting

Проактивный поиск угроз через интерфейс OpenSearch Dashboard. Аналитик строит произвольные запросы KQL / Lucene по всем накопленным событиям, не ограничиваясь готовыми правилами.

Среди типичных сценариев использования — поиск IOC (хэши, IP, домены) по историческим данным, исследование цепочки событий вокруг подозрительного процесса, кросс-хостовый анализ аномалий.

Заключение

В этой статье мы подробно разобрали архитектуру и системы в Wazuh. Справочник можно использовать по мере необходимости, когда нужно настроить SIEM или отдельные его компоненты в своем проекте.