OSSEC/Wazuh HIDS: как я защищаю корпоративные серверы от вторжений
Семёнов Евгений Сергеевич, директор АйТи Фреш. 15+ лет в корпоративной инфраструктуре. Примерно в 70% аудитов, которые мы проводим, на серверах нет никакого мониторинга безопасности кроме антивируса и стандартных логов. А потом внезапно выясняется, что бэкапник полгода назад добавил себе админские права и выгружает базы ночами. Или что на веб-сервере с декабря висит крипто-майнер. OSSEC (и его форк Wazuh) — та самая прослойка, которая ловит подобные сценарии автоматически. Расскажу, как мы в АйТи Фреш разворачиваем HIDS для своих клиентов.
Что такое HIDS и зачем он нужен
Host-based Intrusion Detection System — это система обнаружения вторжений, работающая на уровне хоста. В отличие от NIDS (Snort, Suricata), которые смотрят сетевой трафик, HIDS анализирует происходящее внутри ОС: логи, целостность файлов, процессы, автозагрузку, ядро.
Задачи, которые HIDS закрывает:
- Аудит целостности — любое изменение
/etc/passwd,/etc/sudoers, бинарников в/usr/binнемедленно видно. - Лог-анализ — централизованный сбор syslog/Event Log, корреляция, алерты на подозрительные паттерны (brute-force, privilege escalation, аномальные sudo).
- Контроль реестра Windows — добавление в HKLM\...\Run, изменения в службах.
- Rootkit detection — встроенные проверки на известные руткиты.
- Compliance — политики CIS Benchmarks, PCI DSS, HIPAA из коробки.
OSSEC в 2004 году создал разработчик Daniel Cid, позже его купила Trend Micro. Wazuh — форк от 2015 года, который сейчас значительно обогнал родительский проект. Я всегда ставлю Wazuh, если у клиента нет специфичных причин для OSSEC.
Архитектура: агент-менеджер-индексатор
Классическая схема Wazuh состоит из трёх компонентов:
- Wazuh Agent — небольшой демон на каждом сервере/ПК, собирает логи и события, отправляет менеджеру по TCP/UDP 1514 с AES-шифрованием.
- Wazuh Manager — сервер, принимает события от агентов, применяет декодеры и правила, триггерит алерты и active response.
- Wazuh Indexer + Dashboard — OpenSearch для хранения и Kibana-подобный интерфейс для визуализации.
Для офиса до 50 серверов и 200 ПК подходит одна виртуалка 4 vCPU / 16 ГБ RAM / 500 ГБ SSD со всеми тремя ролями. У нас на практике — виртуалка на Dell Xeon Platinum 8280 в дата-центре МТС, подключение к агентам через корпоративную сеть 40G Mellanox, что позволяет держать сотни подключений без заметной нагрузки.
Установка Wazuh: всё-в-одном
Wazuh даёт скрипт all-in-one, который ставит менеджер, индексатор и дашборд на одну машину. Ubuntu 22.04 LTS:
curl -sO https://packages.wazuh.com/4.7/wazuh-install.sh
bash wazuh-install.sh --all-in-one
# После установки
cat /etc/wazuh-indexer/wazuh-passwords.txt
# Логин: admin, пароль в файле
Открываем https://ip_сервера в браузере, заходим под admin. Даёт полную картину — состояние агентов, алерты, правила, возможность писать кастомные декодеры.
Установка агентов на Linux и Windows
Агенты получают конфигурацию с менеджера, сами регистрируются (через API или общий ключ).
# Linux-агент (Ubuntu/Debian)
curl -so wazuh-agent.deb https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.7.0-1_amd64.deb
WAZUH_MANAGER="wazuh.corp.example.ru" WAZUH_AGENT_GROUP="linux-servers" \
dpkg -i wazuh-agent.deb
systemctl enable --now wazuh-agent
systemctl status wazuh-agent
# Windows-агент (PowerShell от админа)
Invoke-WebRequest -Uri https://packages.wazuh.com/4.x/windows/wazuh-agent-4.7.0-1.msi `
-OutFile $env:TEMP\wazuh-agent.msi
msiexec.exe /i $env:TEMP\wazuh-agent.msi /qn `
WAZUH_MANAGER="wazuh.corp.example.ru" WAZUH_AGENT_GROUP="windows-servers"
Start-Service WazuhSvc
Через 1–2 минуты агент появляется в дашборде со статусом «Active».
File Integrity Monitoring: FIM
Одна из сильных сторон OSSEC — контроль целостности. Настраивается в ossec.conf агента или централизованно через группу:
<syscheck>
<frequency>43200</frequency>
<scan_on_start>yes</scan_on_start>
<directories check_all="yes" realtime="yes">/etc,/usr/bin,/usr/sbin</directories>
<directories check_all="yes" realtime="yes">/var/www/html</directories>
<ignore>/etc/mtab</ignore>
<ignore>/etc/hosts.deny</ignore>
<ignore type="sregex">.log$|.swp$</ignore>
<nodiff>/etc/shadow</nodiff>
</syscheck>
Параметр realtime использует inotify на Linux и FileSystemWatcher на Windows — изменения видны мгновенно. Для типового сервера я контролирую:
| Платформа | Критичные директории |
|---|---|
| Linux | /etc, /usr/bin, /usr/sbin, /boot, /root/.ssh, /var/www |
| Windows Server | C:\Windows\System32, HKLM\SOFTWARE, HKLM\...\Services, C:\Program Files |
| Веб-сервер | /var/www/html, /etc/nginx, /etc/apache2, /opt/custom-app |
| Контроллер домена | NTDS, SYSVOL, GPOs, HKLM\SYSTEM\CurrentControlSet\Services |
Правила и декодеры
Wazuh идёт с тысячами правил из коробки — от SSH brute-force до детекта Mimikatz по event-id. Каждое правило имеет уровень 0–15, я настраиваю алерты на 10+:
<!-- /var/ossec/etc/rules/local_rules.xml -->
<group name="local,custom,">
<rule id="100001" level="12">
<if_sid>5716</if_sid>
<srcip>!10.10.0.0/16</srcip>
<description>SSH brute-force attempt from external IP</description>
</rule>
<rule id="100002" level="13">
<if_sid>550</if_sid>
<match>/etc/passwd</match>
<description>Critical: /etc/passwd modified</description>
</rule>
<rule id="100003" level="10">
<if_sid>60122</if_sid>
<field name="win.eventdata.parentImage">cmd.exe</field>
<field name="win.eventdata.image">powershell.exe</field>
<description>cmd.exe spawned PowerShell — potential LOLBin</description>
</rule>
</group>
Active Response: автоматические реакции
После базовой настройки и двухнедельного наблюдения можно включить active response. Пример — автоматическая блокировка IP при множественных неудачных SSH-логинах:
<ossec_config>
<command>
<name>firewall-drop</name>
<executable>firewall-drop</executable>
<expect>srcip</expect>
<timeout_allowed>yes</timeout_allowed>
</command>
<active-response>
<command>firewall-drop</command>
<location>local</location>
<rules_id>5712,5710</rules_id>
<timeout>600</timeout>
</active-response>
</ossec_config>
Я всегда начинаю с timeout 10 минут и белым списком для доверенных IP. За месяц accumulated data становится видно, что блокировки работают на злоумышленников, а не на сотрудников. Только потом увеличиваю timeout до 24 часов или постоянной блокировки.
Мини-кейс: сеть клиник, 18 серверов
В мае 2025 года к нам на обслуживание пришла сеть клиник — 4 филиала, 18 серверов (терминальный сервер, AD DC, файловые серверы, 1С, Bitrix24). Требование Минздрава — журналирование событий безопасности с хранением 3 года. Задача — развернуть централизованную систему аудита.
Решение:
- Wazuh Manager + Indexer на виртуалке 8 vCPU / 32 ГБ / 2 ТБ SSD в дата-центре МТС.
- Агенты на всех 18 серверах + 120 Windows-ПК, групповые конфиги через Wazuh group.
- FIM на критичные директории всех серверов, в том числе базы 1С (
*.1CD). - Интеграция с Telegram-ботом: алерты уровня 10+ приходят в приватный канал ИБ-отдела.
- Custom-правила для детекта выгрузок 1С и подозрительных SQL-запросов.
- Архивирование событий на отдельную СХД, холодное хранение >90 дней на CEPH-кластере.
За первые две недели поймали 4 инцидента: два внешних SSH brute-force из Китая, одна попытка смены GPO неавторизованным админом, один факт установки PowerShell-скрипта, которого не было в бэкапах. По итогам внесены исправления в процедуры AD. Стоимость внедрения — 240 000 руб., ежемесячное сопровождение — 18 000 руб.
Частые ошибки при внедрении OSSEC
- Установка без фильтрации шума. Свежий Wazuh генерит 10-20К событий в день на агент. Без настройки подавления alert storm, потом трудно найти реальные инциденты.
- Active Response без тестирования. Включили auto-block и заблокировали коллегу, который с нового IP полез на сервер. Обязательно белый список доверенных подсетей.
- Отсутствие мониторинга самого OSSEC. Если агент упал — вы молча потеряли источник событий. Мониторьте состояние агентов через дашборд.
- Дефолтные правила без кастомизации. У каждой инфраструктуры свои нормальные паттерны. Правила нужно тюнить.
- Нет ретеншена. Диск быстро забивается. Настройте ILM в OpenSearch: hot → warm → delete по возрасту.
Интеграции с SIEM и SOC
Wazuh умеет отправлять алерты в сторонние SIEM — Splunk, Graylog, QRadar. У нас есть клиенты, где Wazuh стоит как датасборщик, а анализ идёт в корпоративный Graylog. Для связи — syslog-вывод с кастомным форматом или API-пуллинг.
<!-- Отправка алертов в Graylog -->
<ossec_config>
<syslog_output>
<level>5</level>
<server>graylog.corp.example.ru</server>
<port>5140</port>
<format>json</format>
</syslog_output>
</ossec_config>
/var/ossec/bin/ossec-control enable client-syslog
/var/ossec/bin/ossec-control restart
Развернём Wazuh HIDS в вашем офисе
Полное внедрение OSSEC/Wazuh на все серверы и рабочие станции, настройка правил под вашу инфраструктуру, интеграция с Telegram/SIEM, обучение ИБ-специалиста. Для офисов от 20 серверов, срок — 5–10 рабочих дней. Постоянное сопровождение, реагирование на алерты 24/7.
Телефон: +7 903 729-62-41
Telegram: @ITfresh_Boss
Семёнов Евгений Сергеевич, директор АйТи Фреш
FAQ — частые вопросы по OSSEC/Wazuh
- Чем OSSEC отличается от Wazuh?
- Wazuh — форк OSSEC, который развивается активнее. Для новых инсталляций в 2025 году я всегда рекомендую Wazuh: современный веб-интерфейс, интеграция с Elasticsearch/OpenSearch, большая база правил. OSSEC подходит если нужна минималистичная установка без тяжёлого ELK-стека.
- Нужен ли OSSEC, если уже есть антивирус?
- Да, это разные уровни защиты. Антивирус смотрит на файлы, OSSEC — на логи, изменения в системе, подозрительные процессы, аномалии во входах. OSSEC поймает боковое перемещение атакующего, когда антивирус промолчит.
- Сколько агентов выдержит один OSSEC-сервер?
- До 500 агентов на виртуалке 4 vCPU/8 ГБ без ELK. С Wazuh + OpenSearch — до 1000 агентов на связке из менеджера и двух индексаторов. Для больших инсталляций кластеризуют Wazuh Manager.
- Какие логи OSSEC умеет читать?
- Syslog, Windows Event Log, Auditd, IIS, Apache, Nginx, PostgreSQL, Exchange, Cisco ASA, pfSense — список встроенных декодеров огромный. Свои форматы легко добавляются через XML-декодер и правило.
- Что такое active response?
- Автоматическая реакция на событие: блокировка IP через iptables, отключение учётки, завершение процесса. Ставится с осторожностью — я всегда сначала наблюдаю в режиме только уведомлений, потом включаю реактивные действия.
