Требование 187-ФЗ о КИИ: внедряем SIEM Wazuh для микрофинансовой организации

Мы начали с аудита инфраструктуры «ФинСтрим» — чтобы понять, с чем вообще придётся работать:

• 3 сервера на Ubuntu 22.04: веб-приложение (Django), база данных (PostgreSQL), 1С:Бухгалтерия
• 1 Windows Server 2019 — Active Directory, файловый сервер, RDP-терминал
• 80 рабочих станций — Windows 10/11, часть сотрудников работала удалённо через VPN
• Периметр: Mikrotik RB4011 как основной маршрутизатор, без IDS/IPS

Картина вышла неприятная:

# Проверяем, ведутся ли логи на серверах
ls -la /var/log/auth.log
# -rw-r----- 1 syslog adm 847293 Jan 15 14:32 /var/log/auth.log

# Ротация — только 4 недели хранения
cat /etc/logrotate.d/rsyslog | grep rotate
# rotate 4

# Централизованного сбора логов — НЕТ
# IDS/IPS — НЕТ
# Мониторинга целостности файлов — НЕТ
# Сканирования уязвимостей — НЕТ

# Проверяем SSH — brute-force атаки
grep 'Failed password' /var/log/auth.log | wc -l
# 14832 — за последние 2 недели!

grep 'Failed password' /var/log/auth.log | \
  awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -5
# 4721 218.92.0.107
# 3182 185.234.216.82
# 2891 103.144.240.15
# 2419 45.141.84.93
# 1619 193.42.33.67

Почти 15 000 попыток подбора пароля за две недели — и никто этого не видел. Ни одного оповещения, ни одной блокировки. На Windows Server ситуация не лучше: Event Log переполнен, ротация стирала события старше 7 дней — то есть любые следы атаки просто исчезали.

Мы прогнали несколько SIEM-решений через сравнение:

Остановились на Wazuh. Открытый код, встроенный compliance-модуль (PCI DSS, GDPR), агенты под Linux и Windows, file integrity monitoring и vulnerability detection прямо из коробки. Плюс экономия — «ФинСтрим» не тратила больше миллиона рублей в год по сравнению с коммерческими аналогами. Для МФО с ограниченным IT-бюджетом это не мелочь.

Wazuh есть all-in-one установщик, но для продуктивной среды мы пошли по пошаговой установке — так понятнее, что куда ложится и что потом настраивать:

# Подготовка сервера (Ubuntu 22.04)
sudo apt update && sudo apt upgrade -y
sudo apt install -y curl apt-transport-https gnupg2

# Добавляем GPG-ключ и репозиторий Wazuh
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | \
  sudo gpg --dearmor -o /usr/share/keyrings/wazuh.gpg
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" | \
  sudo tee /etc/apt/sources.list.d/wazuh.list

sudo apt update

# Устанавливаем Wazuh Manager
sudo apt install -y wazuh-manager
sudo systemctl daemon-reload
sudo systemctl enable wazuh-manager
sudo systemctl start wazuh-manager

# Проверяем статус
sudo systemctl status wazuh-manager
# ● wazuh-manager.service - Wazuh manager
#   Active: active (running)

# Устанавливаем Wazuh Indexer (OpenSearch fork)
sudo apt install -y wazuh-indexer

# Генерируем сертификаты для TLS-коммуникации
sudo /usr/share/wazuh-indexer/plugins/opensearch-security/tools/wazuh-certs-tool.sh \
  --admin-cert --indexer-cert --manager-cert --dashboard-cert

# Запускаем Indexer
sudo systemctl enable wazuh-indexer
sudo systemctl start wazuh-indexer

# Устанавливаем Wazuh Dashboard
sudo apt install -y wazuh-dashboard
sudo systemctl enable wazuh-dashboard
sudo systemctl start wazuh-dashboard

После установки Wazuh Dashboard поднялся на https://wazuh-server:443. Первым делом — сменили дефолтные пароли и прикрутили HTTPS с валидным сертификатом Let's Encrypt для внутреннего домена. Работать с дефолтными credentials в продуктиве — плохая идея, видели последствия.

Основная конфигурация Wazuh Manager живёт в /var/ossec/etc/ossec.conf. Под требования «ФинСтрим» мы его основательно переработали:

<!-- /var/ossec/etc/ossec.conf — Wazuh Manager -->
<ossec_config>
  <global>
    <jsonout_output>yes</jsonout_output>
    <alerts_log>yes</alerts_log>
    <logall>no</logall>
    <logall_json>no</logall_json>
    <email_notification>yes</email_notification>
    <smtp_server>smtp.finstrim.local</smtp_server>
    <email_from>wazuh@finstrim.local</email_from>
    <email_to>security@finstrim.ru</email_to>
    <email_maxperhour>30</email_maxperhour>
  </global>

  <!-- Сбор логов syslog -->
  <remote>
    <connection>secure</connection>
    <port>1514</port>
    <protocol>tcp</protocol>
    <queue_size>131072</queue_size>
  </remote>

  <!-- Правила алертинга -->
  <alerts>
    <log_alert_level>3</log_alert_level>
    <email_alert_level>10</email_alert_level>
  </alerts>

  <!-- Интеграция с Telegram для критических алертов -->
  <integration>
    <name>custom-telegram</name>
    <level>12</level>
    <alert_format>json</alert_format>
  </integration>

  <!-- Vulnerability Detector -->
  <vulnerability-detector>
    <enabled>yes</enabled>
    <interval>12h</interval>
    <run_on_start>yes</run_on_start>
    <provider name="canonical">
      <enabled>yes</enabled>
      <os>jammy</os>
      <update_interval>1h</update_interval>
    </provider>
    <provider name="msu">
      <enabled>yes</enabled>
      <update_interval>1h</update_interval>
    </provider>
    <provider name="nvd">
      <enabled>yes</enabled>
      <update_interval>1h</update_interval>
    </provider>
  </vulnerability-detector>
</ossec_config>

Ключевой момент — email_alert_level выставили на 10, Telegram-интеграцию на уровень 12. На практике это работает так: email приходит при серьёзных событиях (уровень 10+), а Telegram дёргает только когда совсем горит — попытки эксплуатации, rootkit detection, массовое удаление файлов. Дежурный не захлёбывается в уведомлениях.

Агенты встали на все 4 сервера и 15 критических рабочих станций — бухгалтерия, руководство, ИТ-отдел:

# Установка агента на Linux-серверах
sudo apt install -y wazuh-agent

# Регистрация агента на менеджере
sudo /var/ossec/bin/agent-auth -m 10.0.1.50 -p 1515 -A "web-server-01"

# Конфигурация агента /var/ossec/etc/ossec.conf
# Указываем адрес менеджера
sudo sed -i 's/MANAGER_IP/10.0.1.50/' /var/ossec/etc/ossec.conf

sudo systemctl enable wazuh-agent
sudo systemctl start wazuh-agent

# Проверяем подключение
sudo /var/ossec/bin/agent_control -l
# ID: 001, Name: web-server-01, IP: 10.0.1.10, Status: Active

На Windows-серверах и рабочих станциях использовали MSI-установщик с параметрами:

:: Установка Wazuh Agent на Windows (PowerShell)
$WazuhMSI = "wazuh-agent-4.7.2-1.msi"
Invoke-WebRequest -Uri "https://packages.wazuh.com/4.x/windows/$WazuhMSI" -OutFile $WazuhMSI

msiexec.exe /i $WazuhMSI /q `
  WAZUH_MANAGER="10.0.1.50" `
  WAZUH_AGENT_NAME="win-dc-01" `
  WAZUH_REGISTRATION_SERVER="10.0.1.50" `
  WAZUH_AGENT_GROUP="windows-servers"

# Запуск службы
NET START WazuhSvc

# Для массового развёртывания через GPO:
# Создаём скрипт startup и назначаем на OU в Active Directory

Через GPO раскатали агенты на все 15 рабочих станций за один вечер. Агент потребляет не более 50 МБ RAM и меньше 1% CPU — пользователи вообще не замечают его присутствия.

Под каждый тип серверов настроили свою конфигурацию FIM в ossec.conf агента:

<!-- FIM для Linux-серверов -->
<syscheck>
  <disabled>no</disabled>
  <frequency>300</frequency>
  <scan_on_start>yes</scan_on_start>
  <alert_new_files>yes</alert_new_files>

  <!-- Критические системные директории -->
  <directories check_all="yes" realtime="yes">/etc,/usr/bin,/usr/sbin</directories>
  <directories check_all="yes" realtime="yes">/bin,/sbin,/boot</directories>

  <!-- Конфигурация веб-приложения -->
  <directories check_all="yes" realtime="yes" report_changes="yes">/opt/finstrim/config</directories>
  <directories check_all="yes" realtime="yes">/opt/finstrim/app</directories>

  <!-- SSH ключи -->
  <directories check_all="yes" realtime="yes">/root/.ssh,/home/*/.ssh</directories>

  <!-- Crontab -->
  <directories check_all="yes" realtime="yes">/var/spool/cron,/etc/crontab,/etc/cron.d</directories>

  <!-- Игнорируем шумные директории -->
  <ignore>/etc/mtab</ignore>
  <ignore>/etc/resolv.conf</ignore>
  <ignore type="sregex">.log$|.swp$</ignore>
</syscheck>

<!-- FIM для Windows (в агенте на DC) -->
<syscheck>
  <directories check_all="yes" realtime="yes">C:\Windows\System32\config</directories>
  <directories check_all="yes" realtime="yes">C:\Windows\System32\drivers\etc</directories>
  <directories check_all="yes" realtime="yes">%PROGRAMDATA%\ssh</directories>

  <!-- Реестр Windows -->
  <windows_registry arch="both">HKEY_LOCAL_MACHINE\Software\Policies</windows_registry>
  <windows_registry arch="both">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services</windows_registry>
  <windows_registry>HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run</windows_registry>
</syscheck>

realtime="yes" задействует inotify на Linux и ReadDirectoryChangesW на Windows — изменения фиксируются мгновенно, не ждём следующего цикла сканирования. А report_changes="yes" для конфигурационных файлов даёт полный diff: видно не просто факт изменения, а что именно и как изменилось. На расследованиях инцидентов это экономит часы.

Wazuh Vulnerability Detector сопоставляет установленное ПО с базами CVE (NVD, Canonical, Microsoft) автоматически. Первое сканирование принесло 47 уязвимостей разной степени серьёзности:

# Просмотр обнаруженных уязвимостей через API
curl -k -u admin:SecretPass123 \
  "https://localhost:55000/vulnerability/001?pretty&limit=5" | jq '.data.affected_items[:5]'

# Результат первого сканирования:
# Критических (CVSS 9.0+):  3
# Высоких (CVSS 7.0-8.9):   12
# Средних (CVSS 4.0-6.9):   27
# Низких (CVSS 0.1-3.9):    5

# Критическая: CVE-2023-44487 (HTTP/2 Rapid Reset) в nginx 1.18
# Критическая: CVE-2024-3094 (xz backdoor) — xz-utils 5.4.1
# Критическая: CVE-2023-4911 (Looney Tunables glibc) — glibc 2.35

# Экстренное обновление:
sudo apt update && sudo apt upgrade -y

# Повторное сканирование после обновления:
# Критических: 0 | Высоких: 2 | Средних: 9 | Низких: 3

Три критические уязвимости на серверах, которые обрабатывают финансовые данные. Именно такие вещи регулятор ожидает видеть задокументированными в журнале — и именно их отсутствие становится поводом для предписаний. После устранения настроили автоматический алерт на любую новую CVE с CVSS выше 7.0.

Django-приложение «ФинСтрим» писало логи в собственном формате — Wazuh из коробки их просто не понимал. Написали custom decoder:

<!-- /var/ossec/etc/decoders/local_decoder.xml -->

<!-- Декодер для логов Django-приложения ФинСтрим -->
<decoder name="finstrim-app">
  <prematch>^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2} \[FINSTRIM\]</prematch>
</decoder>

<decoder name="finstrim-app-auth">
  <parent>finstrim-app</parent>
  <regex>\[FINSTRIM\] (\S+) user=(\S+) ip=(\S+) endpoint=(\S+) status=(\S+)</regex>
  <order>action,user,srcip,url,status</order>
</decoder>

<decoder name="finstrim-app-loan">
  <parent>finstrim-app</parent>
  <regex>\[FINSTRIM\] LOAN_(\S+) user=(\S+) ip=(\S+) amount=(\S+) decision=(\S+)</regex>
  <order>action,user,srcip,extra_data,status</order>
</decoder>

После этого Wazuh начал разбирать логи приложения и генерировать алерты по бизнес-событиям: провальные входы, странные запросы на займы, обращения к API из стран, откуда клиенты исторически не приходят.

Поверх custom decoders написали правила под специфику МФО:

<!-- /var/ossec/etc/rules/local_rules.xml -->

<group name="finstrim,authentication,">
  <!-- Неуспешный вход в приложение -->
  <rule id="100001" level="5">
    <decoded_as>finstrim-app-auth</decoded_as>
    <field name="action">AUTH_FAILED</field>
    <description>ФинСтрим: Неуспешная попытка входа пользователя $(user) с IP $(srcip)</description>
    <group>authentication_failed,pci_dss_10.2.4,pci_dss_10.2.5,</group>
  </rule>

  <!-- Brute-force: 5 неуспешных входов за 2 минуты -->
  <rule id="100002" level="10" frequency="5" timeframe="120">
    <if_matched_sid>100001</if_matched_sid>
    <same_source_ip />
    <description>ФинСтрим: Brute-force атака на приложение с IP $(srcip)</description>
    <group>authentication_failures,pci_dss_11.4,</group>
  </rule>
</group>

<group name="finstrim,loan_operations,">
  <!-- Попытка оформления займа из чужой страны -->
  <rule id="100010" level="12">
    <decoded_as>finstrim-app-loan</decoded_as>
    <field name="action">LOAN_REQUEST</field>
    <field name="srcip">!10.0.|!192.168.</field>
    <description>ФинСтрим: Запрос на выдачу займа с внешнего IP $(srcip) пользователем $(user)</description>
    <group>fraud_detection,</group>
  </rule>

  <!-- Аномально крупный займ -->
  <rule id="100011" level="10">
    <decoded_as>finstrim-app-loan</decoded_as>
    <field name="action">LOAN_APPROVED</field>
    <field name="extra_data">^[5-9]\d{4,}|^\d{6,}</field>
    <description>ФинСтрим: Одобрен крупный займ на сумму $(extra_data) руб. пользователю $(user)</description>
    <group>fraud_detection,pci_dss_10.2.7,</group>
  </rule>
</group>

Правило 100010 с уровнем 12 — оформление займа с нетипичного IP — моментально летит в Telegram к ИТ-директору. По опыту, такие события в 7 случаях из 10 означают компрометацию учётки.

Active Response — это когда Wazuh не просто сигнализирует об угрозе, а сам что-то делает. Настроили два сценария:

<!-- Active Response в ossec.conf менеджера -->

<!-- Блокировка IP при brute-force SSH -->
<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>5763</rules_id>
  <timeout>3600</timeout>
  <repeated_offenders>60,120,1440,10080</repeated_offenders>
</active-response>

<!-- Блокировка при brute-force на приложение -->
<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>100002</rules_id>
  <timeout>7200</timeout>
  <repeated_offenders>120,1440,10080</repeated_offenders>
</active-response>

Параметр repeated_offenders работает по нарастающей: первая блокировка — час, вторая — два, третья — сутки, четвёртая — неделя. За первые семь дней Active Response самостоятельно заблокировал 238 IP-адресов, которые пытались подобрать пароли к SSH и веб-приложению. Без единого звонка нам.

# Проверяем заблокированные IP
sudo /var/ossec/bin/agent_control -L

# Список активных блокировок
sudo iptables -L INPUT -n | grep DROP | wc -l
# 42 — текущих активных блокировок

# Ручная разблокировка (если заблокировали легитимный IP)
sudo /var/ossec/active-response/bin/firewall-drop delete - 203.0.113.10

187-ФЗ для субъекта КИИ — это конкретный список мер, не абстрактных. Мы расписали, какая функция Wazuh что закрывает:

По PCI DSS работает автотегирование: «ФинСтрим» обрабатывает банковские карты, поэтому каждый алерт автоматически получает ссылку на конкретный пункт стандарта. Аудитору — удобно, команде — не нужно делать это руками.

Модуль SCA прогоняет конфигурацию серверов по чеклистам CIS Benchmarks и выдаёт, что не так:

<!-- Включение SCA в ossec.conf агента -->
<sca>
  <enabled>yes</enabled>
  <scan_on_start>yes</scan_on_start>
  <interval>24h</interval>
  <policies>
    <policy>cis_ubuntu22-04.yml</policy>
    <policy>cis_win2019.yml</policy>
    <policy>pci_dss_v4.yml</policy>
  </policies>
</sca>

Первый же SCA-скан нашёл 23 несоответствия CIS Benchmark на Linux-серверах. Незащищённый GRUB, нет auditd, болтаются открытые порты, которые никто не использует годами. Всё закрыли в рамках проекта:

# Пример устранения — защита GRUB загрузчика
sudo grub-mkpasswd-pbkdf2
# Enter password: *****
# PBKDF2 hash of your password is grub.pbkdf2.sha512.10000.ABC123...

sudo bash -c 'cat >> /etc/grub.d/40_custom << EOF
set superusers="admin"
password_pbkdf2 admin grub.pbkdf2.sha512.10000.ABC123...
EOF'
sudo update-grub

# Установка и настройка auditd
sudo apt install -y auditd audispd-plugins
sudo systemctl enable auditd

# Правила аудита для критических операций
sudo bash -c 'cat > /etc/audit/rules.d/finstream.rules << EOF
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/sudoers -p wa -k actions
-w /var/log/auth.log -p wa -k auth_log
-a always,exit -F arch=b64 -S execve -F euid=0 -k rootcmd
EOF'
sudo augenrules --load

Готовые дашборды Wazuh — хорошая отправная точка, но для финансовой организации их не хватает. Сделали дополнительные виды:

• Loan Security Dashboard — всё про операции с займами: аномальные суммы, нетипичные IP, отклонённые запросы — в одном месте
• Compliance Overview — сводка по PCI DSS и 187-ФЗ: сколько выполнено, что открыто, как меняется динамика
• Attack Map — карта источников атак по географии на основе GeoIP: сразу видно, откуда давят
• FIM Change Log — журнал изменений в контролируемых файлах, сгруппированный по серверу и уровню критичности

# Настройка GeoIP для карты атак
# Скачиваем базу MaxMind GeoLite2
wget https://download.maxmind.com/app/geoip_download?edition_id=GeoLite2-City&suffix=tar.gz \
  -O /tmp/GeoLite2-City.tar.gz
tar xzf /tmp/GeoLite2-City.tar.gz -C /usr/share/GeoIP/ --strip-components=1

# Wazuh Indexer автоматически обогащает поле srcip геоданными
# В Dashboard создаём визуализацию типа "Coordinate Map"
# Агрегация: data.srcip с GeoIP-пайплайном

Параллельно прописали для «ФинСтрим» процедуру реагирования на инциденты — прямо завязанную на уровни алертов Wazuh:

1. Уровень 3–7 (Low) — пишем в лог, аналитик смотрит раз в неделю
2. Уровень 8–10 (Medium) — email в ИТ-отдел, разбираются в течение 24 часов
3. Уровень 11–13 (High) — Telegram-алерт, 4 часа на разбор, Active Response включается автоматически
4. Уровень 14–15 (Critical) — Telegram плюс звонок дежурному, хост изолируется, разбор немедленно

# Скрипт интеграции с Telegram
# /var/ossec/integrations/custom-telegram
#!/bin/bash
BOT_TOKEN="7123456789:AAHxxxxxxxxxxxxxxxxxxxxxxxxxx"
CHAT_ID="-100123456789"

ALERT_FILE="$1"
HOOK_URL="https://api.telegram.org/bot${BOT_TOKEN}/sendMessage"

# Парсим JSON алерт
LEVEL=$(jq -r '.parameters.alert.rule.level' "$ALERT_FILE")
DESC=$(jq -r '.parameters.alert.rule.description' "$ALERT_FILE")
AGENT=$(jq -r '.parameters.alert.agent.name' "$ALERT_FILE")
SRCIP=$(jq -r '.parameters.alert.data.srcip // "N/A"' "$ALERT_FILE")
TIME=$(jq -r '.parameters.alert.timestamp' "$ALERT_FILE")

# Формируем сообщение
MSG="🚨 *WAZUH ALERT [Level ${LEVEL}]*
📍 Agent: ${AGENT}
⚠️ ${DESC}
🌐 Source IP: ${SRCIP}
🕐 Time: ${TIME}"

curl -s -X POST "$HOOK_URL" \
  -d chat_id="$CHAT_ID" \
  -d parse_mode="Markdown" \
  -d text="$MSG"

Дежурный «ФинСтрим» получает критические алерты в Telegram мгновенно. Среднее время реакции на инцидент — с «когда заметим» до 12 минут. Разница, как говорится, ощутимая.

Проверку ЦБ прошли без замечаний. Регулятор обратил внимание на SIEM, журнал инцидентов, FIM и vulnerability management. Compliance-отчёты прямо из Wazuh Dashboard отдельно похвалили.

После сдачи проекта отдали «ФинСтрим» дорожную карту — что делать дальше, чтобы система не стояла на месте:

• Внедрение SOAR — Shuffle для автоматизации: тикеты, изоляция хостов, уведомления по инцидентам без ручного труда
• Threat Intelligence — подключение фидов MISP и AlienVault OTX, чтобы алерты обогащались реальными IoC
• Network IDS — Suricata на периметре с интеграцией в Wazuh для сетевого мониторинга
• Расширение агентов — сейчас покрыты только критические узлы, следующий шаг — все 80 рабочих станций
• Red Team — ежеквартальный пентест: проверяем, не превратился ли SIEM в красивый дашборд, который ничего не ловит

Wazuh закрывает требования 187-ФЗ для малого и среднего бизнеса — и без многомиллионных бюджетов на коммерческие SIEM. Мы настраивали его в десятках организаций и честно скажем: при грамотной конфигурации он даёт уровень мониторинга, который вполне сопоставим с тем, за что другие платят по нескольку миллионов в год.