Wazuh

Что такое Wazuh

Wazuh — платформа мониторинга безопасности с открытым кодом. На каждый защищаемый хост ставится агент, который читает логи, следит за изменениями файлов, проверяет настройки и ищет уязвимости; всё это стекается на центральный сервер, где сопоставляется с правилами и превращается в алерты.

Функционально Wazuh закрывает сразу два класса задач: SIEM (сбор и корреляция событий безопасности) и XDR/HIDS (обнаружение угроз на хостах). Вырос из проекта OSSEC, распространяется свободно — платных редакций с урезанным функционалом нет, компания зарабатывает на облаке и поддержке.

Главное, что стоит понимать: Wazuh не защищает периметр как межсетевой экран и не сканирует трафик. Он смотрит внутрь хостов и отвечает на вопрос «что происходит на моих серверах».

Wazuh — это не Zabbix

Самое частое непонимание. Оба ставят агентов на все серверы, оба шлют алерты, но задачи у них разные:

Они не конкуренты и не заменяют друг друга — в зрелой инфраструктуре стоят оба.

Что умеет агент

• Анализ логов — читает системные журналы, логи Nginx, sshd, auditd и прогоняет через правила декодирования. Классический сработавший алерт — брутфорс SSH или успешный вход после серии неудачных.
• FIM (File Integrity Monitoring) — следит за изменениями критичных файлов: кто и когда правил /etc/passwd или подложил файл в веб-каталог. Требование, прямо прописанное в PCI DSS.
• SCA (Security Configuration Assessment) — сверяет настройки хоста с CIS-бенчмарками и показывает, что настроено небезопасно.
• Обнаружение уязвимостей — сопоставляет список установленных пакетов с базами CVE. Позволяет ответить на вопрос «где у нас непропатченный пакет» без отдельного сканера.
• Обнаружение руткитов и аномалий в процессах.
• Active response — автоматическая реакция: заблокировать IP в firewall при атаке.
• Compliance-маппинг — события размечаются по PCI DSS, GDPR, HIPAA, NIST 800-53 и матрице MITRE ATT&CK. Для отчётности это половина работы.

Агенты ставятся на Linux, Windows, macOS; отдельно собираются события из Docker, Kubernetes и облачных провайдеров.

Архитектура

Indexer — форк OpenSearch, который сам является форком Elasticsearch. Это объясняет и сильные стороны (полнотекстовый поиск по событиям из коробки), и главную слабость — аппетит к ресурсам.

Порты: 1514 — события от агентов, 1515 — регистрация агентов, 55000 — REST API, 443 — дашборд.

Что нужно от сервера

Здесь надо быть честным: Wazuh тяжёлый, и виноват в этом indexer — это Java-приложение со всеми вытекающими. Ставить его на минимальный VPS рядом с другими сервисами — плохая идея.

Ориентиры для планирования:

• all-in-one установка на десяток агентов реально требует от 4 ГБ RAM, комфортно — вдвое больше; основной потребитель — indexer;
• диск — только SSD, и его нужно много: события безопасности копятся быстро. Задавайте retention и ILM-политики сразу, а не когда диск кончится;
• при росте компоненты разносят: сервер отдельно, indexer — кластером из нескольких узлов;
• вынесите Wazuh в отдельный сегмент сети. Система, которая знает про все инциденты, — привлекательная цель, и логи безопасности должны пережить компрометацию наблюдаемого хоста.

Разворачивают либо через официальный установочный скрипт, либо Docker Compose-стеком.

Когда Wazuh оправдан

Он даёт много «из коробки», но не бесплатно по трудозатратам: правила придётся донастраивать под свои приложения, иначе шум ложных срабатываний похоронит полезные алерты. Wazuh имеет смысл, когда есть кому разбирать алерты — то есть выделенный человек или SOC. Без этого он превращается в дорогой генератор уведомлений, которые никто не читает.

Альтернативы: коммерческие SIEM, ELK со своими правилами, отдельные HIDS вроде OSSEC.

Связанные термины

• SIEM — класс систем, к которому относится Wazuh
• SOC — кому нужны его алерты
• Zabbix — мониторинг доступности, а не безопасности
• Elasticsearch — предок indexer через форк OpenSearch
• Инцидент ИБ — то, что Wazuh должен обнаружить
• PCI DSS — стандарт, требующий FIM и сбора логов