Wazuh на сервере: частые ошибки и решения

MAATRIX

Wazuh редко ломается целиком — обычно один из трёх компонентов (manager, indexer, dashboard) тихо перестаёт получать данные от другого, и вы узнаёте об этом не по алерту, а по тому, что алертов вообще нет. Разберём шесть ситуаций, с которыми чаще всего сталкиваются на боевом сервере: от агента, который упорно висит в статусе Disconnected, до диска, который забивается индексами за пару недель — с конкретными командами диагностики и рабочими решениями.

Архитектура из трёх частей — и где между ними рвётся

Начиная с 4-й ветки Wazuh — это не единый процесс, а три отдельных сервиса, которые общаются между собой по сети, и большинство «странных» проблем на деле — это разрыв именно на стыке:

Прежде чем разбирать конкретную ошибку, полезно понять, в каком звене она возникла: агент не достучался до manager, manager не отдал данные в indexer через Filebeat, или dashboard не смог прочитать их из indexer. Это три разных набора логов (/var/ossec/logs/ossec.log, journalctl -u filebeat, journalctl -u wazuh-dashboard), и симптомы на глаз легко перепутать.

Агент висит в статусе Disconnected, хотя сеть работает

Самая частая жалоба: в списке агентов (Agents в dashboard или /var/ossec/bin/agent_control -l на manager) агент числится Disconnected, при этом ping до него проходит и firewall вроде не блокирует ничего. Причины обычно две.

Первая — агент действительно не шлёт keepalive на порт 1514, и это видно в логе агента:

tail -f /var/ossec/logs/ossec.log

Если там Unable to connect to '<manager-ip>', проверяйте по порядку: правильный ли IP/hostname указан в <address> секции <client> файла /var/ossec/etc/ossec.conf на агенте, открыт ли порт 1514 в файрволе на стороне сервера с manager, и не изменился ли IP сервера после миграции (частая ситуация при переезде на новый VPS — адрес в конфиге агента остался старым).

# на сервере с manager
sudo ss -tulnp | grep 1514
sudo ufw allow 1514/tcp

Вторая причина — сеть в порядке, keepalive доходит, но время на агенте и manager разошлось сильнее, чем допускает проверка. Wazuh чувствителен к рассинхрону часов: если NTP не настроен, manager может помечать события агента как невалидные. Проверка и синхронизация:

timedatectl status
sudo apt install -y chrony && sudo systemctl enable --now chrony

Порог, после которого manager помечает агента отключённым при отсутствии keepalive, задаётся в <global><agents_disconnection_time> секции ossec.conf на manager (по умолчанию порядка нескольких минут) — при нестабильном аплинке и агенте, который периодически «мигает» без реальных проблем, есть смысл немного увеличить это значение.

Агент не может зарегистрироваться: ошибка на порту 1515

Отдельная категория ошибок — не «отключился», а «вообще не смог присоединиться» при первой установке. В логе агента это выглядит так:

ERROR: (1746): Could not connect to enrollment service at '<manager-ip>':1515

Регистрацией занимается wazuh-authd на стороне manager, и он слушает отдельный порт 1515, независимый от 1514, на котором ходит уже рабочий трафик. Частая ошибка новичков — открыть в firewall только 1514, решив, что «раз агенты подключаются, порт один». Проверьте, что служба вообще запущена и слушает:

sudo /var/ossec/bin/wazuh-control status
sudo ss -tulnp | grep 1515

Если регистрация настроена через общий пароль (а не через доверие по IP), пароль лежит в /var/ossec/etc/authd.pass на manager, и его нужно передать при регистрации агента явно:

sudo /var/ossec/bin/agent-auth -m <manager-ip> -A <agent-name> -P '<пароль-из-authd.pass>'

Ещё одна типичная ситуация — «дублирующийся» агент после клонирования VPS из снапшота: у нового хоста остаётся тот же client.keys, что и у образа, и manager путает два сервера под одним ID. Перед клонированием шаблона всегда сбрасывайте регистрацию:

sudo systemctl stop wazuh-agent
sudo rm -f /var/ossec/etc/client.keys

и регистрируйте заново уже на реальном сервере, а не на образе-шаблоне.

Wazuh indexer не стартует или уходит в red

Indexer — это форк OpenSearch, и он наследует все его требования к системным лимитам. Если после установки wazuh-indexer не поднимается, первым делом смотрите статус и последние строки лога:

sudo systemctl status wazuh-indexer
sudo journalctl -u wazuh-indexer --since "10 min ago"

Классическая причина отказа — заниженный vm.max_map_count: indexer, как и любой продукт на базе Lucene, активно использует mmap и не запускается в «продакшн-режиме» без запаса по числу областей памяти:

sudo sysctl -w vm.max_map_count=262144
echo 'vm.max_map_count=262144' | sudo tee -a /etc/sysctl.conf

Если сервис стартует, но curl до него не отвечает или кластер в состоянии red, проверяйте здоровье через API (indexer работает по HTTPS с самоподписанными сертификатами, поэтому нужен -k и авторизация):

curl -k -u admin:<пароль> "https://localhost:9200/_cluster/health?pretty"

red почти всегда означает нехватку диска (сработал watermark и часть индексов ушла в read-only) или heap, который упирается в лимит и роняет ноду под нагрузкой. Heap задаётся в /etc/wazuh-indexer/jvm.options через -Xms/-Xmx — оба значения должны совпадать и не превышать примерно половину RAM сервера. Логика настройки heap и watermark подробно разобрана на примере родственного движка в статье Elasticsearch на сервере: частые ошибки и решения — большинство выводов применимо к indexer почти без изменений.

Dashboard открывается, но алертов нет (хотя manager их точно генерирует)

Пугающая на первый взгляд ситуация: /var/ossec/logs/alerts/alerts.json на manager растёт, события явно приходят, а в веб-интерфейсе — пусто или ошибка вида «Wazuh App: сервер не готов». В девяти случаях из десяти проблема в Filebeat — именно он отвечает за доставку алертов из manager в indexer, и сам Wazuh dashboard тут ни при чём.

sudo systemctl status filebeat
sudo journalctl -u filebeat --since "30 min ago" | grep -i error
sudo filebeat test output

Частые причины: модуль wazuh для Filebeat не включён или не переустановлен после обновления Wazuh, неверный адрес indexer в output.elasticsearch.hosts файла /etc/filebeat/filebeat.yml, либо просроченный/несовпадающий сертификат — каждый компонент получает свой сертификат при развёртывании через wazuh-certs-tool.sh, и смена hostname сервера после их генерации ломает проверку без явного предупреждения в интерфейсе.

Второй по частоте случай — сам dashboard не может достучаться до indexer (а не Filebeat до него достучаться не может). Проверяется отдельно:

sudo systemctl status wazuh-dashboard
sudo cat /etc/wazuh-dashboard/opensearch_dashboards.yml | grep hosts

Здесь важно убедиться, что адрес indexer в конфиге dashboard совпадает с реальным (после переноса на другой сервер его иногда забывают поправить), и что порт 9200 доступен именно с хоста dashboard, а не только с localhost, если компоненты разнесены по разным серверам.

Шум в алертах: слишком много ложных срабатываний

Wazuh из коробки достаточно чувствителен, и на свежей установке дашборд быстро заполняется низкоуровневыми событиями — рутинными изменениями в системных файлах, штатными попытками SSH-логина с известных адресов, нормальными действиями cron. Это не баг, а сигнал настроить правила под конкретный сервер, а не под усреднённый профиль по умолчанию.

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

sudo /var/ossec/bin/wazuh-logtest

Вставьте туда строку из реального лога — утилита покажет, какое правило её поймало, с каким уровнем важности и почему. Правки правил не трогают системные файлы в /var/ossec/ruleset/, они перезаписываются при обновлении — все кастомные правила и исключения нужно класть в /var/ossec/etc/rules/local_rules.xml:

<group name="local,syslog,sshd,">
  <rule id="100010" level="0">
    <if_sid>5716</if_sid>
    <srcip>203.0.113.10</srcip>
    <description>Игнорировать неуспешные SSH с доверенного IP мониторинга</description>
  </rule>
</group>

Уровень 0 фактически отключает алерт по конкретному условию, не убирая при этом обнаружение целиком — это осторожнее, чем выключать правило глобально. После правки конфигурации перезапуск обязателен, иначе изменения не применятся:

sudo /var/ossec/bin/wazuh-control restart

Если правите syscheck (мониторинг целостности файлов) и он шумит на директориях с часто меняющимися временными файлами приложения — добавьте их в <ignore> внутри <syscheck> секции ossec.conf, а не отключайте модуль целиком. Для серверов, где уже настроен аудит через auditd, стоит свести обе системы воедино, а не дублировать логирование — как это сделать, разобрано в статье аудит логов сервера: настройка auditd.

Диск заполняется: архивы, alerts.json и индексы без ротации

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

На стороне manager за размер алертов и архивов отвечает секция <rotation> внутри <global> в ossec.conf; по умолчанию Wazuh сам ротирует и сжимает alerts.json посуточно, но полное логирование всех событий (<logall>yes</logall>), которое пишет ещё и archives.json, стоит держать выключенным, если построчный архив всего трафика не нужен — он легко удваивает объём записи на диск без соразмерной пользы для расследований.

На стороне indexer растут сами индексы wazuh-alerts-4.x-* — без политики Index State Management (ISM) они не удаляются автоматически. При установке через официальный дистрибутив ISM-политика с ротацией обычно создаётся сама, но если stack ставился вручную, стоит явно проверить, что она применена к нужному паттерну индексов, а не осталась заглушкой. Общий подход к тому, чтобы диск не забивался логами любого типа, разобран в статье ротация логов, чтобы не забивался диск.

Если Wazuh используется для соответствия требованиям (compliance) и логи нужно хранить дольше, чем разумно держать «горячими» в indexer — разумнее выгружать старые индексы в холодное хранилище отдельно, а не наращивать диск под живой кластер бесконечно. Разделение хранения по назначению для задач комплаенса разобрано в статье интеграция VPN и SIEM для логирования и комплаенса.

Частые вопросы