HoginHogin
Назад

Wazuh: подключаем агентов, включаем FIM и rootcheck на Linux и Windows (часть 2/6)

8 мин чтения

В первой части мы подняли single-node Wazuh и получили dashboard с ровно одним источником событий — самим manager, агентом с ID 000. Без агентов SIEM слеп: он не увидит ни правку /etc/sudoers, ни новый ключ автозапуска в реестре Windows, ни то, что на сервере кто-то пересобрал sshd. Вторая часть цикла — про глаза: регистрируем агентов на Ubuntu и Windows, включаем File Integrity Monitoring (FIM) через syscheck, подключаем rootcheck и SCA по CIS Benchmark — и разбираемся, почему из коробки это чаще генератор шума, а не сигнал.

Содержание

Открыть содержание

Почему агент, а не syslog

Доставить логи до manager можно и без агента: wazuh-remoted умеет принимать syslog. Но всё интересное в Wazuh живёт только на агенте — чтобы посчитать хэш файла, прогнать CIS-проверку или снять inventory пакетов, нужно исполнять код на самом хосте. Агент — это один демон (wazuh-agent, systemd-юнит), который локально собирает события и держит постоянное шифрованное соединение с manager. Ему нужны два порта, и оба — исходящие:

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

Enrollment: разовая регистрация, потом только ключи

Прежде чем слать события, агент должен представиться — и быть принятым. Для этого существует enrollment:

Enrollment: разовая регистрация, потом ключи

На manager по умолчанию поднят сервис wazuh-authd, слушающий 1515. Включаем пароль:

<!-- /var/ossec/etc/ossec.conf на manager -->
<auth>
  <use_password>yes</use_password>
  <port>1515</port>
</auth>
echo 'S0meEnr0llPass' > /var/ossec/etc/authd.pass
chmod 640 /var/ossec/etc/authd.pass
systemctl restart wazuh-manager   # Docker из части 1: docker restart wazuh.manager

Пароль один на всех агентов и участвует один раз — при регистрации. После неё каждая сторона хранит в /var/ossec/etc/client.keys симметричный ключ конкретного агента, и весь трафик идёт на 1514 уже по нему. Важно понять это сразу: authd-пароль — не «пароль от событий», а ключ от шлагбаума.

Ручной путь — утилита manage_agents на обеих сторонах: на manager добавляете агента (Add) и выгружаете ключ (Extract), на агенте импортируете его (Import). На Windows то же самое делает manage_agents.exe в каталоге установки. Ручной путь нужен, когда 1515 закрыт сегментацией сети или политика не разрешает автрегистрацию.

И держите в голове горизонт: в Wazuh 5.0 протокол общения агент-сервер переписывается с нуля (release notes). Детали enrollment в 5.x могут измениться, но модель «разовая регистрация → ключ → поток событий» переживёт и его — учите её, а не кнопки.

Что нужно, чтобы подключить Ubuntu-сервер

Нужны root на агенте, сеть до manager по 1514/1515 и минута времени:

# репозиторий
apt-get update && apt-get install -y curl gnupg
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | \
  gpg --dearmor -o /usr/share/keyrings/wazuh.gpg
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" \
  > /etc/apt/sources.list.d/wazuh.list
apt-get update

# установка и регистрация одним махом
WAZUH_MANAGER="10.0.0.5" \
WAZUH_REGISTRATION_SERVER="10.0.0.5" \
WAZUH_REGISTRATION_PASSWORD="S0meEnr0llPass" \
apt-get install -y wazuh-agent

systemctl enable --now wazuh-agent

Переменные подхватывает postinst-скрипт пакета: он прописывает адрес manager в /var/ossec/etc/ossec.conf и тут же ходит на authd за ключом. Если агент уже установлен без регистрации — то же самое вручную:

/var/ossec/bin/agent-auth -m 10.0.0.5 -P 'S0meEnr0llPass'
# и проверьте <address> внутри <client> → <server> в ossec.conf
systemctl restart wazuh-agent

Windows без кликов

MSI-пакет ставится silently и принимает те же переменные:

msiexec.exe /i wazuh-agent-4.14.7-1.msi /q `
  WAZUH_MANAGER="10.0.0.5" `
  WAZUH_REGISTRATION_SERVER="10.0.0.5" `
  WAZUH_REGISTRATION_PASSWORD="S0meEnr0llPass"
NET START WazuhSvc

Конфиг — C:\Program Files (x86)\ossec-agent\ossec.conf, тот же XML, что и на Linux. Служба называется WazuhSvc, перезапуск — Restart-Service WazuhSvc. Дальше разницы между платформами почти нет: одни и те же секции, разные пути.

syscheck: FIM, который можно читать

Главный модуль агента — syscheck, он и есть File Integrity Monitoring. Логика: при первом запуске syscheck обходит настроенные пути и строит baseline — хэши (MD5/SHA1/SHA256), размер, права, владельца, время модификации. Дальше три режима слежения:

syscheck: от изменения файла до алерта

Практический блок для Ubuntu-агента — критичные пути, realtime, diff в алерте и whodata на самом важном:

<syscheck>
  <disabled>no</disabled>
  <frequency>43200</frequency>
  <scan_on_start>yes</scan_on_start>

  <!-- критичные пути: realtime + diff прямо в алерте -->
  <directories check_all="yes" realtime="yes" report_changes="yes">/etc,/root,/bin,/sbin</directories>
  <directories check_all="yes" realtime="yes" report_changes="yes">/usr/bin,/usr/sbin</directories>

  <!-- самое важное: ещё и «кто изменил» через auditd -->
  <directories check_all="yes" whodata="yes" report_changes="yes">/etc/ssh,/etc/sudoers.d</directories>

  <!-- вечный шум выключаем -->
  <ignore>/etc/mtab</ignore>
  <ignore type="sregex">^/etc/apparmor.d/cache</ignore>

  <!-- содержимое секретов не должно уезжать в алерты -->
  <nodiff>/etc/shadow,/etc/gshadow</nodiff>
</syscheck>

По элементам:

На Windows к директориям добавляется реестр — классика persistence-механиков:

<windows_registry check_all="yes" realtime="yes" report_changes="yes" whodata="yes">HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run</windows_registry>
<windows_registry check_all="yes" realtime="yes" report_changes="yes">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services</windows_registry>

Изменённый файл опознает правило 550, удалённый — 551, новый — 553; у реестра своя линейка правил. Всё это видно в dashboard → Modules → Integrity monitoring — с diff и «до/после».

rootcheck и SCA: разные вопросы

rootcheck — старый, но дешёвый детектор аномалий системы: скрытые процессы и файлы (расхождение вывода ps с /proc), странные записи в /dev, подписи руткитов и троянов из поставляемых списков. Современный APT-инструментарий он не перехитрит, но стоит копейки и на Linux-агентах просто живёт в конфиге:

<rootcheck>
  <disabled>no</disabled>
</rootcheck>

SCA (Security Configuration Assessment) отвечает на другой вопрос: «соответствует ли хост формальному стандарту?». Политики — YAML-файлы с проверками из CIS Benchmark: параметры ядра, права на файлы, службы, на Windows — реестр. Результат — pass/fail по каждому пункту. Это не детект вторжений, а контроль дрейфа конфигурации: сервер, который «вдруг» перестал соответствовать базовой линии, — событие само по себе.

Для Ubuntu-агента подключаем готовую политику CIS:

<sca>
  <enabled>yes</enabled>
  <scan_on_start>yes</scan_on_start>
  <interval>12h</interval>
  <policies>
    <policy>cis_ubuntu22.04.yml</policy>
  </policies>
</sca>

Файлы политик лежат в /var/ossec/ruleset/sca/ на агенте. Подбирайте политику под дистрибутив: cis_ubuntu22.04 на Debian даст поток ложных fail ещё до того, как вы что-то сломаете сами.

Группы агентов: конфиг из одной точки

Когда агентов больше трёх, править ossec.conf на каждом невозможно. Группы решают это: manager хранит для каждой группы общий конфиг и раздаёт его участникам.

/var/ossec/bin/agent_groups -a -g prod-linux -q        # создать группу
/var/ossec/bin/agent_groups -a -d 002 -g prod-linux -q # добавить агента (ID из agent_control -ls)
/var/ossec/bin/agent_groups -l -g prod-linux           # проверить состав

Конфиг группы — /var/ossec/etc/shared/prod-linux/agent.conf:

<agent_config>
  <syscheck>
    <directories check_all="yes" realtime="yes" report_changes="yes">/etc,/root,/bin,/sbin,/usr/bin,/usr/sbin</directories>
    <ignore>/etc/mtab</ignore>
    <nodiff>/etc/shadow,/etc/gshadow</nodiff>
  </syscheck>
</agent_config>

Секции из agent.conf имеют приоритет над локальным ossec.conf агента — держите настройку одного модуля в одном месте, иначе через месяц не разберёте, чья директива выиграла.

Шум против сигнала

Одна и та же функция syscheck в зависимости от путей даёт противоположные результаты:

Шум против сигнала

ПараметрДефолтный syscheckНастроенный FIM
Путиширокий набор «на всякий случай»только критичные директории
Режимв основном периодический сканrealtime, на критичном — whodata
Кто изменилнеизвестноuser и исполняемый процесс
Diffнетreport_changes + nodiff для секретов
SCAчто нашлось самоCIS-политика под конкретный дистрибутив
Что в алертахпоток событий о легитимномединицы сигналов на реальные изменения

Типичные ошибки, из-за которых FIM выключают через неделю:

Как проверить, что всё работает

На manager (в Docker-варианте из части 1 — через docker exec -ti wazuh.manager):

/var/ossec/bin/agent_control -ls

Агент должен быть в статусе Active. Дальше smoke-тест FIM — на агенте:

echo '# fim smoke test' | sudo tee /etc/ssh/sshd_config.d/99-fim-test.conf

Через секунды событие придёт: tail -f /var/ossec/logs/alerts/alerts.json | grep fim-test покажет алерт с правилом 553, а в dashboard → Modules → Integrity monitoring появится запись с diff. Результаты SCA смотрим в Endpoints Summary → агент → SCA — там score по политике CIS. Убираем тестовый файл, дожидаемся правила 551 — контур замкнулся.

Итог

Агенты — это глаза Wazuh, и подключаются они за минуты: репозиторий, env-переменные, ключ. Реальная работа — не «включить FIM», а вырезать из него шум: короткие списки путей, ignore для вечных изменщиков, nodiff для секретов, whodata на горстке действительно критичных каталогов, SCA под ваш дистрибутив. Час настройки отделяет бесконечный поток алертов о безобидных изменениях файлов от единиц событий, на которые хочется реагировать. В следующей части — кастомные правила и декодеры: что делать, когда стандартные 550 и 553 говорят «файл изменился», а вам нужно «кто-то получил права root».

Поделиться:
Поделиться в TelegramПоделиться по почте
Следующая статья
Wazuh с нуля: разворачиваем open-source SIEM/XDR за один вечер (часть 1/6)