Как установить и настроить Wazuh на VPS

MAATRIX

Когда на сервере крутится продакшен, одних логов в файлах уже мало — нужно понимать, что именно происходит: кто ломится по SSH, какие файлы поменялись, не появился ли на диске майнер после взлома WordPress. Wazuh закрывает эту задачу бесплатно и без вендор-лока: это open-source SIEM/XDR, который собирает события с серверов, ищет в них аномалии по правилам и выдаёт готовые отчёты под PCI DSS, GDPR и другие требования. Ниже — как поднять Wazuh на VPS с нуля и не утонуть в конфигах.

Что такое Wazuh и когда он нужен

Wazuh вырос из форка OSSEC и сегодня состоит из трёх компонентов:

• Wazuh Indexer — хранилище на базе OpenSearch, куда пишутся все события;
• Wazuh Manager — мозг системы: принимает данные с агентов, прогоняет их через правила и декодеры, генерирует алерты;
• Wazuh Dashboard — веб-интерфейс (тоже форк Kibana/OpenSearch Dashboards) для просмотра алертов, графиков и отчётов.

На каждом защищаемом сервере ставится лёгкий агент, который читает логи, следит за целостностью файлов (FIM), ищет уязвимости в установленных пакетах и умеет запускать active response — например, банить IP через iptables при обнаружении брутфорса.

Wazuh стоит разворачивать, если у вас несколько серверов и нужен единый центр видимости: не бегать по каждому по SSH и грепать /var/log/auth.log, а смотреть дашборд с алертами и историей. Для одного сервера с парой сайтов это, честно говоря, избыточно — там достаточно fail2ban и файрвола ufw. Wazuh раскрывается на 3+ серверах и там, где нужен именно compliance-отчёт, а не просто «чтобы было».

Минимальные требования и выбор сервера

All-in-one установка (indexer + manager + dashboard на одной машине) — самый простой вариант для старта, но она прожорлива по памяти: OpenSearch любит RAM и не любит, когда её мало. Ориентировочные требования, которые стоит закладывать с запасом (точные цифры для вашей нагрузки зависят от числа агентов и объёма логов — проверяйте актуальные рекомендации в официальной документации перед продакшен-развёртыванием):

Для теста и небольшой инфраструктуры разумно взять один VPS под all-in-one с 8 ГБ RAM и SSD — этого хватит, чтобы прочувствовать систему и посмотреть реальное потребление ресурсов у себя. Если план растёт (десятки серверов, длинный retention логов для аудита), Indexer и Dashboard стоит вынести на отдельную машину, а под сам Indexer — заложить NVMe и оперативку с запасом, диск там растёт быстро.

Систему берите Ubuntu 22.04/24.04 или почти любой современный дистрибутив на базе systemd — официальный установщик Wazuh поддерживает их из коробки.

Установка Wazuh (all-in-one) на VPS

Самый быстрый путь — официальный установочный скрипт, который сам разворачивает все три компонента с сертификатами и базовой настройкой. На чистом сервере:

apt update && apt upgrade -y
curl -sO https://packages.wazuh.com/4.x/wazuh-install.sh
sudo bash wazuh-install.sh -a

Флаг -a — as-you-go режим, ставит indexer, manager и dashboard в один прогон и генерирует случайные пароли для служебных пользователей. В конце скрипт выведет пароль администратора дашборда — обязательно сохраните его сразу, второй раз он в открытом виде не покажется (пароли лежат в зашифрованном виде в wazuh-install-files.tar, который скрипт создаёт рядом).

После установки проверьте, что сервисы поднялись:

systemctl status wazuh-indexer wazuh-manager wazuh-dashboard

Дашборд слушает 443 порт по HTTPS — заходите по https://IP-сервера/ и логинитесь под admin и паролем из вывода установщика. Сертификат по умолчанию самоподписанный, браузер будет ругаться — для прод-среды поставьте нормальный сертификат (Let's Encrypt через nginx-реверспрокси перед дашбордом — рабочий и распространённый вариант).

Основные порты, которые должны быть открыты в файрволе:

443/tcp   — веб-дашборд
1514/tcp  — приём событий от агентов
1515/tcp  — регистрация новых агентов
55000/tcp — Wazuh API (используется дашбордом и интеграциями)

Если на сервере уже стоит ufw, не забудьте разрешить эти порты явно — иначе агенты не достучатся до менеджера.

Настройка агентов и подключение серверов

Агент ставится на каждый сервер, который вы хотите мониторить, включая сам сервер с manager (полезно, чтобы видеть события самого SIEM). На Debian/Ubuntu:

curl -so wazuh-agent.deb https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.x.x-1_amd64.deb
WAZUH_MANAGER='IP_ИЛИ_ДОМЕН_МЕНЕДЖЕРА' dpkg -i ./wazuh-agent.deb
systemctl daemon-reload
systemctl enable wazuh-agent
systemctl start wazuh-agent

Точную ссылку на актуальный .deb-пакет под вашу версию Wazuh и дистрибутив берите со страницы установки в официальной документации — версии там обновляются, а хардкодить номер в статье смысла нет.

После запуска агент сам зарегистрируется у менеджера (если включена автоматическая регистрация) или потребует ручного подтверждения через manage_agents на стороне manager:

/var/ossec/bin/manage_agents
# выбрать A (add agent), указать имя и IP, затем экспортировать ключ

Проверить список подключённых агентов и их статус:

/var/ossec/bin/agent_control -l

В дашборде агенты появляются в разделе Agents со статусом Active/Disconnected/Never connected — если агент завис в «Never connected» дольше пары минут, почти всегда дело либо в закрытом 1514/1515 порту, либо в неверном WAZUH_MANAGER в конфиге агента (/var/ossec/etc/ossec.conf, секция <client><server><address>).

Отдельно стоит включить File Integrity Monitoring (FIM) — модуль, который следит за изменением файлов в критичных директориях. В ossec.conf агента:

<syscheck>
  <directories check_all="yes" realtime="yes">/etc,/usr/bin,/usr/sbin</directories>
  <directories check_all="yes">/var/www</directories>
  <ignore>/etc/mtab</ignore>
</syscheck>

realtime="yes" даёт мгновенное обнаружение через inotify, но требует ресурсов — на директории с частыми легитимными изменениями (логи, кэш) его лучше не вешать, иначе получите шум вместо сигнала.

Правила обнаружения, decoders и compliance-модули

Wazuh из коробки везёт большой набор правил (/var/ossec/ruleset/rules/) под типовые источники: SSH, sudo, nginx, Apache, MySQL, Docker, Windows Event Log и десятки других. Свои правила добавляйте не туда, а в отдельный файл, который переживёт обновления:

<!-- /var/ossec/etc/rules/local_rules.xml на менеджере -->
<group name="local,syslog,sshd,">
  <rule id="100010" level="10" frequency="6" timeframe="120">
    <if_matched_sid>5716</if_matched_sid>
    <description>Множественные неудачные SSH-логины с одного IP за 2 минуты</description>
    <group>authentication_failures,</group>
  </rule>
</group>

После правки конфигов на менеджере перезапустите его:

systemctl restart wazuh-manager

Для compliance у Wazuh есть готовые маппинги: правила помечены тегами PCI DSS, GDPR, HIPAA, NIST 800-53, TSC — и в дашборде есть отдельные виджеты, показывающие, сколько алертов относится к каждому стандарту. Это не автоматический аудит «всё ок», а инструмент — он показывает, какие требования затронуты конкретными событиями, а формальное соответствие всё равно проверяется отдельно (аудитором или чек-листом).

Второй важный модуль — SCA (Security Configuration Assessment): сверяет конфигурацию сервера с CIS-бенчмарками (SSH, ядро, файловые права) и показывает, что не соответствует best practice. Включается в ossec.conf агента:

<sca>
  <enabled>yes</enabled>
  <scan_on_start>yes</scan_on_start>
  <interval>12h</interval>
</sca>

Плюс есть модуль Vulnerability Detection — он сверяет установленные пакеты с фидами CVE и подсвечивает уязвимые версии софта прямо в дашборде, без отдельного сканера вроде OpenVAS.

Интеграция с алертами и SIEM-экосистемой

Смотреть дашборд руками каждый день никто не будет — алерты нужно доставлять туда, где вы их реально увидите. У Wazuh есть встроенные интеграции в ossec.conf на менеджере, например для Slack:

<integration>
  <name>slack</name>
  <hook_url>https://hooks.slack.com/services/ВАШ/ВЕБХУК/ТУТ</hook_url>
  <level>10</level>
  <alert_format>json</alert_format>
</integration>

Для Telegram встроенной интеграции нет, но alerts.json (по умолчанию в /var/ossec/logs/alerts/alerts.json) — это обычный построчный JSON, который легко читается своим скриптом на Python и пересылается в бота через sendMessage. Это несложный кусок кода на 20-30 строк, но описывать конкретную боевую реализацию токенов и чатов в статье смысла нет — под ваш кейс её проще написать под конкретный бот и права.

Если в инфраструктуре уже крутится Grafana Loki или Elasticsearch для логов приложений, Wazuh с ними не конкурирует, а дополняет — он лучше заточен именно под security-события и compliance, тогда как Loki/Elasticsearch удобнее для полнотекстового поиска по логам приложения. Ничто не мешает держать оба: подробнее про то, как разделить эти роли, можно почитать в статье про интеграцию VPN-логов и SIEM для комплаенса. Если же вы уже используете auditd для аудита событий ядра — Wazuh умеет читать и его логи, дублировать функциональность не придётся, см. настройку auditd.

Отдельно стоит настроить active response — автоматическую реакцию на инцидент, например бан IP при срабатывании правила брутфорса:

<active-response>
  <disabled>no</disabled>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>100010</rules_id>
  <timeout>600</timeout>
</active-response>

Это не замена fail2ban, а похожий по смыслу механизм на уровне SIEM — если fail2ban уже стоит и работает, дублировать active response на те же правила не обязательно, достаточно смотреть алерты в Wazuh.

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