Серверный кластер Wazuh - архитектура и настройка

Серверный кластер 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 внутри блока <cluster>. Конфигурация должна быть задана на каждом узле кластера.

Полный блок конфигурации

<cluster>
  <name>wazuh</name>
  <node_name>manager_01</node_name>
  <node_type>master</node_type>
  <key>ugdtAnd7Pi9myP7CVts4qZaZQEQcRYZa</key>
  <port>1516</port>
  <bind_addr>0.0.0.0</bind_addr>
  <nodes>
    <node>192.168.1.10</node>
  </nodes>
  <hidden>no</hidden>
  <disabled>no</disabled>
</cluster>

Описание параметров

Генерация ключа кластера

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

openssl rand -hex 16

Результат будет содержать 32 шестнадцатеричных символа, подходящих для параметра key.

Конфигурация master-узла

<cluster>
  <name>production-cluster</name>
  <node_name>master-node</node_name>
  <node_type>master</node_type>
  <key>a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6</key>
  <port>1516</port>
  <bind_addr>0.0.0.0</bind_addr>
  <nodes>
    <node>192.168.1.10</node>
  </nodes>
  <hidden>no</hidden>
  <disabled>no</disabled>
</cluster>

Конфигурация worker-узла

На worker-узле изменяются параметры node_name и node_type. В блоке <nodes> указывается IP-адрес master-узла:

<cluster>
  <name>production-cluster</name>
  <node_name>worker-01</node_name>
  <node_type>worker</node_type>
  <key>a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6</key>
  <port>1516</port>
  <bind_addr>0.0.0.0</bind_addr>
  <nodes>
    <node>192.168.1.10</node>
  </nodes>
  <hidden>no</hidden>
  <disabled>no</disabled>
</cluster>

После изменения конфигурации перезапустите менеджер:

systemctl restart wazuh-manager

Синхронизация между узлами

Master-узел автоматически распространяет определенные файлы и данные на все worker-узлы. Синхронизация обеспечивает единообразие конфигурации анализа событий на всех узлах кластера.

Синхронизируемые данные

От master к worker:

От worker к master:

Механизм синхронизации

Синхронизация работает по модели push от master-узла. При изменении файлов на master-узле вычисляется контрольная сумма, и измененные файлы передаются на все worker-узлы. Worker-узлы не могут инициировать распространение конфигурации - изменения правил и декодеров должны выполняться только на master-узле.

Интервал проверки синхронизации по умолчанию составляет 10 секунд. В течение этого времени master-узел сравнивает контрольные суммы файлов и определяет необходимость обновления.

Добавление и удаление узлов

Добавление worker-узла

1. Установите Wazuh менеджер на новом сервере.

2. Настройте блок <cluster> в /var/ossec/etc/ossec.conf:

<cluster>
  <name>production-cluster</name>
  <node_name>worker-02</node_name>
  <node_type>worker</node_type>
  <key>a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6</key>
  <port>1516</port>
  <bind_addr>0.0.0.0</bind_addr>
  <nodes>
    <node>192.168.1.10</node>
  </nodes>
  <hidden>no</hidden>
  <disabled>no</disabled>
</cluster>

3. Убедитесь, что порт 1516/TCP открыт между новым узлом и master-узлом.

4. Запустите менеджер:

systemctl start wazuh-manager

5. Проверьте подключение узла:

/var/ossec/bin/cluster_control -l

Удаление worker-узла

1. Переназначьте агентов с удаляемого worker-узла на другие узлы.

2. Остановите менеджер на удаляемом узле:

systemctl stop wazuh-manager

3. Убедитесь, что узел исчез из списка:

/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-имя:

<client>
  <server>
    <address>wazuh-cluster.example.com</address>
    <port>1514</port>
    <protocol>tcp</protocol>
  </server>
</client>

Конфигурация через 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 или аналогичных решений.

Рекомендации по распределению

• Направляйте агентов преимущественно на worker-узлы, а не на master
• Master-узел обрабатывает кластерную синхронизацию и API-запросы, поэтому назначение большого количества агентов на master снижает производительность
• Следите за равномерным распределением агентов между worker-узлами с помощью cluster_control

Утилита cluster_control

Утилита /var/ossec/bin/cluster_control предоставляет интерфейс командной строки для мониторинга и управления кластером.

Просмотр состояния кластера

# Список всех узлов кластера
/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

Просмотр распределения агентов

# Показать количество агентов на каждом узле
/var/ossec/bin/cluster_control -a

Пример вывода:

NAME          AGENTS  
master-node   15
worker-01     245
worker-02     240

Дополнительные команды

# Подробная информация о конкретном узле
/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 :

# Получение 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).

Оптимизация master-узла

Master-узел обрабатывает синхронизацию и API-запросы. Для оптимизации:

• Минимизируйте количество агентов, подключенных к master-узлу
• Выделите master-узлу достаточно ресурсов для синхронизации (особенно важно при большом количестве пользовательских правил и декодеров)
• Разместите master-узел и worker-узлы в одной сети для минимизации задержки синхронизации

Настройка Filebeat

Каждый узел кластера передает данные в индексатор через Filebeat. Убедитесь, что Filebeat настроен на каждом узле и указывает на кластер индексатора:

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

ELK Coordinating Nodes

Устранение неполадок

Узел не присоединяется к кластеру

Симптомы: worker-узел не появляется в cluster_control -l.

Проверки:

1. Убедитесь, что ключ (key) идентичен на master и worker узлах.

2. Проверьте сетевую доступность порта 1516/TCP:

nc -zv 192.168.1.10 1516

3. Проверьте имя кластера (name) - оно должно совпадать на всех узлах.

4. Просмотрите лог кластера:

tail -f /var/ossec/logs/cluster.log

5. Убедитесь, что параметр disabled установлен в no.

Проблемы синхронизации

Симптомы: изменения правил на master не применяются на worker-узлах.

Проверки:

1. Проверьте статус синхронизации:

/var/ossec/bin/cluster_control -l -fn

2. Убедитесь, что изменения внесены на master-узле (не на worker).

3. Просмотрите лог кластера на наличие ошибок синхронизации:

grep -i "error\|sync" /var/ossec/logs/cluster.log | tail -20

4. Дождитесь интервала синхронизации (по умолчанию 10 секунд) или перезапустите менеджер.

Split-brain (расщепление кластера)

Симптомы: worker-узлы не видят master, агенты подключены, но алерты не генерируются корректно.

Причины:

• Потеря сетевого соединения между узлами
• Перегрузка master-узла
• Неверная конфигурация сетевых интерфейсов (bind_addr)

Решение:

1. Восстановите сетевое соединение между узлами.

2. Перезапустите worker-узлы после восстановления связи:

systemctl restart wazuh-manager

3. Проверьте целостность кластера:

/var/ossec/bin/cluster_control -l

Высокое потребление ресурсов при синхронизации

Симптомы: master-узел испытывает пиковые нагрузки на CPU/RAM при большом количестве пользовательских правил.

Решение:

• Сократите количество пользовательских правил и декодеров, объединяя дублирующиеся
• Увеличьте ресурсы master-узла
• Проверьте, что не происходит циклическая синхронизация (изменения вносятся только на master)

Для общего обзора инфраструктурных компонентов обратитесь к разделу инфраструктуры Wazuh . Информация о компонентах платформы доступна в разделе архитектура Wazuh .