Профессиональное администрирование Wazuh: от архитектуры до реагирования на инциденты

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

Представьте ситуацию: в три часа ночи на одном из ваших серверов базы данных создается новый пользователь с правами суперпользователя, а через минуту системный бинарный файл /bin/ls меняет свой хэш-сумму. В классической схеме мониторинга вы узнаете об этом, только если вручную проверите логи или дождетесь утреннего отчета. Wazuh же узнает об этом мгновенно, сопоставит эти два события и поднимет тревогу. Но чтобы доверять этой системе и, что более важно, правильно её настраивать, нужно понимать, как именно байты информации превращаются в алерты на вашем экране. Многие администраторы воспринимают Wazuh как «черный ящик», который просто ставится скриптом, однако без понимания внутренней механики взаимодействия агента и менеджера любая сложная диагностика превращается в гадание на кофейной гуще.

Трехуровневая модель: фундамент экосистемы

Wazuh не является монолитным приложением. Это распределенная система, построенная на базе форка OSSEC, которая со временем эволюционировала в мощную платформу XDR (Extended Detection and Response). Ее архитектуру принято делить на три основных уровня: конечные точки (Endpoints), серверная часть (Management Server) и уровень анализа и визуализации (Indexing & Dashboard).

На первом уровне находятся Wazuh Agents. Это легковесные службы, которые вы устанавливаете на серверы, рабочие станции, облачные инстансы или даже контейнеры. Их задача — не анализировать, а собирать. Агент — это «глаза и уши» системы. Он потребляет минимум ресурсов, чтобы не аффектить работу продакшн-сервисов, и отправляет данные «наверх».

Второй уровень — Wazuh Manager. Это «мозг» системы. Именно здесь происходит магия: декодирование сырых логов, сопоставление их с правилами, проверка на соответствие сигнатурам и принятие решения о том, является ли событие инцидентом. Если агент — это датчик, то менеджер — это пульт управления, который анализирует сигналы сотен и тысяч таких датчиков.

Третий уровень — Wazuh Indexer и Wazuh Dashboard. Индексатор (базирующийся на OpenSearch) отвечает за долгосрочное хранение и быстрый поиск по накопленным данным. Дашборд — это графический интерфейс, через который вы взаимодействуете с системой. Важно понимать: когда вы видите красивый график в браузере, вы смотрите не в «живой» поток данных от агента, а в базу данных индексатора, куда менеджер уже сложил результаты своего анализа.

Анатомия агента: как данные покидают хост

Агент Wazuh — это многопоточный демон, состоящий из нескольких модулей. Понимание того, какой модуль за что отвечает, критично для отладки. Если вы настроили сбор логов, но они не приходят, вам нужно знать, какой именно внутренний процесс агента «молчит».

Logcollector: Этот компонент читает файлы логов, системные журналы (Event Channel в Windows, syslog в Linux) и даже вывод команд. Он работает по принципу «хвоста» (tail): следит за добавлением новых строк и передает их дальше.

Syscheck (FIM): Модуль контроля целостности файлов. Он периодически сканирует файловую систему, вычисляет контрольные суммы (MD5, SHA1, SHA256) и сравнивает их с эталонными значениями, хранящимися в локальной базе данных.

Rootcheck: Ищет признаки руткитов, скрытых процессов и аномалий в сетевых портах.

Agent Modules (Vodane): Сюда входят модули инвентаризации (Syscollector), поиска уязвимостей и проверки политик безопасности (SCA).

Связь между агентом и менеджером осуществляется через протокол Wazuh протокол, который работает поверх TCP (реже UDP) на порту 1514. Данные передаются в зашифрованном и сжатом виде.

> Безопасность передачи обеспечивается использованием AES-шифрования. Каждый агент при регистрации получает уникальный ключ (ID и Key), который используется для аутентификации и создания защищенного туннеля. Без валидного ключа менеджер просто сбросит соединение.

Интересный нюанс заключается в буферизации. Если связь с менеджером прерывается (например, из-за проблем в сети), агент не выбрасывает данные. У него есть внутренний анти-флуд механизм и очередь. Как только соединение восстанавливается, агент начинает «выплескивать» накопленные события, но делает это дозированно (по умолчанию 500 событий в секунду), чтобы не перегрузить менеджер и не создать DoS-атаку на собственную систему безопасности.

Жизненный путь события на стороне менеджера

Когда пакет данных от агента прилетает на порт 1514 менеджера, начинается процесс, называемый Analysis Pipeline. Это конвейер, состоящий из нескольких этапов, и ошибка на любом из них приведет к тому, что важное событие будет проигнорировано.

Этап 1: Регистрация и аутентификация (Authd)

Сервис wazuh-authd отвечает за добавление новых агентов. Когда вы запускаете команду регистрации на стороне клиента, он стучится на порт 1515 менеджера. Менеджер проверяет пароль (если задан) и выдает агенту сертификат и ключ. С этого момента агент считается «своим».

Этап 2: Прием данных (Remoted)

Процесс wazuh-remoted слушает входящие соединения от агентов. Он расшифровывает пакеты, проверяет их целостность и передает сырые строки во внутреннюю очередь сообщений (Analysis Engine Queue).

Этап 3: Декодирование (Analysisd)

Это сердце системы. Процесс analysisd берет сырую строку, например: May 10 10:01:02 server1 sshd[1234]: Failed password for root from 192.168.1.50 port 54321 ssh2 и пытается применить к ней декодеры. Декодер — это набор регулярных выражений, который превращает неструктурированный текст в структурированный JSON. В данном примере декодер выделит поля:

program_name: sshd

srcip: 192.168.1.50

dstuser: root

Если декодер не найден, событие помечается как «unknown» и, скорее всего, будет отброшено, если вы не настроили сохранение всех архивов.

Этап 4: Сопоставление с правилами

После того как данные структурированы, менеджер прогоняет их через иерархическую систему правил. Правила имеют уровни от 0 до 15:

Уровень 0: Игнорировать (шум).

Уровень 3: Обычное событие (успешный вход).

Уровень 5-7: Ошибки или подозрительные действия.

Уровень 10+: Критические инциденты (брутфорс, изменение системных файлов).

Система правил работает по принципу «от общего к частному». Сначала срабатывает базовое правило (это лог sshd), затем вложенное (это ошибка входа), затем еще более специфичное (это третья ошибка за минуту с одного IP).

Хранение и визуализация: Индексатор и Дашборд

После того как analysisd решил, что событие достойно внимания (уровень правила выше порога log_level, обычно это 3), он формирует JSON-объект и отправляет его в Wazuh Indexer.

Индексатор — это высокопроизводительная NoSQL база данных. Она хранит данные в виде индексов. Каждый день (по умолчанию) создается новый индекс, например wazuh-alerts-4.x-2023.10.27. Это позволяет эффективно управлять жизненным циклом данных: старые индексы можно сжимать, переносить на медленные диски или удалять.

В этой упрощенной формуле кроется причина большинства проблем с тормозами интерфейса. Если у вас слишком много мелких индексов или недостаточно «шардов» (частей индекса), поиск будет идти мучительно долго.

Wazuh Dashboard — это надстройка над индексатором. Она не хранит данные сама по себе. Когда вы открываете вкладку "Security Events", Дашборд отправляет Query-запрос к Индексатору, получает JSON-ответ и отрисовывает его в виде таблиц и диаграмм. Также Дашборд взаимодействует с Wazuh API (работает на менеджере, порт 55000), чтобы изменять настройки системы, перезагружать агентов или просматривать их статус в реальном времени.

Логика взаимодействия: пример реального инцидента

Разберем цепочку событий при попытке подбора пароля по SSH.

На хосте: Злоумышленник пробует пароли. В /var/log/auth.log появляются записи.

Агент: Модуль logcollector видит новую строку в файле. Он упаковывает ее, шифрует и отправляет менеджеру.

Менеджер (Remoted): Принимает пакет, расшифровывает.

Менеджер (Analysisd):

- Декодер sshd разбивает строку на части. - Срабатывает правило ID 5710 (Attempt to login using a non-existent user). - Менеджер проверяет частоту: если таких событий 8 за 30 секунд, срабатывает правило ID 5712 (SSHD brute force trying to get access to the system).

Менеджер (Filebeat/Output): Записывает алерт в файл /var/ossec/logs/alerts/alerts.json и одновременно отправляет его в индексатор.

Индексатор: Сохраняет документ, обновляет поисковый индекс.

Администратор: Видит красный сектор на круговой диаграмме в Dashboard.

Если в системе настроен Active Response (активное реагирование), менеджер может отправить обратную команду агенту. Например: «Заблокируй IP 192.168.1.50 через iptables на 30 минут». Агент получит эту команду и выполнит локальный скрипт. Это замыкает цикл: Обнаружение -> Анализ -> Реагирование.

Граничные случаи и архитектурные нюансы

При проектировании системы важно учитывать, что Wazuh Manager может стать узким местом. В крупных инсталляциях (более 500-1000 агентов) используется кластерный режим.

В кластере есть одна Master-нода и несколько Worker-нод. Агенты распределяются между воркерами. Мастер-нода отвечает за синхронизацию конфигураций и правил. Если вы измените правило на мастере, оно автоматически разлетится по всем воркерам. Однако анализ логов происходит локально на каждой ноде.

Еще один важный аспект — Agentless monitoring. Wazuh может мониторить устройства, на которые нельзя поставить агента (коммутаторы Cisco, брандмауэры Fortigate, принтеры). В этом случае устройство настраивается на отправку Syslog-сообщений прямо на IP менеджера. Менеджер принимает их, делает вид, что это пришло от «виртуального агента», и прогоняет через те же декодеры и правила. Минус этого подхода — отсутствие шифрования в стандартном Syslog и невозможность использовать FIM или Active Response.

Расширенная инвентаризация и SCA

Помимо логов, Wazuh выполняет роль системы управления активами. Модуль Syscollector на агенте регулярно собирает данные о:

Установленном ПО и его версиях.

Сетевых интерфейсах и IPv4/IPv6 адресах.

Открытых портах и слушающих процессах.

Версии ядра и ОС.

Эти данные не порождают алерты при каждом сканировании. Они складываются в базу данных global.db на стороне менеджера (в формате SQLite). Когда вы открываете инвентарную карточку агента в Dashboard, данные берутся именно оттуда.

Параллельно работает модуль SCA (Security Configuration Assessment). Он проверяет систему на соответствие лучшим практикам (например, рекомендациям CIS Benchmark). Агент получает от менеджера файл политики (YAML), в котором описаны проверки: «Должен ли быть запрещен вход root по SSH?», «Установлены ли права 600 на /etc/shadow?». Агент выполняет проверки и отправляет отчет: Pass или Fail. Это позволяет видеть общую картину защищенности инфраструктуры в процентах.

Потоки данных и порты: шпаргалка администратора

Для успешной работы в сети с брандмауэрами необходимо четко понимать, какие порты должны быть открыты:

| Направление | Порт | Протокол | Назначение | | :--- | :--- | :--- | :--- | | Agent -> Manager | 1514 | TCP (UDP) | Передача логов и событий (основной канал) | | Agent -> Manager | 1515 | TCP | Регистрация новых агентов и получение ключей | | Admin -> Manager | 55000 | TCP | Wazuh API (управление через Dashboard или скрипты) | | Dashboard -> Indexer | 9200 | TCP | Запросы на получение данных для графиков | | Manager -> Indexer | 9200 | TCP | Отправка алертов для индексации | | Cluster Nodes | 1516 | TCP | Синхронизация между нодами менеджера |

Если вы видите статус агента Never connected, первым делом проверяйте доступность порта 1515 для регистрации, а затем 1514 для работы. Если агент Active, но данных нет — проблема в правилах или декодерах на стороне менеджера.

Иерархия конфигураций

Wazuh использует XML-формат для настроек. Основной файл на менеджере — /var/ossec/etc/ossec.conf. Однако управлять сотнями агентов, заходя на каждый и правя конфиг вручную, невозможно. Для этого существует механизм Centralized Configuration.

На менеджере в директории /var/ossec/etc/shared/ создаются группы (например, web-servers, db-servers). Внутри группы лежит файл agent.conf. Как только агент подключается к менеджеру и сообщает, что он состоит в группе web-servers, менеджер «проталкивает» ему этот конфиг. Агент сливает его со своим локальным ossec.conf и перезапускает нужные модули. Это позволяет централизованно менять политики сбора логов или частоту сканирования FIM для целых сегментов сети.

Понимание этой иерархии (Локальный конфиг < Централизованный конфиг) спасает от ситуаций, когда вы правите файл на сервере, а настройки «волшебным образом» откатываются назад после перезапуска агента.

Взаимодействие компонентов Wazuh — это гармоничный танец между легковесными сборщиками и тяжеловесными анализаторами. Менеджер берет на себя всю вычислительную нагрузку, освобождая ресурсы конечных точек, а индексатор обеспечивает возможность мгновенно найти иголку в стоге сена из миллионов событий. В следующей части мы перейдем от теории архитектуры к практике: научимся ориентироваться в интерфейсе Dashboard, чтобы эффективно использовать все те данные, которые мы только что научились передавать.

Интерфейс Wazuh Dashboard: визуализация данных и навигация по событиям

Представьте, что ваша инфраструктура генерирует 10 000 событий в секунду. Среди них — легитимные входы системных администраторов, автоматические обновления ПО, но также и попытки подбора паролей или несанкционированные изменения в конфигурационных файлах. Без адекватного инструмента визуализации этот поток данных превращается в «белый шум», в котором невозможно заметить атаку до того, как она нанесет ущерб. Wazuh Dashboard — это не просто графическая оболочка над базой данных; это высокоуровневый аналитический инструмент, который позволяет превратить сырые логи в осмысленную картину состояния безопасности.

Философия интерфейса и структура навигации

Wazuh Dashboard построен на базе OpenSearch Dashboards (форк Kibana), но значительно модифицирован для нужд кибербезопасности. Основная сложность для новичка заключается в том, что интерфейс разделен на две логические зоны: общие инструменты работы с данными OpenSearch (Discover, Visualize, Dashboards) и специализированный плагин Wazuh, который предоставляет преднастроенные представления для модулей безопасности.

Главное меню Wazuh (доступное через иконку в левом верхнем углу) — это отправная точка для любого исследования. Здесь выделяются ключевые разделы:

Modules: Группировка данных по функциональным возможностям (Security events, Integrity monitoring, SCA, Vulnerabilities).

Agents: Управление и просмотр состояния конкретных конечных точек.

Management: Настройка самой системы, включая правила, декодеры и конфигурацию менеджера.

Важно понимать, что когда вы переходите в раздел Security events, вы видите данные, отфильтрованные по определенному индексу. В Wazuh данные хранятся в индексах вида wazuh-alerts-4.x-*. Понимание структуры этого индекса критически важно для эффективного поиска. Каждый алерт — это JSON-документ, содержащий метаданные о событии.

Глубокое погружение в Security Events и механизм фильтрации

Раздел Security Events — это «сердце» оперативного мониторинга. Здесь отображаются все события, уровень которых (Level) соответствует или превышает порог, заданный в конфигурации менеджера (по умолчанию это уровень 3).

Интерфейс этой секции состоит из трех основных элементов: * Гистограмма событий: Показывает распределение алертов во времени. Резкие всплески («спайки») на графике часто сигнализируют о начале атаки или сбое в работе легитимного сервиса. * Панель фильтров (Query Bar): Позволяет использовать язык запросов DQL (Dashboards Query Language) или KQL (Kibana Query Language). * Таблица событий: Список конкретных алертов с краткой информацией.

Работа с фильтрами и DQL

Для эффективной навигации администратор должен владеть DQL. Это не просто поиск по словам, а точное указание полей. Рассмотрим синтаксис на примерах.

Если вам нужно найти все успешные входы в систему, которые не относятся к пользователю root, запрос будет выглядеть так: rule.groups: "authentication_success" AND NOT data.dstuser: "root"

Здесь rule.groups — это массив групп, к которым относится сработавшее правило, а data.dstuser — поле, извлеченное декодером из лога.

Особое внимание стоит уделить операторам сравнения. В DQL поддерживаются: * Свободный текстовый поиск: agent.name: "web-server" * Логические операторы: AND, OR, NOT. * Проверка существования поля: _exists_: data.srcip (позволяет найти все события, где был зафиксирован IP-адрес источника).

Анатомия алерта

При развертывании конкретного события в таблице вы видите полную JSON-структуру. Для администратора наиболее важны следующие поля:

_index: Указывает, в каком физическом индексе хранится документ.

agent.id и agent.name: Идентификация источника.

rule.id: Уникальный номер правила. Знание этого ID необходимо, если вы решите изменить уровень алерта или добавить исключение.

rule.level: Критичность события от 0 до 15.

full_log: Оригинальная строка лога, как она пришла от агента. Это «истина в последней инстанции», если вы подозреваете, что декодер сработал некорректно.

decoder.name: Имя декодера, который обработал это событие.

Использование раздела Discover для расследований (Threat Hunting)

Хотя встроенные дашборды Wazuh красивы и информативны, для глубокого расследования инцидентов (Threat Hunting) чаще используется раздел Discover. В отличие от стандартных модулей, Discover предоставляет «сырой» доступ к данным без предустановленных фильтров визуализации.

В Discover вы можете самостоятельно выбирать поля, которые хотите видеть в таблице. Например, при анализе сетевой активности удобно оставить только поля timestamp, agent.name, data.srcip, data.srcport и data.action. Это превращает хаотичный список документов в структурированную таблицу, напоминающую лог сетевого экрана.

Сохранение поисковых запросов

Одной из самых недооцененных функций является Save Search. Если вы создали сложный фильтр для мониторинга активности администраторов в нерабочее время, сохраните его. В дальнейшем этот сохраненный поиск можно использовать как основу для создания кастомной визуализации или вынести на отдельный дашборд.

Визуализация данных: от круговых диаграмм до тепловых карт

Wazuh Dashboard позволяет создавать собственные визуализации. Это необходимо, когда стандартных отчетов недостаточно для специфических бизнес-задач.

Типы визуализаций для ИБ

| Тип визуализации | Лучшее применение | Пример использования | | :--- | :--- | :--- | | Data Table | Детальные списки | Топ-10 IP-адресов, с которых зафиксированы атаки. | | Pie Chart | Пропорциональное распределение | Соотношение типов операционных систем в сети. | | Area/Line Chart | Тренды во времени | Динамика появления новых уязвимостей за месяц. | | Metric | Одиночные важные цифры | Количество активных агентов или критических алертов. | | Heat Map | Пересечение двух параметров | Распределение атак по часам суток и дням недели. |

Процесс создания визуализации (Lens)

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

Например, чтобы создать график «Топ-5 атакуемых пользователей»:

Откройте Visualize -> Create visualization -> Lens.

Выберите индекс wazuh-alerts-*.

Перетащите поле data.dstuser на ось X (или в область "Rows").

Lens автоматически предложит агрегацию Count (количество документов).

В настройках функции выберите Top values и ограничьте число до 5.

Работа с инвентаризацией и активами (Inventory Data)

Wazuh — это не только про угрозы, но и про управление состоянием систем. Раздел Agents -> [Имя агента] -> Inventory data предоставляет данные, собранные модулем syscollector.

Здесь визуализируются: * Сетевые интерфейсы: IP и MAC адреса. * Установленное ПО: Полный список пакетов с версиями. * Открытые порты: Какие процессы прослушивают сеть. * Процессы: Список запущенных программ в реальном времени.

Для администратора это бесценный источник информации при аудите. Например, вы можете быстро найти все серверы, на которых установлена устаревшая версия openssl, просто используя поиск по полю os.software.name.

Мониторинг целостности файлов (FIM) и SCA

Модули FIM (File Integrity Monitoring) и SCA (Security Configuration Assessment) имеют свои специализированные интерфейсы.

В интерфейсе FIM вы видите не просто список измененных файлов, а конкретные детали: кто изменил файл (user), какой процесс это сделал (proc) и что именно изменилось в контрольной сумме или атрибутах. Визуализация здесь часто строится вокруг «наиболее часто изменяемых файлов», что помогает выявить либо некорректно настроенное ПО, которое постоянно пишет в конфиги, либо активность вредоносного софта.

Интерфейс SCA представляет собой чек-лист. Каждая проверка (Check) имеет статус: Passed или Failed. При нажатии на проверку интерфейс отображает: * Описание политики безопасности. * Обоснование (почему это важно). * Инструкцию по исправлению (Remediation). * Конкретную причину провала (например, значение параметра в /etc/ssh/sshd_config не соответствует эталонному).

Управление индексами и производительностью интерфейса

Скорость работы интерфейса напрямую зависит от того, как организовано хранение данных в Wazuh Indexer. Если ваши дашборды «тормозят» при попытке отобразить данные за неделю, проблема может быть в слишком большом количестве шардов (shards) или отсутствии оптимизации индексов.

Администратор должен уметь пользоваться разделом Index Management. Здесь можно настроить политики ISM (Index State Management), которые будут автоматически переводить старые индексы в состояние "Warm" или "Cold" (удаление или архивация), тем самым освобождая оперативную память для оперативных дашбордов.

Рекомендации по работе с таймфреймами

В правом верхнем углу интерфейса находится селектор времени. По умолчанию он часто стоит на "Last 24 hours". * Для оперативного дежурства используйте "Last 15 minutes" с автообновлением (Refresh) каждые 30 секунд. * Для ретроспективного анализа инцидента (Investigation) расширяйте диапазон до момента предполагаемого начала атаки. * Избегайте запросов "Last 30 days" на высоконагруженных системах без использования фильтров по конкретному agent.id, так как это создает колоссальную нагрузку на дисковую подсистему индексатора.

Кастомизация Dashboard для разных ролей

Wazuh позволяет создавать разные дашборды для разных специалистов. * Для CISO (директора по ИБ): Высокоуровневые метрики compliance (SCA), количество критических уязвимостей, динамика атак. * Для SOC-аналитика: Детальные графики по типам атак (Brute force, Web anomalies), списки подозрительных IP. * Для системного администратора: Статус агентов (Active/Disconnected), результаты сканирования уязвимостей, изменения в системных файлах.

Вы можете создать новый дашборд, нажав Create dashboard, и добавить на него существующие визуализации. Это позволяет собрать в одном месте данные из разных модулей (например, совместить график системных ошибок из логов и алерты FIM).

Нюансы поиска и «подводные камни»

Иногда администраторы сталкиваются с ситуацией: «Я точно знаю, что событие было, но в Dashboard его нет». Причины могут быть следующими:

Уровень правила: Событие имеет уровень ниже email_alert_level или log_alert_level в ossec.conf. В таком случае алерт не записывается в alerts.json и не попадает в индекс.

Mapping Conflict: Если вы создали собственное правило и передаете в нем данные в нестандартном формате, может возникнуть конфликт типов данных в OpenSearch (например, поле ожидалось как число, а пришла строка). В интерфейсе Index Management это будет видно как ошибки индексации.

Задержка (Lag): Между генерацией события на агенте и его появлением в интерфейсе проходит время (обычно секунды, но при перегрузке менеджера — минуты). Проверяйте поле timestamp (время события) и @timestamp (время индексации).

Эффективное владение интерфейсом Wazuh Dashboard превращает администратора из «читателя логов» в полноценного аналитика безопасности. Главный навык здесь — умение быстро переходить от общего обзора инфраструктуры к детальному изучению одного конкретного события, используя фильтры, DQL и кастомные визуализации.

Управление жизненным циклом агентов и мониторинг их состояния

Представьте ситуацию: в вашей сети пятьсот серверов, и внезапно один из них перестает присылать алерты. Означает ли это, что на сервере всё спокойно, или злоумышленник первым делом отключил службу мониторинга? В системе безопасности «тишина» зачастую опаснее, чем поток уведомлений. Управление жизненным циклом агента — это не просто процесс его установки, а непрерывный контроль его «здоровья», актуальности конфигурации и легитимности его присутствия в системе.

Регистрация и аутентификация: входной билет в инфраструктуру

Жизненный цикл любого агента начинается с его появления в базе данных менеджера. Процесс регистрации (Enrollment) — это критически важный этап с точки зрения безопасности. Если злоумышленник сможет зарегистрировать свой поддельный агент в вашем менеджере, он получит доступ к конфигурационным файлам (через централизованное управление) и сможет отправлять ложные события, маскируя реальную атаку.

В Wazuh за регистрацию отвечает сервис wazuh-authd. По умолчанию он слушает порт 1515. Существует три основных сценария регистрации, каждый из которых подходит для разных уровней зрелости инфраструктуры:

Парольная аутентификация (Password-based): Самый простой метод, при котором менеджер требует общий пароль (shared password) для регистрации нового узла. Пароль хранится в файле /var/ossec/etc/authd.pass.

Сертификаты (Certificate-based): Наиболее безопасный метод. Менеджер проверяет TLS-сертификат агента, выданный вашим внутренним удостоверяющим центром (CA). Это исключает возможность подключения неавторизованных устройств.

Пустой метод (Default): Если настройки безопасности не заданы, менеджер регистрирует любой агент, который постучится на порт 1515. Это допустимо только в изолированных лабораторных средах.

Процесс регистрации автоматизирован через утилиту agent-auth на стороне агента или через автоматическое развертывание (Deployment variables). Когда агент регистрируется, он получает уникальный ID и симметричный ключ Key. Этот ключ используется для шифрования всего последующего трафика по протоколу AES. Ключи хранятся в файле /var/ossec/etc/client.keys на менеджере.

> Важный нюанс: Если вы переустанавливаете агент на той же машине, он может попытаться зарегистрироваться заново и получить новый ID. Это приведет к дублированию записей в базе данных. Чтобы этого избежать, используйте опцию -i (force insert) или настройте менеджер так, чтобы он заменял старые записи при совпадении IP-адреса или имени хоста.

Статусы агентов и логика Keep-alive

После регистрации агент переходит в стадию активной работы. Мониторинг состояния агента в Wazuh реализован через механизм контрольных сообщений (Keep-alive). Агент регулярно отправляет небольшие пакеты данных менеджеру, подтверждая, что он жив и готов передавать логи.

В интерфейсе и API Wazuh вы встретите четыре основных статуса:

* Active (Активен): Агент успешно прошел аутентификацию и регулярно присылает keep-alive сообщения. * Disconnected (Отключен): Менеджер не получал сообщений от агента в течение установленного таймаута (по умолчанию 60 секунд). Это может быть вызвано падением службы, сетевыми проблемами или выключением сервера. * Pending (Ожидание): Регистрация прошла успешно, ключи получены, но агент еще ни разу не вышел на связь для передачи данных. * Never connected (Ни разу не подключался): Запись об агенте создана вручную или через API, но процесс рукопожатия (handshake) не был инициирован.

Управление этими статусами на стороне менеджера регулируется параметрами в секции <monitord> файла ossec.conf. Например, если вы работаете с облачными инстансами, которые часто выключаются, имеет смысл увеличить интервалы проверки, чтобы не получать ложные уведомления о дисконнекте.

Рассмотрим математическую логику определения статуса. Пусть — время получения последнего сообщения от агента, а — текущее системное время. Статус «Disconnected» присваивается, если выполняется условие:

где — значение параметра agents_disconnection_time в конфигурации менеджера. По умолчанию этот порог составляет 60 секунд. Если же агент не выходит на связь очень долго, срабатывает параметр agents_deletion_time, и агент может быть автоматически удален из системы (если эта опция включена).

Централизованная конфигурация: файл agent.conf

Одной из самых мощных функций управления жизненным циклом является возможность менять настройки сотен агентов, не заходя на каждый сервер по SSH или RDP. Это реализуется через механизм shared configuration.

На менеджере в директории /var/ossec/etc/shared/ создаются группы (например, web-servers, databases, windows-endpoints). Внутри каждой группы лежит файл agent.conf. Когда агент подключается к менеджеру, он сообщает, в какой группе он состоит. Менеджер сравнивает контрольную сумму (MD5/SHA256) локального конфига агента с тем, что хранится в группе на сервере. Если они различаются, менеджер отправляет новую конфигурацию агенту.

Иерархия и приоритеты групп

Агент может принадлежать к нескольким группам одновременно. Это позволяет строить гибкие политики:

Группа "Global": Общие настройки для всех (например, интервал FIM-сканирования раз в сутки).

Группа "OS-Linux": Настройки сбора логов /var/log/syslog.

Группа "Nginx-Servers": Специфические правила мониторинга путей /var/log/nginx/access.log.

При объединении конфигураций Wazuh применяет их последовательно. Однако стоит помнить о конфликтах: если в одной группе указано сканировать директорию /etc раз в час, а в другой — раз в день, итоговое поведение будет зависеть от порядка применения групп.

> При работе с agent.conf критически важно проверять синтаксис перед сохранением. Ошибка в XML-теге на менеджере может привести к тому, что все агенты в группе получат невалидный конфиг и перестанут перезапускать свои модули, фактически «зависнув» в старом состоянии. Для проверки используйте утилиту: > /var/ossec/bin/verify-agent-conf

Протокол взаимодействия и буферизация данных

Понимание того, как данные физически перемещаются от агента к менеджеру, помогает диагностировать потери алертов. Агент использует протокол обмена данными, который работает поверх UDP или TCP (порт 1514). В современных инсталляциях настоятельно рекомендуется использовать TCP, так как он гарантирует доставку пакетов и обеспечивает контроль потока.

Внутренняя очередь агента — это «подушка безопасности». Если связь с менеджером прерывается, агент не отбрасывает события, а накапливает их в локальном буфере. Параметры этого буфера настраиваются в секции <client_buffer>: * queue_size: количество событий, которые могут храниться в памяти (по умолчанию 5000). * events_per_second: ограничение скорости отправки (EPS), чтобы не «заспамить» менеджер и не забить канал связи.

Если буфер переполняется (например, при длительном обрыве связи), агент начинает отбрасывать старые события (Flood protection). В системных логах агента (ossec.log) это отражается записью Agent buffer is full. Для высоконагруженных систем, таких как контроллеры домена или загруженные веб-серверы, размер очереди необходимо увеличивать до 50 000 - 100 000 событий.

Мониторинг "здоровья" системы (Self-monitoring)

Чтобы эффективно управлять агентами, администратор должен видеть не только их статус (Active/Disconnected), но и то, насколько эффективно они работают. Wazuh предоставляет для этого внутренние метрики.

В разделе Agents -> [Имя агента] -> Dashboard можно увидеть статистику использования ресурсов процессора и памяти самой службой Wazuh. Но более важным является мониторинг модулей. Каждый модуль (Rootcheck, Syscollector, Syscheck) имеет свое время последнего запуска и завершения. Если вы видите, что модуль FIM (Syscheck) последний раз сканировал систему месяц назад, хотя в конфиге стоит «раз в день» — это признак проблемы, даже если статус агента горит зеленым (Active).

Основные причины «засыпания» модулей:

Конфликт ресурсов: Система ограничила потребление CPU для агента (параметр process_priority или внешние лимиты cgroups/systemd).

Блокировка базы данных: Локальная база данных агента (SQLite) повреждена или заблокирована другим процессом.

Ошибки в правилах исключений: Модуль пытается просканировать сетевую папку с миллионами файлов, тратя на это недели.

Обновление агентов: стратегия и риски

Жизненный цикл включает обязательное обновление версий (Upgrade). Wazuh позволяет делать это удаленно через менеджер. Процесс выглядит следующим образом:

Менеджер отправляет агенту команду на обновление.

Агент скачивает WPK-пакет (Wazuh Package) с репозитория или самого менеджера.

Специальный скрипт проверяет целостность пакета, останавливает службу, обновляет бинарные файлы и запускает её снова.

Риск: Если обновление завершится неудачно, агент может «окирпичиться» и перестать выходить на связь. В таком случае потребуется ручное вмешательство на конечной точке. Рекомендация: Всегда обновляйте агенты поэтапно. Сначала тестовая группа, затем 10% инфраструктуры, и только через несколько дней — остальные. Никогда не запускайте массовое обновление (bulk upgrade) для всех 100% агентов одновременно, так как это создаст колоссальную нагрузку на сеть и менеджер в момент скачивания пакетов и массовой перерегистрации.

Для проверки доступных обновлений через консоль менеджера используется утилита agent_upgrade. Пример команды для просмотра списка агентов, требующих обновления: /var/ossec/bin/agent_upgrade -l

Удаление и вывод из эксплуатации

Когда сервер выводится из эксплуатации, его агент нужно корректно удалить из системы. Простое выключение сервера оставит его в статусе «Disconnected» навечно, что будет искажать общую статистику безопасности и занимать место в лицензии (если вы используете платные надстройки) или просто в базе данных.

Удаление агента производится через API или утилиту manage_agents. Важно понимать, что при удалении агента с менеджера его ключи в client.keys аннулируются. Если этот сервер когда-нибудь снова включится с установленным агентом, он не сможет подключиться, пока не пройдет процедуру повторной регистрации.

Автоматизация очистки «мертвых» агентов — признак хорошего тона в администрировании. Настройте скрипт, который через API Wazuh удаляет агенты, находящиеся в статусе Disconnected более 30 дней, если это не противоречит вашим политикам комплаенса.

Практический сценарий: диагностика "исчезнувшего" агента

Допустим, агент на критически важном сервере перешел в статус Disconnected. Профессиональный алгоритм диагностики выглядит так:

Проверка сетевой доступности: Пингуется ли хост? Если да, проверьте доступность порта 1514/TCP с помощью telnet или nc -zv [IP менеджера] 1514.

Анализ локальных логов: На стороне агента откройте /var/ossec/logs/ossec.log (Linux) или C:\Program Files (x86)\ossec-agent\ossec.log (Windows). Ищите ошибки со словами Connection refused, Waiting for server reply или Invalid key.

Проверка ключей: Убедитесь, что ID и Key на агенте соответствуют тому, что записано в client.keys на менеджере. Иногда при восстановлении сервера из бэкапа ключи «откатываются» на старые, которые менеджер уже аннулировал.

Проверка MTU: В некоторых VPN-каналах пакеты Wazuh могут отбрасываться из-за слишком большого размера (MTU mismatch). Попробуйте уменьшить MTU на сетевом интерфейсе или переключиться на TCP, если использовался UDP.

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

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

Представьте, что ваша инфраструктура генерирует терабайты текстового шума: сообщения об успешных входах, ошибки сегментации, уведомления о смене прав доступа и отчеты о работе планировщика задач. Без структурирования этот поток данных бесполезен. Для системы безопасности лог-файл — это не просто текст, это улика, из которой нужно извлечь конкретные атрибуты: кто совершил действие, откуда, когда и каков был результат. В Wazuh за превращение «сырого» текста в структурированный инцидент отвечает связка декодеров и правил. Понимание того, как именно происходит эта трансформация, отделяет администратора, который просто «смотрит в дашборд», от специалиста, способного обнаружить атаку, скрытую за нестандартным форматом логов.

Путь события: от Logcollector до Analysisd

Процесс обработки данных начинается на стороне агента, но его интеллектуальная часть сосредоточена на менеджере. Модуль logcollector на агенте читает файлы, указанные в конфигурации, и пересылает их на менеджер в неизменном виде. Менеджер принимает эти строки через демон remoted и передает их «сердцу» системы — analysisd.

Именно здесь происходит магия. Процесс анализа разделен на два этапа:

Декодирование (Pre-decoding и Decoding): Система пытается понять структуру строки и выделить из нее ключевые поля (IP-адреса, имена пользователей, ID событий).

Сопоставление с правилами (Rule Matching): На основе выделенных полей система ищет подходящее правило, которое определит уровень опасности события.

Если лог не прошел этап декодирования, он не сможет быть корректно обработан правилами, основанными на специфических полях. В лучшем случае сработает общее правило «поиска по строке», в худшем — событие будет проигнорировано как шум.

Механика декодеров: выделение смысла из хаоса

Декодер в Wazuh — это набор инструкций, использующих регулярные выражения (PCRE), для поиска паттернов в текстовой строке. Декодеры имеют иерархическую структуру: сначала отрабатывает «родительский» декодер, определяющий тип лога (например, SSH, Apache, Windows EventLog), а затем — «дочерние», которые уточняют детали.

Предварительное декодирование (Pre-decoding)

Прежде чем в дело вступят ваши кастомные регулярные выражения, Wazuh выполняет стадию pre-decoding. На этом этапе извлекаются статические метаданные, которые присутствуют почти в каждом логе: * Hostname: имя узла, отправившего лог. * Program_name: имя приложения (например, sshd или sudo). * Timestamp: время события.

Если ваше приложение пишет логи в нестандартном формате, где имя программы не отделено двоеточием или находится в середине строки, стандартный pre-decoder может ошибиться. В таких случаях приходится писать кастомные декодеры с нуля.

Структура XML-декодера

Рассмотрим типичный блок декодера:

Здесь мы видим два важных элемента:

<prematch>: Это «быстрый» фильтр. Если строка не начинается с MyCustomApp:, Wazuh даже не будет пытаться применять тяжелые регулярные выражения из этого блока. Это критически важно для производительности менеджера.

<regex> и <order>: В круглых скобках регулярного выражения захватываются группы. Тег <order> сопоставляет эти группы с именами полей, которые потом появятся в JSON-алерте.

Важно понимать, что Wazuh использует библиотеку PCRE. Если вы допустите ошибку в регулярном выражении (например, создадите катастрофический бэктрекинг), это может привести к скачку нагрузки на CPU менеджера.

Динамические поля и Sibling-декодеры

Иногда одно регулярное выражение не может охватить все вариации лога. В этом случае используются "сиблинги" (декодеры одного уровня). Если первый дочерний декодер не подошел, система пробует следующий. Это позволяет обрабатывать логи одного и того же приложения, имеющие разную структуру (например, лог аутентификации и лог изменения конфигурации).

Иерархия и логика правил

Когда декодер закончил работу, у нас есть набор полей: data.user, data.srcip, data.id и так далее. Теперь в игру вступает analysisd со своим набором правил. Правила в Wazuh — это логические условия, которые проверяют значения этих полей.

Уровни правил (Alert Levels)

Wazuh использует шкалу от 0 до 15 для классификации серьезности: * 0: Игнорируемые события (шум). Не записываются в архивы и не создают алертов. * 2-3: Низкий приоритет. Обычные системные уведомления. * 5-7: Ошибки конфигурации или подозрительные действия (например, неудачный вход). * 10-12: Серьезные аномалии. Многократные ошибки входа, запуск подозрительных утилит. * 13-15: Критические инциденты. Успешный брутфорс, обнаружение руткита, срабатывание антивируса.

По умолчанию в Dashboard отображаются только алерты уровня 3 и выше. Это настраивается параметром log_level в ossec.conf менеджера.

Зависимости и наследование (if_sid, if_group)

Главная сила правил Wazuh — в их способности строить цепочки. Правило редко существует само по себе. Обычно оно ссылается на «родителя».

В этом примере правило 100002 сработает только в том случае, если сначала сработало 100001. Это позволяет создавать глубоко вложенную логику, минимизируя ложные срабатывания. Если мы видим ошибку входа — это уровень 5. Если эта ошибка входа совершена пользователем admin — это уровень 9. Если это 10 ошибок входа за 1 минуту — это уровень 12.

Группировка правил

Каждое правило принадлежит к одной или нескольким группам (pci_dss_10.2.4, syslog, authentication_failed). Группировка позволяет:

Фильтровать алерты в Dashboard.

Использовать логическое условие if_group в правилах.

Настраивать автоматическое реагирование (Active Response) сразу для целой категории событий.

Продвинутые механизмы: Состояния и Частотный анализ

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

Опция frequency и timeframe

Предположим, мы хотим детектировать перебор паролей. Одиночная ошибка входа — норма. Пять ошибок за 30 секунд — атака.

* frequency="5": правило сработает только при пятом совпадении. * timeframe="30": окно времени в секундах. * <same_source_ip />: критически важный тег. Он говорит системе: «считай эти 5 событий только если они пришли с одного и того же IP». Без него система суммирует ошибки всех пользователей со всей сети, что приведет к ложному срабатыванию.

Существуют также теги <same_user />, <same_location /> и возможность комбинировать их.

Игнорирование повторов (ignore)

Иногда случается «шторм» логов. Например, процесс упал и каждую секунду пишет об этом в лог. Чтобы не забить дисковое пространство и не перегрузить базу данных алертами, используется тег <ignore>. Он позволяет «замолчать» правило на определенное время после первого срабатывания.

Работа с форматом JSON и Out-of-the-box интеграции

Современные приложения (Docker, Kubernetes, облачные сервисы) часто пишут логи сразу в формате JSON. Для Wazuh это подарок, так как такие логи не требуют написания сложных регулярных выражений в декодерах.

Менеджер имеет встроенный JSON-декодер. Если лог пришел в формате {"user": "admin", "action": "login", "status": "fail"}, Wazuh автоматически создаст поля data.user, data.action и data.status. Вам остается только написать правила, которые будут проверять эти поля.

Однако здесь кроется ловушка: Mapping Conflict. Если одно приложение присылает поле status как число (200), а другое — как строку ("success"), Wazuh Indexer может выдать ошибку при попытке записать такой документ. Поэтому при проектировании сбора логов важно следить за типизацией данных.

Практические советы по оптимизации

При росте инфраструктуры нагрузка на analysisd растет линейно количеству логов. Вот как сохранить производительность:

Используйте <prematch>: Это самая быстрая операция. Чем точнее будет prematch, тем меньше строк будет обрабатываться тяжелым движком регулярных выражений.

Порядок правил имеет значение: Wazuh проверяет правила сверху вниз. Однако он делает это эффективно, используя дерево зависимостей. Старайтесь делать родительские правила максимально общими, а дочерние — специфичными.

Не злоупотребляйте PCRE: Вместо .* (любой символ любое количество раз) используйте более строгие классы: \S+ (непробельные символы) или \d+ (цифры). Это предотвратит избыточное сканирование строки.

Тестирование через wazuh-logtest: Это главный инструмент администратора. Утилита позволяет вставить сырую строку лога и увидеть, какой декодер ее обработал и какое правило сработало.

Пример использования:

На выходе вы получите детальный отчет: * Phase 1: Pre-decoding: извлечено имя программы и таймстемп. * Phase 2: Decoding: какой декодер сработал и какие поля захвачены. * Phase 3: Rule selection: ID правила, уровень и описание.

Кастомизация: файлы local_decoder.xml и local_rules.xml

Никогда не меняйте стандартные файлы правил в /var/ossec/ruleset/rules/. При обновлении Wazuh они будут перезаписаны, и ваши труды пропадут. Для пользовательских настроек предназначена директория /var/ossec/etc/rules/ и /var/ossec/etc/decoders/.

Файлы с префиксом local_ загружаются последними, что позволяет переопределять (overwrite) стандартные правила. Если вам нужно изменить уровень стандартного правила (например, сделать SSH Login уровнем 10 вместо 3), вы используете атрибут overwrite="yes".

Сбор логов без агентов (Agentless и Syslog)

Хотя агент — предпочтительный способ, иногда его нельзя установить (на сетевые коммутаторы, принтеры или ESXi-хосты). В таких случаях Wazuh Manager может выступать в роли Syslog-сервера.

В ossec.conf менеджера настраивается секция <remote>, где указывается порт (обычно 514 UDP/TCP) и разрешенные IP-адреса. Логи, приходящие по сети, проходят тот же путь: декодер -> правило. Единственное отличие — в поле agent.id у таких событий будет стоять 000 (менеджер), а реальный источник будет виден в поле location или data.srcip.

Интеграция с внешними API и скриптами

Иногда лог нужно обогатить данными перед тем, как сработает правило. Например, проверить IP-адрес в базе AbuseIPDB. Для этого в Wazuh существуют CDB-листы (Constant DataBase) и интеграции.

CDB-листы позволяют загружать списки (например, черные списки IP или соответствие имен пользователей их департаментам) и использовать их в правилах:

Это работает молниеносно, так как списки компилируются в бинарный формат, оптимизированный для поиска.

Централизованный сбор логов в Wazuh — это не просто пересылка файлов. Это процесс фильтрации, нормализации и интеллектуального анализа. Правильно настроенные декодеры экономят ресурсы сервера, а выверенная иерархия правил позволяет ИБ-специалисту не утонуть в море алертов, фокусируясь только на том, что действительно несет угрозу. В следующих модулях мы увидим, как эти алерты становятся триггерами для автоматического блокирования атакующих, но фундамент этой защиты закладывается именно здесь — в XML-файлах конфигурации анализатора.

Обнаружение вторжений и поведенческий анализ аномалий в реальном времени

Представьте, что злоумышленник уже преодолел периметр вашей сети, используя украденные учетные данные. Он не сканирует порты агрессивно и не рассылает спам — он действует осторожно, мимикрируя под легитимного администратора. Традиционные антивирусы молчат, так как в системе не запускается вредоносный код, а используются штатные инструменты ОС (PowerShell, bash, ssh). В этой ситуации единственным способом обнаружить угрозу становится поведенческий анализ: фиксация отклонений от нормы в реальном времени. Wazuh предоставляет для этого мощный инструментарий, выходящий за рамки простого сопоставления логов с сигнатурами.

Механизмы обнаружения вторжений: от статики к динамике

Системы обнаружения вторжений (IDS) в Wazuh работают на стыке двух подходов: сигнатурного (Rule-based) и поведенческого (Anomaly-based). Если сигнатурный подход ищет конкретные «отпечатки» известных атак (например, специфическую строку в логе веб-сервера), то поведенческий анализ фокусируется на контексте событий.

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

Детекция аномалий через частотный анализ

Одним из базовых способов выявления аномального поведения является использование параметров frequency и timeframe в правилах. Это позволяет отличить единичную ошибку ввода пароля от направленной атаки методом перебора (brute-force).

Рассмотрим математическую модель срабатывания такого правила. Пусть — количество событий, — временной интервал в секундах. Правило активируется, если выполняется условие:

внутри окна времени .

Однако в реальной инфраструктуре статичные пороги часто приводят к ложноположительным срабатываниям (False Positives). Например, скрипт автоматизации может генерировать десятки успешных входов в секунду. Для решения этой проблемы Wazuh использует иерархию правил, где мы можем создавать исключения для конкретных хостов или пользователей, не отключая общую логику детектирования аномалий.

Группировка событий и корреляция

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

Представим цепочку событий:

Неудачная попытка входа (Rule ID: 5710).

Еще 10 неудачных попыток с того же IP.

Успешный вход с этого же IP (Rule ID: 5715).

С точки зрения системы, это не просто три разных события, а потенциальный инцидент «Successful login after brute force». Создание правил, которые «ждут» определенного паттерна поведения, превращает Wazuh из сборщика логов в интеллектуальную систему мониторинга.

Модуль Rootcheck: поиск скрытых угроз

Одной из самых сложных задач в обнаружении вторжений является поиск руткитов (rootkits) — вредоносного ПО, которое скрывает свое присутствие в системе, модифицируя системные вызовы или структуры ядра. Модуль rootcheck в составе Wazuh агента предназначен именно для этих целей.

Логика работы Rootcheck

Модуль работает в фоновом режиме и выполняет ряд проверок, которые невозможно реализовать простым анализом логов:

Проверка скрытых портов: Агент сравнивает список открытых портов, полученных через стандартные API ОС, с результатами прямого сканирования портов. Если порт открыт, но не отображается в системных таблицах, это явный признак присутствия вредоносного кода, перехватывающего вывод утилит типа netstat или ss.

Проверка скрытых процессов: Аналогично портам, rootcheck ищет расхождения между списком процессов в /proc (для Linux) и результатами системных вызовов getsid().

Анализ интерфейсов: Проверка сетевых интерфейсов на наличие режима «promiscuous» (неразборчивый режим), который часто используется снифферами для перехвата трафика в сегменте сети.

Сканирование файловой системы: Поиск файлов в директориях, которые обычно используются руткитами для хранения своих компонентов (например, /dev/.lib или скрытые папки в /tmp).

Важно понимать, что rootcheck — это не антивирусный сканер. Он ищет не «вирусы», а «аномалии в представлении системы самой себе». Если системная утилита говорит, что процессов всего 50, а ядро сообщает о 51 — Wazuh сгенерирует алерт высокого уровня.

Мониторинг системных вызовов и аудит процессов

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

Настройка правил аудита для детекции аномалий

Стандартный лог процесса часто содержит мало информации. Auditd дополняет её контекстом. Например, мы можем настроить мониторинг вызова execve. Когда пользователь запускает команду, Wazuh получает детальный отчет:

Кто запустил (uid, auid).

Какая команда и с какими аргументами.

Какой был рабочий каталог.

Идентификатор процесса (PID) и родительского процесса (PPID).

Это позволяет выявлять аномалии типа Living off the Land (LotL). Например, если процесс веб-сервера apache2 внезапно запускает whoami или nc (netcat), это почти всегда означает успешную эксплуатацию уязвимости и попытку злоумышленника закрепиться в системе.

В Windows аналогичную роль выполняет интеграция с Sysmon. Sysmon предоставляет расширенные события, такие как «Process Creation» (Event ID 1) или «Network Connection» (Event ID 3), которые включают в себя хэши исполняемых файлов. Это позволяет Wazuh не только видеть запуск процесса, но и мгновенно сверять его хэш с базами Threat Intelligence (например, через интеграцию с VirusTotal).

Поведенческий анализ сетевой активности

Хотя Wazuh в первую очередь является Host-based IDS (HIDS), он эффективно анализирует сетевое поведение через логи системы и интеграцию с сетевыми IDS (например, Suricata).

Детекция сканирования и эксплойтов

Аномальное сетевое поведение часто проявляется в виде:

Большого количества соединений на разные порты одного хоста (сканирование портов).

Соединений с хостами, имеющими плохую репутацию (C2-серверы).

Нетипичных объемов передаваемых данных (возможная эксфильтрация).

Wazuh анализирует логи брандмауэров (iptables, Windows Firewall) и сетевых сервисов. Если мы видим, что рабочая станция бухгалтера внезапно начинает обращаться к внутреннему серверу базы данных по порту 3306, хотя раньше этого никогда не происходило — это поведенческая аномалия.

Для реализации такой проверки используются CDB-листы (Constant DataBase), о которых мы упоминали ранее. Мы можем составить список «белых» соединений для каждой группы хостов. Любое соединение, не входящее в список, будет вызывать алерт низкого уровня для последующего анализа.

Использование анализа аномалий для обнаружения инсайдерских угроз

Инсайдеры — одна из самых сложных категорий нарушителей, так как у них есть легитимный доступ. Здесь на помощь приходит анализ временных интервалов и паттернов доступа.

Анализ времени активности

Если администратор обычно работает с 9:00 до 18:00, то его вход в систему в 3:00 ночи в воскресенье является аномалией. В Wazuh это реализуется через проверку поля timestamp в правилах.

Пример логики правила для обнаружения внеурочной активности:

Событие: успешный вход (Rule ID 5715).

Условие: время события попадает в диапазон 00:00 - 06:00 ИЛИ день недели — суббота/воскресенье.

Действие: повысить уровень алерта до 7 или 10.

Аномалии доступа к данным

С помощью модуля FIM (который мы подробно разберем в следующей главе) и правил анализа логов можно отслеживать аномальное количество обращений к файлам. Если пользователь за одну минуту открыл 500 документов в сетевой папке, это может свидетельствовать либо о работе скрипта-шифровальщика (Ransomware), либо о попытке массового копирования данных перед увольнением.

Практический кейс: обнаружение атаки типа Pass-the-Hash

Атака Pass-the-Hash (PtH) позволяет злоумышленнику аутентифицироваться на удаленном сервере, используя NTLM-хэш пароля пользователя, не зная самого пароля. В логах Windows это выглядит как успешный вход, но с определенными атрибутами, которые считаются аномальными.

При анализе такого события в Wazuh Dashboard мы обращаем внимание на тип входа (Logon Type). Для PtH характерно сочетание:

Logon Type 9 (NewCredentials): часто используется утилитами типа Mimikatz.

Logon Process: seclogo: вторичный вход в систему.

Создавая правило, которое ищет именно это сочетание в событиях Event ID 4624, мы реализуем поведенческий детектор конкретной техники атаки, которую трудно заметить обычным мониторингом.

Обогащение данных и контекстный анализ

Для того чтобы поведенческий анализ был точным, Wazuh должен «понимать» контекст. Это достигается за счет обогащения алертов внешней информацией.

Интеграция с Threat Intelligence

Wazuh может в реальном времени отправлять извлеченные из логов IP-адреса, домены или хэши файлов во внешние API. Например, при обнаружении запуска нового процесса (Event ID 1 в Sysmon), менеджер Wazuh может:

Выполнить скрипт интеграции с VirusTotal.

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

Если детекций , автоматически сгенерировать новый алерт с уровнем 12 («Known malicious file executed»).

Это превращает пассивный мониторинг в активную систему защиты.

Использование Mitre ATT&CK

Почти все стандартные правила Wazuh уже размечены тегами в соответствии с матрицей Mitre ATT&CK. Это позволяет специалисту по безопасности видеть не просто «подозрительное событие», а конкретную тактику и технику (например, T1003 - OS Credential Dumping).

В интерфейсе Dashboard это дает возможность строить тепловые карты угроз. Если вы видите концентрацию алертов в области «Persistence» (Закрепление в системе), значит, злоумышленник уже внутри и пытается обеспечить себе долгосрочный доступ.

Нюансы настройки и предотвращение «алертового шума»

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

Стратегия настройки порогов

При внедрении поведенческих правил рекомендуется следовать алгоритму:

Этап обучения (Baseline): Включите правила в режиме «только запись» (уровень 0 или 3) на 1-2 недели.

Анализ статистики: Используйте Wazuh Dashboard (раздел Discover), чтобы увидеть, какие хосты генерируют больше всего срабатываний.

Тонкая настройка:

- Если срабатывания легитимны (например, скрипт бэкапа), создайте дочернее правило с level="0", которое отфильтровывает этот конкретный случай по имени пользователя или IP. - Если срабатываний слишком мало и они пропускают реальные тесты (Red Teaming), снизьте порог frequency.

Использование динамических списков (CDB)

CDB-листы позволяют динамически изменять поведение системы без перезагрузки правил. Вы можете вынести список доверенных IP-адресов администраторов в отдельный файл. Правило будет проверять: «Если это попытка входа по SSH И IP-адрес НЕ в списке admin_ips, то поднять уровень тревоги». Обновление списка происходит мгновенно, что крайне удобно в динамических средах.

Архитектурные ограничения мониторинга в реальном времени

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

Память: Каждое частотное правило заставляет analysisd держать в памяти счетчики событий для каждого уникального источника (например, для каждого IP) в течение периода timeframe. Если у вас идет массированная атака с тысяч IP, потребление памяти может резко вырасти.

Задержки (Latency): Внешние интеграции (вызовы API) должны быть асинхронными, иначе процесс анализа логов может замедлиться, что приведет к переполнению очередей на агентах.

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

Финальное замыкание мысли

Обнаружение вторжений в реальном времени в Wazuh — это не статичная настройка, а непрерывный процесс адаптации системы под ландшафт угроз и особенности вашей инфраструктуры. Переход от простого сбора логов к поведенческому анализу позволяет выявлять сложные атаки, такие как LotL, PtH и инсайдерские злоупотребления. Используя комбинацию частотных правил, модулей контроля скрытых угроз (Rootcheck) и глубокой интеграции с системным аудитом (Auditd/Sysmon), администратор получает полную видимость происходящего на конечных точках. Ключом к успеху здесь является баланс между чувствительностью детекторов и качеством фильтрации «шума», что достигается через постоянную работу с исключениями и обогащение данных контекстом безопасности.

Контроль целостности файлов (FIM) и глубокий аудит системных изменений

Представьте, что злоумышленник получил доступ к вашему серверу с правами суперпользователя. Его первая задача — закрепиться в системе так, чтобы остаться незамеченным. Он может заменить легитимную бинарную утилиту ls или ps на модифицированную версию (rootkit), которая скрывает его файлы и процессы, или добавить свой публичный ключ в файл authorized_keys. В обоих случаях системные логи могут промолчать, но состояние файловой системы изменится безвозвратно. Модуль File Integrity Monitoring (FIM) в Wazuh, исторически называемый Syscheck, является тем самым «цифровым сторожем», который замечает малейшее отклонение в битах и байтах критически важных объектов.

Механика работы Syscheck: от сканирования до алертов

Модуль FIM не просто следит за файлами — он создает базу данных «нормального» состояния системы и постоянно сверяет реальность с этим эталоном. Процесс работы Syscheck можно разделить на три ключевых этапа: создание базовой линии (baseline), мониторинг изменений и генерация событий.

Формирование Baseline

При первом запуске агента или после изменения конфигурации Syscheck выполняет полное сканирование указанных директорий. Для каждого файла агент вычисляет контрольные суммы (MD5, SHA1, SHA256), собирает метаданные (права доступа, владелец, группа, размер) и, в случае Windows, атрибуты и разрешения (ACL). Эти данные отправляются на Wazuh Manager, где сохраняются в локальной базе данных SQLite, специфичной для каждого агента.

Эта база данных является точкой отсчета. Любое последующее сканирование будет сравнивать текущие показатели файлов с теми, что хранятся в этой базе.

Режимы сканирования: Scheduled vs Real-time

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

Периодическое сканирование (Scheduled Scan): Агент обходит дерево каталогов через заданные интервалы времени (параметр frequency). Это ресурсоемкий процесс, так как он требует чтения всех файлов для пересчета хэшей. Однако это самый надежный метод, гарантирующий обнаружение изменений, даже если механизмы уведомлений ядра были обойдены.

Мониторинг в реальном времени (Real-time): Использует подсистемы ядра (inotify в Linux, ReadDirectoryChangesW в Windows). Как только происходит обращение к файлу (запись, удаление, переименование), ядро мгновенно уведомляет агент Wazuh. Это позволяет генерировать алерт в течение секунд после инцидента.

Who-data (Аудит доступа): Самый глубокий уровень мониторинга. В дополнение к факту изменения файла, этот режим сообщает, кто именно внес изменения. В Linux это реализуется через подсистему Auditd, в Windows — через механизм SACL (System Access Control Lists).

Конфигурация модуля: тонкая настройка syscheck

Настройка FIM производится в секции <syscheck> файла ossec.conf (или agent.conf для групп). Рассмотрим структуру и параметры, которые определяют эффективность мониторинга.

Основные параметры директорий

Для того чтобы Wazuh начал следить за объектом, необходимо использовать тег <directories>.

Атрибут check_all="yes" — это шорткат, который включает проверку всех доступных параметров: размера, прав, владельца, группы и трех видов хэш-сумм. Если вам нужно экономить ресурсы (например, на очень больших файлах), вы можете явно указать check_sha256="yes" и отключить остальные.

Особенности Who-data и системные требования

Режим whodata является золотым стандартом для форензики, но он требует предварительной подготовки ОС. * В Linux: Необходимо наличие установленного пакета auditd. Wazuh автоматически добавит необходимые правила в Auditd для мониторинга указанных путей. Важно помнить, что если в системе уже настроены сложные правила аудита, может возникнуть конфликт приоритетов. * В Windows: Требуется включение политик аудита доступа к объектам (Object Access Auditing) в GPO или локальных политиках безопасности. Кроме того, на сами папки должны быть установлены SACL для группы "Everyone" или конкретных пользователей.

Динамическое игнорирование и ограничение нагрузки

FIM может стать источником «шторма событий», если натравить его на активно меняющиеся логи или базы данных. Параметр nodiff позволяет следить за фактом изменения файла, но не пытаться вычислить разницу в его содержимом (diff), что критично для конфиденциальных файлов (например, /etc/shadow).

Для предотвращения перегрузки CPU во время сканирования используется параметр process_priority (в Windows) и nice (в Linux), а также sleep_after — пауза в миллисекундах между чтением файлов.

Глубокий анализ: Diff и хранение изменений

Одной из самых мощных функций Wazuh FIM является возможность видеть, что именно изменилось внутри текстового файла. Это достигается с помощью атрибута report_changes="yes".

Когда этот параметр включен, агент при обнаружении изменения копирует файл во временное хранилище, сравнивает его с предыдущей копией и отправляет текстовую разницу (diff) на менеджер.

> Важное ограничение безопасности: > Никогда не включайте report_changes для директорий, содержащих секреты, ключи или пароли. Хотя данные передаются по зашифрованному каналу, они будут храниться на менеджере в открытом виде в составе алертов. Для таких файлов используйте check_all="yes", но без report_changes.

Пример алерта с report_changes в интерфейсе Dashboard покажет блок:

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

Мониторинг реестра Windows

Для Windows-инфраструктуры контроль файлов — это лишь половина дела. Огромное количество вредоносного ПО закрепляется через ключи реестра (Run, RunOnce, сервисы). Wazuh позволяет мониторить реестр так же эффективно, как и файлы.

Атрибут arch="both" критически важен для 64-битных систем, так как он заставляет агент проверять обе ветки реестра (стандартную и Wow6432Node), где часто прячутся 32-битные зловреды. Мониторинг реестра также поддерживает режим реального времени, что позволяет ловить создание новых служб в момент их регистрации.

Жизненный цикл базы данных FIM и очистка данных

База данных Syscheck на менеджере не является статичной. Со временем в ней накапливаются записи о файлах, которые были удалены или перемещены. Для поддержания актуальности и производительности используются следующие механизмы:

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

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

Обработка удаления: Когда файл удаляется, Syscheck генерирует алерт с уровнем 7 (по умолчанию), что является важным сигналом при атаках типа Ransomware.

Практический кейс: Обнаружение Ransomware с помощью FIM

Шифровальщики работают по предсказуемому паттерну: чтение файла -> создание зашифрованной копии -> удаление оригинала или переименование. Настроив FIM на критические папки с данными пользователей, мы можем построить цепочку алертов: * Множественные события Deleted для легитимных документов. * Множественные события Added для файлов с неизвестными расширениями (например, .crypt). * Высокая частота изменений в короткий промежуток времени.

Комбинируя эти события с правилами корреляции (которые мы изучим в следующих главах), можно настроить Active Response для автоматической изоляции хоста от сети при достижении порога в 50 измененных файлов за 10 секунд.

Оптимизация производительности: Баланс между безопасностью и ресурсами

FIM — самый «тяжелый» модуль Wazuh. Неправильная настройка может привести к 100% загрузке дисковой подсистемы.

Таблица: Сравнение режимов мониторинга

| Параметр | Нагрузка на CPU/Disk | Скорость реакции | Информативность | Требования к ОС | | :--- | :--- | :--- | :--- | :--- | | Scheduled | Высокая (пиковая) | Низкая (до след. цикла) | Средняя (факт изменения) | Минимальные | | Real-time | Низкая (постоянная) | Мгновенно | Средняя (факт изменения) | inotify / WinAPI | | Who-data | Средняя | Мгновенно | Максимальная (User ID, Process) | Auditd / SACL |

Для оптимальной работы рекомендуется:

Использовать real_time="yes" для большинства критических путей.

Устанавливать frequency (полное сканирование) на ночное время или раз в 24 часа для обнаружения того, что мог пропустить real-time.

Ограничивать глубину рекурсии (recursion_level), если вы мониторите папки с огромной вложенностью.

Активно использовать ignore для файлов, которые меняются легитимно (логи, кэши, временные файлы БД).

Продвинутые техники: Использование атрибутов для специфических задач

Wazuh позволяет отслеживать не только содержимое, но и специфические атрибуты. Например, атрибут check_inode="yes" поможет обнаружить атаку типа "hardlink attack", когда злоумышленник подменяет файл, создавая жесткую ссылку на другой объект, при этом размер и хэш могут остаться прежними (если содержимое идентично), но номер inode изменится.

На системах Windows крайне полезен атрибут check_attrs="yes". Он позволяет заметить, когда файл становится "Скрытым" (Hidden) или "Системным" (System). Часто вредоносное ПО устанавливает эти атрибуты на свои исполняемые файлы, чтобы обычный пользователь не увидел их в проводнике.

Интеграция с внешними системами через FIM

События FIM являются отличным триггером для обогащения данных. Когда Syscheck сообщает об изменении или добавлении нового бинарного файла в /usr/bin, это событие содержит хэш-сумму файла. В Wazuh Manager можно настроить автоматическую отправку этого хэша во внешние сервисы, такие как VirusTotal или AlienVault OTX.

Если внешний сервис возвращает информацию о том, что хэш принадлежит известному вредоносу, Wazuh генерирует новый алерт с критическим уровнем (12-15), что позволяет немедленно приступить к реагированию, не дожидаясь ручного анализа.

Настройка исключений: Борьба с шумом

Одной из главных проблем при внедрении FIM является огромное количество алертов на начальном этапе. Системные обновления (apt upgrade, yum update) могут генерировать тысячи событий изменения файлов.

Для решения этой проблемы существует два пути:

Временное отключение: Остановка агента или модуля Syscheck на время проведения регламентных работ.

Интеллектуальная фильтрация: Создание правил в local_rules.xml, которые понижают уровень алерта до 0, если изменение внесено доверенным процессом (например, установщиком пакетов), при условии использования режима whodata.

Пример правила для исключения шума от обновления yum:

Визуализация данных FIM в Dashboard

В интерфейсе Wazuh Dashboard модулю FIM посвящен отдельный раздел. Он позволяет: * Видеть общую динамику изменений в инфраструктуре. * Фильтровать события по типу (Added, Modified, Deleted). * Просматривать инвентарную базу данных (Inventory) — текущее состояние всех отслеживаемых файлов на конкретном агенте без необходимости ждать алерта. * Сравнивать состояние файлов между разными хостами (например, убедиться, что конфигурация Nginx идентична на всех узлах кластера).

Раздел Inventory Data в меню агента — это мощный инструмент аудита. Если вы подозреваете компрометацию, вы можете зайти в этот раздел и мгновенно увидеть список всех файлов в /etc с их хэшами и временем последнего изменения, даже если само событие изменения уже ротировалось из основных индексов алертов.

Замыкание контура безопасности

Контроль целостности файлов — это не просто «детектор взлома». Это инструмент обеспечения дисциплины администрирования. В правильно настроенной среде любое изменение в /etc/nginx/nginx.conf должно сопровождаться алертом в Wazuh. Если алерт пришел, а тикета на изменение конфигурации нет — это повод для внутреннего расследования.

FIM превращает «черный ящик» сервера в прозрачную систему, где каждое движение бита фиксируется и анализируется. В сочетании с анализом логов и поведенческим мониторингом, которые мы обсуждали ранее, Syscheck формирует надежный фундамент для построения процесса Threat Hunting и обеспечения соответствия жестким стандартам безопасности, таким как PCI DSS или SOC2, где контроль целостности является обязательным требованием.

Детекция уязвимостей ПО и автоматизированная инвентаризация системных активов

Представьте ситуацию: в популярной библиотеке логирования или почтовом сервере обнаруживается критическая уязвимость (0-day), позволяющая удаленно выполнить код. У вас в управлении три сотни серверов с разными версиями ОС, сотни рабочих станций и десятки контейнеризированных приложений. Первый вопрос, который задаст руководство: «Мы уязвимы?». Без автоматизированных инструментов ответ на этот вопрос может занять дни ручного аудита, в то время как злоумышленникам достаточно нескольких часов для массового сканирования интернета.

Wazuh превращает этот хаос в структурированную базу данных, объединяя два критически важных процесса: непрерывную инвентаризацию (Asset Inventory) и автоматический поиск уязвимостей (Vulnerability Detection). Эти модули работают в тесной связке: один строит детальную карту того, что установлено в системе, а второй сопоставляет эти данные с глобальными базами угроз.

Механика сбора данных: Модуль Syscollector

Прежде чем искать уязвимости, система должна точно знать «состав» каждой конечной точки. За это отвечает модуль Syscollector. Это внутренний компонент агента Wazuh, который периодически сканирует хост и отправляет отчеты на менеджер.

В отличие от классических сканеров портов, которые видят систему «снаружи», Syscollector работает изнутри. Он имеет доступ к пакетным менеджерам (APT, RPM, MSI), таблицам сетевых интерфейсов и реестру. Это позволяет избежать проблем с закрытыми портами или брандмауэрами, которые часто искажают результаты внешнего сканирования.

Настройка периодичности и охвата

Конфигурация модуля находится в блоке <wodle name="syscollector"> файла ossec.conf. По умолчанию сканирование происходит каждые 1 час, но для стабильных серверов этот интервал можно увеличить, чтобы снизить нагрузку на CPU.

Основные параметры сбора:

os: сбор информации о версии ОС, ядре и архитектуре.

packages: инвентаризация установленного ПО. Это фундамент для поиска уязвимостей.

ports: список открытых портов (TCP/UDP) и процессов, которые их прослушивают.

netaddr: информация о сетевых интерфейсах, IP-адресах и MAC-адресах.

hardware: данные о железе (CPU, RAM, серийные номера).

Важно понимать, что Syscollector работает по принципу дельта-обновлений. После первого полного сканирования агент отправляет только изменения, что значительно экономит сетевой трафик в крупных инсталляциях.

Инвентаризация активов как инструмент расследования

Данные, собранные Syscollector, попадают в раздел Inventory Data в Wazuh Dashboard. Это не просто статичный список, а мощный инструмент для системного администратора и офицера безопасности.

Поиск «теневого» ПО

Часто инциденты происходят из-за софта, который не должен находиться на сервере. Например, системный администратор установил nmap или tcpdump для отладки и забыл удалить. Или разработчик развернул старую версию Python в обход стандартных репозиториев. Через фильтры Inventory Data можно мгновенно найти все хосты, где установлены специфические пакеты, или отфильтровать системы по версии ядра.

Мониторинг сетевого периметра

Секция Network Ports позволяет увидеть реальную картину открытых портов. Если на сервере базы данных внезапно открывается порт 22 (SSH) на внешнем интерфейсе, это повод для немедленной проверки. Wazuh сопоставляет порт с конкретным PID (Process ID), что позволяет точно определить, какой именно процесс инициировал прослушивание.

Инвентаризация аппаратной части

Хотя Wazuh — это инструмент безопасности, данные о железе помогают в планировании ресурсов. Вы можете за несколько секунд получить список всех серверов, у которых объем оперативной памяти меньше 8 ГБ или тип процессора не соответствует корпоративному стандарту.

Vulnerability Detector: от логов к управлению рисками

Модуль Vulnerability Detector — это «мозг» системы обнаружения дыр в безопасности. Он работает на стороне Wazuh Manager и использует данные инвентаризации, полученные от агентов.

Источники данных об уязвимостях

Менеджер Wazuh автоматически загружает и обновляет базы CVE (Common Vulnerabilities and Exposures) из нескольких доверенных источников:

Canonical (Ubuntu), Red Hat, Debian, SUSE: специфические для дистрибутивов базы патчей.

NVD (National Vulnerability Database): глобальный репозиторий уязвимостей от NIST.

Microsoft: данные об обновлениях безопасности Windows.

Процесс сопоставления выглядит так: менеджер берет список пакетов из базы данных конкретного агента и сравнивает их версии с версиями, указанными в базах CVE. Если установленная версия , генерируется алерт.

Типы обнаружения: Пакеты vs ОС

Wazuh разделяет уязвимости на две категории:

OS Vulnerabilities: проблемы в компонентах самой операционной системы (ядро, системные библиотеки).

Application Vulnerabilities: уязвимости в прикладном софте (браузеры, офисные пакеты, среды разработки).

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

Глубокая настройка и оптимизация детектора

Работа с уязвимостями в большой сети может создать высокую нагрузку на менеджер и индексер. Чтобы система оставалась отзывчивой, необходимо понимать нюансы конфигурации в блоке <vulnerability-detector>.

Настройка фидов (Feeds)

Для каждой поддерживаемой ОС необходимо включить соответствующий фид. Например:

Здесь update_interval определяет, как часто менеджер будет ходить в интернет за свежими данными от вендора. Для критических систем рекомендуется интервал в 1-3 часа.

Проблема ложноположительных срабатываний (False Positives)

Ни один сканер уязвимостей не идеален. Иногда Wazuh может пометить пакет как уязвимый, хотя вендор уже выпустил "backported" патч (исправление безопасности, перенесенное в старую версию пакета без изменения минорного номера версии).

Для борьбы с этим Wazuh использует механизмы проверки OVAL (Open Vulnerability and Assessment Language). Если вы столкнулись с систематическим ложным срабатыванием на определенный пакет, вы можете использовать правила фильтрации в Wazuh Dashboard или, в крайнем случае, настроить исключения через кастомные правила с низким уровнем (Level 0), чтобы подавить алерты для конкретного vulnerability.cve.

Оценка критичности: метрики CVSS

Wazuh не просто говорит «у вас есть уязвимость», он приоритизирует её на основе системы CVSS (Common Vulnerability Scoring System). Это критически важно для администратора, у которого в списке 5000 уязвимостей и ограниченное время на их устранение.

В интерфейсе алерты группируются по уровням:

Critical (9.0 - 10.0): Требуют немедленного исправления. Обычно это удаленное выполнение кода (RCE) без аутентификации.

High (7.0 - 8.9): Серьезные бреши, которые могут привести к полной компрометации системы.

Medium (4.0 - 6.9): Уязвимости, требующие специфических условий для эксплуатации.

Low (0.1 - 3.9): Ошибки, которые сами по себе не опасны, но могут быть использованы в цепочке атак.

Использование фильтра vulnerability.severity: "critical" в разделе Vulnerabilities позволяет сфокусироваться на тех 5% проблем, которые представляют реальную угрозу прямо сейчас.

Инвентаризация горячих исправлений (Hotfixes) в Windows

Мониторинг Windows имеет свои особенности. В отличие от Linux, где обновление пакета обычно закрывает уязвимость, в Windows безопасность часто зависит от установленных KB (Knowledge Base) патчей.

Wazuh через модуль Syscollector собирает список всех установленных Hotfixes. Vulnerability Detector сопоставляет этот список с данными Microsoft Security Update Guide. Если для закрытия CVE-2023-XXXX требуется установка KB502XXXX, а её нет в списке инвентаризации хоста, Wazuh пометит систему как уязвимую, даже если версия самого файла кажется актуальной.

Нюанс с "Superseded" обновлениями

Microsoft часто выпускает кумулятивные обновления, которые заменяют (supersede) предыдущие. Wazuh умеет отслеживать эти цепочки. Если у вас установлено более свежее кумулятивное обновление, которое включает в себя исправления для старых KB, система поймет это и не будет генерировать лишние алерты.

Кейс: Обнаружение уязвимостей в Docker-контейнерах

Современная инфраструктура — это не только ОС, но и контейнеры. Wazuh позволяет проводить инвентаризацию и поиск уязвимостей внутри запущенных контейнеров.

Существует два подхода:

Агент внутри контейнера: дает максимальную детализацию, но противоречит идеологии «легковесных» контейнеров.

Мониторинг через Docker Socket: агент Wazuh устанавливается на хост-систему, подключается к /var/run/docker.sock и получает данные о запущенных образах.

Wazuh может сканировать слои образов и находить уязвимые библиотеки (например, старую версию openssl внутри образа Alpine). Это позволяет выявлять риски еще на этапе тестирования, до того как уязвимый контейнер попадет в продакшн.

Жизненный цикл уязвимости в Wazuh

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

Active: Уязвимость обнаружена и все еще присутствует в системе.

Solved: Уязвимость была устранена (пакет обновлен, патч установлен). Wazuh автоматически переводит статус в Solved после следующего сканирования Syscollector.

Obsolete: Уязвимость больше не актуальна (например, пакет был удален из системы).

Эта прослеживаемость позволяет строить отчеты о динамике безопасности: «Сколько критических уязвимостей мы закрыли за прошлый месяц?».

Взаимодействие с другими модулями

Инвентаризация и поиск уязвимостей не работают в вакууме. Их данные обогащают всю систему безопасности.

Связка с FIM (File Integrity Monitoring)

Если FIM фиксирует изменение бинарного файла в /usr/bin/, а через час Vulnerability Detector сообщает о новой уязвимости в этом же пакете, это может указывать на то, что злоумышленник подменил легитимный файл на уязвимую версию для последующей эксплуатации.

Связка с Active Response

Хотя автоматическое обновление пакетов при обнаружении уязвимости — рискованная затея (может нарушить работу приложения), вы можете настроить Active Response на изоляцию хоста от сети, если на нем обнаружена критическая уязвимость с публично доступным эксплойтом (на основе данных из метаданных CVE).

Ограничения и граничные случаи

Администратору необходимо знать, где возможности Wazuh заканчиваются:

Самописное ПО: Wazuh не найдет уязвимости в коде, который написали ваши разработчики, если он не упакован в стандартный пакет и не внесен в базы CVE.

Portable-приложения: Если софт просто скопирован в папку (например, бинарник Go или Java JAR-файл), Syscollector может его не заметить, если не настроен специфический мониторинг путей.

Выключенные системы: Если сервер выключен, данные о его уязвимостях в Dashboard будут «заморожены» в последнем известном состоянии.

Для покрытия этих зон рекомендуется комбинировать Wazuh с инструментами статического анализа кода (SAST) и динамического сканирования (DAST).

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

Начинать работу с этими модулями стоит поэтапно, чтобы не захлебнуться в потоке данных.

Этап 1: Только инвентаризация. Включите Syscollector на всех агентах, но оставьте Vulnerability Detector выключенным на менеджере. Дайте системе 24 часа, чтобы собрать базу активов.

Этап 2: Выборочный детектор. Включите Vulnerability Detector только для одной ОС (например, Ubuntu 22.04). Оцените объем алертов и нагрузку на Indexer.

Этап 3: Фильтрация шума. Изучите список Medium/Low уязвимостей. Если они относятся к неиспользуемым компонентам, решите — удалять ли эти компоненты или просто фильтровать алерты.

Этап 4: Полный охват. Включите все фиды и настройте еженедельные отчеты для руководства по метрике "Time to Patch" (время от обнаружения до закрытия уязвимости).

Wazuh предоставляет беспрецедентный уровень видимости инфраструктуры. Понимая, что именно установлено на ваших серверах и какие риски несет каждый байт кода, вы переходите от реактивной модели защиты («что-то случилось, надо чинить») к проактивной («мы знаем о дырах и закрываем их раньше, чем ими воспользуются»).