Проверка доставки событий в Wazuh: агент «зелёный» ещё не журнал

Проверьте доставку: с критичного хоста в Wazuh приходят события журнала, а не только keepalive. Статус Active значит «агент стучится», не «auth.log читается». Установку и агентов не повторяем: Wazuh в Docker. Доля «агент стоит» в отчёте — другая цифра: метрика покрытия. Какие правила потом сработают — правила выявления.

Статья опирается на логику направления «Мониторинг кибербезопасности» из методики зрелости Группы Сбер (источник); это методика для крупных компаний, мы используем её как ориентир и пересказываем своими словами. CIS Control 8 требует собирать журналы и проверять, что сбор идёт: cisecurity.org/controls. Поля агента status и lastKeepAlive — в API Wazuh: Listing agents. Это не российский закон. Команды — на своей системе.

Три слоя, которые путают

Список агентов на менеджере (имена контейнера подставьте свои, как в статье про установку):

docker exec single-node-wazuh.manager-1 /var/ossec/bin/agent_control -l

Ожидаемо: нужный хост Active. Без Docker тот же бинарник: /var/ossec/bin/agent_control -l. Keepalive менеджер считает отдельно; время отключения задаёт agents_disconnection_time в <global>: global options.

Контрольное событие

На агенте Linux посмотрите, что реально читается:

sudo grep -A2 localfile /var/ossec/etc/ossec.conf

Ожидаемо: путь к auth.log или journald. Как добавляют файлы — документация Wazuh: monitoring log files. Затем обычный вход sudo на этом хосте (не подбор пароля и не сканирование):

sudo -n true
date -u +%Y-%m-%dT%H:%M:%SZ

Запомните время UTC и имя хоста. На менеджере:

sudo grep -F "ИМЯ_ХОСТА" /var/ossec/logs/alerts/alerts.json | tail

В Docker путь внутри контейнера менеджера тот же относительно /var/ossec. Должна появиться строка про сессию sudo/PAM около этого времени. Если Active есть, а строки нет — доставки журнала нет: неверный путь localfile, агент не в группе с agent.conf, диск менеджера, отсечка EPS. Не включайте logall навсегда: в архив пишутся все события, диск заканчивается; это переключатель отладки, по умолчанию в примере Wazuh стоит no.

Какие события системы обязаны писать — не этот рецепт: политика журналирования. Сбор на хосте без Wazuh: journald и rsyslog.

Риск: считать покрытие по Active и спать. При инциденте окажется, что недели не было ни одной строки с кассы.

Диагностика

Где это в модели зрелости

Материал относится к направлению «Мониторинг кибербезопасности» (хаб: мониторинг, карта: карта зрелости). Установка Wazuh закрывает наличие системы. Без пробы доставки метрика покрытия врёт. Политика журналирования скажет что писать; эта страница — дошло ли.

Как проверить

1. По трём критичным хостам из реестра есть дата последней строки события, не только lastKeepAlive.
2. Контрольный sudo (или аналог на Windows) за последний месяц найден в alerts.json.
3. Хост с Active без событий не стоит в числителе «журналы» метрики покрытия.
4. Статья не повторяет docker-compose и не добавляет новых правил атаки.
5. logall в продуктивном <global> снова no, если включали для отладки.

Источники

• Wazuh, listing agents: documentation.wazuh.com.
• Wazuh, global (logall, disconnection time): documentation.wazuh.com.
• Wazuh, monitoring log files: documentation.wazuh.com.
• CIS Control 8: cisecurity.org/controls.