Требование 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 попыток подбора пароля за 2 недели — и никто этого не видел. Ни одного оповещения, ни одной блокировки. На Windows Server ситуация была аналогичной: Event Log переполнен, ротация стирала события старше 7 дней.

Мы рассмотрели несколько SIEM-решений:

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

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 для внутреннего домена.

Основная конфигурация 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 писало логи в собственном формате. Мы создали 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 ИТ-директору. Такие инциденты часто указывают на компрометацию учётной записи.

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 увеличивает время блокировки при повторных атаках: первый раз — 1 час, второй — 2 часа, третий — 24 часа, четвёртый — 7 дней. В первую же неделю 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 (стандарт актуален, т.к. МФО обрабатывает банковские карты) Wazuh автоматически тегирует правила — каждый алерт содержит ссылку на пункт стандарта.

Модуль SCA проверяет конфигурацию серверов на соответствие best practices 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 для автоматизации реагирования (тикеты, изоляция хостов, email инциденты)
• Threat Intelligence — подключение фидов MISP и AlienVault OTX для обогащения алертов IoC
• Network IDS — Suricata на периметре с интеграцией в Wazuh для сетевого мониторинга
• Расширение агентов — установка на все 80 рабочих станций (на текущий момент покрыты только критические)
• Red Team — ежеквартальное пентест-тестирование для проверки эффективности SIEM

Wazuh доказал, что open source SIEM способен закрыть требования 187-ФЗ для малых и средних организаций без многомиллионных бюджетов. При грамотной настройке он обеспечивает уровень мониторинга, сопоставимый с коммерческими решениями.