Андрей Ефремов

Что такое Wazuh Для хранения событий в составе Wazuh используется другой продукт с открытым исходным кодом — OpenSearch, который позволяет хранить логи, искать и анализировать данные в реальном времени. Ключевые преимущества Wazuh — open source-проект. Код открыт для изменений и аудита. Возможности уровня Enterprise. Полноценный SIEM, IDS, VM и SCA в одном продукте без вендорской зависимости. Гибкое развертывание. Можно использовать пакеты, Docker-контейнеры, Kubernetes. Активное сообщество. Проект может похвастаться регулярными обновлениями правил, интеграцией со сторонними продуктами, наличием подробной документации. Поддержка IdP. Интеграция с OIDC/SAML-провайдерами и LDAP из коробки. Кроссплатформенность. Wazuh можно поставить на сервер с Windows, Linux, macOS, а также установить на сетевые устройства. Архитектура Wazuh Wazuh состоит из пяти компонентов. Каждый выполняет строго определенную роль — это позволяет горизонтально масштабировать нагрузку. КомпонентРольОсобенностиMaster NodeRESTful API, управление кластером и агентамиТолько одна Master Node на кластер — репликация не поддерживаетсяWorker NodeРазбор событий (decoders), Применение правил (rules), Обогащение событийМожно масштабировать горизонтальноIndexerХранение событий, Управление индексамиПоддерживает репликацию и кластеризациюDashboardВеб-интерфейс, Визуализация данныхПереработанный OpenSearch DashboardAgentСбор событий, 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-execdActive Response: исполнение скриптов блокировки и реагированияwazuh-logcollectorСбор логов из файлов, journald, windows eventswazuh-syscheckdFIM: обнаружение изменений файлов и директорийwazuh-modulesdSCA, Vulnerability Detector, инвентаризация, Docker-listenerwazuh-dbSQLite-менеджер БД агентов (инвентаризация, FIM, статусы)wazuh-apidRESTful API (JWT): управление кластером, агентами, правиламиwazuh-clusterdКластеризация: синхронизация между Master и Workerwazuh-integratordИнтеграции: Slack, PagerDuty, VirusTotal и др.wazuh-maildEmail-уведомления об алертахwazuh-monitordМониторинг агентов, ротация лог-файлов сервераwazuh-csyslogdПересылка алертов во внешние syslog-серверыwazuh-agentlessdМониторинг без агента (SSH / telnet)wazuh-dbdКоннектор к внешним БД (MySQL, PostgreSQL)wazuh-reportdГенерация отчетов на основе алертов Сбор логов Агент собирает логи через модуль Logcollector (обычный Filebeat/Ingest Pipelines под капотом), сервер — анализирует их в реальном времени: декодеры разбирают (токенизируют) события, движок Analysisd сопоставляет их с правилами и создает алерты. Сбор логов осуществляется с помощью инструкции в ossec.conf. Куда пишутся результаты обработанных событий Все результаты обработанных событий сохраняются на Worker / Master Node. Сбор всех событий включается в ossec.conf тегами и . В продакшене обязательно отключайте опцию, иначе она быстро заполнит диск. Конфигурации сбора логов Локальная конфигурация (ossec.conf на агенте) — основной конфигурационный файл. Настройки применяются только к данному агенту. ОСПутьLinux / Unix/var/ossec/etc/ossec.confWindowsC:\Program Files (x86)\ossec-agent\ossec.confmacOS/Library/Ossec/etc/ossec.conf Централизованная конфигурация (agent.conf на сервере) распространяет настройки сразу на группы агентов. Это полезно, например, если необходимо иметь разные конфигурации для dev/stage/prod-окружений. При этом agent.conf имеет приоритет над локальным ossec.conf на агенте. Сбор логов и событий из файлов Конфигурация описывается в блоке . Агент поддерживает несколько способов указания путей. Обычный файл (статический путь) — используется для сервисов с фиксированным именем лога. Файл с датой в имени (strftime) — подходит, Если приложение создает новый файл каждые сутки (например, file-23-06-15.log). Wildcard-паттерны (маски) — удобно, если имен файлов много и они создаются динамически. При этом поиск новых файлов происходит не мгновенно, а с интервалом, заданным конфигурацией агента. Переменные окружения (только Windows) — позволяет использовать системные пути независимо от буквы диска или имени папки Windows. Поддерживаемые форматы и типы логов Wazuh должен понимать структуру входящих данных. syslog — стандарт для текстовых логов, где одна строка отвечает за одно событие. json — самый эффективный формат. Если выбрать json , Wazuh автоматически распарсит поля. Создавать кастомный decoder в этом случае не требуется — данные сразу попадут в поиск в структурированном виде. multi-line — используется для многострочных логов, например Java Stacktrace или логи Oracle. Позволяет объединять строки в одно событие на основе регулярного выражения. command — позволяет превратить вывод любой CLI-команды в лог-событие (например, мониторинг свободного места на диске). Обогащение данных через метки (Labels) Метки позволяют добавить к каждому событию контекст, который упрощает фильтрацию в Dashboard. Это критически важно для большой инфраструктуры, чтобы понимать, из какого филиала, окружения (prod/dev) или от какого заказчика пришел лог. Используйте код с осторожностью. Обычные метки — добавляются в JSON-событие и видны в поиске. Скрытые метки (hidden"yes") — используются только «внутри» сервера Wazuh для срабатывания правил (rules), но не сохраняются в индекс базы данных, экономя место в хранилище. Тонкая настройка производительности Если ваше приложение генерирует тысячи строк в секунду, агент может перегрузить процессор или сеть. Для защиты предусмотрен Client Buffer. Лимит событий. Параметр events_per_second ограничивает интенсивность отправки. Чтение с начала. По умолчанию агент читает только новые строки. Чтобы просканировать старый файл целиком при первом запуске, используйте параметр no . Сбор логов из Systemd Journald В современных Linux-системах большинство сервисов пишут логи не в текстовые файлы, а напрямую в бинарный журнал journald. Wazuh-агент умеет подключаться к нему напрямую, извлекая данные в структурированном виде и конвертируя их в формат syslog для сервера. По умолчанию сбор из журнала часто уже включен в базовом конфиге: Чтобы не перегружать сервер Wazuh второстепенными событиями, в блоке journald можно использовать фильтры по конкретным полям юнитов или уровням важности (приоритетам). 1. Сбор логов только конкретного сервиса (например, SSH): 2. Фильтрация по приоритету (на примере CRON): Здесь мы собираем логи планировщика, исключая отладочную информацию (Priority 7 — Debug), оставляя только события от 0 (Emergency) до 6 (Informational). 3. Мониторинг Docker-контейнеров: Если Docker настроен на использование драйвера journald, вы можете собирать логи демона (или самих контейнеров) аналогичным образом, как показано в примере. При этом вам не нужно заботиться о правах доступа к файлам в /var/log или ротации логов — агент работает с системным API журнала, что гораздо надежнее. Сбор логов через Event Channels (Windows) Для ОС Windows сбор текстовых логов из файлов — вторичная задача. Основной поток данных идет из журнала событий (Event Viewer). Начиная с современных версий Windows, Wazuh использует формат eventchannel, который позволяет подписываться на конкретные каналы событий, включая системные, приложения и журналы безопасности. Сбор логов через Syslog (от устройств без агента) Для сетевого оборудования (коммутаторы, роутеры, межсетевые экраны) и старых Legacy-систем, на которые невозможно установить агент, Wazuh может работать как классический Syslog-сервер. В отличие от предыдущих примеров, эта конфигурация вносится в файл ossec.conf на стороне сервера (Wazuh Manager) в блоке : Ключевые параметры . Стандартный порт 514. Можно изменить на любой свободный, если на сервере уже работает другой syslog-демон, например rsyslog. . Поддерживаются udp и tcp. Для сетевого оборудования чаще используется UDP. . Критически важная настройка безопасности. Укажите конкретные IP-адреса или подсети устройств, которым разрешено присылать логи. Это защитит сервер от лишнего шума и потенциальных атак. . IP-адрес интерфейса сервера, на котором Wazuh будет ожидать входящие пакеты. Декодеры (Decoders) Декодеры — инструкции для Wazuh, как разобрать сырую строку лога на именованные поля. Без корректного декодера правило не сможет проверить конкретное значение в событии. Как работает декодер Когда лог попадает на сервер, за него принимается демон Analysisd. Его задача — превратить неструктурированную строку текста в набор именованных полей (например, srcip, user, status), по которым потом можно будет строить графики и фильтры. Процесс разбора идет в два этапа. Родительский декодер (Prematch). Движок ищет ключевое слово или паттерн, который идентифицирует программу (например, слово sshd или nginx). Если совпадение найдено, лог закрепляется за этим декодером. Дочерний декодер (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 строятся по иерархической модели. Это позволяет экономить ресурсы сервера: вместо проверки каждой строки и тысяч регулярных выражений, система сначала быстро отсеивает нужный тип лога по «родителю», а затем применяет к нему детальный разбор. ТегНазначение Быстрая фильтрация строк по regex — только подходящие идут дальше Имя родительского декодера, создаёт иерархию Regex для извлечения данных (группы захвата) Имена полей в том же порядке, что группы в Тип: ossec, syslog, json, windows и др. Встроенный плагин (JSON, Windows Events и т. д.) Пример: декодер для CRON Родительский декодер через prematch находит характерную метку \(\S+\) CMD, подтверждая принадлежность строки к сервису. Следом дочерний декодер, ссылаясь на parent, с помощью регулярного выражения regex извлекает имя пользователя и саму команду в соответствующие поля user и command. В результате вместо сырой строки в интерфейсе Wazuh появляются готовые фильтры для поиска запусков конкретных скриптов. Проверка через wazuh-logtest Это основной инструмент для отладки конфигурации, позволяющий проверить работу декодеров и правил в реальном времени без перезапуска сервиса. Достаточно запустить утилиту и вставить в консоль строку лога — система прогонит ее через три фазы анализа. На первой происходит выделение системных полей, на второй — полноценный разбор пользовательским декодером с извлечением именованных полей, а на третьей — сопоставление с правилами для определения уровня опасности события. Правила (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. При этом пользовательские правила имеют приоритет, что позволяет «перекрывать» стандартную логику, меняя уровень критичности или описание для конкретных событий под нужды вашей инфраструктуры. Структура правила и ключевые теги Правило строится на комбинации фильтров. Самый простой вариант — проверка по имени декодера ( ) или вхождению подстроки ( ). Для более сложных сценариев используются композитные правила: связка тегов и позволяет отслеживать повторяющиеся события — например, брутфорс. Тег создает цепочки зависимостей, позволяя правилу сработать только в том случае, если перед этим было зафиксировано другое конкретное событие. ТегНазначение Фильтр по имени декодера, который обработал событие Простое совпадение строки в полном сообщении Regex для поиска в сообщении Проверка конкретного декодированного поля Срабатывает, если ранее сработало правило с указанным ID + N событий за T секунд — composite-правила Группировать события по одному source IP Теги классификации — используются в дашборде и Active Response no_log Не писать в лог алертов (для шумных событий) Пример: правила для CRON В данном примере мы разделяем обычное выполнение задач и административные действия. Первое правило фиксирует рядовой запуск процесса, присваивая ему низкий уровень приоритета (3), что полезно для общего аудита, но не создает лишнего шума. Второе — реагирует на ключевое слово RELOAD, которое указывает на изменение конфигурации или перезапуск сервиса. Это событие уже имеет уровень 8, так как несанкционированное изменение расписания задач может быть признаком закрепления злоумышленника в системе. Отладка и диагностика с помощью wazuh-logtest Утилита wazuh-logtest — это «песочница» для разработчика, которая позволяет мгновенно увидеть результат изменений в конфигах без риска уронить боевой сервер. Процесс тестирования прозрачен: на первой фазе система выделяет базовые метаданные вроде даты и имени программы. Вторая фаза подтверждает, что ваш регулярный паттерн корректно «раскидал» данные по полям. Финальная фаза показывает, какой уровень угрозы присвоен событию и сработало ли правило корреляции. Если вывод пуст или поля не заполнены, это четкий сигнал о том, что ошибка закралась либо в регулярное выражение декодера, либо в логику фильтра . Проще говоря, wazuh-logtest позволяет итеративно проверять разбор без перезапуска сервиса: Для тех, кто предпочитает графический интерфейс, аналогичный функционал доступен 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-правила. File Integrity Monitoring (FIM) Отслеживает изменения файлов: создание, модификацию, удаление, управление правами и владельцами — и директорий в реальном времени:. Реализован через wazuh-syscheckd и работает на Linux, Windows и macOS. Среди типичных сценариев — контроль системных файлов (/etc, /bin), обнаружение веб-шеллов, мониторинг конфигов приложений, соответствие PCI DSS и NIST. Настраивается на каждом агенте в ossec.conf: Vulnerability Detector Автоматически сопоставляет инвентаризацию ПО с базами CVE. По умолчанию загружает базы с cti.wazuh.com. Можно переключиться на собственные источники и подключить несколько баз одновременно: Дашборд отображает CVE-идентификатор, уровень (Critical / High / Medium / Low), затронутый пакет, наличие исправления: MITRE ATT&CK Wazuh автоматически сопоставляет правила с тактиками и техниками MITRE ATT&CK. Встроенные правила уже содержат маппинг, а для своих правил достаточно добавить: IT Hygiene (инвентаризация) Автоматически собирает с каждого агента список пакетов, запущенные процессы, открытые порты, локальных пользователей и группы, запущенные службы. Обновляется по расписанию. Позволяет ответить без дополнительных инструментов, какие версии ПО в организации, есть ли устаревшее ПО, кто имеет локальный доступ, какие процессы запущены и т. д. Threat Hunting Проактивный поиск угроз через интерфейс OpenSearch Dashboard. Аналитик строит произвольные запросы KQL / Lucene по всем накопленным событиям, не ограничиваясь готовыми правилами. Среди типичных сценариев использования — поиск IOC (хэши, IP, домены) по историческим данным, исследование цепочки событий вокруг подозрительного процесса, кросс-хостовый анализ аномалий. Заключение В этой статье мы подробно разобрали архитектуру и системы в Wazuh. Справочник можно использовать по мере необходимости, когда нужно настроить SIEM или отдельные его компоненты в своем проекте.

Андрей Ефремов

Материалы автора

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