Wazuh на Linux: установка SIEM, агенты и FIM 2026

Обновлено: 14 июня 2026

Wazuh, если говорить совсем просто, это open-source платформа XDR/SIEM, которая объединяет хостовый IDS, мониторинг целостности файлов (FIM), обнаружение уязвимостей, аудит соответствия и активный отклик в одном стеке. На Linux она разворачивается из трёх центральных компонентов (Wazuh indexer, Wazuh manager, Wazuh dashboard) и лёгких агентов, которые отправляют события на менеджер по защищённому каналу. В этом руководстве я разверну Wazuh 4.x на Ubuntu 24.04 LTS и Rocky Linux 9, подключу агенты, настрою FIM, vulnerability detection, правила MITRE ATT&CK и активный отклик с интеграцией fail2ban-подобной блокировки через firewalld. В последний раз я ставил этот стек на парк из ~800 хостов, так что несколько граблей покажу заодно.

• Wazuh 4.x состоит из трёх ядерных сервисов: indexer (форк OpenSearch), manager (анализ и правила) и dashboard (UI на базе OpenSearch Dashboards).
• All-in-one установка через wazuh-install.sh подходит для PoC и до ~500 агентов. Для продакшена выносите indexer на отдельный узел и используйте кластер из 3+ нод.
• FIM в Wazuh работает через syscheck и обнаруживает изменения файлов в режиме realtime через inotify; whodata добавляет имя пользователя и процесс через auditd.
• Модуль vulnerability-detector в 4.8+ использует индексатор и фиды CVE от Canonical, Red Hat, Debian, ALAS и NVD (обновляется каждые 6 часов).
• Правила Wazuh маппятся на MITRE ATT&CK через поле mitre.id, что даёт фильтры по тактикам и техникам в дашборде.
• Активный отклик автоматически блокирует IP, останавливает сервисы или запускает кастомные скрипты при срабатывании правила с заданным уровнем серьёзности.

Что такое Wazuh и чем он отличается от OSSEC

Wazuh, по сути, форк OSSEC, который в 2015 году отделился ради переписанного агента, интеграции с Elastic/OpenSearch стеком и регулярных релизов. К версии 4.x от OSSEC осталась лишь идейная схожесть: модуль syscheck для FIM и формат правил XML. Всё остальное (vulnerability-detector, sca или Security Configuration Assessment, AWS/Azure/GCP коннекторы, FIM whodata через auditd, нативная корреляция с MITRE ATT&CK, кластеризация менеджера и встроенный indexer на форке OpenSearch 2.x) это уже целиком Wazuh.

В отличие от Falco, который работает в ядре через eBPF и фокусируется на runtime threat detection в контейнерах, Wazuh относится к классическим HIDS+SIEM: он читает логи, состояния файлов, реестр аудита, инвентарь пакетов и отправляет события на центральный менеджер для корреляции. Эти инструменты дополняют друг друга, и мы подробно разобрали тему в материале Falco на Linux: обнаружение угроз в реальном времени через eBPF. На практике крупные SOC ставят оба: Falco для runtime в Kubernetes, Wazuh для соответствия, FIM и инвентаризации.

Wazuh бесплатен и распространяется под GPLv2 (агент и менеджер) и Apache 2.0 (indexer и dashboard). Коммерческая поддержка от Wazuh Inc. опциональна; полностью открытый стек работает без ограничений по числу агентов и срокам.

Архитектура Wazuh 4.x: indexer, manager, dashboard

Стек Wazuh 4.x состоит из трёх сервисов и агентов:

• Wazuh indexer: форк OpenSearch 2.x, хранит alerts, archives и состояния FIM/SCA/inventory. Слушает 9200/tcp.
• Wazuh manager: ядро анализа. Принимает события агентов на 1514/tcp (или UDP, deprecated), запускает analysisd, парсит логи через декодеры, применяет правила и отправляет alerts в indexer. Authd слушает 1515/tcp для регистрации агентов.
• Wazuh dashboard: форк OpenSearch Dashboards с плагином wazuh-kibana-app, слушает 443/tcp за nginx. Предоставляет UI для алертов, MITRE-фильтров, SCA отчётов и vulnerability inventory.
• Wazuh agent: лёгкий бинарь (~25 МБ RAM в idle), запускается как набор демонов (wazuh-agentd, wazuh-syscheckd, wazuh-logcollector, wazuh-modulesd, wazuh-execd).

Связь агент → менеджер шифруется AES-256 (Blowfish исключён в 4.x) и использует shared key, выданный wazuh-authd. Связь manager → indexer и dashboard → indexer идёт по HTTPS с самоподписанными или Let's Encrypt сертификатами. Для производственных развёртываний рекомендуется кластер indexer из 3 нод (data + master) и кластер manager из 1 master + N worker. Горизонтальное масштабирование начинается примерно с 5 000 агентов.

Системные требования и подготовка Linux-сервера

Минимальные требования для all-in-one установки и до 100 агентов: 4 vCPU, 8 ГБ RAM, 50 ГБ NVMe для логов и индексов. До 500 агентов закладывайте 8 vCPU, 16 ГБ RAM, 200 ГБ диска. Главное узкое место, как обычно, запись в indexer; используйте SSD/NVMe и держите vm.max_map_count=262144.

Поддерживаемые ОС в 4.12: Ubuntu 22.04/24.04, Debian 11/12, Rocky/Alma/RHEL 8/9, Amazon Linux 2/2023, openSUSE Leap 15.5+. Перед установкой:

# системные параметры под indexer
echo 'vm.max_map_count=262144' | sudo tee /etc/sysctl.d/99-wazuh.conf
sudo sysctl --system

# отключите swap или ограничьте его (для предсказуемой задержки indexer)
sudo swapoff -a
sudo sed -i.bak '/ swap / s/^/#/' /etc/fstab

# откройте порты на firewalld (Rocky/RHEL)
sudo firewall-cmd --permanent --add-port=443/tcp   # dashboard
sudo firewall-cmd --permanent --add-port=1514/tcp  # agent to manager
sudo firewall-cmd --permanent --add-port=1515/tcp  # authd регистрация
sudo firewall-cmd --permanent --add-port=55000/tcp # Wazuh API
sudo firewall-cmd --reload

Если вы используете nftables напрямую, аналогичные правила вписываются в таблицу inet filter. Подробный набор боевых конфигов разобран в гайде nftables для продакшена.

Установка Wazuh server на Ubuntu и Rocky Linux

Wazuh поставляет официальный all-in-one скрипт wazuh-install.sh, который ставит indexer, manager и dashboard на один узел с сгенерированными TLS-сертификатами. Это правильный путь для PoC, lab и небольших инсталляций.

# 1. скачайте установщик с GitHub релизов
curl -sO https://packages.wazuh.com/4.12/wazuh-install.sh
curl -sO https://packages.wazuh.com/4.12/config.yml

# 2. (опционально) отредактируйте config.yml для распределённой установки
#    в all-in-one оставьте секцию nodes с одной записью node1

# 3. сгенерируйте сертификаты
sudo bash wazuh-install.sh --generate-config-files

# 4. установите всё в одну команду
sudo bash wazuh-install.sh --all-in-one

Скрипт занимает 5–10 минут и в конце печатает учётные данные admin для дашборда. Сохраните их сразу: пароль admin генерируется случайным образом и не выводится повторно (я в первый раз пропустил вывод, пришлось дёргать passwords-tool, не повторяйте). Дашборд будет доступен на https://<server-ip>.

Ручная установка для продакшена

На Ubuntu 24.04 для распределённой установки подключите репозиторий и поставьте только manager:

curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | \
  sudo gpg --no-default-keyring --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import
sudo chmod 644 /usr/share/keyrings/wazuh.gpg
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] \
  https://packages.wazuh.com/4.x/apt/ stable main" | \
  sudo tee /etc/apt/sources.list.d/wazuh.list

sudo apt update
sudo apt install -y wazuh-manager
sudo systemctl enable --now wazuh-manager

На Rocky Linux 9 всё аналогично через dnf-репозиторий https://packages.wazuh.com/4.x/yum/. Состояние сервиса проверяется через systemctl status wazuh-manager и логи в /var/ossec/logs/ossec.log. Если manager падает на старте, проверьте, что indexer достижим по 9200 и в /var/ossec/etc/ossec.conf указан правильный хост в секции <indexer>.

Развёртывание агентов и регистрация через authd

Агент устанавливается из того же репозитория. На Ubuntu/Debian:

curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | \
  sudo gpg --no-default-keyring --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import
sudo chmod 644 /usr/share/keyrings/wazuh.gpg
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] \
  https://packages.wazuh.com/4.x/apt/ stable main" | \
  sudo tee /etc/apt/sources.list.d/wazuh.list

sudo apt update
WAZUH_MANAGER="10.10.0.10" sudo -E apt install -y wazuh-agent
sudo systemctl enable --now wazuh-agent

Переменная WAZUH_MANAGER вписывает адрес менеджера в /var/ossec/etc/ossec.conf. Регистрация выполняется автоматически через wazuh-authd на 1515/tcp; для production защитите этот канал паролем:

# на менеджере
sudo bash -c 'echo "S3cur3-Pre-Sh4red-K3y" > /var/ossec/etc/authd.pass'
sudo chown wazuh:wazuh /var/ossec/etc/authd.pass
sudo chmod 640 /var/ossec/etc/authd.pass
sudo systemctl restart wazuh-manager

# на агенте
sudo /var/ossec/bin/agent-auth -m 10.10.0.10 -P 'S3cur3-Pre-Sh4red-K3y'
sudo systemctl restart wazuh-agent

Проверьте подключение командой /var/ossec/bin/agent_control -l на менеджере: агент должен значиться как Active. Для парка из тысяч хостов используйте unattended-установку через Ansible с шаблоном ossec.conf и общим pre-shared key.

Настройка FIM: realtime, whodata и исключения

FIM в Wazuh реализован модулем syscheck и настраивается в /var/ossec/etc/ossec.conf агента. По умолчанию проверяются /etc, /usr/bin, /usr/sbin, /bin, /sbin и /boot каждые 12 часов. Это слишком грубо для боевых серверов, так что переключайтесь на realtime или whodata:

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

  <!-- realtime через inotify -->
  <directories realtime="yes" check_all="yes">/etc</directories>
  <directories realtime="yes" check_all="yes">/var/www</directories>

  <!-- whodata: realtime + кто/чем менял (требует auditd) -->
  <directories whodata="yes" check_all="yes" report_changes="yes">
    /etc/ssh
  </directories>

  <!-- исключения для шумных директорий -->
  <ignore>/etc/mtab</ignore>
  <ignore>/etc/hosts.deny</ignore>
  <ignore type="sregex">.log$|.swp$|.tmp$</ignore>

  <nodiff>/etc/shadow</nodiff>
</syscheck>

Атрибут realtime="yes" подключает inotify watchers и срабатывает за миллисекунды на каждое write/rename/unlink. whodata="yes" дополнительно подключается к auditd и наполняет alert полями audit.user.name, audit.process.name, audit.process.id. Без whodata вы знаете, что файл изменился; с whodata, кто именно и каким бинарём.

Параметр report_changes="yes" хранит diff содержимого (макс. 64 КБ). Это удобно для конфигов вроде sshd_config, но не включайте его на бинарных директориях. Для systemd-сервисов добавьте мониторинг /etc/systemd/system и /lib/systemd/system. Это обычная точка закрепления злоумышленника, как мы разбирали в материале защита сервисов systemd.

Vulnerability detection: фиды CVE и тонкая настройка

Начиная с Wazuh 4.8, модуль vulnerability detection переписан и теперь работает поверх indexer. Менеджер собирает инвентарь пакетов с агентов (модуль syscollector) и сопоставляет его с CVE-фидами Canonical (Ubuntu OVAL), Red Hat (security data), Debian Security Tracker, Amazon Linux Security Advisories, ALAS и NVD. Включается секцией в ossec.conf менеджера:

<vulnerability-detection>
  <enabled>yes</enabled>
  <index-status>yes</index-status>
  <feed-update-interval>6h</feed-update-interval>
</vulnerability-detection>

<indexer>
  <enabled>yes</enabled>
  <hosts>
    <host>https://10.10.0.20:9200</host>
  </hosts>
  <ssl>
    <certificate_authorities>
      <ca>/etc/wazuh-indexer/certs/root-ca.pem</ca>
    </certificate_authorities>
    <certificate>/etc/wazuh-indexer/certs/admin.pem</certificate>
    <key>/etc/wazuh-indexer/certs/admin-key.pem</key>
  </ssl>
</indexer>

На агентах включите syscollector с интервалом сбора пакетов 6 часов. Реже нет смысла, чаще нагружает менеджер на парке от 1000 машин:

<wodle name="syscollector">
  <disabled>no</disabled>
  <interval>6h</interval>
  <packages>yes</packages>
  <processes>yes</processes>
  <hotfixes>yes</hotfixes>
</wodle>

Результаты появляются в дашборде Vulnerabilities → Inventory. Каждая запись содержит CVE-ID, CVSS v3 score, package name/version, фикс-версию и ссылку на advisory. Фильтруйте по vulnerability.severity:"Critical" для триажа в первую очередь.

Правила, декодеры и интеграция MITRE ATT&CK

Правила Wazuh, это XML-файлы в /var/ossec/ruleset/rules/ с уровнями severity 0–15. Кастомные правила пишутся в /var/ossec/etc/rules/local_rules.xml, чтобы пережить обновление пакета. Минимальный пример, алерт на 5 неудачных SSH-логинов с одного IP за 60 секунд:

<group name="sshd,authentication_failures,">
  <rule id="100100" level="10" frequency="5" timeframe="60">
    <if_matched_sid>5760</if_matched_sid>
    <same_source_ip />
    <description>sshd: 5 неудачных входов с одного IP за минуту</description>
    <mitre>
      <id>T1110.001</id>
    </mitre>
    <group>authentication_failures,pci_dss_10.2.4,pci_dss_10.2.5,gdpr_IV_35.7.d,</group>
  </rule>
</group>

Тег <mitre><id> маппит правило на технику ATT&CK (здесь T1110.001 Brute Force: Password Guessing). В дашборде появится граф «Топ техник за 24 часа», который SOC использует для приоритизации. Wazuh поддерживает ATT&CK v15 (2024) с автоматическим обновлением через /var/ossec/ruleset/utils/mitre.db.

Перезагрузка правил выполняется без рестарта менеджера: sudo /var/ossec/bin/wazuh-control reload. Проверьте синтаксис XML заранее: sudo /var/ossec/bin/wazuh-logtest. Этот REPL прогоняет произвольную строку лога через декодеры и правила и печатает финальный alert.

Полная база техник ATT&CK с описаниями и митигациями доступна на attack.mitre.org. Используйте её как референс при написании правил для специфичных угроз.

Активный отклик: блокировка IP и кастомные скрипты

Active Response, это автоматический запуск скрипта на менеджере или агенте при срабатывании правила. Из коробки идут firewall-drop, host-deny, disable-account, route-null. Минимальная конфигурация для блокировки brute-force в ossec.conf менеджера:

<command>
  <name>firewall-drop</name>
  <executable>firewall-drop</executable>
  <timeout_allowed>yes</timeout_allowed>
</command>

<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>100100,5712</rules_id>
  <timeout>600</timeout>
</active-response>

При срабатывании правила 100100 (того самого, что мы только что определили) или встроенного 5712 (sshd brute force) на агенте, где произошёл инцидент, запустится /var/ossec/active-response/bin/firewall-drop. Скрипт сам выберет nftables, iptables или firewall-cmd в зависимости от того, что установлено, и добавит DROP-правило на 600 секунд. Через 10 минут таймер агента снимет блокировку автоматически.

Кастомные скрипты пишутся на любом языке и кладутся в /var/ossec/active-response/bin/ с правами 750 и владельцем root:wazuh. Пример скрипта на Bash, который вызывает webhook в Slack при критическом алерте:

#!/usr/bin/env bash
# /var/ossec/active-response/bin/slack-notify.sh
# stdin: JSON с alert полями (since 4.2)

WEBHOOK="https://hooks.slack.com/services/T0/B0/XX"
read INPUT_JSON
ALERT=$(echo "$INPUT_JSON" | jq -r '.parameters.alert.rule.description')
AGENT=$(echo "$INPUT_JSON" | jq -r '.parameters.alert.agent.name')

curl -sS -X POST -H 'Content-Type: application/json' \
  --data "{\"text\":\":rotating_light: ${AGENT}: ${ALERT}\"}" \
  "$WEBHOOK"

Аудит соответствия: CIS, PCI DSS, NIST 800-53

Модуль SCA (Security Configuration Assessment) запускает на агенте YAML-политики и проверяет состояние системы относительно CIS Benchmarks. Wazuh поставляет готовые политики для Ubuntu 22.04/24.04, RHEL 8/9, Debian 12, Windows Server и Kubernetes. Включается в ossec.conf агента:

<sca>
  <enabled>yes</enabled>
  <scan_on_start>yes</scan_on_start>
  <interval>12h</interval>
  <skip_nfs>yes</skip_nfs>
  <policies>
    <policy>cis_ubuntu24-04.yml</policy>
  </policies>
</sca>

Результаты доступны в дашборде Security Configuration Assessment с разбивкой по pass/fail/not applicable. Для каждого зафейленного контроля показано «Rationale», «Remediation» и точка из CIS-документа. Этого, честно говоря, достаточно, чтобы Junior SecOps закрыл 80% находок без эскалации.

Маппинг правил на PCI DSS, HIPAA, GDPR и NIST 800-53 уже встроен через теги <group> (см. пример с правилом 100100 выше). В дашборде есть отдельные views «PCI DSS», «HIPAA», «NIST 800-53 rev5», которые фильтруют alerts по соответствующим контролям и выводят compliance score за период. Для аудиторов экспортируется PDF-отчёт прямо из UI.

Часто задаваемые вопросы

Wazuh бесплатный или платный?

Wazuh полностью бесплатен и распространяется под лицензиями GPLv2 (агент, менеджер) и Apache 2.0 (indexer, dashboard). Нет ограничений по числу агентов, объёму логов или сроку использования. Wazuh Inc. продаёт опциональную коммерческую поддержку и облачный SaaS (Wazuh Cloud), но on-prem стек работает без подписки.

Какие требования к серверу Wazuh для 100 агентов?

Для all-in-one установки на 100 агентов достаточно 4 vCPU, 8 ГБ RAM и 50 ГБ NVMe-диска. Главное узкое место, это запись в indexer, поэтому SSD/NVMe обязательны. При росте до 500 агентов закладывайте 8 vCPU, 16 ГБ RAM и 200 ГБ диска. Свыше 1000 агентов выносите indexer и manager на отдельные узлы.

Чем Wazuh отличается от OSSEC?

Wazuh, это форк OSSEC 2015 года, который за десять лет ушёл далеко вперёд: переписанный агент, встроенный indexer на OpenSearch, модули vulnerability detection и SCA, нативная интеграция с MITRE ATT&CK, AWS/Azure/GCP коннекторы, кластеризация менеджера. OSSEC ограничивается классическим HIDS+FIM без UI и SIEM-функций.

Можно ли установить только агент Wazuh без сервера?

Технически да, пакет wazuh-agent ставится самостоятельно, но без менеджера он только пишет события локально в /var/ossec/logs/ и не выполняет корреляцию. Для любой осмысленной работы нужен Wazuh manager: либо собственный, либо облачный Wazuh Cloud.

Как обновить Wazuh с 4.7 до 4.12?

Обновление выполняется через пакетный менеджер: apt update && apt install wazuh-manager wazuh-indexer wazuh-dashboard на сервере, затем apt install wazuh-agent на агентах. Сначала обновляйте indexer, потом manager, в конце dashboard и агенты. Конфиги ossec.conf и кастомные правила в local_rules.xml переживают обновление; для мажорных версий читайте release notes на GitHub.