Wazuh 4.14.7 против 5.0 Beta 5: это миграция, а не обновление

Одна и та же последовательность на двух стендах. Останавливаю indexer, продолжаю слать события, перезапускаю менеджер до того, как indexer вернется, поднимаю indexer обратно и считаю, сколько дошло. События на обеих сторонах идут одним путем - через своего агента, а не подкладываются менеджеру в файл, - и каждое несет собственный идентификатор. Число записанных строк подтверждается перечитыванием файла агента, а не берется из счетчика цикла; уникальные считаются точно по возвращенным идентификаторам, а не оценкой. Во всех двенадцати фазах подтвержденная запись равна 100, а дубликатов нет ни в одной.

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

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

Значит, дело не в надежности как таковой. Дело в том, что граница отказа переехала, а вместе с ней устарел рефлекс, который на моих установках 4.x проходил без последствий: «не отвечает - перезапусти менеджер». В 5.0 этот шаг в неудачный момент стирает все, что менеджер держал для отправки.

Дальше разбираю, что именно переехало вместе с этой границей, и во что это обходится при переходе. Все мои лабораторные измерения ниже сняты 6 и 7 сентября 2026 года на двух одноузловых стендах, поднятых из официальных образов: 4.14.7 и 5.0.0 Beta 5, оба на arm64, оба в контейнерах, оба с небольшой нагрузкой. Числа, взятые из документации, публичных отчетов о дефектах и трекера тестирования, помечены как таковые по месту. Сценарий отказа выполнен по три раза на каждой версии; все остальные наблюдения - парный прогон события, инвентари, транспорт, состав потоков - единичные. Это лабораторные наблюдения, а не нагрузочное тестирование, и переносить их на многоузловую установку с промышленным потоком нельзя.

Почему менеджер перестал быть местом, где событие переживает сбой

В 4.14.7 порядок такой: менеджер декодирует событие, сопоставляет с правилами, создает alert и кладет его в /var/ossec/logs/alerts/alerts.json, а уже оттуда Filebeat отправляет его в indexer. В моем прогоне при выключенном indexer менеджер записал в этот файл все сто alert, и они спокойно дождались возвращения indexer, пережив по дороге собственный перезапуск.

В 5.0 Filebeat удален, и его место занял indexer connector. Это не отдельный демон, а разделяемая библиотека, с которой слинкованы движок нормализации, служба обнаружения уязвимостей и служба синхронизации инвентаря. Документация описывает его буферизацию прямо и без обиняков: коннектор буферизует в памяти и отбрасывает накопленные документы при остановке или перезапуске менеджера, поэтому рассчитывать на менеджер как на поглотитель длительных задержек индексации не следует (indexer connector).

Механизм отбрасывания буфера я взял из документации и сам не наблюдал. Что измерено, так это результат: из 100 событий, подтвержденно записанных агентом, в indexer после восстановления не оказалось ни одного. Сколько из них менеджер успел принять до перезапуска, я не знаю и знать не могу: в 5.0 между приемом и индексацией нет наблюдаемой точки, тогда как в 4.14.7 ее дает локальный файл alert. Это ограничение метода, и оно само по себе часть разницы между версиями.

Сам менеджер при этом ведет себя аккуратно и о происходящем сообщает. В журнале видно, как он теряет узел и как находит его снова:

monitoring: INFO: Indexer node 'https://wazuh.indexer:9200' is no longer available. Reason: Could not resolve hostname
wazuh-manager-modulesd:inventory-sync-server: WARNING: No configured indexer host is currently reachable. Documents will queue or be retried until one comes back; checking again every 60 s.
monitoring: INFO: Indexer node 'https://wazuh.indexer:9200' is available again.

Обещание поставить документы в очередь и повторить относится к синхронизации инвентаря и не распространяется на переживание перезапуска менеджера. Разница между этими двумя утверждениями и есть цена вопроса.

Для эксплуатации отсюда следует конкретное правило, а не общее пожелание быть осторожнее: в этой топологии и в этом сценарии, пока indexer недоступен, менеджер 5.0 перезапускать нельзя. Сначала возвращают indexer, дают потоку разойтись, и только потом обслуживают менеджер. В runbook, унаследованный от 4.x, этот порядок надо вписать явно, потому что раньше он не имел значения.

Заодно упомяну мелочь, которая стоила мне ложного результата. Журнал менеджера в 5.0 называется wazuh-manager.log; файла ossec.log в установке нет. Моя проверка искала старое имя, ничего не находила и бодро сообщала, что ошибок в журнале нет. Любая ваша автоматика, которая читает логи по старому пути, соврет точно так же и так же тихо.

Два пути события рядом, чтобы было видно, где именно переехала граница:

Одна строка лога через оба конвейера

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

На 4.14.7 инструмент wazuh-logtest показывает три фазы. Предварительное разложение достает отметку времени, имя узла и program_name. Декодирование дает декодер sshd с полями srcip и srcuser. Сопоставление дает правило 5710 уровня 5 (шкала уровней 0-16, закреплено на теге v4.14.7) с описанием sshd: Attempt to login using a non-existent user, группами authentication_failed и invalid_login, техниками MITRE T1110.001 и T1021.004 и сопоставлениями с GDPR, GPG13, HIPAA, NIST 800-53, PCI DSS и TSC. В конце инструмент сообщает, что алерт будет создан.

На 5.0 та же строка становится документом из 39 полей. Вот его существенная часть:

{
  "event.action": "authentication-failure",
  "event.category": ["authentication"],
  "event.outcome": "failure",
  "event.kind": "event",
  "source.ip": "203.0.113.77",
  "source.port": 52814,
  "user.name": "...",
  "process.name": "sshd",
  "process.pid": 4321,
  "wazuh.integration.name": "linux",
  "wazuh.integration.category": "system-activity",
  "wazuh.integration.decoders": ["decoder/core-wazuh-message/0", "decoder/syslog/0", "decoder/system-auth/0"],
  "wazuh.space.name": "standard"
}

Здесь видно сразу три вещи. Поля переименованы и легли в общую схему: srcip стал source.ip, srcuser стал user.name, имя и идентификатор процесса выделились отдельно. Декодер перестал быть одним именем и стал цепочкой из трех версионированных ресурсов. И событие уехало в поток wazuh-events-v5-system-activity - маршрутизация по категории интеграции теперь часть конвейера, а не следствие того, какое правило сработало.

В самом документе нет ни номера правила, ни уровня, ни техник MITRE, ни соответствия стандартам. Проверив потоки findings сразу после отправки и увидев ноль, я едва не написал, что вердикта по событию нет вовсе. Это была бы ошибка, и она стоит отдельного абзаца, потому что ловушка тут методическая: в 4.x решение принимается в момент разбора, и проверять результат через секунду - нормально, а в 5.0 detection работает по расписанию, и через секунду там честно пусто.

На деле вердикт появился. Тот же самый SSH-лог через некоторое время дал finding в потоке wazuh-findings-v5-system-activity, и вот чем этот finding отличается от alert из 4.14.7:

Разница не в том, что в 5.0 вердикта нет, а в том, что он приходит позже, отдельным документом, с UUID вместо номера, с категорией вместо числа и с более широким набором соответствия - десять стандартов против шести, включая CMMC, FedRAMP, ISO 27001 и NIS2, которых в alert 4.x не было.

Как устроен этот путь, описано в рабочем процессе детектирования (закреплено на теге, живая страница). Отдельно стоит сказать, кто именно вынес вердикт, потому что моя первая догадка была неверна. Detector не пришлось настраивать: платформа поставляется с 22 detector, из которых 15 включены. Мое событие поймал не специализированный, а универсальный wazuh-generic-1, который смотрит сразу на все семь категорийных потоков. Рядом работает linux, привязанный ровно к wazuh-events-v5-system-activity с интервалом в 2 минуты, но он несет всего шесть готовых правил, и неудачной аутентификации SSH среди них нет. Из шести правил два посвящены загрузке модулей ядра: одно видит запуск insmod, modprobe или kmod через Sysmon for Linux, второе ловит ошибки проверки подписи модуля в syslog. Остальные четыре покрывают реверс-шеллы, запись в authorized_keys, cron/at-персистентность и успешный вход root по паролю.

Вот это и есть настоящая находка для планирования: покрытие стандартным контентом в 5.0 распределено иначе. То, что в 4.14.7 ловит именное правило 5710 с уровнем 5, в 5.0 ловит универсальный detector с уровнем low. Прежде чем считать, что после миграции все на месте, стоит прогнать свой корпус событий и посмотреть, какие из них получают вердикт и с какой серьезностью, а не сверять списки правил.

И два следствия, которые остаются в силе. Событие и finding - разные объекты с разными объемами, ретеншеном и правами, считать их надо раздельно. И между приходом события и вердиктом есть окно, нижнюю границу которого задает расписание detector, а фактическую величину - еще и время выполнения, очередь и поведение при нехватке ресурсов. Распределение этой задержки я не измерял, поэтому про режим, близкий к реальному времени, здесь ничего не утверждается.

Правила не переезжают

Самый дорогой пункт перехода сформулирован в плане перехода (закреплено на теге, живая страница) в одном предложении: перенести пользовательские правила и декодеры 4.x в формате XML в 5.x нельзя, нужный контент создается заново средствами управления контентом. Копирование файлов в установку менеджера тоже не работает - контентом теперь управляет отдельная подсистема.

Рядом лежит изменение, которое легко недооценить, потому что выглядит как переименование поля. rule.level стал wazuh.rule.level, но вместе с именем поменялся тип: было целое число от 0 до 16, стали пять категорий - informational, low, medium, high, critical. Взаимно однозначного отображения семнадцати значений в пять Wazuh не публикует, и придумывать его самостоятельно - плохая идея: от уровня зависят пороги уведомлений, фильтры дашбордов и логика эскалации.

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

Отдельная потеря для тех, кто живет в терминале: инструмента wazuh-logtest в 5.0 нет. Проверить декодер и правило на строке лога прямо на менеджере больше нельзя, эта задача переехала в интерфейс и API. Если ваш процесс разработки правил построен вокруг быстрого цикла в консоли, его придется пересобрать.

Активное реагирование переписывается целиком

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

Все перечисленное ниже взято из руководства по переносу скриптов активного реагирования. Условия срабатывания уезжают из блока <active-response> конфигурации менеджера в monitor типа Active response подсистемы Alerting. Файла ar.conf больше нет: имя скрипта, исполняемый файл, тип и таймаут теперь приходят внутри объекта wazuh.active_response каждого сообщения, и скрипт, работающий с состоянием, читает свой таймаут оттуда же. Значения команды изменились: вместо add и delete приходят enable и disable, так что скрипт, разбирающий это поле, получит незнакомое значение. Что именно он сделает - пропустит действие или завершится ошибкой - зависит от того, как в нем написана обработка неизвестной команды. Сами данные finding приходят не в parameters.alert, а через wazuh.active_response и поля WCS верхнего уровня вроде source.ip, user.name, wazuh.rule.id и file.path.

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

Сам сквозной путь от finding до результата на агенте я не измерял, поэтому про задержки и повторы активного реагирования здесь ничего не утверждаю.

Что реально переносится, а что создается заново

Слово «миграция» скрывает четыре разные операции с разной ценой.

Пользовательские дашборды, визуализации, сохраненные поиски и index patterns экспортируются из 4.x и импортируются в 5.x (перенос dashboard, закреплено на теге). А вот стандартные объекты 4.x импортировать нельзя: они перезапишут стандартные объекты 5.x и притащат несовместимые визуализации. После импорта своих объектов их все равно нужно перенастроить на новые index patterns и поля WCS, так что импорт экономит структуру, но не работу.

Исторические индексы переносятся снапшотом, и здесь есть жесткое условие: исходная установка должна работать на 4.4.0 или новее (перенос indexer, закреплено на теге). Восстановленные индексы сохраняют маппинги 4.x, остаются отдельными от индексов и потоков 5.x, и новые данные Wazuh 5.x в них не пишет. То есть вы получаете два мира схем и два набора запросов, а не единую историю.

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

И, наконец, откат. Понижения версии на месте не существует, но это не значит, что дороги назад нет. Официальный план перехода прямо требует держать работающую установку 4.x до тех пор, пока новая среда не проверена. Откат в этой модели означает вернуть агентов и источники данных на сохраненную 4.14.7, а не откатывать 5.x. Разница практическая: пока вы не погасили старую среду, у вас есть куда вернуться.

Транспорт агента и то, как в парк попадают агенты 4.x

Транспорт в 5.0 переписан, и его контракт лежит прямо в исходниках проверяемой сборки (reference-документ модуля на теге v5.0.0-beta5), что для беты надежнее меняющейся страницы. Агент общается с менеджером по HTTPS на порту 1517: POST /enroll для регистрации, POST /stateless для событий, POST /stateful для инвентаря. Все конечные точки живут под настраиваемым префиксом пути, по умолчанию /wazuh-manager/.

Аутентификация у регистрации и у всего остального разная, и путать их нельзя. /stateless и /stateful агент подписывает персональным bearer-токеном, который формирует своим ключом из client.keys. У /enroll такого ключа быть не может: агент как раз за ним и пришел, записи в client.keys еще нет. Поэтому регистрация аутентифицируется отдельным механизмом уровня слушателя, и именно она остается той точкой, где решается, кого вообще пускать в парк.

На стенде это подтверждается: менеджер отвечает по префиксу, соединение согласует TLS 1.3 с набором TLS_AES_256_GCM_SHA384. Радоваться этому в одиночку не стоит: сертификат менеджера самоподписанный, а агент 5.0 при первом запуске пишет в журнал TLS verification is DISABLED (verify_mode=none). Современный протокол на транспорте есть, проверки подлинности собеседника по умолчанию нет, и это разные вещи. В 4.14.7 в той же секции конфигурации стоит классическая строка шифров OpenSSL и параметр ssl_auto_negotiate, который по умолчанию разрешает только TLS 1.2; в 5.0 этого параметра нет вовсе, а список наборов состоит только из наборов TLS 1.3. Согласование версии само по себе никуда не делось: TLS по-прежнему предполагает выбор общей версии, поддерживаемой обеими сторонами, и TLS 1.3 этого не запрещает. Изменилось то, какие версии Wazuh готов поддержать. На стенде это видно прямо: попытка соединиться с портом 1517 с принудительным TLS 1.2 отвергается с alert protocol version, тогда как порт 1515 на 4.14.7 такое соединение принимает и согласует ECDHE-RSA-AES256-GCM-SHA384. То есть отказ от старого протокола - свойство конфигурации Wazuh, а не самого протокола. Заодно там же включена парольная регистрация: файл общего пароля создается сам, а в 4.14.7 соответствующий переключатель по умолчанию выключен.

Теперь про смешанный парк, и здесь я сам сначала сделал неверный вывод. Механизм описан так: канал AES на порту 1514 поднимается только при наличии блока <legacy> внутри <remote>. Прочитав это, легко решить, что подключение агентов 4.x - осознанное решение оператора. На самом деле наоборот: поставляемый wazuh-manager.conf этот блок уже содержит, причем включенным. На моем стенде менеджер 5.0 одновременно слушает 1514, 1515 и 1517. То есть смешанный парк - состояние по умолчанию, а отдельное решение требуется как раз чтобы его запретить.

Агент 4.14.7 к менеджеру 5.0 действительно подключается, по старому каналу с AES, и получает идентификатор в общем списке рядом с агентом 5.0. Его события доходят: за время наблюдения от него пришли документы rootcheck, SCA и авторизации. А вот состояния за время наблюдения не появилось ни одного документа. Во всех индексах состояния на стенде лежало 1165 документов - файловая целостность, пакеты, пользователи, интерфейсы, порты, - и все они принадлежали агенту 5.0.

Оговорюсь честно: агент 4.x работал у меня около пяти минут, а синхронизация состояния может требовать больше времени, так что это наблюдение за окном, а не доказанная невозможность. Но направление совпадает с руководством по переносу агентов, закрепленным на теге, которое прямо предупреждает о неполной поддержке FIM, SCA, инвентаря, активного реагирования и обнаружения уязвимостей до обновления агента.

Формулировать это лучше словами самой документации: перечисленные модули не поддержаны полностью до обновления агента. На моем стенде за наблюдаемое окно это выглядело как инвентарь без следов хоста на 4.x. «Подключился» и «работает так же» - разные состояния, и смешанный режим годится как переходное окно, а не как место, где живут постоянно.

Что еще исчезло или переехало

Набор исполняемых файлов менеджера сократился с 29 до 16: четырнадцать удалены, один добавлен, десять переименованы, пять сохранили имена. Ушли manage_agents, agent_control, clear_stats, wazuh-agentlessd, wazuh-maild, wazuh-csyslogd, wazuh-integratord, wazuh-regex, wazuh-reportd, wazuh-logtest вместе со своей устаревшей версией, а также wazuh-logcollector, wazuh-syscheckd и wazuh-execd. Добавился wazuh-manager-service-control. Последние три исчезли не потому, что функция пропала, а потому что на менеджере больше нет локального агента: в 4.14.7 сам менеджер числится агентом с идентификатором 000, в 5.0 такой записи нет, и первый зарегистрированный агент получает 001. Десять прежних исполняемых файлов получили префикс wazuh-manager-, и это не только демоны: там же оказались управляющие утилиты wazuh-control и wazuh-keystore. Еще пять файлов вроде agent_groups и cluster_control сохранили прежние имена.

Дальше идет группа переименований, каждое из которых само по себе мелочь, а вместе они ломают любую автоматику, перенесенную без правки. Менеджер переехал из /var/ossec в /var/wazuh-manager, его конфигурация называется wazuh-manager.conf, а корневой элемент в ней - wazuh_config вместо ossec_config. Агент при этом остался в /var/ossec со своим ossec.conf и старыми именами демонов, так что на одном хосте теперь спокойно уживаются две разные схемы именования.

Изменился и слой хранения, и здесь легко обмануться. Корневой запрос к indexer 4.14.7 отвечает номером 7.10.2, но это маскировка: в opensearch.yml включен параметр compatibility.override_main_response_version, который подменяет номер версии в корневом ответе ради старых клиентов (о режиме совместимости). Настоящую версию отдает _nodes, и там 2.19.5, что подтверждается и файлом opensearch-2.19.5.jar в самой установке. В Beta 5 подмена не включена, и обе проверки согласно дают 3.6.0. То есть переход - это OpenSearch 2.19.5 на Lucene 9.12.3 против 3.6.0 на Lucene 10.4.0, смена мажорной версии со своей совместимостью плагинов и синтаксиса запросов. Если вы проверяете версию корневым запросом, вы получите неверный ответ на обеих сторонах сравнения.

Вместо одного шаблона wazuh-alerts-* появился набор потоков: события и findings раздельно, каждый разбит по семи категориям - access-management, applications, cloud-services, network-activity, other, security, system-activity - плюс поток unclassified для того, что не разложилось по категориям, и отдельный поток сырых событий. Рядом живут индексы состояния и служебные потоки метрик. Все старые index patterns, ISM-политики, сохраненные поиски и выгрузки во внешние системы придется пересобрать под эту раскладку.

Состояние беты, которое видно невооруженным глазом

Ставить 5.0 Beta 5 в продуктив никто и не предлагает, но полезно понимать, насколько она готова к серьезному пилоту.

Официальный комплект для Docker в текущем виде не запускается. Файл docker-compose.yml для одноузловой установки монтирует девять файлов сертификатов из каталога config, а ни этого каталога, ни инструмента для создания сертификатов в дереве репозитория нет - ни на теге беты, ни в живой ветке. При этом README того же тега продолжает описывать и генератор сертификатов, и файл README для одноузловой установки, которых там тоже нет. Мне пришлось взять описание узлов и генератор из комплекта 4.14.7 и разложить полученные сертификаты в ту раскладку, которую ждет новый compose. Это рабочий обход, а не процедура, и повторять его в чужой инсталляции я бы не советовал без понимания, что именно вы собираете.

Тут стоит различать две даты. У самой Beta 5 дата публикации есть: 1 сентября 2026 года. Не объявлена дата GA, и признак этого - заголовок release notes версии 5.0.0, который на момент проверки читается как 5.0.0 Release notes - TBD. Живая документация при этом активно правится: за три дня после публикации беты в нее внесли переработанные разделы про менеджер, агента, схему конфигурации агента в руководстве по миграции. Часть страниц из-за этого противоречила друг другу - например, обзор архитектуры утверждал, что legacy-службы включены по умолчанию, а справочник по службам менеджера писал, что канал поднимается только при явном включении блока. Разрешает противоречие поставляемый конфиг, где блок присутствует, но искать эту развязку читателю приходится самому.

Отсюда и правило обращения с источниками, которому следует эта статья: там, где утверждение можно закрепить на теге v5.0.0-beta5, стоит ссылка на закрепленный источник, а живая страница дается рядом как удобный адрес для чтения. Две ссылки остались только живыми, и это не небрежность. Руководства по переносу скриптов активного реагирования на теге не существует вовсе, а файл про indexer connector на теге есть, но предупреждения о буферизации в памяти в нем нет - его добавили позже. То есть два факта, на которых держатся целые разделы, существуют только в изменяемой ветке, и честнее это назвать, чем маскировать закрепленной ссылкой, которая их не содержит.

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

Что действительно стало лучше

Минусы в этом тексте доказаны подробнее плюсов, и это перекос метода: отказы измеряются за минуты, а выигрыш от схемы виден за месяцы. Поэтому назову плюсы прямо, отделив проверенное от заявленного.

Проверено на стенде. Событие получает предсказуемую структуру: те же 39 полей, что раньше пришлось бы вытаскивать из произвольного JSON, теперь лежат на документированных местах ECS, а цепочка декодеров записана в самом документе, так что по любому событию видно, чем именно оно разобрано. Категория интеграции определяет маршрут, поэтому запросы к одному типу источников не требуют знания имен правил. Событие и finding разделены, а значит охоту можно вести по всему потоку, а не только по тому, на что кто-то заранее написал правило. В 4.x полный поток тоже доступен, но отдельной дорогой: нужно включить архивирование и отправку archives.json (журналирование событий, закреплено на теге v4.14.7), иначе не попавшее в alert событие аналитику не видно. Разница в том, что в 5.0 полный поток входит в основную модель, а не требует включать второй конвейер.

Заявлено документацией и мной не измерялось. Строгая проверка схемы отклоняет неправильное поле на этапе активации контента, а не превращает его в тихо мертвую детекцию. Продвижение контента идет по цепочке draft в test в custom, где test проверяется инструментом Log test, а standard остается доступным только для чтения и синхронизируется из CTI (spaces, закреплено на теге). Это нормальный предпродакшн-процесс для детектов, которого в файловой модели 4.x не было вовсе.

Стоит понимать и границу этого выигрыша. Sigma-совместимая форма правил не делает их переносимыми: они по-прежнему опираются на имена полей WCS, расширения Wazuh, категорию интеграции и настроенный detector. Выигрыш в том, что семантика записана в форме, которую понимают и другие инструменты, а не в том, что правило можно унести куда угодно.

Известные проблемы Beta 5 на 7 сентября 2026 года

Это состояние на дату, и его нужно перепроверять: беты живут быстро.

Собственный трекер сквозного тестирования Beta 5 - живой документ, и его состав меняется в течение дня. В сохраненном мной снимке от 7 сентября 2026 года, 12:12 UTC, он содержит 38 наборов: 25 зеленых, 12 красных, один желтый и ни одного без результата (трекер, последняя правка в тот же день в 09:23 UTC). Среди красных - развертывание в Docker, в Kubernetes и через Ansible, обнаружение уязвимостей, IOC, ограничения агента, docker_listener, wodle_command и четыре облачные интеграции. Отметка времени здесь обязательна: за три часа до этого снимка соотношение было другим, и восстановить прежнее состояние по ссылке уже нельзя.

Отдельно стоит открытый дефект, который важнее остальных для того, кто думает про детектирование. При работе службы backpressure в режиме принуждения indexer отменяет поисковые задачи, которыми пользуются мониторы уровня документа, fan-out монитора падает с all shards failed, и документы из этой партии остаются без оценки - без finding и без какого-либо сигнала оператору. В зарегистрированном случае за окно в 1,4 секунды таким образом остались непроверенными 70000 документов (дефект, открыт 2 сентября, обновлен 4 сентября). Переносить это число на любую нагрузку нельзя: оно снято на стенде с кучей 1940 МБ под давлением памяти. Но класс проблемы серьезный, потому что дыра в детектировании здесь молчаливая.

С моим собственным наблюдением это сходится: на стенде с кучей 1 ГБ indexer отвечал менеджеру HTTP 429 с circuit_breaking_exception при попытке прочитать удаленные настройки. Это свойство лабораторного масштаба, а не продукта. И утверждать, что 5.0 чувствительнее к памяти, чем 4.x, я не могу: сравнения потребления под одинаковой нагрузкой я не проводил. Доказано другое, и этого достаточно: память и доступность indexer теперь лежат на критическом пути детектирования, тогда как в 4.x detection в indexer не жил вовсе.

Есть и дефект, объясняющий, почему стенд может выглядеть готовым раньше времени: healthcheck контейнера дашборда считает его здоровым, как только HTTP-сервер отвечает, включая ответ страницей «сервер еще не готов» (дефект). Тот же healthcheck стоит и в одноузловом compose, которым я поднимал стенд.

Три карты, по которым удобно планировать

Ниже три таблицы, собранные из документации и из наблюдений на стендах. Пометка в скобках говорит, откуда взята строка: «измерено» - видел на стенде, «документ» - взято из документации и на стенде не проверялось.

Где выполняется функция

Ломающее изменение, действие и владелец

Старое и новое

Кому что делать сейчас

Что я проверял и чего не проверял

Проверено на стендах: поведение при отказе indexer с перезапуском менеджера и без него на обеих версиях, прогон одной строки лога через оба конвейера, подключение агента 4.14.7 к менеджеру 5.0 и состав его данных, порт и параметры TLS нового транспорта, состав потоков и индексов, инвентарь исполняемых файлов и конфигураций.

Проверено частично и названо частичным: смешанный парк. Я убедился, что агент 4.14.7 подключается к менеджеру 5.0 и что его события доходят, а состояние за короткое окно не появилось. Полной матрицы возможностей - FIM, SCA, обнаружение уязвимостей, активное реагирование и обновление агента по отдельности - я не снимал, и выдавать одно наблюдение за такую матрицу нельзя.

Не проверено и потому не утверждается: задержка от события до finding, поведение активного реагирования от начала до конца, перенос снапшотов 4.x в 5.x, импорт сохраненных объектов дашборда, поведение при недоступности CTI, приватность AI Assistant и сравнение потребления ресурсов под одинаковой нагрузкой. Все это остается открытым и будет отдельной работой.

Итог у меня получается такой. Wazuh 5.0 действительно упрощает состав платформы и дает то, чего в 4.x не хватало: единую схему, правила в Sigma-совместимой форме, управляемый жизненный цикл контента. Слово «переносимые» к этим правилам не подходит: они по-прежнему опираются на имена полей WCS, расширения Wazuh, категорию интеграции и detector. Улучшение в том, что семантика записана в форме, которую понимают и другие инструменты. Но переход с работающей 4.14.7 - это не обновление, а отдельный проект с собственным бэклогом: переписать правила, перенастроить и починить те дашборды, которые оставляете, переучить runbook, обновить автоматику под новые пути и имена, и заранее знать, что при недоступном indexer менеджер трогать нельзя. Решение о сроках стоит принимать не по списку возможностей, а по тому, сколько в вашей установке накоплено собственных детектов, которые придется доказать заново на том же корпусе событий.

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

Смотрите также

• Wazuh + AWS Bedrock: RAG с Titan Embeddings (Часть 3)
• Статический анализ правил Wazuh: эволюция линтера
• Wazuh MCP Server: Claude Desktop + OpenSearch (Часть 2)
• Wazuh + AWS Bedrock: ИИ-аналитика в Docker (Часть 1)
• От Wazuh Ambassador до AWS Community Builder