Как известно, SIEM‑системы предназначены для обнаружения угроз и мониторинга безопасности, но при этом важно учитывать, что и сама SIEM является сложной распределенной системой, с которой также могут возникнуть различные проблемы. Так, к примеру, в Wazuh может отключиться агент, переполниться диск с логами или перестать работать менеджер. В этой статье мы рассмотрим практические подходы к мониторингу состояния Wazuh, чтобы вы всегда были уверены в его работоспособности.
Мониторинг системы мониторинга
Прежде, чем приступать к рассмотрению практических примеров, давайте разберемся, с тем, а зачем вообще нужно следить за состоянием здоровья вашей SIEM системы. Давайте представим ситуацию, когда на вашу сеть идет атака, но ваш Wazuh‑менеджер «упал» час назад, и вы не получили ни одного предупреждения. Или еще худший сценарий: диск с индексами Elasticsearch заполнен, и новые логи просто не записываются, создавая слепую зону в безопасности. Мониторинг состояния самой системы Wazuh позволяет избежать подобных сценариев.
Мониторинг состояния агентов
Начнем с первой линии при сборе событий — агентов. Здесь нам необходимо на регулярной основе отслеживать подключение агентов. Каждый агент осуществляет сбор событий с определенной группы источников, и, если по какой‑либо причине этот агент перестанет работать, мы не сможем обнаружить атаки на эти узлы.
Для выявления проблем с агентами можно использовать различные средства. Прежде всего, можно воспользоваться веб‑консолью администрирования Wazuh.
В консоли перейдите в раздел Agents management. Здесь вы увидите сводку: количество активных, отключенных и никогда не подключавшихся агентов. Зеленый индикатор Active — всё хорошо.
В случае, если у вас используются внешние системы мониторинга, такие как Zabbix или Prometheus, то лучшим решением будет мониторинг через Wazuh API. Вы просто можете выполнить GET‑запрос к агенту и получить структурированные JSON‑данные о статусе каждого агента. Более подробно о работе с Wazuh API можно узнать в статье.
На сервере Wazuh также имеется функционал для проверки состояния агентов. Так, с помощью утилиты agent_control можно быстро узнать о статусе всех агентов или какого‑то конкретного.
Показать статус всех агентов:
/var/ossec/bin/agent_control -l
Показать статус конкретного агента (например, с ID 001):
/var/ossec/bin/agent_control -i 001
Вывод покажет, активен ли агент (Active), отключен (Disconnected) или находится в ожидании (Pending).
Также, мы можем проверить статус на самом агенте через файл состояния. Например, если вы подозреваете проблемы на стороне агента, можно пров��рить его локальный статус.
sudo grep ^status /var/ossec/var/run/wazuh-agentd.state
Возможные статусы: connected, disconnected, pending.
Итак, мы разобрались с мониторингом состояния агентов. Теперь перейдем непосредственно к ядру системы и поговорим о мониторинге Wazuh Manager.
Самонаблюдаемая система
Для критически важных компонентов, таких как Wazuh Manager, можно реализовать систему самодиагностики, которая не только сигнализирует о проблеме, но и пытается ее исправить. Мы можем написать bash‑скрипт, который проверяет ключевые процессы менеджера (wazuh‑authd, wazuh‑db, и др.). Если процесс не работает, скрипт пытается его перезапустить и логирует свои действия в JSON‑файл.
Вот пример подобного скрипта, найденный на просторах Github:
#!/bin/bash # Определяем IP хоста host=$(ip route get 8.8.8.8 | awk -F"src " 'NR==1{split($2,a," ");print a[1]}') # Проверяем процесс wazuh-authd if pgrep wazuh-authd > /dev/null; then echo "{\"host\":\"$host\", \"process\":\"wazuh-authd\", \"status\":\"healthy\"}" >> /tmp/health.json else echo "{\"host\":\"$host\", \"process\":\"wazuh-authd\", \"status\":\"attempting_restart\"}" >> /tmp/health.json systemctl restart wazuh-manager # Здесь можно добавить проверку после рестарта fi
Далее этот скрипт можно выполнять по расписанию. Но неплохо было уведомить администратора Wazuh о том, что м одним из компонентов системы произошел сбой.
Для того, чтобы данные из скрипта попали в Wazuh и стали видимыми в дашборде, создадим правило корреляции, которое будет регулярно проверять содержимое файла /tmp/health.json.
Для этого добавьте в файл /var/ossec/etc/rules/local_rules.xml правила, которые будут реагировать на статусы из health.json. Например, вот правило, которое сработает, если какой‑то процесс не здоров или была попытка перезапуска.
<group name="wazuh_healthcheck"> <rule id="100100" level="12"> <field name="status">attempting_restart</field> <description>Wazuh Manager: Process $(process) on $(host) is down. Restart attempted.</description> </rule> </group>
Этот подход превращает Wazuh в самонаблюдаемую систему, которая не только ищет угрозы вовне, но и следит за собственным «здоровьем».
Мониторинг производительности и системных метрик
Мы рассмотрели варианты, когда Wazuh следит за своими компонентами сам, но лучше на этом не ограничиваться и использовать внешнюю систему для сбора метрик с него. Вот несколько метрик, по которым можно оценить общее состояние компонентов Wazuh:
Размер очереди логов: Если входящий поток событий слишком велик, очередь может переполняться, и часть данных будет потеряна. За этим нужно следить.
Использование диска: Wazuh Indexer (Elasticsearch) очень чувствителен к заполнению диска. При заполнении диска индексация останавливается. Мониторинг места на дисках с логами — обязательная процедура.
Ресурсы: Загрузка CPU и RAM на сервере Wazuh напрямую влияет на скорость обработки событий.
Состояние кластера: Если у вас кластерная установка, необходимо отслеживать состояние нод и их синхронизацию.
Эти метрики лучше всего собирать внешней системой мониторинга, такой как Zabbix, Prometheus + Grafana или встроенными средствами Elastic Stack.
Мониторинг пользовательских сценариев и команд
Помимо прочего, Wazuh позволяет выполнять произвольные команды на агентах. Данный функционал можно использовать для проактивной проверки работоспособности сервисов, а не только для поиска угроз. Например, если нам необходимо убедиться в том, что процесс Cron постоянно работает, мы можем настроить на агенте выполнение команды ps с определенной периодичностью.
Для этого добавляем в ossec.conf следующее:
<localfile> <log_format>full_command</log_format> <command>ps -auxw | grep [c]ron</command> <alias>check_cron_status</alias> <frequency>300</frequency> <-- Каждые 5 минут --> </localfile>
На стороне сервера нам необходимо указать следующее:
<group name="service_monitor,"> <rule id="100010" level="0"> <if_sid>530</if_sid> <match>^ossec: output: 'check_cron_status'</match> <description>Cron check executed.</description> </rule> <rule id="100011" level="10"> <if_sid>100010</if_sid> <match>cron</match> <description>CRITICAL: Cron process is NOT running!</description> </rule> </group>
В результате правило 100 010 срабатывает на любой вывод нашей команды. А идущее за ним правило 100 011 проверяет, есть ли в выводе слово «cron».
Обратите внимание на конструкцию [c]ron в команде ps. Она используется, чтобы сам grep не находил сам себя в выводе. В результате, если Cron не запущен, команда ps не вернет строк с «cron», и правило 100 011 сработает, создав критический алерт.
Заключение
Мониторинг состояния самого Wazuh так же важен, как и мониторинг безопасности инфраструктуры, осуществляемый с его помощью. Используя комбинацию встроенных инструментов (дашборд, API), внешних систем (Zabbix) и кастомизированных скриптов, вы можете построить надежную систему самоконтроля. Реализовав эти практики, вы превратите Wazuh из пассивного сборщика логов в активного стража, за здоровьем которого вы следите так же пристально, как и за здоровьем вашей инфраструктуры.
Когда SIEM сама становится источником слепых зон, цена ошибки — не алерт, а пропущенная атака. На курсе по SIEM вы разбираете архитектуру, внедрение и эксплуатацию таких систем на практике: от настройки сбора событий до сценариев реагирования и контроля их «здоровья». Это как раз тот уровень, где перестаешь просто смотреть в дашборд и начинаешь понимать, что в нем на самом деле происходит.
А чтобы узнать больше о формате обучения и задать вопросы экспертам, приходите на бесплатные уроки:
8 апреля в 20:00 «Настройка аудита событий информационной безопасности в Windows». Записаться
21 апреля в 20:00 «Архитектура контроля событий информационной безопасности в инфраструктуре на базе SIEM». Записаться
