· 15 мин чтения

OSSEC/Wazuh HIDS: как я защищаю корпоративные серверы от вторжений

OSSEC/Wazuh HIDS: как я защищаю корпоративные серверы от вторжений

Семёнов Евгений Сергеевич, директор АйТи Фреш. 15+ лет в корпоративной инфраструктуре. Примерно в 70% аудитов, которые мы проводим, на серверах нет никакого мониторинга безопасности кроме антивируса и стандартных логов. А потом внезапно выясняется, что бэкапник полгода назад добавил себе админские права и выгружает базы ночами. Или что на веб-сервере с декабря висит крипто-майнер. OSSEC (и его форк Wazuh) — та самая прослойка, которая ловит подобные сценарии автоматически. Расскажу, как мы в АйТи Фреш разворачиваем HIDS для своих клиентов.

Что такое HIDS и зачем он нужен

Host-based Intrusion Detection System — это система обнаружения вторжений, работающая на уровне хоста. В отличие от NIDS (Snort, Suricata), которые смотрят сетевой трафик, HIDS анализирует происходящее внутри ОС: логи, целостность файлов, процессы, автозагрузку, ядро.

Задачи, которые HIDS закрывает:

OSSEC в 2004 году создал разработчик Daniel Cid, позже его купила Trend Micro. Wazuh — форк от 2015 года, который сейчас значительно обогнал родительский проект. Я всегда ставлю Wazuh, если у клиента нет специфичных причин для OSSEC.

Архитектура: агент-менеджер-индексатор

Классическая схема Wazuh состоит из трёх компонентов:

Для офиса до 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 ServerC:\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 года. Задача — развернуть централизованную систему аудита.

Решение:

За первые две недели поймали 4 инцидента: два внешних SSH brute-force из Китая, одна попытка смены GPO неавторизованным админом, один факт установки PowerShell-скрипта, которого не было в бэкапах. По итогам внесены исправления в процедуры AD. Стоимость внедрения — 240 000 руб., ежемесячное сопровождение — 18 000 руб.

Частые ошибки при внедрении OSSEC

Интеграции с 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, отключение учётки, завершение процесса. Ставится с осторожностью — я всегда сначала наблюдаю в режиме только уведомлений, потом включаю реактивные действия.

Подпишитесь на рассылку ITfresh

Раз в неделю — практические гайды для руководителя IT и сисадмина: безопасность, 1С, миграции, резервные копии, лайфхаки из реальных проектов.

Реквизиты оператора персональных данных

ООО «АЙТИ-ФРЕШ», ИНН 7719418495, КПП 771901001. Юридический адрес: 105523, г. Москва, Щёлковское шоссе, д. 92, корп. 7. Контакт: info@itfresh.ru, +7 903 729-62-41. Оператор обрабатывает e-mail подписчика в целях рассылки информационных и рекламных материалов до момента отзыва согласия.