Nový Wazuh 5.0 je téměř zde!

Wazuh 5.0 posouvá platformu od sběru a vyhodnocování bezpečnostních událostí také k jejich správě a řešení přímo v dashboardu. Právě praktický posun v části Event Management — evidence případu, jeho stav, priorita, komentáře a sledování reakce — považujeme v initMAX za jeden z nejdůležitějších přínosů. Wazuh byl SIEM už před touto verzí; pětka ale rozšiřuje to, co v něm analytik zvládne po nalezení problému. Zkratka SIEM znamená Security Information and Event Management.

Nejdůležitější praktická informace je ale jiná: centrální komponenty Wazuh 4.x se na Wazuh 5.x neupgradují přímo na místě. Přechod znamená čerstvou instalaci nového prostředí vedle původního, ruční přenos či nové nastavení kompatibilní konfigurace a postupné přepojení agentů. Nejde tedy o běžnou aktualizaci balíčků, ale o migrační projekt.

Pozor: historická data z Wazuhu 4.x do nového Wazuhu 5 nepřenesete podporovaným migračním postupem. V novém systému začínáte se sběrem událostí a nálezů od nuly. Pro popisovanou verzi 5.0.0 Beta 5 výrobce neposkytuje podporovaný přenos těchto dat ani přes snapshot/restore či reindex. Viz oficiální omezení migrace.

Stará data tím sama o sobě nezmizí, ale pro jejich dohledávání je nutné zachovat původní indexer a dashboard 4.x jako oddělené prostředí pro čtení. Staré indexy ani potřebné 4.x prostředí proto při přechodu nemažte.

Šest změn, které jsou pro správce a analytiky nejdůležitější

Srovnání vychází z celé řady Wazuh 4.x včetně 4.14.7, nikoli jen z původního vydání 4.0. U známých funkcí rozlišujeme, co pětka skutečně přidává a kde mění jejich implementaci, konfiguraci nebo způsob používání.

• Správa událostí a incidentů přímo ve Wazuhu. Case Management přidává k nálezu stav, prioritu, popis a komentáře. Pro tento základní workflow už není nutné otevírat samostatný ticket v jiném systému.
• HTTPS a důvěra mezi agentem a managerem. Nový transport mění požadavky na konfiguraci obou stran. Serverový certifikát je nutný, ale ověřování protistrany nelze automaticky předpokládat: v Beta 5 má agent bez konfigurace <ssl> výchozí režim none. Bezpečný přechod vyžaduje připravit důvěru a ověřování, případně klientské certifikáty, podle zvoleného režimu.
• Nová instalace bez přenosu historie: v systému 5.x začíná sběr dat od nuly. Podle migračního postupu pro Beta 5 se přenáší kompatibilní konfigurace, nikoli historická indexovaná data. Původní indexer a dashboard 4.x zachovejte pro čtení historie; nové prostředí 5.x vybudujte vedle nich.
• Nové psaní a testování vlastních pravidel. XML dekodéry a pravidla se nepřenesou pouhým přejmenováním souborů. Mění se syntaxe, normalizovaná pole i workflow: YAML dekodér, Sigma kompatibilní pravidlo a oddělené prostory Draft → Test → Custom. Je nutné ověřit parsování i pozitivní a negativní detekční scénář.
• Plánovaný reporting v nové reportovací vrstvě. Plán a notifikace zjednodušují předávání výsledků, ale odkaz na report není totéž co hotové PDF v e-mailové příloze. Samotný PDF/CSV export není novinkou pětky; přestavuje se reportovací workflow a jeho konfigurace. U Beta 5 navíc výrobce uvádí chybu chybějící patičky ve výsledném PDF.
• Manager pracuje jako cluster i s jediným uzlem. Sjednocuje se výchozí provozní model. V initMAX tento přístup používáme dlouhodobě; jeden uzel ovšem sám o sobě nezajišťuje vysokou dostupnost.

Wazuh 5.0 se blíží. Článek popisuje změny ve verzi 5.0.0 Beta 5. Finální vydání může přinést další úpravy; předběžná verze není určena pro produkční nasazení.

S nasazením a přechodem na novou verzi vám pomůžeme od návrhu architektury po ověření vlastních pravidel. Praktické ukázky připravujeme také do našich webinářů.

Proč je Wazuh 5.0 skutečně nová generace

V hlavní alertové cestě Wazuh 4.x manager přijímá data od agentů, dekóduje je, porovnává s pravidly a vytváří alerty. Filebeat následně čte soubor s alerty a posílá dokumenty do indexeru pro zobrazení v dashboardu. Ne všechna data však ve 4.x procházejí Filebeatem: indexer connector už existuje například pro stavová data zranitelností a novějšího inventáře. Pětka zásadně mění právě cestu bezpečnostních událostí a místo, kde se nad nimi vyhodnocují pravidla.

Ve Wazuh 5.0 je tok rozdělen do dvou hlavních analytických vrstev:

• Normalizační engine ve Wazuh manageru přijme surovou událost, vybere správnou integraci a dekodéry, rozparsuje data, převede je do Wazuh Common Schema a případně je obohatí o GeoIP, ASN nebo IOC kontext.
• Detekční engine ve Wazuh indexeru vyhodnotí normalizovaná data pomocí Sigma kompatibilních pravidel a detektorů. Pokud podmínky odpovídají, vytvoří finding – bezpečnostní nález, který v nové architektuře přebírá roli alertu z Wazuh 4.x.

Základní tok tedy vypadá takto:

Rozdělení není jen interní refaktoring. Ovlivňuje formát pravidel, indexy, názvy polí, provozní metriky, retenci dat, vlastní dashboardy i způsob reakce na incident. Skript, který ve 4.x četl alerts.json, dashboard postavený nad wazuh-alerts-* nebo automatizace závislá na číselné hodnotě rule.level se bez úprav do nové architektury nepřenese.

Událost a finding už nejsou totéž

Wazuh 5.0 důsledně odděluje událost od výsledku detekce. Událost je normalizovaný záznam toho, co se ve sledovaném prostředí stalo. Finding vznikne až tehdy, když detektor najde shodu s pravidlem. Jedna událost může projít více aktivními politikami a vytvořit více nálezů, pokud odpovídá více detekčním pravidlům.

Toto rozdělení zlepšuje dohledatelnost. Analytik může pracovat s kompletním normalizovaným proudem událostí, ale současně má oddělenou datovou vrstvu pro bezpečnostní nálezy. Finding obsahuje původní událost, informace o pravidle, závažnost, vazby na MITRE ATT&CK a compliance a případně také data pro správu případu.

Provozní dopad je významný: při hledání v Discoveru nebo při návrhu dashboardu je potřeba vědět, zda chceme procházet všechny události, nebo pouze nálezy. Dotaz nad wazuh-events* odpovídá na jinou otázku než dotaz nad wazuh-findings*.

Co to znamená v praxi

• Týmy získají čistší hranici mezi sběrem a detekcí.
• Pravidla pracují nad normalizovaným schématem místo nad různorodými poli jednotlivých produktů.
• Vlastní integrace, dekodéry a pravidla se spravují jako obsah s řízeným životním cyklem.
• Detekce běží v indexeru, takže návrh a výkon indexerového clusteru budou mít přímý vliv i na rychlost tvorby findings.
• Migrace se musí testovat jako celek – nestačí ověřit pouze spojení agentů s managerem.

Wazuh 5.0 není běžný upgrade balíčků. Pokud potřebujete zjistit, co změna znamená právě pro vaše vlastní dekodéry, pravidla, integrace, retenci a automatizaci, kontaktujte nás. Společně připravíme inventář závislostí a realistický plán přechodu ještě před prvním zásahem do produkce.

Filebeat končí, události posílá nativní indexer-connector

Jednou z nejviditelnějších architektonických změn je odstranění Filebeatu z výchozího toku dat. Wazuh 4.x typicky zapisuje alerty na manageru do JSON souboru a Filebeat je odesílá do indexeru. Wazuh 5.0 používá nativní spojení Wazuh manageru s indexerem prostřednictvím indexer-connector.

Nový tok odstraňuje samostatnou shipper vrstvu a související konfiguraci filebeat.yml, moduly i frontu založenou na čtení alerts.json. Manager zároveň podle dokumentace Wazuh 5.x už alerty z endpointů lokálně neukládá stejným způsobem jako dříve. Normalizované události předává přímo do odpovídajících datových proudů indexeru.

Technická zajímavost: Filebeat v C++? Funkčně je toto přirovnání v oblasti odesílání dat výstižné: Filebeat je napsaný v Go, zatímco nativní indexer-connector je knihovna v C++. Oba řeší dávkování přes Bulk API, frontování, časované odesílání a vyhodnocování položek items v bulk odpovědi. Při HTTP 413 konektor rozdělí dávku nebo sníží její limit podle použitého režimu; dočasné chyby řeší opakováním s prodlužovanou prodlevou. Nejde však o doložený přepis či převzetí kódu Filebeatu ani o shodné garance doručení. Konektor byl součástí už Wazuh 4.x; změnou v pětce je rozšíření jeho role a odstranění samostatného Filebeatu z hlavního toku událostí. Srovnání vychází z implementace a dokumentace konektoru, Go klienta Beats pro Bulk API a konektoru ve Wazuh 4.14.7.

To zjednodušuje počet centrálních komponent, ale mění provozní diagnostiku. Při výpadku dat už administrátor nebude kontrolovat jen stav manageru, velikost alerts.json a Filebeat registry. Bude sledovat:

• dostupnost indexerových uzlů z manageru;
• TLS certifikáty a oprávnění účtu používaného konektorem;
• logy indexer-connector včetně kontextu volajícího modulu;
• stav front a interní watermarks manageru;
• indexovací chyby, mapping konflikty a stav datových proudů v indexeru;
• metriky komunikace a normalizačního enginu na dashboardu.

Beta 5 pro spojení manageru s indexerem definuje služební účet wazuh-manager s omezenou rolí wazuh_manager. Při migraci zkontrolujte účet uložený v manager keystoru a jeho skutečná oprávnění pro nové datové proudy. Přihlašovací údaje administrátora z původní konfigurace není vhodné mechanicky přenášet do běžného sběru dat.

Zdrojový kód ukazuje také provozní rozměry fronty. Výchozí event queue má 131 072 slotů a limit 32 MB, zatímco fronta konektoru do indexeru má 64 MB. Bulk dávka má 8 MB a výchozí flush interval 20 sekund. Orchestrátor samostatně měří zaplnění počtem položek i bajty, počítá zahozené vstupy a po desetiminutové souvislé kontenci nad 90 % zapisuje varování. Tyto hodnoty jsou fallbacky ve zdrojovém tagu, nikoli univerzální sizing; balíček nebo interní konfigurace je mohou přepsat. Pro monitoring jsou podstatné především metriky zaplnění fronty, zahozených událostí a EPS za 1, 5 a 30 minut.

Co se stane s vlastními výstupy

Odstranění Filebeatu neznamená, že Wazuh 5.0 zakazuje integraci s jinými analytickými platformami. Znamená však, že dosavadní konfiguraci nelze automaticky považovat za kompatibilní. Pokud organizace používá upravený Filebeat pipeline, Logstash, vlastní ingest pipeline, kopii alerts.json nebo externí archivaci, musí přesně popsat současný tok a navrhnout jeho nový ekvivalent.

Při návrhu doporučujeme oddělit tři potřeby:

• Provozní data Wazuh 5.0, která zapisuje nativní konektor do nových datových proudů.
• Historická data Wazuh 4.x, pro jejichž dohledávání zůstává původní 4.x prostředí jako oddělený archiv.
• Externí export, například do dlouhodobého archivu, datového jezera nebo dalšího SIEMu, který musí mít vlastní jasně podporovanou cestu.

Wazuh Engine a nový systém Security Analytics

Nová analytická architektura rozděluje práci mezi více komponent. Wazuh Engine v manageru normalizuje a obohacuje události; Security Analytics v indexeru nad nimi vyhodnocuje detekční pravidla. Content Manager spravuje jejich obsah. Nejde tedy o jeden engine přesunutý na jiné místo ani o prosté přepsání původního analysisd. V dashboardu se správa normalizace a detekce soustřeďuje pod Security Analytics.

Bezpečnostní obsah se skládá z několika typů prostředků:

• Integration seskupuje obsah pro konkrétní produkt nebo zdroj logů.
• Decoder rozpozná vstup, rozparsuje jej a namapuje hodnoty do Wazuh Common Schema.
• Rule popisuje detekční podmínky v Sigma kompatibilním YAML formátu.
• Detector propojí pravidla s konkrétním indexem nebo aliasem a spouští jejich vyhodnocování podle plánu.
• KVDB poskytuje seznamy a mapování typu klíč–hodnota pro normalizaci a obohacení.
• Filter rozhoduje, které události projdou do dalších fází pipeline.
• Policy určuje pořadí a chování jednotlivých fází zpracování.

Content Manager: standardní i vlastní obsah na jednom místě

Content Manager je plugin Wazuh indexeru, který udržuje pravidla, dekodéry, integrace, KVDB, filtry a IOC obsah. Stahuje standardní obsah z Wazuh CTI, vystavuje API pro vlastní obsah a synchronizuje změny s managerem, kde běží normalizační část enginu.

Oddělení vlastních pravidel od pravidel výrobce není novinka. Ve 4.x už slouží adresáře etc/rules a etc/decoders pro vlastní obsah, odděleně od dodaného ruleset; správně uložené úpravy proto nemusí upgrade přepsat. Změnou v 5.0 je správa obsahu přes Content Manager a explicitní pracovní cyklus Draft → Test → Custom. Místo přímé editace produkčních XML souborů připravujete nový formát obsahu, ověřujete jeho vazby a řídíte jeho aktivaci.

Content Manager podle současného návrhu pravidelně kontroluje nové verze obsahu. Zároveň umožňuje ruční aktualizaci a instalace indexeru obsahuje snapshoty rulesetu, vulnerability feedu a IOC feedu, aby čerstvě nasazený cluster měl výchozí obsah i bez okamžitého spojení ven.

Co ve skutečnosti probíhá při aktualizaci obsahu

Nejde o prosté přepsání souborů. Výchozí synchronizace Content Manageru běží po 120 sekundách, zatímco IOC a GeoIP obsah se kontrolují po 360 sekundách. Manager nejdřív porovná SHA-256 hash vzdálené politiky s právě nasazenou verzí. Pokud se hash nezměnil, neprovádí žádný reload.

Při změně se obsah stáhne do dočasného namespace, zvaliduje a teprve potom se aktivní route atomicky přepne na novou verzi. Kód obsahuje rollback při chybě importu i při neúspěšném hot-swapu. Synchronizace se navíc vyhne stažení ve chvíli, kdy vzdálený consumer není ve stavu idle, aby nevytvořila snapshot napůl provedené aktualizace.

Obsah lze aktivovat bez restartu celého manageru, ale změna není nutně okamžitá. Samotný hot reload není novinka pětky: analysisd jej pro pravidla, dekodéry a CDB seznamy získal už ve Wazuh 4.13. V 5.0 se mění správa a distribuce obsahu přes Content Manager, jeho validace v oddělených prostorech a přepínání politik normalizačního enginu. Při diagnostice kontrolujte hash, stav consumeru, poslední úspěšnou synchronizaci a skutečně aktivní namespace, nikoli pouze to, že se pravidlo už zobrazuje v dashboardu.

Čtyři spaces: Draft, Test, Custom a Standard

Wazuh 5.0 zavádí čtyři logické prostory:

Vlastní změna prochází cestou Draft → Test → Custom. Content Manager při povýšení zpracuje změny a aktualizuje cílový space. Připravenost normalizačního obsahu je nutné ověřit v enginu; distribuce a aktivace vlastního obsahu nejsou totéž jako zobrazení změny v seznamu. Průběžnou detekci nad uloženými událostmi zajišťuje samostatně nakonfigurovaný detektor. Standardní a vlastní politika zůstávají oddělené, takže lze u každé události identifikovat, zda ji zpracoval standardní nebo vlastní obsah.

Tento workflow je výrazně bezpečnější než přímá editace XML souboru na produkčním manageru. Neodstraňuje ale potřebu verzování a peer review. Doporučujeme vlastní YAML obsah dál uchovávat v Gitu, každou změnu svázat s testovacím logem a do Custom ji povýšit teprve po kontrole očekávaných i negativních scénářů.

Integrace určují vlastnictví a kategorii dat

Integration je nejvyšší organizační jednotka pro související dekodéry, pravidla a pomocný obsah. Každý dekodér patří právě do jedné integrace. Integrace zároveň dostává kategorii, která určuje, do jakého datového proudu se normalizovaná událost zařadí.

Aktuální kategorie jsou:

• access-management pro autentizaci, autorizaci, identity a přístupy;
• applications pro webové servery, databáze, middleware a aplikace;
• cloud-services pro AWS, Azure, GCP a další cloudové služby;
• network-activity pro firewally, proxy, DNS a síťové toky;
• security pro EDR, SIEM feedy, skenery a další bezpečnostní nástroje;
• system-activity pro operační systémy, audit a syslog;
• other pro události, které se nevejdou jinam.
• unclassified pro události, které přijal pouze kořenový dekodér a žádný konkrétní dekodér je nezařadil.

Kategorie se zapisuje do wazuh.integration.category a ovlivňuje routing do datového proudu, například wazuh-events-v5-cloud-services. Nesprávná volba tedy není jen kosmetický problém v seznamu integrací. Promítne se do indexů, detektorů, dashboardů, retence i oprávnění.

Dekodéry přecházejí z XML na YAML a WCS

Ve Wazuh 4.x jsou vlastní dekodéry typicky XML soubory v manageru. Wazuh 5.0 používá YAML assety a malý doménově specifický jazyk. Dekodér má tři hlavní části:

• check ověří, zda má dekodér událost zpracovat;
• parse rozebere vstup pomocí parserových vzorů a odpovídajících parserů; nejde automaticky o regulární výraz;
• normalize namapuje získané hodnoty do polí Wazuh Common Schema.

Na konkrétním SSH logu je dobře vidět, proč nestačí změnit příponu souboru. Standardní dekodér decoder/system-auth/0 převezme výsledek syslog parsování, rozpozná zprávu sshd a nastaví normalizovanou akci. Následující výřez pochází z jeho části normalize; nejde o samostatný importovatelný dekodér:

normalize:
  - check: $_system.auth.ssh.event == Invalid OR $_system.auth.ssh.event == Failed OR $_system.auth.ssh.event == failures OR $_system.auth.ssh.event == fatal OR $_system.auth.ssh.event == exceeded OR $_system.auth.ssh.event == Disconnecting
    map:
      - event.action: authentication-failure
      - event.category: array_append(authentication)
      - event.outcome: failure
      - event.type: array_append(info)

Například SSH zpráva Failed password for invalid user demo-admin from 203.0.113.10 port 51234 ssh2 se standardním dekodérem normalizuje na event.action: authentication-failure, event.outcome: failure, user.name: demo-admin a source.ip: 203.0.113.10. Nad těmito poli pracuje detekční pravidlo. Dočasné pole _system.auth.ssh.event do výsledného dokumentu nepatří — pomocné hodnoty s podtržítkem slouží při dekódování, nikoli jako veřejné schéma události.

Přímý převod starého XML do YAML není pouze syntaktická změna. U každého dekodéru je nutné znovu rozhodnout:

• který vstup skutečně přijímá;
• do jaké integrace a kategorie patří;
• která pole mají WCS ekvivalent;
• co zůstane pouze v event.original;
• zda má událost dostat GeoIP nebo IOC obohacení;
• která pravidla a dashboardy jsou na původních názvech polí závislé.

Log Test ověřuje normalizaci i detekci

Nový Log Test je rozdělený podle skutečného toku dat. Nejdřív ukazuje, jaké dekodéry přijaly nebo odmítly vstup a jak vypadal normalizovaný dokument. Poté lze ověřit pravidla a výslednou detekci. Test pracuje s obsahem v Test, Custom a Standard space, takže před nasazením vidíme nejen syntaktickou validitu, ale také interakci s již aktivním obsahem.

K dobrému testu nepatří pouze jeden vzorový log, který musí projít. Pro každou integraci doporučujeme připravit:

• platné události pro všechny důležité varianty formátu;
• neplatné nebo nesouvisející události, které dekodér přijmout nesmí;
• hraniční hodnoty, chybějící pole a neobvyklé kódování;
• očekávaný normalizovaný JSON;
• očekávaná pravidla a závažnost findings;
• regresní vzorky pro dříve opravené false positive a false negative případy.

Vlastní dekodér a pravidlo: od textového logu k nálezu

Na jednoduchém přihlášení do vlastní aplikace je vidět celý nový postup. Schopnost napsat vlastní dekodér a pravidlo měl už Wazuh 4.x. V pětce se mění syntaxe, normalizovaná pole a práce s obsahem v Draft, Test a Custom; průběžnou detekci navíc propojuje s datovým zdrojem samostatný detektor. Následující ukázka odpovídá rozhraní 5.0.0 Beta 5.

Použijeme dvě zprávy se stejným formátem. První popisuje neúspěšné přihlášení, druhá úspěšné. Obě mají být dohledatelné jako události, ale nález má vzniknout pouze pro result=failure. Jednotlivé neúspěšné přihlášení samo o sobě není důkaz útoku ani detekce brute force.

Sep 10 12:00:00 app01 initmax-auth: user=alice src=192.0.2.10 result=failure
Sep 10 12:00:00 app01 initmax-auth: user=alice src=192.0.2.10 result=success

Příprava integrace a dekodéru v Draft

V Security Analytics → Overview vyberte Draft a v seznamu Integrations otevřete vytvoření integrace. Zadejte název initmax-auth-demo, kategorii access-management, autora a ponechte integraci zapnutou. V Normalization → Decoders vytvořte dekodér přiřazený k této integraci a vložte následující definici:

name: decoder/initmax-auth/0
enabled: true
metadata:
  title: initMAX authentication decoder
  author: initMAX
  description: Parses the user, source IP and result from an example application log.
  references: []
check:
  - event.original: contains(initmax-auth:)
parse|event.original:
  - '<_tmp.header> initmax-auth: user=<user.name> src=<source.ip> result=<event.outcome>'
normalize:
  - map:
      - '@timestamp': get_date()
      - event.kind: event
      - event.category: [authentication]
      - event.action: user-login

check vybírá zprávy obsahující initmax-auth:. Blok parse|event.original používá parserový vzor Logpar s pojmenovanými poli — nejde o regulární výraz ze starého XML dekodéru. Výsledkem jsou user.name, source.ip a event.outcome. Normalizace doplní event.action: user-login a kategorii authentication; pomocné pole _tmp.header se do výsledného dokumentu nepřenáší.

Příklad záměrně předpokládá pevné pořadí polí. Funkce get_date() nastavuje čas zpracování, nikoli čas ze syslog hlavičky. Pro skutečnou aplikaci doplňte zpracování jejího timestampu a variant vstupu; tento krátký dekodér není univerzální parser všech autentizačních logů.

V Overview → Draft → Actions → Edit musí být zapnutá politika space a nastavený kořenový dekodér. Tato samostatná ukázka používá jako Root Decoder decoder/initmax-auth/0. V existující instalaci nepřepisujte její kořenovou politiku tímto příkladem: jde o nastavení společné pro space, ne jen pro jednu položku v seznamu. Nový dekodér je potřeba začlenit do stávajícího stromu a při povyšování zkontrolovat i ostatní změny.

Pravidlo nad normalizovanými poli

V Security Analytics → Detection → Rules ponechte Draft, zvolte vytvoření pravidla, integraci initmax-auth-demo a YAML editor. Níže je vlastní definice; automaticky spravované identifikátory a data vytvoření se mezi instalacemi liší a nejsou součástí detekční podmínky. Pokud editor obsahuje pole id, ponechte identifikátor svého pravidla.

enabled: true
status: experimental
metadata:
  title: initMAX application login failure
  author: initMAX
  description: Detects a failed login to the example application. A single failure is not proof of an attack.
  references: []
logsource:
  product: initmax-auth-demo
detection:
  selection:
    event.action: user-login
    event.outcome: failure
  condition: selection
level: low

Pravidlo nekontroluje původní řetězec result=failure, ale pole vytvořená dekodérem. Musí současně odpovídat akce user-login i výsledek failure. Závažnost low odpovídá jednoduchému nálezu, který může být i běžnou chybou uživatele; pravidlo nepočítá opakované pokusy ani časové okno.

Povýšení do Test a pozitivní i negativní kontrola

V Overview otevřete Actions → Promote pro Draft, prohlédněte celý seznam změn a potvrďte povýšení do Test. Poté v Log Test vyberte Test a integraci initmax-auth-demo. Vkládejte vždy jednu zprávu a kontrolujte nejen normalizovaný dokument, ale také výsledek detekce:

• result=failure: pole se rozparsují a odpovídá jedno pravidlo — initMAX application login failure.
• result=success: pole se rozparsují, ale vlastní pravidlo neodpovídá.
• Zpráva s jiným názvem aplikace: vlastní dekodér ji nepřijme.
• src=not-an-ip: parser neprojde a nevznikne odpovídající nález. Samotná úspěšná odpověď API není důkaz úspěšné normalizace.

Po úspěšné kontrole povyšte změny z Test do Custom. Náhled musí obsahovat právě zamýšlenou politiku, integraci, dekodér a pravidlo. Počkejte na aktivaci vlastního obsahu a zopakujte pozitivní i negativní Log Test v Custom. Výsledek v Log Testu ještě sám o sobě nedokazuje, že běží průběžná detekce nad daty od agentů.

Aktivní detektor a skutečný sběr z agenta

V Security Analytics → Detection → Detectors → Create detector vytvořte detektor s těmito parametry:

• Name: initMAX authentication demo.
• Data source: wazuh-events-v5-access-management — datový proud odpovídající kategorii integrace.
• Space / Integration: Custom / initmax-auth-demo.
• Selected rules: pouze initMAX application login failure.
• Run every: 1 minute. Pro tuto ukázku nejsou nastavené notifikace ani Active Response.

Po vytvoření ověřte stav Active a seznam aktivních pravidel. Na agentovi musí být nastavený běžný sběr aplikačního logu. Pro soubor v této ukázce je to následující blok uvnitř ossec_config v lokálním ossec.conf; při centrální správě patří do příslušné sdílené konfigurace skupiny. Soubor musí existovat a být pro sběrač čitelný. Není nutné kvůli samotné tvorbě dekodéru přepisovat celé nastavení agenta.

<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/initmax-demo.log</location>
</localfile>

Do sledovaného souboru nyní nechte aplikaci zapsat nové zprávy s výsledkem failure a success. Detektor je vyhodnocuje podle svého intervalu, takže nečekejte nález synchronně s odesláním logu. V této ukázce zůstaly v datovém proudu dvě události a vznikl jeden nález pro neúspěšné přihlášení. Nález odkazuje na původní dokument pomocí event.index a event.doc_id a zachovává identitu agenta i event.original. Úspěšné přihlášení vlastní nález nemá.

V Threat Hunting → Findings výsledek omezíte dotazem wazuh.integration.name : "initmax-auth-demo". Pro kontrolu úspěšné zprávy je potřeba prohlédnout také proud událostí, nikoli pouze Findings. Tím se uzavírá celý řetězec: sběr logu → vlastní dekodér → WCS událost → naplánovaný detektor → finding.

Podrobnosti k ovládání jednotlivých částí: normalizace a práce se spaces a pravidla a detektory v dokumentaci Beta 5.

Wazuh Common Schema: nový společný jazyk pro bezpečnostní data

Wazuh Common Schema, zkráceně WCS, je základ nové datové vrstvy. Staví na ECS a ve Wazuh 5.0 se připravuje na ECS 9.1.0. Cílem je, aby stejné informace měly stejné názvy a datové typy bez ohledu na to, zda pocházejí z Windows Event Logu, firewallu, cloudové služby nebo vlastní aplikace.

Příklad je jednoduchý: zdrojová IP adresa nemá být v jednom produktu srcip, v jiném source_address a ve třetím client.ip. Dekodér ji namapuje do standardního pole source.ip. Díky tomu může stejné Sigma pravidlo, vizualizace nebo IOC enrichment pracovat nad více integracemi.

WCS se neomezuje na síťová pole. Obsahuje normalizované oblasti pro událost, proces, soubor, uživatele, hostitele, cloud, DNS, registry, zranitelnosti, compliance i Wazuh metadata. Pro původní log je určené event.original. Jeho zachování však závisí na dekodéru a dalších transformacích; nejde o bezpodmínečnou garanci archivu. Rozdíl mezi běžnou normalizací, raw sběrem a helperem discard_events() popisujeme níže.

Nové názvy polí ovlivní dotazy i dashboardy

Wazuh metadata se přesouvají pod namespace wazuh.*. Některé změny jsou přímočaré, jiné mění i typ hodnoty. Migrační dokumentace uvádí například:

U rule.groups neexistuje univerzální náhrada. Podle účelu filtru se používá například wazuh.integration.name nebo jiná WCS metadata. Závažnost rule.level se navíc mění z čísla 0–16 na slovní úroveň: informational, low, medium, high nebo critical.

Nejnebezpečnější je změna rule.level. Dotaz rule.level >= 10 nemá v 5.x přímý ekvivalent, protože úroveň je kategoriální. Je potřeba přepsat filtry, alertovací podmínky, severity mapování i vlastní vizualizace podle nového modelu.

Datové proudy podle kategorie a účelu

Místo jednoho hlavního index patternu přichází několik rodin datových proudů. Mezi nejdůležitější patří:

• wazuh-events-v5-{category} pro normalizované události;
• wazuh-findings-v5-{category} pro výsledky detekce;
• wazuh-events-raw-v5 pro volitelnou indexaci surových událostí;
• wazuh-active-responses pro požadavky na aktivní reakci;
• wazuh-metrics-* pro telemetrii agentů, komunikace a normalizace;
• wazuh-states-* pro stavová data, například inventář, SCA, FIM a zranitelnosti.

Časové řady používají data streams s index templates a Index State Management politikami. Setup plugin je při startu indexeru vytváří spolu s výchozími rolemi a nastavením. ISM se stará o rollover a odstranění starých dat podle stáří nebo velikosti. Pro indexy vytvářené Wazuh pluginy je připravený výchozí zstd kodek, který má snížit nároky na úložiště za cenu určitého výpočetního overheadu.

Oddělení kategorií umožňuje nastavit jinou retenci nebo oprávnění pro cloudové události, systémovou aktivitu a bezpečnostní nálezy. Současně ale zvyšuje význam dobrého indexového návrhu. Široký pattern wazuh-events* je pohodlný pro průzkum, ale u náročných dashboardů je vhodné dotaz zúžit na skutečně potřebné kategorie.

Výchozí retence ze sestavených index templates

Kontrola hotových JSON artefaktů ve zdrojovém tagu Wazuh Indexer Plugins Beta 5 odhaluje důležitý detail: výchozí retence se mezi proudy výrazně liší.

Rollover má v těchto politikách práh velikosti primárního shardu 20 GB nebo 200 milionů dokumentů; u AI sessions také podmínku stáří jeden den. Jde o podmínky vyhodnocované plánovačem, nikoli o přesný časovač. Akce mají tři pokusy s exponenciálním backoffem začínajícím na jedné minutě.

Tyto hodnoty nejsou TTL jednotlivých událostí. ISM nejdříve dokončuje akce aktuálního stavu a až potom vyhodnocuje přechod do dalšího stavu. Pokud index čeká na objemový rollover, samotné uplynutí jedné hodiny nemusí spustit jeho smazání. Stáří indexu navíc není totéž jako stáří každého dokumentu. Efektivní doba uchování proto závisí na rolloveru, stáří backing indexu, intervalu plánovače a úspěchu akcí. Před produkcí ověřte aktivní politiku i stav přes ISM Explain a nastavte časový rollover a retenční cíle podle požadavků organizace. Krátká podmínka pro events je varování pro forenzní návrh, nikoli důkaz, že všechny logy automaticky zmizí přesně za hodinu. Jak ISM vyhodnocuje akce a přechody.

Stejně zajímavá je struktura mapování. Template pro events obsahuje 2 299 dynamických field šablon a findings 2 345, přesto mají mapping.total_fields.limit nastavený na 1 000. Není to rozpor: konkrétní mapping se vytvoří líně až při prvním použití pole a staticky zůstává jen základní objektová kostra. Tím Wazuh drží široké WCS pod limitem jednoho indexu, ale současně vzniká důvod sledovat skutečný počet použitých polí a zabránit nekontrolované field explosion z vlastních integrací.

Hotové templates dále nastavují jeden primární shard, auto_expand_replicas v rozsahu 0-1, kodek zstd a refresh interval dvě sekundy pro events a findings. To jsou rozumné instalační defaulty, nikoli automaticky správný návrh pro víceuzlový produkční cluster. Počet shardů, replik, refresh interval i ISM se musí odvodit od EPS, velikosti dokumentu, retenčního cíle a požadovaného RPO.

Surové a zahozené události

Archivace vstupních logů ani filtrování nejsou nové schopnosti. Ve 4.x už existují archivy řízené například logall/logall_json a rozpoznávání událostí pomocí parent, prematch, regex a pravidel. V 5.0 se mění jejich zapojení do normalizační pipeline: samostatné filtry mohou rozhodovat před dekódováním i po obohacení a politika řídí také zacházení s událostmi označenými jako discarded.

Pokud událost neprojde pre-filtrem, dekodéry se pro ni vůbec nespustí. Post-filter rozhoduje až po dekódování a obohacení, zda smí pokračovat do výstupů. To není totéž jako rodičovská vazba dekodéru: ta vybírá rozpoznávání vstupu, zatímco filtr omezuje průchod celou danou politikou.

Rozdíl je vidět na vlastní integraci initmax-auth-demo z předchozí ukázky. Dekodér převádí result=failure na event.outcome: failure. Při stejném vstupu a jediném aktivním filtru v dané fázi vychází:

• Pre-filter $event.outcome == failure: zprávu nepustí k dekodéru, protože toto pole před dekódováním ještě neexistuje. Z této vlastní politiky nevznikne normalizovaná událost ani nález.
• Post-filter $event.outcome == failure: po dekódování podmínka platí. Událost se uloží a navazující detektor vytvoří jeden nález podle vlastního pravidla.
• Post-filter $event.outcome == success: dekodér zprávu zpracuje, ale filtr ji nepustí do výstupu. Událost ani nález z této politiky nevzniknou, a to ani při index_discarded_events: true.

Raw sběr je samostatný. Pokud je aktivní engine.index_raw_events, může vstup zůstat v wazuh-events-raw-v5 i při odmítnutí pre-filtrem nebo post-filtrem. Není však automaticky plnotextově prohledávatelný: výchozí šablona raw streamu v Beta 5 ukládá event.original do dokumentu, ale má pro něj index: false a doc_values: false. Záznam proto nejprve omezte podle času, agenta nebo ID události a potom otevřete jeho původní obsah.

index_discarded_events není záchranná síť pro všechny zahozené logy. Hodnota false zastaví po dekódování událost označenou wazuh.space.event_discarded: true; hodnota true jí dovolí pokračovat. Neobchází však pre-filter ani post-filter a nezaručuje přijetí dokumentu indexerem. Rozhodující je pořadí fází normalizační pipeline i platnost výsledného dokumentu.

Úskalí Beta 5: helper discard_events() není pouhé nastavení příznaku. Při index_discarded_events: true odstraní dosavadní pole dokumentu a nastaví discarded. Pokud ho v uvedeném dekodéru použijete na konci normalizace, zmizí i @timestamp a původní log. Následné automatické doplnění údajů o integraci čas neobnoví: indexer takový dokument odmítne kvůli chybějícímu povinnému timestampu. Samotným zapnutím volby proto archiv zahozených událostí nevytvoříte; zachování původního vstupu řeší oddělený raw sběr.

Log Test není potvrzení zápisu ani vzniku nálezu. V Beta 5 může vrátit shodu pravidla i tehdy, když trace ukazuje neúspěšný post-filter nebo zastavení discarded události. Testovací služba vyhodnocuje normalizovaný výstup samostatně; při průběžném sběru se odmítnutý dokument k detektoru nedostane. Kontrolujte proto celý trace a po aktivaci politiky také skutečnou událost a nález v indexeru.

Před zapnutím raw sběru nebo ukládání discarded událostí spočítejte EPS, velikost průměrné zprávy, retenci a dopad na počet shardů. Diagnostická funkce bez omezené retence se může rychle změnit v problém s diskem.

Nejste si jistí sizingem a retencí? Návrh Wazuh 5.0 se musí opřít o skutečné EPS, velikost dokumentů a požadovanou dobu dohledatelnosti. Ozvěte se nám a připravíme kapacitní návrh i bezpečné výchozí politiky pro vaše prostředí.

Nová pravidla: Sigma kompatibilní YAML místo XML

Wazuh 5.0 přesouvá detekční pravidla k Sigma formátu. Pravidlo obsahuje standardní bloky detection a logsource, Wazuh metadata, závažnost a volitelné mapování na MITRE ATT&CK a compliance. Podporované jsou běžné Sigma operátory i Wazuh rozšíření, například dynamické dosazení polí z události do výsledného nálezu.

Detekční podmínka musí odpovídat skutečnému výstupu dekodéru. Následuje zkrácený výřez standardního pravidla pro neúspěšnou autentizaci; plná definice navíc obsahuje mapování na compliance a MITRE ATT&CK:

id: 42532ad3-3951-57ee-a3a3-bc6a1b9e6e72
status: stable
level: low
logsource:
  product: wazuh-generic-1
  service: authentication
metadata:
  title: "Failed authentication attempt - {{user.name}} from {{source.ip}}"
detection:
  selection:
    event.action: authentication-failure
    event.category: authentication
    event.kind: event
  condition: selection

Jde o shodu s jednou událostí, nikoli o důkaz brute-force útoku. Opakování v časovém okně, počet pokusů a vazbu na konkrétní IP nebo účet je nutné vyhodnotit samostatně. I proto má toto standardní pravidlo závažnost low; překlep v hesle sám o sobě není kritický incident.

Konkrétní pole musí existovat ve WCS. Pokud pravidlo odkazuje na neplatné pole, engine ho při validaci odmítne a vrátí strukturovanou chybu. To je důležitý posun proti pravidlům, která se sice načetla, ale nikdy nemohla odpovídat kvůli překlepu nebo jinému názvu pole.

Wazuh implementace podporuje například modifikátory contains, startswith, endswith, cidr, exists, porovnání lt, lte, gt, gte a práci se seznamy. logsource organizuje pravidlo podle produktu, kategorie a služby, ale samotnou shodu určuje blok detection.

Závažnost už není číslo 0 až 16

Pravidla používají slovní úrovně informational, low, medium, high a critical. Je to čitelnější pro analytiky a lépe kompatibilní s novým schématem, ale jde o breaking change pro automatizace založené na numerické hranici.

Pohled initMAX: na slovní úrovně jako interní reprezentaci závažnosti se po zkušenostech se Zabbixem díváme skepticky. Pro výpočty, porovnávání a návazné automatizace nám dává větší smysl číselná hodnota se srozumitelným názvem ve frontendu. Odhadujeme, že se Wazuh může časem k číselné reprezentaci vrátit; jde ale pouze o náš názor a odhad, nikoli o oznámený plán Wazuhu. Současné integrace je nutné navrhovat podle dnes používaných slovních úrovní.

Při migraci nestačí mechanicky prohlásit například všechny staré úrovně 10 až 12 za high. Je vhodné zohlednit účel pravidla, spolehlivost detekce, dostupný kontext a reakci, která na nález navazuje. Stejnou mapu pak musí používat dashboardy, notifikace, SLA a případné napojení na ticketovací systém.

Detektory oddělují pravidlo od datového zdroje

Pravidlo popisuje, co hledáme. Detector určuje, nad jakým indexem nebo aliasem se pravidla vyhodnocují a jak často. Wazuh dodává standardní detektory. Pro vlastní obsah lze vytvořit detektor nad vybraným datovým proudem a sadou pravidel.

Detektory běží v naplánovaných intervalech, takže dokumentace hovoří o detekci v téměř reálném čase, nikoli o synchronní shodě přímo při příjmu logu. Skutečnou latenci ovlivní interval, indexační zpoždění, počet pravidel, objem dat a zatížení indexeru.

Detektor může pracovat buď se Standard, nebo s Custom space; obě sady nelze v jednom detektoru míchat. Aktuální plugin také používá konfigurovatelné limity počtu pravidel na detektor a počtu uživatelských detektorů. Při návrhu větší knihovny proto dává smysl seskupovat pravidla podle logsource a kategorie a měřit čas jednotlivých běhů.

Findings nahrazují alerty

Výsledkem shody je finding. Obsahuje plnou zdrojovou událost a metadata pravidla pod wazuh.rule, například ID, titul, úroveň, stav, MITRE a compliance. Enriched findings se ukládají do wazuh-findings-v5-{category}.

Je důležité rozlišit dva kroky. Security Analytics nejdřív vytvoří interní záznam o shodě a poté ho asynchronně obohatí o zdrojový dokument a pravidlo. Obohacení nemá blokovat primární detekční cestu. Při diagnostice chybějícího detailu je proto nutné kontrolovat nejen samotný detector, ale i následnou enrichment a bulk-indexaci do Wazuh findings streamu.

CTI, GeoIP a IOC enrichment přímo v analytické pipeline

Wazuh CTI slouží jako zdroj vulnerability feedu už od přepracování Vulnerability Detection ve Wazuh 4.8; není to nově připojený katalog zranitelností. V 5.0 se jeho role rozšiřuje na distribuci standardního detekčního obsahu a IOC přes Content Manager v indexeru. Pro správce se mění hlavně cesta aktualizací a obsah, který je nutné synchronizovat do analytické pipeline.

Normalizovaná událost může před uložením projít obohacením. GeoIP vrstva doplní k source.ip nebo destination.ip zemi, region, město, souřadnice, časové pásmo a ASN. IOC vrstva porovná podporovaná pole s feedem známých indikátorů – IP adresami, doménami, URL nebo hashi – a přidá kontext pod wazuh.threat.

Obohacení nevzniká pro každý vstup. U interní nebo dokumentační IP nemusí být země ani reputační kontext k dispozici. V našem SSH scénáři používáme dokumentační adresy, takže jejich přítomnost v nálezu není ukázkou skutečné GeoIP ani IOC shody.

IOC enrichment je augmentace, ne samostatný verdikt. Shoda s feedem přidá kontext, ale událost dál prochází pravidly. Detekce tak může kombinovat reputaci indikátoru s typem aktivity, aktivem, uživatelem a dalšími poli. Pro analytika je současně důležité vidět poskytovatele, první a poslední výskyt a konkrétní pole, které shodu vyvolalo.

Vulnerability Detection používá indexer jako autoritativní zdroj

Agent dál sbírá inventář operačního systému, balíčků a hotfixů a komunikuje s managerem. Ani ve 4.x nepotřeboval kvůli Vulnerability Detection přímý přístup k CTI. Změna v 5.0 je na centrální straně: CVE obsah z CTI spravuje indexer a manager na něj navazuje. Synchronizace rozlišuje první scan, změny inventáře a aktualizace feedu. Internetový přístup jednotlivých endpointů tím není novou podmínkou.

Konkrétní novinkou proti 4.14.7 je zpracování skóre CVSS 4.0: dřívější scanner vybíral mezi CVSS 3.1, 3.0 a 2.0; implementace 5.0 upřednostňuje dostupnou metriku 4.0. Datový model CVE 5 přitom existoval už ve 4.x — pětka ho rozšiřuje o další pole, nezavádí ho od nuly. U vlastních exportů ověřte verzi použitého skóre, vazbu na balíček a změny stavu po aktualizaci inventáře; samotný počet zranitelností změnu nevystihuje.

Active Response se konfiguruje v dashboardu

Spouštění reakcí na agentech existovalo už ve 4.x. Mění se jejich řízení: místo bloků <command> a <active-response> v konfiguraci manageru definujete reakci v Explore → Active Responses a připojíte ji ke spouštěcí podmínce monitoru typu Active Response v Alertingu. Monitor vytvoří požadavek v indexeru, manager z něj připraví úlohu pro agenta a wazuh-execd na cílovém endpointu spustí místní program. Dashboard ani indexer tento program za agenta nevykonává.

Při vytvoření reakce se vybírá:

• název a popis;
• spustitelný soubor a volitelné argumenty;
• umístění – agent, který událost vytvořil (Local), konkrétní ID (Defined agent), nebo všichni agenti (All);
• typ – jednorázový stateless, nebo stateful, u kterého musí skript umět provedení i následné odvolání akce;
• timeout u stateful reakce;
• následně v Alertingu podmínku a trigger, který vybranou reakci vyvolá.

Vytvoření reakce v dashboardu nedistribuuje její skript. Spustitelný soubor musí na cílovém agentovi už existovat v adresáři pro Active Response; jeho nasazení, oprávnění a závislosti dál zajišťuje vaše automatizace nebo správa balíčků. To není podmíněné kopírováním starých XML bloků do manageru 5.x. Vlastní skript navíc musí zpracovat nový JSON kontrakt s metadaty wazuh.active_response a odpovídající pole události.

Vlastní skripty používající JSON kontrakt 4.x vyžadují úpravy. V 5.0 Beta 5 dostanou přes standardní vstup JSON s příkazem enable pro provedení a disable pro odvolání; dříve šlo o add a delete. Údaje čtou z WCS polí, například source.ip, nikoli ze starého parameters.alert.data.srcip. Volitelné argumenty jsou v wazuh.active_response.extra_arguments, ne v argumentech příkazové řádky. Podrobnosti uvádí migrační kontrakt Active Response.

Volba All je stejně riziková jako dříve: chybný skript nebo příliš široká podmínka může zasáhnout celé prostředí. Nejprve proto ověřte detekci monitorem s pouhou notifikací, bez připojené aktivní reakce. Potom vyzkoušejte reakci na konkrétním testovacím agentovi. U stateful akce musí skript správně obsloužit příkazy enable a disable; timeout sám neumí vrátit libovolnou změnu. Ověřte také opakovanou shodu během aktivního zásahu.

U stateful skriptu záleží také na protokolu check_keys: agent vrací continue nebo abort. Pokud skript klíče neodešle, wazuh-execd jej nezařadí do seznamu pro pozdější odvolání. Opakovaný stejný klíč během aktivního zásahu zabrání opětovnému provedení a obnoví začátek timeoutu. Návrat proto neodvozujte pouze od času prvního nálezu. Toto chování řídí lokální daemon agenta.

Co to znamená v praxi

Provozní cesta je nyní definice v dashboardu → trigger v Alertingu → požadavek v indexeru → Task Manager na manageru → HTTPS řídicí kanál agenta → místní wazuh-execd. Musí fungovat všechny tyto části, nejen samotný skript. Běžný e-mailový či webhookový kanál Notifications není podmínkou aktivní reakce: v triggeru jde o samostatnou akci Add active response, odlišnou od Add notification. Podrobnosti ukazuje zapojení Active Response do monitoru.

Stav úlohy delivered není potvrzení úspěšné reakce. Znamená předání agentovi; skript přesto může skončit chybou. Úspěch potvrďte až podle jeho logu, skutečného účinku na endpointu a u stateful akce také následného odvolání.

AI Assistant přichází přímo do Wazuh dashboardu

Wazuh AI Assistant přidává konverzační rozhraní nad daty, která analytik může procházet také pomocí existujících dashboardů a vyhledávání. Novinkou tedy není možnost najít odpojeného agenta nebo zranitelnost, ale zadání dotazu přirozeným jazykem, navazující práce s kontextem a slovní shrnutí výsledků. Odpověď je potřeba ověřit proti zdrojovým dokumentům, například v Discoveru.

Nejde pouze o obecný chat vložený do iframe. Assistant má nástroje pro dotazování nad Wazuh datovými plochami a při odpovědi pracuje s kontextem konkrétního prostředí. Konverzace se ukládají, lze se k nim vracet a pokračovat ve vyšetřování. Aktuální implementace rozšiřuje práci s agentovým inventářem, findings, agregacemi, časovým rozsahem a předáním dotazu do Discoveru.

Assistant nemění zdroj pravdy. Zdrojovým důkazem zůstává dokument v indexeru, jeho timestamp, index, pravidlo a původní událost. Vygenerované vysvětlení je pomůcka pro orientaci, nikoli automaticky potvrzený incident.

AI je volitelná a cloudový model není podmínkou provozu Wazuhu. Při použití externího providera mu asistent předává obsah potřebný pro odpověď — dotaz a kontext získaný jeho nástroji; neznamená to automatický export celého indexeru. Pokud požadujete, aby AI data neopouštěla infrastrukturu, asistenta nepřipojujte k externí službě. Alternativou je vlastní kompatibilní model na interním endpointu; jeho podporu nástrojů, provoz a odchozí komunikaci je nutné ověřit.

Podporovaní poskytovatelé

Vývojová dokumentace uvádí následující typy providerů:

• Wazuh AI Assistant Brain;
• Anthropic;
• OpenAI kompatibilní endpoint, kam mohou patřit služby OpenAI, Gemini, Ollama nebo LM Studio podle kompatibility konkrétního API a modelu.

Formulář Beta 5 nabízí dvě volby: OpenAI-compatible a Anthropic. Wazuh AI Assistant Brain se objevuje ve vývojové dokumentaci, nikoli jako samostatná třetí volba tohoto formuláře. U OpenAI-compatible endpointů záleží na kompatibilitě konkrétního API a modelu, zejména na podpoře volání nástrojů.

Administrátor nastavuje jméno providera, endpoint, model a API klíč. Klíče vyžadují šifrované úložiště. Před produkčním nasazením je nutné ověřit, jaký poskytovatel data zpracovává, v jakém regionu, zda je používá pro trénování a jaká platí retenční politika.

Samotné označení „OpenAI compatible“ neznamená, že každý model poskytne stejné výsledky. Model se musí umět držet nástrojového rozhraní, pracovat s tabulkami a vrátit finální odpověď i po více tool calls. Lokální model může být vhodný pro citlivá data, ale jeho přesnost a hardwarové nároky je potřeba změřit na reálných analytických otázkách.

Privacy mode a field policies

Privacy mode je ve výchozím nastavení Beta 5 vypnutý. Administrátor jej může zapnout jako výchozí, nastavit odlišnou volbu pro jednotlivé providery a zakázat uživatelům změnu v konverzaci. Při zapnutém režimu volba Anonymize nahrazuje hodnoty ve výsledcích nástrojů vratnými pseudonymy, například HOST_1 nebo IP_1. Nejde o nevratnou anonymizaci. Never send má jiný význam: vyloučí dané pole z předávaného výsledku i při vypnutém Privacy mode. Neodstraňuje však automaticky tutéž informaci ze všech ostatních polí a volného textu. Původní data v indexeru ani místní tabulka výsledků se tím nemění.

Pozor na ručně vložené údaje. Zapnutý Privacy mode rozpoznává například IP adresy a plné doménové názvy. Krátký hostname demo-node07 nebo uživatelské jméno, které uživatel napíše poprvé a pro které ještě neexistuje mapování, ale může odejít beze změny. Dříve známé identifikátory lze nahradit i v dalších dotazech. Při přepnutí ochrany do zapnutého stavu se z předávané historie vynechávají dřívější nechráněné výsledky nástrojů a odpovědi asistenta; uživatelské dotazy se zachovávají a procházejí textovou kontrolou. Nejde tedy o univerzální filtr citlivých informací. Viz pravidla ochrany polí a zpracování zpráv pro providera.

Toto je zásadní bezpečnostní kontrola, ne jen uživatelská volba. Findings mohou obsahovat uživatelská jména, hostname, IP adresy, názvy procesů, cesty, příkazové řádky, cloudová ID, e-mailové adresy i původní log v event.original. Pokud organizace používá externí model, musí definovat minimální sadu polí potřebnou pro každý analytický scénář.

Doporučený postup:

• Začít s privacy mode vynuceným pro všechny uživatele.
• Zakázat odesílání event.original, secrets, tokenů, command line a volného textu, pokud nejsou pro dotaz nezbytné.
• Pseudonymizovat identity agentů, hostname, uživatele a interní adresy.
• Otestovat pseudonymizaci a její omezení také v historii konverzace a v opakovaných dotazech.
• V logu nebo síťové inspekci ověřit skutečný payload odesílaný providerovi.
• Nastavit retenci historie konverzací a zvlášť ověřit ISM politiku backing indexů. Hodnota 0 podle současné dokumentace vypíná aplikační časový limit, ale výchozí ISM artefakt v Beta 5 současně obsahuje sedmidenní podmínku stáří indexu pro přechod do delete po rolloveru. Efektivní retenci proto určuje kombinace obou vrstev a skutečný průběh ISM.

Co AI Assistant dělat nemá

Assistant by neměl bez lidského potvrzení klasifikovat incident jako uzavřený, měnit důkazní data ani spouštět Active Response. Užitečná odpověď musí být reprodukovatelná: analytik má mít možnost otevřít odpovídající dokumenty v Discoveru a zkontrolovat časový rozsah, filtry a počet výsledků.

Pro přijetí do produkce doporučujeme vytvořit evaluační sadu. Obsahuje otázky se známou odpovědí, testy prázdného výsledku, pokusy o přístup k nepovoleným agentům, citlivá pole, prompt injection uložený v logu a dotazy vyžadující úplný seznam. Hodnotí se nejen jazyk odpovědi, ale hlavně správnost filtrů, úplnost, RBAC a to, zda assistant bezpečně zachází s nedůvěryhodným textem uvnitř událostí.

Case Management: triage findings bez externího ticketu

Wazuh 5.0 přidává k findings základní správu případů. Nález lze opatřit objektem wazuh.case a vést přes analytický workflow přímo v indexovaných datech. Podporována jsou pole:

• titul a podrobný popis;
• stav, například active, acknowledged nebo completed;
• severity a priorita;
• TLP klasifikace TLP:RED, TLP:AMBER, TLP:GREEN nebo TLP:CLEAR;
• tagy;
• komentáře s autorem a časem vytvoření či úpravy;
• uživatel a čas poslední změny.

Case Management nevytváří oddělenou kopii události. Rozšiřuje konkrétní finding o triage metadata. Analytik tak může z detailu nálezu založit případ, popsat vyšetřování, změnit stav a přidat komentáře. Pro API existuje bulk update endpoint s konfigurovatelným limitem počtu findings v jedné operaci.

Identita analytika a napojení na AD

Pole User není přidělený řešitel. V Beta 5 obsahuje wazuh.case.user.name jméno analytika, který případ naposledy změnil; při další úpravě se přepíše. Autor každého komentáře se eviduje zvlášť. Rozhraní dovoluje nejvýše 20 komentářů; jednotlivý komentář může upravit nebo odstranit jen jeho původní autor. Nejde však o neměnný auditní záznam. Samostatná akce vyčištění případu může při odpovídajících oprávněních odstranit všechna jeho metadata včetně komentářů ostatních autorů; původní finding zůstává zachovaný. Práva ke čtení, úpravám a vyčištění proto nastavujte odděleně podle potřeb týmu. Jde o chování dashboardové cesty správy případů, nikoli o samostatný systém přiřazování úkolů.

Identitu dashboard získává z account API přihlášeného uživatele, ne výběrem ze seznamu lokálních účtů. Case Management ale nesynchronizuje adresář AD ani nenabízí přiřazení případu libovolnému kolegovi z IDM. U přihlášení přes LDAP/AD či SSO je nutné ověřit jméno vracené autentizační vrstvou a mapování rolí pro čtení a změny findings. Samotné úspěšné přihlášení tato oprávnění nepotvrzuje.

Severity a priorita řeší dvě odlišné věci

Severity popisuje závažnost bezpečnostního problému. Priorita určuje, jak rychle se jím má tým zabývat. Kritický nález na izolovaném laboratorním stroji může mít nižší provozní prioritu než high nález na produkčním identity serveru. TLP naopak určuje pravidla sdílení informace.

Dobře navržený proces proto nemá kopírovat stejnou hodnotu do všech tří polí. Měl by zohlednit kritičnost aktiva, spolehlivost detekce, dopad, dostupný exploit, rozsah a to, zda jde o probíhající aktivitu.

Vestavěný workflow a stávající integrace

Základní evidenci a postup řešení nálezu nyní zvládne přímo Wazuh. Kvůli stavu, prioritě, popisu nebo komentářům už nemusíte nejprve zakládat ticket jinde. Stávající napojení na Jira, ServiceNow nebo jiný nástroj lze dál využívat podle vašich procesů; není však podmínkou použití nového Case Managementu. To je podstatný posun ve správě bezpečnostních událostí a jejich řešení přímo v platformě.

Incident Response: viditelnost nad provedenými zásahy

Incident Response soustřeďuje přehled vyvolaných aktivních reakcí: jejich název, program, typ, cílení a vazbu na původní nález. Nové workflow využívá záznamy wazuh-active-responses*. Záznam požadavku ale není automatickým potvrzením úspěšné změny na endpointu. Logy Active Response existovaly už ve 4.x; změnou je jejich nové řídicí workflow a přehled v dashboardu, nikoli první možnost reakci dohledat.

To uzavírá důležitou provozní smyčku:

událost → finding → rozhodnutí/monitor → Active Response → výsledek zásahu

Poslední krok je potřeba doložit na agentovi: přijetí a spuštění v ossec.log, výsledek v logu konkrétního skriptu a skutečný účinek na systému. Vestavěné skripty obvykle zapisují do active-responses.log, vlastní skript může používat jiný cíl. U stateful reakce ověřte také návrat po timeoutu. Dashboard sám tento důkaz nenahrazuje; stejné rozlišení popisuje dokumentace sledování reakcí.

Je vhodné sledovat alespoň poměr úspěšných a neúspěšných akcí, dobu do provedení, nejčastější spouštěcí pravidla, endpointy s opakovanými zásahy a stateful reakce, u kterých chybí potvrzený revert.

Alerting a Notifications se stávají centrální součástí platformy

Wazuh 5.0 staví upozornění a reakce na Wazuh variantách OpenSearch Alerting a Notifications pluginů. Monitor prohledává vybraný datový proud, vyhodnotí podmínku a spustí akci. Notification channel určuje, kam se výsledek odešle.

E-mail, Teams, Slack ani webhooky nejsou samy o sobě novinkami 5.0. Mění se jejich zapojení: monitor v Alertingu vyhodnotí data a akci naváže na kanál Notifications, místo aby se bez úprav přenesla stará konfigurace e-mailového daemonu nebo Integratoru. Při migraci je proto potřeba znovu nastavit a otestovat podmínku, cílový kanál a oprávnění, ne jen ověřit, že se v menu nachází název používané služby.

Praktický monitor může každou minutu kontrolovat wazuh-events-v5-system-activity, filtrovat event.action: authentication-failure a při překročení prahu pro konkrétní zdrojovou IP odeslat e-mail nebo zprávu do Teams. Počítáním původních událostí se vyhneme násobení pokusů, pokud nad jedním eventem vznikne více findings. Název normalizované akce ověřte proti používanému dekodéru. Standardní SSH dekodér používá authentication-failure.

Notifikace nejsou Active Response

Alerting monitor může odeslat informaci člověku nebo vytvořit požadavek pro Active Response. Notifikace přímo nemění stav endpointu, přesto může nesprávnému příjemci zpřístupnit citlivá data nebo zahltit obsluhu. Automatické blokování adresy či deaktivace účtu navíc může způsobit výpadek. Podmínky, příjemce i rozsah zásahu proto ověřujte odděleně.

Proto doporučujeme jeden detekční scénář zavádět ve třech fázích:

• pouze dashboard a měření false positives;
• notifikace s lidským potvrzením;
• automatická reakce s omezeným rozsahem, timeoutem a rollbackem.

Reporting: PDF a CSV z dashboardů a uložených hledání

Automatizovaný reporting je důležitý pro pravidelné předávání výsledků: definice reportu určuje datový zdroj, formát a plán generování, případně doručení podle použitého typu reportu a konfigurace. Samotný PDF/CSV export a plugin OpenSearch Reporting však existovaly už ve 4.x. Ve Wazuh 5.0 se odstraňuje původní vlastní generátor reportů uvnitř Wazuh pluginu a reportovací workflow přebírá Wazuh varianta OpenSearch Reporting. Nová je tedy změna používané reportovací vrstvy a její migrace, ne první možnost získat PDF.

Naplánovaný report není automaticky PDF příloha. U dashboardů a vizualizací v Beta 5 vzniká záznam reportu s vybraným časovým rozsahem; e-mailová notifikace může obsahovat odkaz vložený pomocí {{reportLink}}. Vizuální PDF se poté vykresluje a stahuje v prohlížeči uživatele. Záznam se stavem Success či Shared proto sám neprokazuje existenci uloženého PDF ani jeho úspěšné doručení. Pokud zákazník potřebuje bezobslužné ukládání hotových PDF nebo jejich odesílání v příloze, tento konkrétní proces je nutné řešit a ověřit zvlášť. Viz postup doručení odkazu a generátor vizuálního reportu.

Staré PDF soubory si ponechte jako archiv: nová reportovací vrstva je automaticky neimportuje. Nepřenáší se ani původní konfigurace brandingu. Hlavičku a případné logo nastavujte v definici konkrétního reportu přes Explore → Reporting → Create → Report definition → Add header, nikoli jen změnou loga samotného dashboardu.

Známá chyba v Beta 5: patička se do PDF nevygeneruje. Volba Add footer je v rozhraní dostupná, ale dokumentace výrobce výslovně upozorňuje, že výsledný report patičku neobsahuje. Zákazníkovi proto nelze slíbit převzetí původního vzhledu bez kontroly vygenerovaného PDF.

Ukázka ke stažení: PDF report Active Response s logem initMAX (666 kB). Nativní export z Wazuh 5.0.0 Beta 5 obsahuje pouze demo události a testovací endpointy, žádná zákaznická data. Hlavička uvádí časové období i časové pásmo; chybějící patička odpovídá výše popsanému omezení této beta verze.

Při validaci reportu kontrolujte nejen vzhled, ale i rozsah zpřístupněných dat, časové pásmo, time range, maximální počet CSV řádků a dostupnost e-mailového kanálu. Samostatně ověřte právo vytvořit definici, spustit report a přečíst zdrojová data při otevření odkazu. Funkční pohled administrátora neprokazuje, že příjemce uvidí stejná data nebo že soubor vznikne bez jeho přihlášení.

Nový dashboard, navigace a health checks

Wazuh dashboard 5.x je postavený na OpenSearch Dashboards 3.x a jako výchozí používá novou generaci tématu v9. Domovská stránka sjednocuje přehled endpointů, bezpečnostních nálezů, zranitelností a stavu centrálních komponent. Navigace je seskupena podle činností analytika místo historického rozdělení jednotlivých pluginů.

Mezi viditelné změny patří:

• Security Analytics pro normalizaci, pravidla, detektory a Log Test;
• AI Assistant v horní liště a Active Response pod Explore;
• Case Management a Incident Response;
• samostatné patterns pro events, findings, FIM, SCA, vulnerability a metriky;
• přepracovaný Health Check pro API, indexer, pluginy, certifikáty a výchozí monitory;
• centralizovaná aplikace Regulatory Compliance;
• nový přehled statistik pro komunikaci a normalizační engine;
• konfigurace indexeru dostupná z rozhraní podle oprávnění.

Compliance na jednom místě

Dashboard sjednocuje PCI DSS, GDPR, HIPAA, NIST 800-53 a TSC do jedné aplikace Regulatory Compliance. Release notes dále uvádějí nové moduly pro CMMC, FedRAMP, ISO 27001, NIS2 a NIST 800-171.

Dashboard není důkazem splnění regulace sám o sobě. Zobrazuje findings mapované pravidly na konkrétní požadavky. Pro audit je nutné prokázat rozsah agentů, pokrytí zdrojů, správnost vlastních pravidel, retenci, řízení přístupu a postup nápravy. Nové centralizované zobrazení ale zjednodušuje průřezovou kontrolu a porovnání stejného nálezu proti více rámcům.

Odstraněné aplikace a změněné názvy

Původní samostatné aplikace Rules, Decoders, CDB List a Ruleset Test nahrazuje nové workflow Security Analytics a Content Manageru. Odstraněný je také původní generátor reportů uvnitř Wazuh aplikace, nikoli možnost reportovat přes OpenSearch Reporting. Mění se staré obrazovky Statistics, Cluster a App Settings a mizí původní dashboardové moduly CIS-CAT a Osquery; odstranění obrazovky samo o sobě není důkazem odstranění každé možnosti sběru daných dat.

Z pohledu uživatele je důležité, že položka, která „zmizela z menu“, nemusí být zrušená bez náhrady. Často se přesunula do nového workflow nebo nyní čte data přímo z indexeru. Před migrací rolí a interní dokumentace proto projděte každou používanou obrazovku a určete její nový ekvivalent.

Wazuh agent: lokální stav, nový synchronizační model a vyšší limity

Wazuh 5.0 odstraňuje závislost stavových modulů na interní knihovně RSync a mění způsob uchovávání jejich pracovního stavu na agentovi. Lokální databáze existovaly už ve 4.x; novinkou je přepracovaná perzistence a synchronizace. FIM, Security Configuration Assessment a systémový inventář mají zachovávat pracovní stav také mezi restarty agenta. Nejde o odstranění linuxového programu rsync, ale interní knihovny Wazuhu, o jejíž přítomnosti správce často ani nevěděl.

Prakticky jde o zachování výchozího stavu pro další porovnávání změn, ne pouze o jeho uložení na centrálním serveru. Agent předává stav a změny přes manager do stavových indexů; nový protokol řeší verze dokumentů a obnovu konzistence. Perzistence však neznamená, že po restartu nikdy neproběhne nový scan nebo úplná synchronizace. U FIM je to konkrétní migrační změna: v Beta 5 se kontrola spouští při každém startu agenta a volba scan_on_start uvnitř syscheck už není platná. Ze staré konfigurace ji odstraňte; nepřenášejte toto omezení automaticky na SCA nebo Syscollector, které mají vlastní nastavení. Viz změny konfigurace agenta při migraci. Změnu popisuje návrh perzistence stavů a nový synchronizační model. Dopad na síť a zátěž závisí na konkrétním inventáři a četnosti změn.

Mezi další potvrzené změny patří:

• výchozí limit synchronizace FIM <synchronization><max_eps> roste z 10 zpráv/s ve 4.14.7 na 75 v Beta 5. Samostatný limit běžných FIM událostí <max_eps> zůstává 50; vyšší synchronizační limit tedy není příslibem vyšší celkové kapacity nasazení;
• konzistentnější první čtení souboru při rotaci logů;
• ve zdrojovém tagu 5.0.0-beta5 odesílá Windows Event Channel z agenta XML z EvtRender(), zatímco 4.14.7 sestavuje JSON; výsledný normalizovaný dokument v indexeru je nadále JSON. Vlastní dekodéry a pravidla nad Windows Event Viewerem proto znovu ověřte proti novému vstupu a normalizovaným polím.
• agent-start a buffer-status události používají JSON odpovídající WCS;
• zjednodušený rootcheck bez serverové databáze a starého sync/API povrchu;
• redukce zastaralých binárek a modulů;

Podpora distribuce není jedna společná funkce

MSI ani balíčky ARM64 WPK nejsou novinkou 5.0. Stejně tak nelze za novou platformu označit AlmaLinux: jeho podpora ve Vulnerability Detectoru přibyla už ve 4.6. Release notes 4.13 už uvádějí také rozpoznání AlmaLinuxu a Rocky Linuxu v upgrade modulu. Konkrétně jde o automatický výběr typu RPM při vzdáleném upgradu, ne o první možnost na těchto systémech agenta provozovat.

Pro přechod na 5.0 proto rozlišujte dostupnost instalačního balíčku, vzdálený upgrade, SCA politiky a pokrytí zranitelností. Jedno nepotvrzuje druhé. Matice Beta 5 je podkladem pro kontrolu konkrétního systému a architektury; samotná položka v instalační nabídce není důkazem funkčnosti všech těchto cest.

HTTPS komunikace a komprese

Wazuh 5.0 přináší novou HTTPS komunikační cestu mezi agentem a managerem včetně HTTPS enrollment endpointu. Současně zapíná na agentovi ve výchozím stavu kompresi zstd. Jde o provozně významnou změnu, jejíž finální podobu a výchozí nastavení je nutné při vydání znovu ověřit v dokumentaci.

Novinkou není samotná kontrola certifikátů ani existence firewallu, ale změna komunikační cesty. Agent 5.x používá HTTPS listener manageru, standardně na TCP 1517; zachovaný kanál 1514 slouží starším agentům 4.x. Ověření původní registrace proto samo nepotvrzuje, že agent po upgradu dosáhne na nový endpoint. Pokud před managerem skutečně provozujete vlastní reverse proxy nebo load balancer, zkontrolujte také směrování a identitu protistrany. Nejde o vestavěnou proxy Wazuhu ani o povinnou součást nasazení.

Do produkčního návrhu nepatří předpoklad, že „HTTPS“ automaticky vyřeší správu důvěry. Je potřeba stanovit vlastní CA, životní cyklus certifikátů, povolené šifry, rotaci a monitoring expirovaných certifikátů.

HTTPS není automaticky ověřená identita protistrany. Ve zdrojovém tagu v5.0.0-beta5 nastavuje agent při chybějícím bloku <agent><ssl> režim AGENT_VERIFY_NONE. Režim full ověřuje certifikační řetězec i hostname; potřebuje odpovídající důvěryhodnou CA a serverový certifikát. Hodnota system používá systémové úložiště důvěry. Rozdíl je vidět přímo v inicializaci agenta.

Na manageru je serverový certifikát povinný; balíček při instalaci vytvoří self-signed pár, pokud chybí. To ale nepředstavuje automatickou distribuci důvěry agentům. Ověřování klientského certifikátu řídí samostatně <remote><https><verification_mode>: referenční výchozí hodnota je none, při explicitním nastavení CA bez režimu se přepne na certificate. Požadavek na klientské certifikáty tedy nepřisuzujeme automaticky každé instalaci.

Dopad migrace: připravte konfiguraci serveru a důvěru na agentech před přepojením. Pokud vyžadujete vzájemné TLS, doplňte také klientské certifikáty a klíče. Samotné zachování ID, enrollment heslo ani vzdálená výměna balíčku tento krok neřeší; vypínání ověřování není doporučená náhrada.

Enrollment je chráněný sdíleným heslem

Dodaná konfigurace manageru nastavuje <auth><use_password>yes</use_password></auth>. Po registrujícím se agentovi tedy ve výchozí instalaci vyžaduje sdílené heslo. Parser má při vynechání této volby jiný fallback (no); výchozí instalaci a chování neúplné vlastní konfigurace proto nelze zaměňovat. Ochrana heslem sama o sobě existovala už ve 4.x.

Slabým místem zůstává uložení hesla v čitelném textu v /var/wazuh-manager/etc/authd.pass, nikoli v manager keystoru. Při tomto způsobu nasazení ho agent čte z /var/ossec/etc/authd.pass. Práva souboru omezují přístup, ale jeho obsah nešifrují. Kdo získá oprávnění soubor číst, získá i společné enrollment tajemství. Ochránit je potřeba také jeho zálohy a distribuci; samotný přesun do keystoru by nenahradil řízení přístupu.

Heslo patří masteru a distribuuje se workerům. Je-li ochrana zapnutá a soubor chybí či je neplatný, HTTPS enrollment nesmí přejít do nechráněného režimu. Heslo ovšem není povinné ve všech možných konfiguracích: HTTPS listener podporuje také ověřování klientským certifikátem. Kontrola certifikátu a požadavek na heslo jsou nezávislé; bez obou ochran by registrace zůstala otevřená. Tento článek nedoporučuje ochrany vypínat.

Cluster je výchozí i pro jediný manager

Tuto změnu vítáme: v initMAX používáme clusterové uspořádání i pro jedno managerové nasazení už dlouhodobě. Pětka tím sjednocuje provozní model jednoho i více uzlů. Jednouzlový cluster však sám o sobě neposkytuje vysokou dostupnost.

Každá instalace Wazuh serveru 5.0 běží jako cluster node. Odpadá rozlišení mezi klasickým standalone managerem a clusterovou instalací a volba cluster.disabled byla odstraněna. Jednouzlový systém je z pohledu management API a konfigurace stále cluster s jediným uzlem.

To sjednocuje kódové cesty a administraci, ale mění názvy API oprávnění, obrazovky dashboardu a očekávání automatizačních skriptů. Staré volání /manager/... může mít nový ekvivalent pod /cluster/{node_id}/.... Dashboard proto také odstranil část manager-specific logiky a používá clusterové akce.

Instalátor generuje náhodný cluster key pro nové nasazení. Při více manager uzlech musí být klíč bezpečně distribuován a uzly musí mít unikátní jména. U jednouzlové instalace má smysl clusterové metriky stále monitorovat; stejný provozní model se použije při případném rozšíření na více uzlů.

Bezpečnostní změny a princip minimálních oprávnění

RBAC, certifikáty ani zabezpečený enrollment nejsou novinkami pětky. Mění se konkrétní výchozí hodnoty a oprávnění pro nové komponenty:

• pro spojení manageru s indexerem definuje Beta 5 služební účet wazuh-manager s rolí wazuh_manager. Jeho oprávnění odpovídají novým datovým proudům a stavovým indexům; nejde o důvod používat pro běžný sběr administrátorský účet. Viz přehled účtů a rolí;
• vznikají předdefinované role odpovídající Content Manageru, Security Analytics, Alertingu, Notifications a Reportingu;
• API role mappings počítají s rolemi wazuh-admin, wazuh-readonly a wazuh-demo;
• cluster key je náhodný;
• dodaná výchozí konfigurace zapíná heslo pro enrollment;
• dashboard podporuje klientské certifikáty a kontrolu CA při spojení s manager API;
• část starých API a CLI nástrojů s širokým přístupem byla odstraněna;

U migrace bezpečnostních rolí je důležité nevycházet pouze ze souborů na disku. Efektivní konfigurace security pluginu je uložená v security indexu a soubory mohou být starší. Před migrací je nutné aktivní konfiguraci exportovat, zkontrolovat uživatele, role, role mappings a authentication domains a poté vytvořit jejich 5.x variantu.

Spuštění indexer-security-init.sh může obsah adresáře /etc/wazuh-indexer/opensearch-security/ nahrát do security indexu a přepsat změny provedené dříve přes dashboard nebo API. Tento krok proto patří do řízeného change postupu se zálohou a kontrolou diffu.

Odstraněné komponenty a kompatibilita

Odstranění komponenty je potřeba odlišit od přejmenování a změny její role. Manager 5.0 už neinstaluje původní wazuh-agentlessd a wazuh-maild. Autentizační a databázová služba ale nezmizely: Beta 5 obsahuje wazuh-manager-authd a wazuh-manager-db. Také manage_agents nelze označit za plošně odstraněný — instalační větev pro agenta ho stále obsahuje, zatímco manager používá nové nástroje a API. Samostatný agent-auth se již touto cestou neinstaluje. Rozdíl ukazuje instalační kód manageru a agenta.

Odstranění názvu neznamená vždy odstranění celé schopnosti. Enrollment například pokračuje novou manager službou a API, notifikace řeší Notifications plugin a detekční obsah Content Manager. Na druhou stranu agentless monitoring nebo vlastní integrace navázaná na zrušený daemon může vyžadovat úplně nový návrh.

Před migrací doporučujeme vytvořit inventář všech vazeb na Wazuh:

• soubory a adresáře pod /var/ossec;
• API endpointy volané automatizací;
• CLI příkazy v Ansible, skriptech a runboocích;
• vlastní rules, decoders, CDB lists a integrations;
• Filebeat a Logstash konfiguraci;
• alert e-maily z wazuh-maild;
• Active Response skripty;
• vlastní dashboardy, reporty a index patterns;
• účty, role a napojení LDAP/SAML/OIDC;
• systémy čtoucí alerts.json nebo staré indexy.

Tento seznam je inventář závislostí, nikoli seznam dat určených ke smazání. Staré indexy ani snapshoty při přechodu nemažte. Historické dokumenty se automaticky nepřevádějí na nové WCS events a findings; jejich čitelnost, retenci a možnost návratu ověřujte odděleně od nového toku dat.

Chcete vědět, jestli je vaše prostředí na Wazuh 5.0 připravené? Nabízíme technické posouzení současného Wazuh 4.x, mapu nekompatibilit a návrh pilotu i rollbacku. Domluvte si konzultaci. Samostatný praktický článek a webinář k migraci z 4.x na 5.0 právě připravujeme.

Minimální platforma a hardwarové nároky

Modelové tabulky kapacity nepřenášejte mechanicky mezi 4.x a 5.x. Nově se ukládají normalizované events a findings odděleně a datový objem ovlivní typ logů, audit policy, raw stream, discarded events, repliky, počet shardů i komprese. Započítejte také stavové indexy, CTI obsah, prostor pro snapshoty a rezervu pro obnovu. Rozhodující je měření vlastního reprezentativního pilotu, nikoli počet agentů sám o sobě.

Jak sizing ověřit

Nejpřesnější je změřit současnou instalaci:

• průměrné a špičkové EPS po jednotlivých zdrojích;
• denní přírůstek primárních dat bez replik;
• poměr events ku findings;
• velikost state indices a CTI obsahu;
• dobu detektorů při reálném počtu pravidel;
• heap pressure, CPU, fronty a indexační latenci;
• požadovanou retenci a recovery time po obnově snapshotu.

Na základě výsledku lze rozhodnout, zda má smysl all-in-one, oddělený indexer, nebo plně distribuované clustery.

Migrace z Wazuh 4.x na 5.x: nový systém vedle starého

Nejdůležitější breaking change celé verze je migrační model. Oficiální návrh říká: udržte původní Wazuh 4.x v provozu, nasaďte nové Wazuh 5.x prostředí a migrujte nebo znovu vytvořte pouze podporované části.

Centrální komponenty 4.x nelze povýšit in-place. Důvodem není jediný balíček, ale kombinace OpenSearch 3.x, nového schématu, data streams, Content Manageru, přesunu detekce a změn konfigurace. Upgrade existující VM přes package manager by neposkytl konzistentní výsledek ani bezpečný rollback.

Doporučená vysoká úroveň projektu:

inventář 4.x → zálohy → nový 5.x lab → převod obsahu → paralelní validace
→ zachování 4.x historie → registrace a skupiny agentů → pilotní agenti
→ porovnání událostí/findings → produkční cutover → 4.x archiv do konce retence

Co lze migrovat a co se musí vytvořit znovu

Skupinová konfigurace není totéž co členství agentů

Sdílená konfigurace skupin zůstává ve Wazuh 5.0 souborová: /var/wazuh-manager/etc/shared/<skupina>/agent.conf. Používá XML s kořenem <agent_config>. Lokální nastavení linuxového agenta je jiný soubor: /var/ossec/etc/ossec.conf s kořenem <ossec_config>. Tyto názvy nejsou zaměnitelné.

V běžícím manageru vytváří API skupinu jako adresář a soubor agent.conf; členství mění přes Wazuh DB. Zobrazení konfigurace v indexeru proto neznamená, že stačí přenést index. Zálohujte definice skupin i mapu agent → skupiny, do nového manageru přeneste pouze kompatibilní nastavení a členství obnovte proti importovaným ID. Runtime soubor merged.mg se vytvoří znovu. Přenos adresáře sám členství nezachová.

Historická data zůstávají oddělená

V novém systému Wazuh 5.x historii z Wazuhu 4.x mít nebudete: podporovaný migrační postup ji nepřenáší a nový sběr začíná od nuly. Ke starým datům se dál dostanete přes zachovaný indexer a dashboard 4.x. Oficiální migrační postup pro Beta 5 zahrnuje ruční přenos kompatibilní konfigurace, ne historických indexovaných dat. Výrobce pro ně nepodporuje přímý upgrade, snapshot/restore ani reindex ze 4.x do 5.x. Viz omezení migrace indexeru.

Pokud potřebujete dohledávat staré alerty, ponechte původní 4.x indexer a dashboard dostupné jako oddělené prostředí pro čtení. Po přesměrování sběru do 5.x zastavte zápis nových dat do 4.x a podle provozního návrhu nastavte historické indexy pouze pro čtení. Ověřte přístup, oprávnění a vyhledávání ve skutečném historickém časovém rozsahu.

Nové události a findings od okamžiku přechodu patří do 5.x; starší historii hledáte ve 4.x. Jednotný pohled přes obě generace není součástí tohoto migračního postupu. Vlastní export nebo převod dat by byl samostatný integrační projekt, nikoli podporovaný převod starých alertů na nové findings.

Staré indexy, zálohy ani potřebné 4.x prostředí neodstraňujte při samotném přepnutí agentů. Jejich odstavení plánujte až podle retenční politiky a požadavků na audit. Úspěšná obnova vybraného indexu v konkrétní technické kombinaci sama o sobě neprokazuje podporu migrace ani funkčnost historických dat v aplikacích Wazuh 5.x.

Manager má nový adresář a nový konfigurační soubor

Sjednocení pojmenování manageru vítáme: jeho hlavní soubor je nyní /var/wazuh-manager/etc/wazuh-manager.conf. Zůstává to XML, nikoli YAML. Kořen <ossec_config> se mění na <wazuh_config>. YAML dekodéry jsou samostatný detekční obsah, ne nový formát tohoto souboru.

Ukázka nové syntaxe pro manager:

<wazuh_config>
  <global>
    <agents_disconnection_time>15m</agents_disconnection_time>
    <agents_disconnection_alert_time>0</agents_disconnection_alert_time>
  </global>
  <remote>
    <https>
      <port>1517</port>
    </https>
  </remote>
</wazuh_config>

Jde o výřez, ne kompletní instalační konfiguraci. Do výchozího souboru konkrétní instalace přeneste potřebné podporované volby; ponechte jeho správnou clusterovou konfiguraci, certifikáty a indexer připojení. Pro starší agenty se listener 1514 konfiguruje samostatně pod <remote><legacy>, nikoli původními plochými volbami přímo pod <remote>.

Interní přepisy manageru patří do /var/wazuh-manager/etc/wazuh-manager-internal-options.conf ve formátu modul.volba=hodnota. Například následující volba nastavuje interval kontroly změny enrollment hesla v sekundách:

remoted.enroll_password_refresh_interval=10

Konfigurace REST API zůstává samostatným YAML souborem /var/wazuh-manager/api/configuration/api.yaml; dashboard používá /etc/wazuh-dashboard/opensearch_dashboards.yml. Nelze tedy říct, že se veškeré nastavení přesunulo do jednoho souboru. U vlastních šablon je potřeba rozlišit službu, cílový soubor i jeho syntaxi.

Dashboard se instaluje nově

Dashboard 4.x nelze upgradovat in-place. Konfigurace se přesouvá ze souboru:

/usr/share/wazuh-dashboard/data/wazuh/config/wazuh.yml

do:

/etc/wazuh-dashboard/opensearch_dashboards.yml

hosts nahrazuje wazuh_core.hosts, jednotlivé checks.* přebírá healthcheck.checks_enabled a staré cron.* a wazuh.monitoring.* volby mizí. Globální přepsání Advanced Settings se nastavuje pomocí uiSettings.overrides.

Vlastní saved objects lze exportovat a importovat. Výchozí Wazuh dashboardy 4.x se ale importovat nemají, protože by mohly přepsat nové objekty nekompatibilními patterns. Panel přenášený na nové findings potřebuje odpovídající datový zdroj a názvy polí. Panel určený pro historické alerty ponechte v původním 4.x dashboardu nad jejich původním patternem. Každý ověřte v časovém rozsahu s dostupnými daty.

V terminologii dashboardu je index pattern uložený výběr dat, například wazuh-alerts-*; není to Filebeat index template definující mappings. Nemusíte kvůli migraci měnit názvosloví indexů. Podstatné je rozlišit původní historické panely v zachovaném 4.x prostředí a vizualizace přenesené do 5.x nad novým proudem wazuh-findings-v5*. Samotný import saved object nepřenáší jeho podkladová data. Přejmenování pole a přesměrování datového zdroje jsou dva různé kroky.

Vlastní rules a decoders jsou samostatný projekt

XML pravidla a dekodéry nelze vložit do manageru 5.x. Každý balík je potřeba převést na integraci, YAML dekodéry, WCS mapování a Sigma pravidla. Doporučený pracovní balíček pro jednu integraci obsahuje:

• inventář starých souborů a jejich checksum;
• seznam typických i problematických logů;
• mapu starých a nových polí;
• nové dekodéry a pravidla v Draft space;
• pozitivní a negativní Log Test;
• porovnání počtu alertů 4.x a findings 5.x na stejném vstupu;
• seznam navazujících dashboardů, notifikací a Active Response;
• schválený promotion do Custom space.

Mechanický převod syntaxe bez paralelního replay testu může tiše změnit detekční pokrytí.

Migraci vlastních XML pravidel a dekodérů plánujte jako ruční převod obsahu. Migrační příručka výrobce výslovně požaduje ruční přepis pravidel; pro dekodéry popisuje mapování jednotlivých konstrukcí. Nestačí převést značky XML na YAML: mění se pole, normalizace i význam některých vazeb a korelací.

Kde je Draft: v dashboardu otevřete Security Analytics → Overview a nahoře zvolte Space: Draft. Zde vznikají a upravují se vlastní integrace, dekodéry, pravidla a KVDB. Draft není aktivní produkční obsah. Po přenosu do Test se obsah validuje v enginu; teprve následný přenos do Custom ho zařadí do produkčního vlastního obsahu. Standard obsahuje obsah dodaný Wazuhem, nikoli další schvalovací krok.

Agenty lze přeregistrovat se zachováním identity

Registrace agentů jsou ve 4.x uloženy v /var/ossec/etc/client.keys a manager databázi. Migrační postup importuje aktivní řádky přes API 5.x manageru, čímž zachová ID, název, IP omezení i autentizační klíč. Poté se na agentovi změní adresa manageru a agent se restartuje.

Wazuh 4.x agent se může k 5.x manageru připojit, ale FIM, SCA, System Inventory, Active Response a Vulnerability Detection nejsou plně podporované, dokud agent nepřejde na 5.x. Přechodový stav je tedy vhodný pro krátký pilot, ne jako trvalá architektura.

Aktualizace balíčku agenta není totéž co dokončená migrace. Odděleně řešte zachování identity, kompatibilitu konkrétního typu balíčku a přechod na HTTPS. Podporu DEB, RPM, MSI, PKG a vzdáleného WPK postupu nelze vzájemně zaměňovat. Centrální komponenty vyžadují nové souběžné nasazení.

Zachování identity není příprava nového spojení. Přenos client.keys zachová identitu a sdílený klíč, ale nevyřeší důvěru k serverovému certifikátu ani distribuci klientského certifikátu, pokud ho manager vyžaduje. Heslo authd.pass se týká enrollmentu; není důvod automaticky přeregistrovat každého agenta, jehož identita byla správně přenesena.

Pokud na endpointu není předem připraveno potřebné TLS nastavení a důvěra, bude před přepojením nutný samostatný zásah — ručně nebo prostřednictvím vaší správy konfigurací. Samotný vzdálený upgrade balíčku tuto přípravu nenahrazuje. Vypnutí ověřování certifikátů ani obcházení bezpečnostních kontrol není doporučený migrační postup.

Doporučený validační checklist před cutoverem

• Všechny centrální komponenty mají očekávanou verzi a sestavení a zdravý cluster.
• Manager zapisuje normalizované události do všech používaných kategorií.
• Standard i Custom policy jsou načtené a Content Manager hlásí konzistentní verzi.
• Replay reprezentativních logů dává očekávané WCS dokumenty a findings.
• Počet událostí a nálezů je vysvětlený; rozdíl není pouze „přibližně stejný“.
• FIM, SCA, inventář a vulnerability data se po upgradu agentů plně synchronizují.
• Vlastní dashboardy používají správná pole pro zamýšlená data: nové findings odděleně od historických alertů. Historické panely zůstávají v původním 4.x prostředí; jejich dostupnost je ověřena odděleně.
• Notification channels doručují zprávy a neodhalují citlivá data.
• Active Response je otestovaný včetně revertu a nouzového vypnutí.
• Pokud je AI Assistant zapojený, respektuje RBAC, pravidla ochrany dat a odkazuje na ověřitelné zdrojové dokumenty.
• Zálohy a obnova v kompatibilním prostředí jsou ověřené; přístup k historii funguje ve 4.x. Nejde o příslib restore 4.x indexů do 5.x.
• Staré 4.x prostředí zůstává dostupné po předem určenou rollback dobu.

Jak se na Wazuh 5.0 připravit

Podpora 4.x po vydání pětky

Technická podpora není automatický příslib dalších oprav pro každou starší verzi. Aktuálně odkazované podmínky placené podpory výrobce pracují s verzemi N a N−1; u N−1 negarantují vývoj patchů a oprava může vyžadovat přechod na aktuální verzi. Z toho nelze odvodit garantované opravy celé řady 4.x po vydání 5.0.

Konkrétní datum ukončení podpory 4.x zde bez potvrzení výrobce neuvádíme. Pro migrační plán si nechte potvrdit přesnou verzi, dobu podpory a dostupnost bezpečnostních oprav podle své smlouvy. Samotná dostupnost starého balíčku není zárukou jeho údržby.

Co připravit před přechodem

Dokud není vydána finální verze, patří Wazuh 5.0 do izolovaného labu. Produkční upgrade má smysl plánovat, ale neprovádět před vydáním finální verze a ověřením podporované upgrade/migrační matice.

Příprava může začít okamžitě:

• aktualizujte zdrojové prostředí na podporovanou 4.14.x větev;
• sepište všechny vlastní rules, decoders, lists, Filebeat pipelines a integrace;
• uložte reprezentativní anonymizované logy pro replay test;
• exportujte vlastní dashboardy včetně navázaných saved objects a zkontrolujte odkazy na wazuh-alerts-* a použitá pole; panel pro historii ponechte ve 4.x, panel přenesený do 5.x musí odpovídat novým findings;
• zmapujte API a CLI automatizaci;
• změřte EPS, datový přírůstek a retenci;
• ověřte podporu operačních systémů centrálních uzlů i agentů;
• navrhněte novou PKI a správu enrollment hesla;
• pokud chcete AI Assistant používat, nastavte jeho režim zpracování dat podle bezpečnostních omezení popsaných přímo v kapitole o AI;
• připravte paralelní 5.x lab a první vlastní integraci převeďte end-to-end.

Tím se největší rizika odhalí dřív, než je projekt svázaný s termínem produkčního cutoveru.

Chcete změny vidět naživo? Vedle pravidelných Wazuh webinářů připravujeme speciální ukázku Wazuh 5.0 a samostatný webinář o upgradu a migraci. Ukážeme nejen postup, ale hlavně místa, kde se běžná instalace 4.x při přechodu komplikuje. Sledujte termíny Wazuh webinářů.

Shrnutí: největší přínos i největší migrační skok

Wazuh 5.0 sjednocuje data do WCS, odděluje normalizaci od detekce a posouvá pravidla, detektory, reporting, notifikace a reakce blíže k indexeru. Content Manager a workflow Draft → Test → Custom přinášejí řád do vlastního detekčního obsahu. Sigma pravidla, IOC enrichment a nové findings zlepšují přenositelnost a kontext detekce. Case Management, Incident Response a AI Assistant zase posouvají dashboard od pouhého zobrazení alertů k analytickému pracovnímu prostředí.

Cena za tento posun je vysoká míra nekompatibility s 4.x. Podle migračního postupu pro Beta 5 potřebujete novou instalaci a ruční přenos kompatibilní konfigurace; historická data se nepřenesou a v novém systému začíná sběr od nuly. Původní 4.x prostředí proto zachovejte jako oddělený archiv po požadovanou retenční dobu. Přechod vyžaduje paralelní testování, převod vlastních pravidel a řízené přepojení agentů, nikoli jen aktualizaci balíčků.

Právě proto má smysl začít s inventářem a labem už nyní, ale produkční rozhodnutí opřít o aktuální release notes a výsledky vlastních testů.

Wazuh 5.0 ke stažení a další užitečné odkazy

• Testovací sestava: Wazuh 5.0.0 Beta 5
• Release notes: Wazuh 5.0.0 release notes v oficiální dokumentaci
• Nová datová analýza: Data analysis ve Wazuh dokumentaci
• Přechod z 4.x na 5.x: Wazuh migration guide
• Změny Wazuh indexeru: Wazuh Indexer Plugins – release notes
• Zdrojový kód ověřované verze manageru a Engine: wazuh/wazuh v5.0.0-beta5
• Zdrojový kód ověřovaných indexerových pluginů: wazuh/wazuh-indexer-plugins v5.0.0-beta5
• Wazuh CTI: Introducing Wazuh CTI
• Služby initMAX: Wazuh SIEM a XDR
• Školení initMAX: Wazuh školení

Jako specialisté na Wazuh, SIEM, infrastrukturu a automatizaci vám pomůžeme s posouzením připravenosti, návrhem architektury, převodem vlastního detekčního obsahu, pilotním prostředím i řízenou migrací. Pokud chcete Wazuh 5.0 vidět v praxi nebo porovnat možnosti s vaším současným Wazuh 4.x, kontaktujte nás.