# Серверный кластер Wazuh - архитектура и настройка > Настройка кластера серверов Wazuh 4.14 - архитектура master/worker, конфигурация ossec.conf, синхронизация, балансировка агентов и устранение неполадок Source: https://opennix.org/docs/wazuh/infrastructure/wazuh-server-cluster/ Серверный кластер Wazuh объединяет несколько менеджеров для обеспечения горизонтального масштабирования и отказоустойчивости. Кластерная архитектура master/worker позволяет распределить нагрузку анализа событий между узлами, сохраняя единую конфигурацию правил, декодеров и политик безопасности. ## Архитектура кластера ### Роли узлов Кластер Wazuh использует модель с двумя типами узлов: **Master (главный узел)** - центральный узел кластера, выполняющий следующие функции: - Хранение эталонной конфигурации (правила, декодеры, CDB-списки) - Распространение изменений конфигурации на worker-узлы - Управление регистрацией и группами агентов - Прием подключений от worker-узлов для синхронизации - Обработка запросов REST API, касающихся кластера **Worker (рабочий узел)** - узел, принимающий события от агентов и выполняющий их анализ: - Получение событий от назначенных агентов через порт 1514/TCP - Выполнение декодирования и сопоставления правил - Передача результатов анализа в индексатор через Filebeat - Получение обновлений конфигурации от master-узла - Отправка информации о состоянии агентов на master-узел В кластере допускается только один master-узел. Количество worker-узлов ограничено только ресурсами инфраструктуры. ### Коммуникация между узлами Узлы кластера обмениваются данными через порт 1516/TCP с шифрованием. Master-узел прослушивает входящие соединения от worker-узлов. Каждый worker устанавливает постоянное соединение с master-узлом для получения обновлений конфигурации и отправки статусной информации. ``` ┌─────────────────┐ │ Master Node │ │ (manager_01) │ │ Port 1516 │ └────┬───────┬────┘ 1516/TCP │ │ 1516/TCP ┌────────────┘ └────────────┐ ▼ ▼ ┌─────────────────┐ ┌─────────────────┐ │ Worker Node 1 │ │ Worker Node 2 │ │ (manager_02) │ │ (manager_03) │ └────┬───────┬────┘ └────┬───────┬────┘ │ │ │ │ 1514/TCP 1514/TCP 1514/TCP 1514/TCP │ │ │ │ ┌────┘ ┌───┘ ┌────┘ ┌───┘ ▼ ▼ ▼ ▼ Agent 1 Agent 2 Agent 3 Agent 4 ``` ## Конфигурация кластера в ossec.conf Настройка кластера выполняется в файле `/var/ossec/etc/ossec.conf` внутри блока ``. Конфигурация должна быть задана на каждом узле кластера. ### Полный блок конфигурации ```xml wazuh manager_01 master ugdtAnd7Pi9myP7CVts4qZaZQEQcRYZa 1516 0.0.0.0 192.168.1.10 no no ``` ### Описание параметров | Параметр | Описание | Значение по умолчанию | Допустимые значения | |---|---|---|---| | `name` | Имя кластера. Все узлы кластера должны использовать одинаковое имя | `wazuh` | Буквенно-цифровая строка | | `node_name` | Уникальное имя данного узла внутри кластера | `node01` | Произвольная строка, уникальная для каждого узла | | `node_type` | Роль узла в кластере | `master` | `master`, `worker` | | `key` | 32-символьный ключ шифрования для межузловой коммуникации. Должен быть идентичным на всех узлах | - | 32 буквенно-цифровых символа | | `port` | TCP-порт для кластерного взаимодействия | `1516` | 1-65535 | | `bind_addr` | IP-адрес, на котором узел принимает кластерные соединения | `0.0.0.0` | Валидный IPv4/IPv6-адрес | | `nodes` | Список IP-адресов или DNS-имен master-узла | - | IP-адреса или FQDN | | `hidden` | Скрывает информацию об источнике кластера в алертах | `no` | `yes`, `no` | | `disabled` | Отключает кластерную функциональность | `no` | `yes`, `no` | ### Генерация ключа кластера Ключ должен содержать ровно 32 буквенно-цифровых символа. Для генерации используйте: ```bash openssl rand -hex 16 ``` Результат будет содержать 32 шестнадцатеричных символа, подходящих для параметра `key`. ### Конфигурация master-узла ```xml production-cluster master-node master a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6 1516 0.0.0.0 192.168.1.10 no no ``` ### Конфигурация worker-узла На worker-узле изменяются параметры `node_name` и `node_type`. В блоке `` указывается IP-адрес master-узла: ```xml production-cluster worker-01 worker a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6 1516 0.0.0.0 192.168.1.10 no no ``` После изменения конфигурации перезапустите менеджер: ```bash systemctl restart wazuh-manager ``` ## Синхронизация между узлами Master-узел автоматически распространяет определенные файлы и данные на все worker-узлы. Синхронизация обеспечивает единообразие конфигурации анализа событий на всех узлах кластера. ### Синхронизируемые данные **От master к worker:** | Категория | Файлы/данные | Описание | |---|---|---| | Правила | `/var/ossec/etc/rules/local_rules.xml` и пользовательские правила | Правила детектирования угроз | | Декодеры | `/var/ossec/etc/decoders/local_decoder.xml` и пользовательские декодеры | Парсеры логов | | CDB-списки | `/var/ossec/etc/lists/` | Списки для дополнительной классификации | | Конфигурация групп | `/var/ossec/etc/shared/` | Конфигурации agent.conf для групп агентов | | Пользовательские файлы | Файлы, добавленные в директории правил и декодеров | Все содержимое директорий `etc/rules` и `etc/decoders` | **От worker к master:** | Категория | Данные | Описание | |---|---|---| | Информация об агентах | Статус, версия, ОС агентов | Данные о подключенных к worker-узлу агентах | | Статус агентов | Время последнего подключения, keepalive | Оперативная информация о состоянии агентов | | Группы агентов | Принадлежность агента к группам | Синхронизация назначений групп | ### Механизм синхронизации Синхронизация работает по модели push от master-узла. При изменении файлов на master-узле вычисляется контрольная сумма, и измененные файлы передаются на все worker-узлы. Worker-узлы не могут инициировать распространение конфигурации - изменения правил и декодеров должны выполняться только на master-узле. Интервал проверки синхронизации по умолчанию составляет 10 секунд. В течение этого времени master-узел сравнивает контрольные суммы файлов и определяет необходимость обновления. ## Добавление и удаление узлов ### Добавление worker-узла 1. Установите Wazuh менеджер на новом сервере. 2. Настройте блок `` в `/var/ossec/etc/ossec.conf`: ```xml production-cluster worker-02 worker a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6 1516 0.0.0.0 192.168.1.10 no no ``` 3. Убедитесь, что порт 1516/TCP открыт между новым узлом и master-узлом. 4. Запустите менеджер: ```bash systemctl start wazuh-manager ``` 5. Проверьте подключение узла: ```bash /var/ossec/bin/cluster_control -l ``` ### Удаление worker-узла 1. Переназначьте агентов с удаляемого worker-узла на другие узлы. 2. Остановите менеджер на удаляемом узле: ```bash systemctl stop wazuh-manager ``` 3. Убедитесь, что узел исчез из списка: ```bash /var/ossec/bin/cluster_control -l ``` Master-узел автоматически определяет отключение worker-узла и обновляет список активных узлов. ## Балансировка агентов между worker-узлами ### Назначение агентов Агенты могут подключаться к любому узлу кластера (master или worker). Для балансировки нагрузки рекомендуется использовать внешний балансировщик нагрузки (HAProxy, Nginx, AWS NLB), который распределяет входящие подключения агентов по worker-узлам. ### Конфигурация через DNS Round-Robin Простейший вариант балансировки - DNS-запись с несколькими A-записями: ``` wazuh-cluster.example.com A 192.168.1.11 ; worker-01 wazuh-cluster.example.com A 192.168.1.12 ; worker-02 wazuh-cluster.example.com A 192.168.1.13 ; worker-03 ``` В конфигурации агента (`ossec.conf`) укажите DNS-имя: ```xml
wazuh-cluster.example.com
1514 tcp ``` ### Конфигурация через HAProxy Для более контролируемой балансировки используйте HAProxy: ``` frontend wazuh_agents bind *:1514 mode tcp default_backend wazuh_workers backend wazuh_workers mode tcp balance roundrobin server worker-01 192.168.1.11:1514 check server worker-02 192.168.1.12:1514 check server worker-03 192.168.1.13:1514 check ``` Подробнее о настройке балансировки см. в документации [HAProxy для pfSense](/docs/pfsense/) или аналогичных решений. ### Рекомендации по распределению - Направляйте агентов преимущественно на worker-узлы, а не на master - Master-узел обрабатывает кластерную синхронизацию и API-запросы, поэтому назначение большого количества агентов на master снижает производительность - Следите за равномерным распределением агентов между worker-узлами с помощью `cluster_control` ## Утилита cluster_control Утилита `/var/ossec/bin/cluster_control` предоставляет интерфейс командной строки для мониторинга и управления кластером. ### Просмотр состояния кластера ```bash # Список всех узлов кластера /var/ossec/bin/cluster_control -l ``` Пример вывода: ``` NAME TYPE VERSION ADDRESS master-node master 4.14.3 192.168.1.10 worker-01 worker 4.14.3 192.168.1.11 worker-02 worker 4.14.3 192.168.1.12 ``` ### Просмотр распределения агентов ```bash # Показать количество агентов на каждом узле /var/ossec/bin/cluster_control -a ``` Пример вывода: ``` NAME AGENTS master-node 15 worker-01 245 worker-02 240 ``` ### Дополнительные команды ```bash # Подробная информация о конкретном узле /var/ossec/bin/cluster_control -i worker-01 # Проверка состояния синхронизации /var/ossec/bin/cluster_control -l -fn # Вывод справки /var/ossec/bin/cluster_control -h ``` ### Мониторинг через REST API Состояние кластера также доступно через [REST API](/docs/wazuh/infrastructure/wazuh-server-api/): ```bash # Получение JWT-токена TOKEN=$(curl -sk -u wazuh-wui:password \ -X POST "https://localhost:55000/security/user/authenticate?raw=true") # Информация об узлах кластера curl -sk -H "Authorization: Bearer $TOKEN" \ "https://localhost:55000/cluster/nodes?pretty=true" # Состояние кластера curl -sk -H "Authorization: Bearer $TOKEN" \ "https://localhost:55000/cluster/status?pretty=true" # Распределение агентов по узлам curl -sk -H "Authorization: Bearer $TOKEN" \ "https://localhost:55000/agents?pretty=true&select=node_name&limit=500" ``` ## Настройка производительности ### Рекомендации по количеству агентов Количество агентов, которое может обслужить один узел, зависит от аппаратных ресурсов и интенсивности генерации событий (EPS - Events Per Second). | Ресурсы узла (CPU/RAM) | Рекомендуемое число агентов | Примерный EPS | |---|---|---| | 2 CPU / 4 ГБ | До 50 | До 100 | | 4 CPU / 8 ГБ | До 200 | До 500 | | 8 CPU / 16 ГБ | До 1000 | До 2500 | | 16 CPU / 32 ГБ | До 5000 | До 10000 | ### Оптимизация master-узла Master-узел обрабатывает синхронизацию и API-запросы. Для оптимизации: - Минимизируйте количество агентов, подключенных к master-узлу - Выделите master-узлу достаточно ресурсов для синхронизации (особенно важно при большом количестве пользовательских правил и декодеров) - Разместите master-узел и worker-узлы в одной сети для минимизации задержки синхронизации ### Настройка Filebeat Каждый узел кластера передает данные в [индексатор](/docs/wazuh/infrastructure/wazuh-indexer-cluster/) через Filebeat. Убедитесь, что Filebeat настроен на каждом узле и указывает на кластер индексатора: ```yaml output.elasticsearch: hosts: - "192.168.1.20:9200" - "192.168.1.21:9200" - "192.168.1.22:9200" protocol: https username: admin password: "${INDEXER_PASSWORD}" ssl.certificate_authorities: - /etc/filebeat/certs/root-ca.pem ``` ## Сравнение с другими SIEM-системами ### Splunk Indexer Clustering | Характеристика | Wazuh Server Cluster | Splunk Indexer Cluster | |---|---|---| | Модель | Master/Worker | Cluster Manager/Peers | | Функция master | Синхронизация конфигурации | Управление репликацией данных | | Балансировка | Внешний балансировщик (HAProxy) | Встроенный (forwarder affinity) | | Синхронизация | Правила, декодеры, списки | Бандлы конфигурации | | Стоимость | Бесплатно (open source) | Коммерческая лицензия | ### ELK Coordinating Nodes | Характеристика | Wazuh Server Cluster | ELK Stack | |---|---|---| | Анализ событий | На серверном кластере | На уровне Logstash | | Кластеризация | Встроенная | Отдельная для каждого компонента | | Конфигурация | Единый ossec.conf | Раздельные конфигурации ES, Logstash, Kibana | | Детектирование | Правила и декодеры | ElastAlert / Detection Rules (отдельный проект) | ## Устранение неполадок ### Узел не присоединяется к кластеру **Симптомы:** worker-узел не появляется в `cluster_control -l`. **Проверки:** 1. Убедитесь, что ключ (`key`) идентичен на master и worker узлах. 2. Проверьте сетевую доступность порта 1516/TCP: ```bash nc -zv 192.168.1.10 1516 ``` 3. Проверьте имя кластера (`name`) - оно должно совпадать на всех узлах. 4. Просмотрите лог кластера: ```bash tail -f /var/ossec/logs/cluster.log ``` 5. Убедитесь, что параметр `disabled` установлен в `no`. ### Проблемы синхронизации **Симптомы:** изменения правил на master не применяются на worker-узлах. **Проверки:** 1. Проверьте статус синхронизации: ```bash /var/ossec/bin/cluster_control -l -fn ``` 2. Убедитесь, что изменения внесены на master-узле (не на worker). 3. Просмотрите лог кластера на наличие ошибок синхронизации: ```bash grep -i "error\|sync" /var/ossec/logs/cluster.log | tail -20 ``` 4. Дождитесь интервала синхронизации (по умолчанию 10 секунд) или перезапустите менеджер. ### Split-brain (расщепление кластера) **Симптомы:** worker-узлы не видят master, агенты подключены, но алерты не генерируются корректно. **Причины:** - Потеря сетевого соединения между узлами - Перегрузка master-узла - Неверная конфигурация сетевых интерфейсов (`bind_addr`) **Решение:** 1. Восстановите сетевое соединение между узлами. 2. Перезапустите worker-узлы после восстановления связи: ```bash systemctl restart wazuh-manager ``` 3. Проверьте целостность кластера: ```bash /var/ossec/bin/cluster_control -l ``` ### Высокое потребление ресурсов при синхронизации **Симптомы:** master-узел испытывает пиковые нагрузки на CPU/RAM при большом количестве пользовательских правил. **Решение:** - Сократите количество пользовательских правил и декодеров, объединяя дублирующиеся - Увеличьте ресурсы master-узла - Проверьте, что не происходит циклическая синхронизация (изменения вносятся только на master) Для общего обзора инфраструктурных компонентов обратитесь к [разделу инфраструктуры Wazuh](/docs/wazuh/infrastructure/). Информация о компонентах платформы доступна в разделе [архитектура Wazuh](/docs/wazuh/getting-started/wazuh-architecture/).