# Wazuh SIEM: моніторинг безпеки сервера та контроль FIM

> Wazuh SIEM для моніторингу безпеки сервера поєднує аналіз логів, контроль цілісності файлів (FIM) та автоматичне блокування атак через active response.

Wazuh SIEM — безплатна open-source платформа класу SIEM/XDR для моніторингу безпеки сервера: аналіз логів, контроль цілісності файлів, пошук вразливостей та автоматичне реагування на атаки. Wazuh декодує події, застосовує понад 3000 готових правил і класифікує інциденти за рівнями небезпеки від 0 до 15. Для власників VDS/VPS у Німеччині, США та Франції це спосіб побачити спробу злому в момент атаки, а не через тиждень у логах.

## Що таке Wazuh SIEM і навіщо він потрібен для захисту сервера?

Wazuh SIEM вирішує те, з чим не справляється звичайне логування: записи з `/var/log/auth.log`, `/var/log/nginx/access.log` та `dmesg` самі по собі не показують зв'язку між подіями. Wazuh збирає дані з агентів, корелює їх на менеджері і присвоює єдиний рівень тривоги. Десять невдалих SSH-підключень за хвилину перетворюються не на десять рядків логу, а на одне оповіщення про підбір паролів.

Платформа ширша, ніж fail2ban: [fail2ban](https://www.zevshost.net/uk/kb/nastroit-fail2ban/) реагує лише на шаблони в логах і банить IP, а Wazuh додатково контролює файли, перевіряє конфігурацію на відповідність CIS-бенчмаркам і зіставляє події з матрицею MITRE ATT&CK.

## Як влаштована архітектура Wazuh: manager, агент та індексатор?

Архітектура Wazuh складається з трьох компонентів, які можна розгорнути на одному сервері або окремо для навантажених інфраструктур.

- Wazuh manager — центральний сервер, приймає події від агентів по TCP-порту 1514, застосовує декодери й правила, запускає active response.
- Wazuh agent — легкий процес на захищуваному сервері, збирає логи, стежить за файлами (FIM) і надсилає дані менеджеру зашифрованим каналом.
- Wazuh indexer — сховище на базі OpenSearch, приймає оброблені події від менеджера через порт 9200.
- Wazuh dashboard — веб-інтерфейс на порту 443 для перегляду алертів, графіків і статусу агентів.

## Як встановити Wazuh-агент на VPS?

Якщо Wazuh manager уже розгорнутий (наприклад, через офіційний quick-start скрипт на окремому сервері управління), агент встановлюється на кожен захищуваний VDS/VPS однією командою.

```
curl -so wazuh-agent.deb https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.9.0-1_amd64.deb
WAZUH_MANAGER="10.0.0.5" dpkg -i ./wazuh-agent.deb
systemctl daemon-reload
systemctl enable wazuh-agent
systemctl start wazuh-agent
```

Після запуску агент з'являється у списку підключених хостів на дашборді менеджера. Варто одразу розподілити агенти за групами (веб-сервери, бази даних, пошта) — це спрощує застосування різних наборів правил FIM для кожної ролі сервера.

## Як налаштувати File Integrity Monitoring (FIM) для контролю файлів?

FIM відстежує зміни важливих файлів: якщо атакувальник підмінить `/etc/passwd`, додасть бекдор у веб-корінь сайту або змінить `/etc/ssh/sshd_config`, Wazuh зафіксує це в реальному часі і покаже, що саме змінилося — права доступу, власника чи контрольну суму.

| Шлях | Режим | Що контролюється |
| --- | --- | --- |
| /etc/passwd | realtime | Додавання та зміна облікових записів |
| /etc/ssh/sshd\_config | realtime | Послаблення налаштувань SSH-доступу |
| /etc/crontab | scheduled | Впровадження шкідливих завдань планувальника |
| /var/www/html | realtime | Веб-шели та підміна файлів сайту |
| /etc/wazuh-agent/ossec.conf | scheduled | Спроби вимкнути сам моніторинг |

Налаштування — у файлі `/var/ossec/etc/ossec.conf` на агенті, всередині блоку `syscheck`:

```
<syscheck>
  <directories realtime="yes" report_changes="yes" check_all="yes">/etc,/var/www/html</directories>
  <directories check_all="yes" whodata="yes">/etc/ssh/sshd_config,/etc/passwd</directories>
  <frequency>43200</frequency>
</syscheck>
```

## Як Wazuh аналізує логи та зіставляє атаки з MITRE ATT&CK?

Аналіз логів проходить чотири кроки: збір рядка логу агентом, розбір декодером на поля (IP, користувач, код відповіді), зіставлення з правилом із бази decoder/rule і присвоєння рівня тривоги. Правила для SSH, nginx, Apache, MySQL і десятків сервісів йдуть у комплекті.

Відмінність від простого логування — правило несе мітку тактики і техніки з матриці MITRE ATT&CK. Серія невдалих спроб входу класифікується як підбір облікових даних, а правка sshd після підозрілої активності — як закріплення в системі. Про аудит системних викликів ядра, який доповнює Wazuh, — у статті про [auditd](https://www.zevshost.net/uk/kb/linux-auditd-monitoring/).

## Як налаштувати active response та алерти в Telegram і Slack?

Active response — автоматична реакція менеджера на спрацьоване правило без участі адміністратора. Частий сценарій — блокування IP після серії невдалих спроб входу по SSH.

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

Сповіщення про алерти налаштовуються у блоці `integration` файлу `/var/ossec/etc/ossec.conf` на менеджері: вбудовані інтеграції надсилають повідомлення в Slack, Telegram (через проксі-скрипт) і на email, передаючи рівень тривоги, правило і сервер, де відбулася подія. Адміністратор отримує повідомлення протягом секунд після інциденту, а не знаходить його під час планової перевірки логів.

## Чек-лист впровадження Wazuh на сервері

- Розгорнути Wazuh manager, indexer і dashboard на окремому сервері управління.
- Встановити Wazuh agent на кожен VDS/VPS, розподілити агенти за групами.
- Увімкнути FIM realtime для /etc/passwd, /etc/ssh/sshd\_config і веб-кореня сайту.
- Перевірити, що правила для nginx/Apache, MySQL і SSH активні і отримують події.
- Налаштувати active response для блокування IP при підборі паролів.
- Підключити алерти в Telegram або Slack із фільтром за рівнем тривоги від 7.
- Раз на тиждень звірятися із загальним [чек-листом безпеки сервера](https://www.zevshost.net/uk/kb/server-security-checklist/).

---

Джерело: https://www.zevshost.net/uk/kb/wazuh-siem-monitoring/