Wazuh – это open-source платформа класса SIEM/XDR, реализующая функции централизованного сбора и корреляции событий безопасности, анализа журналов, обнаружения угроз, контроля целостности и реагирования на инциденты в ИТ-инфраструктуре.

 

SIEM (Security Information and Event Management) – это класс систем информационной безопасности, предназначенных для централизованного сбора, хранения, корреляции и анализа событий из различных источников для обнаружения угроз, расследования инцидентов и обеспечения соответствия требованиям безопасности в ИТ-инфраструктуре.

XDR (Extended Detection and Response) – это технология централизованного обнаружения угроз и реагирования на инциденты безопасности с объединением данных из разных источников инфраструктуры.

SIEM в первую очередь собирает, хранит и анализирует события безопасности (фокус на мониторинге). XDR дополнительно объединяет данные из разных систем и ориентирован на активное обнаружение и реагирование на атаки (более высокая автоматизация, фокус на обнаружение и реагирование).

Wazuh является бесплатным программным обеспечением с открытым исходным кодом. Бесплатный сыр, как известно, в мышиловке. Wazuh очень сложно настраивать и логика её правил корреляции тоже не всегда логичная. В этом основа её коммерческой реализации – бесплатное open-source ядро + платное обслуживание (установка, настройка, поддержка). Ходят слухи о переводе Wazuh 5 на полностью коммерческую модель, но официальной информации об этом не опубликовано.

 

Структура Wazuh.

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

Agent – отправляет логи на сервер с клиентов Windows. Логи так же могут поступать в безагентном варианте с других сетевых устройств.

Indexer – хранит и индексирует логи и события.

Manager – главный серверный компонент Wazuh. Принимает события от агентов и выполняет основную логику SIEM.

Filebeat – передача логов в Indexer.

Dashboard – визуализация (web-интерфейс), поиск и анализ событий.

 

Начиная с версии Wazuh 4.3 для роли Indexer вместо Elasticsearch используется технология OpenSearch, для Dashboard вместо Kibana – OpenSearch Dashboards. При этом Wazuh всё ещё поддерживает интеграцию с Elastic Stack отдельно, но это уже внешний вариант интеграции, а не основная архитектура.

OpenSearch – поисковый и аналитический движок для хранения и анализа логов.

Elastikserch – это аналогичная OpenSearch технология – распределенное хранилище и поисковый движок. Хранит и индексирует данные логов и событий. Использовался в старых версиях Wazuh.

Kibana – это веб-интерфейс для визуализации данных из Elasticsearch. Используется для построения дашбордов, поиска и анализа событий в старых версиях Wazuh.

Существуют три архитектуры развертывания: All-in-one deployment (всё на одном сервере), Single-node deployment (каждый компонент на отдельном сервере) и Multi-node deployment (кластеры для больших сред). В данном описании всё установлено на одном сервере.

 

Принцип работы.

Wazuh работает по следующему принципу. На клиенте Windows устанавливается wazuh-агент. Через GPO или локальную политику определяется, какие логи будут передаваться. Далее агент передает на сервер Wazuh указанные логи. Сервер принимает логи по порту 1514 TCP/UDP, собирает их как обычный syslog и, если настроить, пропускает логи через правила корреляции для акцентирования внимания на событиях безопасности (так называемых алертах).

Можно настроить оповещение об выбранных событиях на электронную почту или в Telegram если нет постоянного дежурного на мониторинге. Например, ввели неправильно пароль 5 раз при входе в компьютер и учетная запись заблокировалась – приходит сообщение.

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

Логи с коммутаторов и Linux принимаются в безагентном режиме. Если оборудование использует нестандартный формат логов, например, некоторые модели BDCOM, требуется написание собственных декодеров для корректной обработки (чтоб логи отображались в GUI и пропускались через правила корреляции).

По результатам полученной информации из мониторинга или из мессенджера, администратор ИБ реагирует на инцидент.

 

Примерный расчет параметров сервера.

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

В данном случае архитектура All-in-one deployment (все компоненты на одном сервере). Рассчитаем EPS или EPM для такого варианта.

EPS (Events Per Second) – это количество событий (логов), которые SIEM-система обрабатывает в секунду. Этот показатель используется для оценки производительности и расчёта аппаратных ресурсов.

EPM (Events Per Minute) – это количество событий, обрабатываемых системой за минуту. Это тот же показатель нагрузки, но в другом масштабе (1 EPM = 60 EPS).

Для расчёта требуемых ресурсов SIEM необходимо:

-определить количество источников событий (серверы, сетевые устройства, системы безопасности и т. д.);

-учесть их тип (например, Windows, Linux, firewall, KSC, приложения);

-оценить среднее количество генерируемых логов каждым источником за выбранный период времени;

-перевести общий объём событий в EPS или EPM.

Чтоб сориентироваться на примере нашей сети, у нас в Wazuh поступают логи из 400 ПК Windows, 20 серверов Windows/Linux (среди них наиболее активные DC1-2), сетевого экрана, роутера и 20 коммутаторов ЛВС.

Wazuh и OpenSearch масштабируются прежде всего по потоку событий, объёму индексации, объёму поиска, объему хранилища (зависящего от сроков хранения логов). Количество устройств само по себе вторично: 1000 «тихих» Linux-хостов могут давать меньше нагрузки, чем 20 шумных DC и сетевых экранов. Sysmon, auditd, IDS подробное логирование (verbose) и тп. резко увеличивают EPS.

Общий поток событий в Wazuh можно оценить так:

EPS = Σ (Ni × Ei)

где:

Ni – количество источников определённого типа;

Ei – среднее количество событий в секунду от одного источника этого типа.

 

С учетом названного оборудования, формула будет выглядеть так:

EPS = (Npc × Epc) + (Nserv × Eserv) + (Ndc × Edc) + (Nfw × Efw) + (Nrt × Ert) + (Nsw × Esw)

 

То есть:

EPS = (400 × Epc) + (18 × Eserv) + (2 × Edc) + (1 × Efw) + (1 × Ert) + (20 × Esw)

Чтобы получить реальные цифры, нужно замерить текущий поток логов (например, за сутки) в Wazuh, разделить события по типам источников, рассчитать средний EPS и пиковый EPS. Добавить запас 20-30% для роста и всплесков.

В корпоративных сетях часто используют такие стартовые значения:

ПК: 0,05-0,3 EPS;

обычный сервер: 1-3 EPS;

DC: 10-50 EPS;

firewall: 50-500 EPS;

сетевое оборудование (switch/router): 1-10 EPS.

Но это очень зависит от уровня логирования.

В результате средний расчётный поток событий ≈ 557 EPS. Немного накинем запаса и примем в работу значение 800 EPS. В реальной инфраструктуре EPS почти всегда растёт из-за различных факторов.

 

На основании расчета можно ориентироваться на следующие системные требования.

CPU  8-12 vCPU

RAM 16-32 GB

Storage 500 GB-2 TB SSD

Важный момент – для Wazuh RAM почти всегда важнее CPU. Например: 8 vCPU + 32 GB RAM обычно лучше, чем 16 vCPU + 8 GB RAM.

Основная нагрузка в Wazuh приходится на Wazuh Indexer (OpenSearch), который отвечает за индексацию, хранение и поиск событий.

В официальной документации приводятся системные требования для каждого компонента Wazuh отдельно (Indexer, Server, Dashboard).

 

Операционная система для Wazuh.

Wazuh устанавливается на операционных системах Linux. В данном случае использована Ubuntu.

Wazuh поддерживает Ubuntu начиная с версии 13. Более новые версии Ubuntu тоже предполагаются совместимыми, если не указано обратное. Полный перечень поддерживаемых ОС представлен на этой странице.

Ubuntu 22-24 сейчас считается нормальным и актуальным вариантом для Wazuh.

Скачиваем выбранный дистрибутив ОС с официального сайта.

 

Создание виртуальной машины (ВМ).

Для работы с ВМ использован Hyper-V Windows Server 2019.

В данном случае системные параметры ВМ следующие:

-ядер процессора (Intel Xeon Gold 6542Y) – 10шт;

-оперативная память – 24Гб;

-дисковое пространство для ОС – 100Гб SSD RAID;

-дисковое пространство для данных – 500ГБ SSD RAID (объем зависит от ситуации);

-операционная система – Ubuntu 22.

С такими параметрами работается вполне комфортно и без перегрузок при сборе данных с примерно 400 сетевых устройств разного типа (как описано выше в расчете).

Объем диска заполняется за 3-4 месяца. Нужно предусмотреть «холодное» хранение логов на сетевом хранилище.

Логи нужно хранить согласно местного регламента, например, 1-3-5 лет. У каждого по-разному. Это прописано в политиках ИБ организации.

 

​

​

 

Удаленный доступ.

Доступ осуществляется по SSH. Сервер OpenSSH установлен в процессе развертывания Ubuntu.

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

Чтоб выполнялось большинство команд необходимо перейти в режим с правами root.

(пароль)

Далее все действия в терминале выполняются с правами root. В командах ниже это ни как не обозначено (например $ или sudo перед командой).

 

Обновляем репозитории (без этого не установится).

 

Устанавливаем ssh-сервер.

 

Запускаем любой удобный SSH-терминал (Putty, cmd-windows, MobaXterm и тп.) Указываем IP-адрес сервера и протокол подключения.

 

Подтверждаем.

 

Вводим логин и пароль, которые указывали при установке Ubuntu.

Получаем доступ к управлению сервером.

 

Настройка время на сервере.

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

Проверка текущего состояния.

 

Находим и выбираем нужный часовой регион.

 

Установка часового региона.

 

Включение синхронизации по NTP:

Сервера NTP в локальной сети раздаются через DHCP-сервер роутера. Единый источник времени для всех устройств сети, как правило, контроллер домена. На нем должна быть настроена служба времени w32tm.

 

Проверка статуса синхронизации.

 

Установка Wazuh.

Процесс установки под названием Quickstart понятно изложен в оригинальной документации на сайте Wazuh. Для тех, кто не умеет читать оригинал, ниже представлен весь процесс. У виртуальной машины Wazuh должен быть обеспечен доступ в Интернет.

Устанавливаем команду curl.

curl (Client for URL) – это инструмент командной строки, позволяющий взаимодействовать с серверами, отправлять запросы и получать ответы без использования графического браузера.

 

Запускаем помощника конфигурирования wazuh – скрипт который автоматом скачает и установит все компоненты (сервер, индексатор и панель управления)

 

Компоненты следующие:

— Wazuh indexer —

indexer (wazuh-indexer service)

 

— Wazuh server —

manager (wazuh-manager service)

filebeat (filebeat service)

 

— Wazuh dashboard —

Dashboard (wazuh-dashboaerd service)

 

Лог установки.

Установка завершается сообщением «Installation finished».

В установочном логе отображаются логин и пароль для входа в web-интерфейс wazuh.

 

В компьютере админа, в этой же локальной сети переходим в браузере по адресу сервера.

 

Подтверждаем переход на сайт с недоверенным сертификатом.

 

Логин и пароль предоставлялись в терминале.

 

Попадаем в главный интерфейс Wazuh.

После успешного выполнения настроек у нас получилась полностью работающая сием Wazuh в конфигурации All-in-one.