Развёртывание SIEM: Wazuh или Elastic Security для лабораторной сети

SIEM это место, где журналы со всех систем собираются в одну картину, а правила превращают её в сигналы. Без него даже отличная политика аудита остаётся набором файлов на разных серверах. В статье мы выберем платформу для лабораторной сети itpages.lab.local, развернём её на srv-siem01 (192.168.10.30) и подключим srv-dc01, srv-web01 и rtr-edge01. Покажем Wazuh как основной вариант, потому что для небольшой лаборатории он быстрее заводится, а Elastic Security разберём как альтернативу.

Всё, что ниже, делай только на собственной лаборатории или в среде, где у тебя есть полномочия. Версии пакетов и точные параметры сверяй с актуальной документацией производителя: они меняются часто.

Wazuh или Elastic Security: как выбрать

Wazuh это открытая платформа с агентами для Windows, Linux и macOS, встроенными правилами обнаружения, контролем целостности файлов, оценкой конфигурации (SCA) и сопоставлением с MITRE ATT&CK. Состоит из менеджера, индексатора и дашборда. Плюсы: из коробки много полезного для защитника, один пакет установки, невысокие требования для лаборатории. Минусы: гибкость кастомной аналитики ниже, чем у чистого Elastic.

Elastic Security строится на Elasticsearch, Kibana и Elastic Agent. Плюсы: мощный поиск, гибкие панели, большая экосистема интеграций, правила обнаружения с привязкой к ATT&CK. Минусы: больше ресурсов и больше настроек, часть продвинутых функций лицензируется платно.

Простое правило выбора. Если у тебя один-два админа и цель быстро получить обнаружение и контроль конфигураций, бери Wazuh. Если ты уже работаешь с Elastic, нужны гибкие запросы и большая аналитика, смотри на Elastic Security. Для лаборатории с четырьмя хостами оба варианта работают, но дальше мы строим на Wazuh.

Шаги: Wazuh на srv-siem01

Шаг 1. Подготовь сервер

Минимум для лаборатории: 4 vCPU, 8 ГБ ОЗУ и 100 ГБ диска под индексы (на рабочей нагрузке нужно больше). Сервер лучше ставить на поддерживаемый дистрибутив Linux и сразу сделать три вещи: синхронизировать время, обновить систему и закрыть лишнее.

sudo timedatectl set-timezone UTC
sudo timedatectl set-ntp true
sudo apt update && sudo apt -y upgrade
sudo hostnamectl set-hostname srv-siem01
echo "192.168.10.30 srv-siem01.itpages.lab.local srv-siem01" | sudo tee -a /etc/hosts

Время это основа корреляции: если хосты расходятся по часам, события из разных источников невозможно сопоставить. Все серверы лаборатории должны синхронизироваться с одним источником времени, а журналы лучше хранить в UTC.

Шаг 2. Установи Wazuh

Wazuh предлагает установочный помощник, который разворачивает все компоненты на один узел. Скачай скрипт с официального сайта проекта (адрес и актуальную версию бери в документации), проверь его содержимое и контрольную сумму до запуска, и только потом запускай:

# версию и URL возьми из официальной документации Wazuh
curl -sO https://packages.wazuh.com/<версия>/wazuh-install.sh
sha256sum wazuh-install.sh        # сверь с опубликованным значением
less wazuh-install.sh             # просмотри, что именно будет выполняться
sudo bash wazuh-install.sh -a     # all-in-one: менеджер, индексатор, дашборд

В конце установщик выведет учётные данные администратора дашборда. Сохрани их в менеджере паролей и сразу смени. После установки проверь службы:

sudo systemctl status wazuh-manager wazuh-indexer wazuh-dashboard --no-pager
sudo ss -tlnp | grep -E '1514|1515|55000|9200|443'

Порты: 1514 для событий от агентов, 1515 для регистрации агентов, 55000 для API, 9200 для индексатора (не должен быть доступен снаружи), 443 для дашборда.

Шаг 3. Ограничь доступ

SIEM содержит самую чувствительную информацию о сети, поэтому его защита стоит отдельного внимания. Открой только то, что нужно, и только нужным подсетям:

sudo ufw default deny incoming
sudo ufw allow from 192.168.10.0/24 to any port 1514 proto tcp
sudo ufw allow from 192.168.10.0/24 to any port 1515 proto tcp
sudo ufw allow from 192.168.10.0/24 to any port 514 proto udp   # syslog от rtr-edge01
sudo ufw allow from 192.168.10.50 to any port 443 proto tcp    # рабочее место администратора
sudo ufw enable

Порт 9200 и API 55000 наружу не публикуй. Доступ к дашборду разрешай только с адреса администратора или через VPN, а для входа включай отдельные учётные записи с минимальными ролями.

Шаг 4. Подключи агентов

На srv-web01 (Linux) установи агент из официального репозитория Wazuh и укажи адрес менеджера. Пример для Debian-подобной системы после добавления репозитория:

sudo WAZUH_MANAGER="192.168.10.30" WAZUH_AGENT_NAME="srv-web01" apt -y install wazuh-agent
sudo systemctl daemon-reload
sudo systemctl enable --now wazuh-agent

На srv-dc01 (Windows) установи MSI-пакет агента с параметрами менеджера и запусти службу. В PowerShell от администратора:

msiexec.exe /i wazuh-agent.msi /q WAZUH_MANAGER="192.168.10.30" WAZUH_AGENT_NAME="srv-dc01"
NET START WazuhSvc

Проверь на менеджере, что агенты в статусе active:

sudo /var/ossec/bin/agent_control -l

Если агента нет в списке, смотри журнал на агенте (/var/ossec/logs/ossec.log в Linux, C:\Program Files (x86)\ossec-agent\ossec.log в Windows) и проверяй доступность портов 1514 и 1515 с агента.

Шаг 5. Включи нужные источники событий

Агент Windows собирает журналы по настройке в ossec.conf. Для контроллера домена нужны как минимум Security, System и Application, а на этом сервере также Directory Service:

<localfile>
  <location>Security</location>
  <log_format>eventchannel</log_format>
</localfile>
<localfile>
  <location>System</location>
  <log_format>eventchannel</log_format>
</localfile>
<localfile>
  <location>Directory Service</location>
  <log_format>eventchannel</log_format>
</localfile>

Для srv-web01 добавь журналы веб-сервера. Без них сайт остаётся слепой зоной:

<localfile>
  <log_format>apache</log_format>
  <location>/var/log/nginx/access.log</location>
</localfile>
<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/nginx/error.log</location>
</localfile>

Добавь контроль целостности файлов (FIM) для каталога сайта и важных конфигураций. Изменения в них должны быть редким и объяснимым событием:

<syscheck>
  <directories check_all="yes" realtime="yes">/var/www/html</directories>
  <directories check_all="yes">/etc/nginx,/etc/ssh</directories>
</syscheck>

Шаг 6. Принимай syslog с маршрутизатора

Сетевое оборудование не умеет ставить агентов, поэтому оно отправляет syslog на менеджер. Разреши приём в конфигурации менеджера (/var/ossec/etc/ossec.conf):

<remote>
  <connection>syslog</connection>
  <port>514</port>
  <protocol>udp</protocol>
  <allowed-ips>192.168.10.1</allowed-ips>
</remote>

На стороне rtr-edge01 настрой отправку (синтаксис условный, зависит от производителя):

logging host 192.168.10.30
logging trap informational
logging source-interface Vlan10
service timestamps log datetime msec

После изменений перезапусти менеджер: sudo systemctl restart wazuh-manager.

Шаг 7. Проверь, что обнаружение работает

Самая безопасная проверка это безвредное событие, которое должно вызвать алерт. Например, несколько неудачных входов по SSH на тестовую учётную запись в srv-web01 или создание нового локального пользователя на тестовом хосте. Сделай это в окне проверки, предупредив команду, и найди алерт в дашборде или в файле:

sudo tail -f /var/ossec/logs/alerts/alerts.json | jq -c '{time:.timestamp, agent:.agent.name, rule:.rule.id, level:.rule.level, descr:.rule.description}'

Если алерта нет, иди по цепочке в обратном порядке: сработало ли событие на хосте, прочитал ли его агент, дошло ли оно до менеджера, есть ли правило, не отфильтровано ли оно по уровню. Для проверки того, как менеджер разбирает конкретную строку журнала, используй встроенную утилиту:

sudo /var/ossec/bin/wazuh-logtest

Вставь строку журнала и посмотри, какое правило сработало и какие поля извлечены. Это основной инструмент отладки правил.

Шаг 8. Добавь своё правило

Собственные правила кладут в /var/ossec/etc/rules/local_rules.xml, а не правят встроенные. Пример: повысить уровень алерта на очистку журнала безопасности Windows:

<group name="itpages,windows,">
  <rule id="100100" level="12">
    <if_sid>60100</if_sid>
    <field name="win.system.eventID">^1102$</field>
    <description>IT-Pages: очищен журнал безопасности</description>
    <mitre>
      <id>T1070.001</id>
    </mitre>
  </rule>
</group>

Номер родительского правила в if_sid проверь через wazuh-logtest на реальном событии, он может отличаться в твоей версии. Диапазон идентификаторов 100000 и выше зарезервирован для пользовательских правил.

Если выбрал Elastic Security

Логика та же: развернуть Elasticsearch и Kibana, включить безопасность (TLS и аутентификацию, они активны по умолчанию в современных версиях), поставить Fleet Server, раздать Elastic Agent с политиками интеграций (Windows, Linux, Nginx, syslog) и включить предустановленные правила обнаружения. Особое внимание уделяй ресурсам: Elasticsearch требовательнее к памяти, ему нужно не менее 8 ГБ на узел, а лучше больше. Все остальные шаги про время, ограничение доступа, проверку источников и тестирование алертов применяются без изменений.

Эксплуатация: что делать после установки

Установка занимает час, а эксплуатация остаётся на годы, поэтому сразу заведи короткий регламент. Раз в день дежурный просматривает алерты высокого уровня и закрывает или эскалирует каждый. Раз в неделю проверяется список агентов: нет ли отключённых и давно молчащих. Раз в месяц просматриваются самые шумные правила: если одно срабатывает сотни раз, его нужно настроить или исключить явно известные безопасные источники, фиксируя каждое исключение вместе с причиной. Раз в квартал проводится проверка резервного копирования конфигурации и тест восстановления.

Отдельное внимание обновлениям. Сам SIEM это обычное программное обеспечение с уязвимостями, и он находится в центре сети, а значит, обновлять его нужно регулярно, предварительно проверив совместимость версий менеджера, индексатора и дашборда на тестовой копии. Не обновляй один компонент без остальных, если документация не говорит иначе. Храни конфигурации и собственные правила в системе контроля версий, чтобы любое изменение можно было откатить и объяснить.

И подумай о масштабировании заранее. Один узел подходит для лаборатории и очень небольшой организации. Если число источников растёт, потребуется разнести менеджер и индексатор по разным серверам, а при критичных требованиях к доступности перейти на кластер. Нормализация и аккуратный выбор собираемых источников отодвигают этот момент на годы, поэтому следующая статья серии особенно полезна.

Частые ошибки и как их избежать

• Открытый интерфейс SIEM и индексатора. Дашборд на 443 и особенно порт 9200 нельзя оставлять доступными из всех сетей. Ограничивай по адресам, включай отдельные роли и ведущие аудит учётные записи, храни резервную копию конфигурации и сертификатов.
• Неверное время. Рассинхрон часов делает корреляцию бессмысленной, а расследование мучительным. Настрой NTP на всех хостах, включая маршрутизатор, и храни события в UTC.
• Сбор всего подряд без плана. Если отправить в SIEM каждый журнал, диск закончится за неделю, а полезные сигналы утонут в шуме. Начинай с журналов безопасности и аутентификации, расширяй по приоритетам из своей карты покрытия, следи за размером индексов и задай политику хранения.

Автор — Команда IT-Pages