Развёртывание SOC на базе Wazuh SIEM для среднего бизнеса

SOC — это не привилегия банков и телекомов. За последние пару лет мы видим, как атаки сместились в сторону среднего бизнеса: шифровальщики, утечки клиентских баз, угон учёток через фишинг. Если у вас есть ИТ-инфраструктура — у вас уже есть повод задуматься.

Wazuh — open-source SIEM-платформа, которая под одним капотом собирает сразу несколько инструментов:

• HIDS — мониторинг целостности файлов и обнаружение rootkit
• Log management — централизованный сбор и анализ логов
• Vulnerability detection — сканирование уязвимостей прямо на хостах, без отдельного сканера
• Compliance — проверка соответствия PCI DSS, GDPR, CIS Benchmarks
• Incident response — активное реагирование: заблокировать IP, убить процесс
• MITRE ATT&CK — маппинг обнаруженных угроз на фреймворк MITRE

Wazuh бесплатен и, если честно, закрывает процентов 80 того, что умеют Splunk или QRadar. Мы разворачивали его в компаниях с парком от 50 до 500 машин — нигде не упёрлись в потолок функциональности. По соотношению цены и возможностей конкурентов просто нет.

Из чего состоит Wazuh:

• Wazuh Server — анализирует события, коррелирует их, хранит правила
• Wazuh Indexer — OpenSearch под капотом: хранение и поиск по событиям
• Wazuh Dashboard — веб-интерфейс на базе OpenSearch Dashboards
• Wazuh Agents — агенты, которые ставятся на каждый контролируемый хост

Системные требования для 200 агентов:

До 200 агентов всё спокойно живёт на одном сервере: 8 vCPU, 32 ГБ RAM, 500 ГБ SSD. Когда инфраструктура вырастет — разнесёте компоненты на отдельные машины, это несложно.

Быстрая установка всех компонентов на один сервер (Ubuntu 22.04 / CentOS 9):

curl -sO https://packages.wazuh.com/4.7/wazuh-install.sh
curl -sO https://packages.wazuh.com/4.7/config.yml

# Отредактируйте config.yml — укажите IP сервера
vi config.yml

Минимальный config.yml:

nodes:
  indexer:
    - name: wazuh-indexer
      ip: "10.0.0.50"
  server:
    - name: wazuh-server
      ip: "10.0.0.50"
  dashboard:
    - name: wazuh-dashboard
      ip: "10.0.0.50"

Запустите установку:

sudo bash wazuh-install.sh --generate-config-files
sudo bash wazuh-install.sh --wazuh-indexer wazuh-indexer
sudo bash wazuh-install.sh --start-cluster
sudo bash wazuh-install.sh --wazuh-server wazuh-server
sudo bash wazuh-install.sh --wazuh-dashboard wazuh-dashboard

После установки откройте https://10.0.0.50 в браузере. Логин: admin, пароль появится в выводе установщика — сразу сохраните его куда-нибудь, потом не найдёте.

Дальше — агенты на все хосты, которые хотите контролировать.

Windows:

# PowerShell от администратора
Invoke-WebRequest -Uri https://packages.wazuh.com/4.x/windows/wazuh-agent-4.7.0-1.msi `
    -OutFile wazuh-agent.msi

.\wazuh-agent.msi /q WAZUH_MANAGER="10.0.0.50" `
    WAZUH_AGENT_GROUP="windows-servers" `
    WAZUH_AGENT_NAME="DC01"

net start WazuhSvc

Linux:

# Debian/Ubuntu
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | 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" > /etc/apt/sources.list.d/wazuh.list
apt update && apt install wazuh-agent -y

# Настройка
sed -i 's/MANAGER_IP/10.0.0.50/' /var/ossec/etc/ossec.conf
systemctl enable --now wazuh-agent

Убедитесь, что агенты подключились: в Dashboard откройте Agents → Manage Agents. Каждый агент должен быть в статусе «Active». Если висит «Disconnected» — смотрите файрвол, порт 1514/tcp.

Из коробки Wazuh идёт с тысячами правил. Но на практике выясняется: без кастомных правил под вашу конкретную инфраструктуру половина реально важных событий проходит мимо.

Файл кастомных правил: /var/ossec/etc/rules/local_rules.xml

<group name="custom,">
  <!-- Обнаружение brute-force на RDP -->
  <rule id="100001" level="10" frequency="5" timeframe="120">
    <if_matched_sid>60122</if_matched_sid>
    <description>Brute-force атака на RDP: $(srcip)</description>
    <mitre>
      <id>T1110</id>
    </mitre>
  </rule>

  <!-- Подозрительное создание нового администратора -->
  <rule id="100002" level="12">
    <if_sid>60137</if_sid>
    <field name="win.eventdata.targetUserName">^(?!.*\$$)</field>
    <field name="win.eventdata.groupName">Administrators|Администраторы</field>
    <description>Пользователь добавлен в группу администраторов: $(win.eventdata.targetUserName)</description>
    <mitre>
      <id>T1136</id>
    </mitre>
  </rule>

  <!-- Массовое удаление файлов (возможный шифровальщик) -->
  <rule id="100003" level="14" frequency="50" timeframe="60">
    <if_matched_sid>554</if_matched_sid>
    <description>Массовое изменение файлов — возможная атака шифровальщика</description>
    <mitre>
      <id>T1486</id>
    </mitre>
  </rule>
</group>

Перезагрузите правила: sudo systemctl restart wazuh-manager

Wazuh умеет не только сигнализировать, но и действовать: заблокировать IP через iptables, отключить учётную запись, убить подозрительный процесс. Руки сами не дойдут — система сделает за вас.

Настройка в /var/ossec/etc/ossec.conf на сервере:

<ossec_config>
  <!-- Блокировка IP при brute-force -->
  <active-response>
    <command>firewall-drop</command>
    <location>local</location>
    <rules_id>100001</rules_id>
    <timeout>3600</timeout>
  </active-response>

  <!-- Блокировка на Linux через iptables -->
  <active-response>
    <command>firewall-drop</command>
    <location>local</location>
    <rules_id>5712</rules_id>
    <timeout>1800</timeout>
  </active-response>
</ossec_config>

Для кастомных действий создайте скрипт реагирования:

#!/bin/bash
# /var/ossec/active-response/bin/disable-user.sh
SOURCE=$1
USER=$2
ACTION=$3

if [ "$ACTION" = "add" ]; then
    # Отключить учётную запись AD через PowerShell Remoting
    ssh admin@dc01 "powershell -c \"Disable-ADAccount -Identity '$USER'\""
    logger -t wazuh-ar "Disabled AD account: $USER (triggered by $SOURCE)"
fi

Wazuh поддерживает интеграции для уведомлений и обогащения данных:

Telegram-уведомления о критических событиях:

Файл /var/ossec/integrations/custom-telegram.py:

#!/usr/bin/env python3
import sys
import json
import requests

BOT_TOKEN = "123456:ABC-DEF"
CHAT_ID = "-1001234567890"

def main():
    alert_file = sys.argv[1]
    with open(alert_file) as f:
        alert = json.load(f)
    
    level = alert.get('rule', {}).get('level', 0)
    desc = alert.get('rule', {}).get('description', 'N/A')
    agent = alert.get('agent', {}).get('name', 'Unknown')
    src_ip = alert.get('data', {}).get('srcip', 'N/A')
    
    text = f"🚨 Wazuh Alert (Level {level})\n"
    text += f"Host: {agent}\n"
    text += f"Description: {desc}\n"
    text += f"Source IP: {src_ip}"
    
    requests.post(
        f"https://api.telegram.org/bot{BOT_TOKEN}/sendMessage",
        json={"chat_id": CHAT_ID, "text": text}
    )

if __name__ == "__main__":
    main()

Активация в ossec.conf:

<integration>
  <name>custom-telegram.py</name>
  <level>10</level>
  <alert_format>json</alert_format>
</integration>

Инструмент без процессов — это просто красивый дашборд. Чтобы SOC реально работал, нужно выстроить регламенты реагирования.

Приоритизация алертов по уровням:

• Level 12–15 (Critical) — реагируем немедленно: компрометация, шифровальщик
• Level 10–11 (High) — разбираемся в течение часа: brute-force, подозрительный доступ
• Level 7–9 (Medium) — анализируем в течение дня: изменения конфигурации, новые сервисы
• Level 0–6 (Low/Info) — еженедельный обзор, статистика, фоновый шум

Создайте Dashboard с ключевыми метриками — чтобы дежурный инженер с первого взгляда понимал, что происходит:

1. Количество алертов по уровням за 24 часа
2. Топ-10 атакующих IP-адресов
3. Хосты с наибольшим количеством событий
4. Карта MITRE ATT&CK — какие техники фиксируются прямо сейчас
5. Агенты с проблемами: offline, устаревшая версия

Раз в неделю садитесь разбирать накопленное: что оказалось ложным срабатыванием, какие правила врут, где вообще нет покрытия. Без этого ревью система постепенно деградирует — проверено.