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

Wazuh 5.0 není běžná aktualizace s několika novými funkcemi. Přináší zásadní změnu způsobu, jakým platforma přijímá události, normalizuje je, ukládá, vyhodnocuje pravidla a předává výsledky analytikům. Mění se role Wazuh manageru a indexeru, odchází Filebeat, pravidla a dekodéry dostávají nový životní cyklus a detekční část se přesouvá blíže k datům v indexeru. Vedle toho přichází nový Wazuh Common Schema, práce s IOC a GeoIP kontextem, Case Management, přepracovaný Active Response a také AI Assistant.

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á vybudovat nové prostředí, přenést podporovaná data a konfiguraci a postupně do něj přepojit agenty. Pro mnoho instalací tak bude Wazuh 5.0 současně technologickým upgradem i migračním projektem.

Wazuh 5.0 se blíží. Novinky jsme prozkoumali ve zdrojovém kódu a v testovací sestavě 5.0.0 Beta 5. Ukázky zachycují tuto předběžnou verzi; finální vydání může přinést další změny.

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ářů.

Ukázky jsme ověřili v odděleném labu na třech virtuálních strojích s Ubuntu 24.04: Wazuh 4.14.7, Wazuh 5.0.0 Beta 5 a jeden migrovaný agent. Bez Dockeru jsme otestovali zachování ID 001, upgrade, plně ověřované HTTPS spojení, návrat ke 4.x a následný návrat k 5.x včetně restartu. Replay 35 syntetických SSH zpráv vytvořil 30 nálezů neúspěšné a 5 nálezů úspěšné autentizace. Agent odeslal 279 výsledků SCA a počáteční inventář 3 576 souborů pro FIM; obnovili jsme také 639 z 639 historických dokumentů. Nejde o produkční incidenty ani o benchmark výkonu.

Hranice ověření: úplný tok balíčkového inventáře a Vulnerability Detection tímto pilotem nepotvrzujeme; při prvním měření chyběly balíčkové stavy a objevilo se varování Syscollector VD. Přehled vlastností níže vychází také z dokumentace a zdrojového kódu, ne ze zátěžového nebo kompatibilitního testu všech funkcí.

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

Wazuh 4.x lze zjednodušeně popsat jako systém, ve kterém 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 Wazuh indexeru, odkud je zobrazuje dashboard. Toto schéma fungovalo dlouho, ale část práce se koncentrovala na manageru, detekční obsah byl svázaný se soubory na jeho filesystému a možnosti jednotné správy obsahu, verzování a normalizace byly omezené.

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

1. 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.
2. 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:

zdroj logu / agent
        ↓
Wazuh manager: příjem → dekódování → normalizace → obohacení
        ↓  indexer-connector
Wazuh indexer: uložení události → detektor → Sigma pravidlo
        ↓
finding → dashboard → analytik / notifikace / Active Response

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.

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.

Wazuh 5.0 navíc mění účet, kterým se manager po standardní instalaci připojuje k indexeru. Release notes místo administrátorského účtu uvádějí omezený účet wazuh-server, což lépe odpovídá principu minimálních oprávnění. Kontrola zdrojového tagu Beta 5 ale ukázala, že engine stále obsahuje interní fallback wazuh-manager. Efektivní účet proto po instalaci neodvozujte pouze z výchozí hodnoty v dokumentaci nebo zdrojáku: ověřte hodnotu uloženou v manager keystoru a její skutečné role v indexeru.

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:

1. Provozní data Wazuh 5.0, která zapisuje nativní konektor do nových datových proudů.
2. Historická data Wazuh 4.x, která lze obnovit ze snapshotu, ale zůstanou v původním schématu a Wazuh 5.0 do nich nebude zapisovat.
3. 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

Srdcem nové analytické architektury je Wazuh Engine. Není to jen přepsaný analysisd. Jde o systém, který kombinuje normalizaci událostí v manageru, správu detekčního obsahu v indexeru a detekci nad normalizovanými dokumenty. V dashboardu se tato oblast zobrazuje 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.

Nová architektura řeší dlouhodobý provozní problém: oficiální pravidla a lokální úpravy už nemají být promíchané ve stejném adresářovém stromu. Standardní obsah spravovaný Wazuh CTI je oddělený od vlastního obsahu organizace. Aktualizace výrobce tak nemusí přepisovat lokální soubory a vlastní pravidla lze připravovat a testovat před nasazením.

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

Kontrola implementace manager enginu ukazuje, že 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.

Praktický důsledek je dvojí. Nový obsah lze aktivovat bez restartu celého manageru, ale změna není nutně okamžitá. Při diagnostice je proto potřeba kontrolovat 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. Při povýšení Content Manager obsah nasadí do enginu, zvaliduje konfiguraci, vyvolá reload a aktualizuje cílový space. 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 JSON, CSV, key-value nebo text regulárním výrazem;
• 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)

V našem labu zpráva Failed password for invalid user demo-admin from 203.0.113.10 port 51234 ssh2 skutečně vytvořila event.action: authentication-failure, event.outcome: failure, user.name: demo-admin a source.ip: 203.0.113.10. Právě tyto hodnoty pak použilo standardní 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.

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. Původní nezměněný záznam zůstává v event.original, takže normalizace nezničí forenzní kontext.

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

Wazuh Engine může podle nastavení zachovat také raw události a události označené jako discarded. To je užitečné při tvorbě integrace nebo vyšetřování, proč konkrétní log nevytvořil finding. V produkci však tato volba dramaticky mění objem dat.

Pre-filter může událost odmítnout ještě před dekódováním a ušetřit práci enginu. Post-filter se vyhodnocuje až po dekódování nebo obohacení. Pokud je indexace discarded events vypnutá, pipeline událost po označení zahodí. Pokud je zapnutá, událost projde do výstupu pro troubleshooting.

Před zapnutím raw nebo discarded streamu je proto potřeba spočítat 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. Tohle je zkrácený výřez standardního pravidla, které v našem labu vytvořilo nálezy 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.

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 už není pouze web s informacemi o zranitelnostech. Ve Wazuh 5.0 se stává distribuční vrstvou pro standardní detekční obsah, vulnerability feed a indikátory kompromitace. Content Manager pravidelně kontroluje aktualizace a doručuje je do indexeru a enginu.

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 ve Wazuh 5.0 stále sbírá inventář operačního systému, balíčků a hotfixů. Vulnerability Detection ale používá Wazuh indexer jako jediný autoritativní zdroj CVE dat; agentová část už nemá komunikovat přímo s CTI. Synchronizační algoritmus rozlišuje první scan, změnu inventáře a aktualizaci feedu.

Nová verze přidává podporu CVSS 4.0 a polí schématu CVE 5.0. Prakticky to znamená bohatší informace o zranitelnosti, ale také další místa, kde se mohou změnit vlastní exporty a dashboardy. Při migraci je potřeba ověřit nejen počet zranitelností, ale také jejich stav, vazbu na konkrétní balíček, závažnost podle nové metriky a chování po aktualizaci inventáře.

Active Response se konfiguruje v dashboardu

Wazuh 4.x definuje příkazy a aktivní reakce v manager konfiguraci pomocí bloků <command> a <active-response>. Ve Wazuh 5.0 se konfigurace přesouvá do části Explore → Active Response v dashboardu. Požadavky na provedení se ukládají do vlastního datového proudu a spouští je dedikovaný Alerting monitor. Samotný příkaz nadále provádí wazuh-execd na cílovém agentovi.

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

• název a popis;
• spustitelný soubor a volitelné argumenty;
• umístění – lokální agent, který událost vytvořil, nebo všichni agenti;
• typ – jednorázový stateless, nebo stateful s automatickým vrácením změny;
• timeout u stateful reakce;
• pravidlo nebo podmínka, která reakci vyvolá.

Přesun do dashboardu zlepšuje přehled a auditovatelnost, ale vyžaduje přepsat stávající konfiguraci. Staré XML bloky se do manageru 5.x nekopírují. Je potřeba také ověřit, že skript na agentovi umí zpracovat nový tvar předaného findingu a že field paths odpovídají WCS.

Volba All je stejně riziková jako dříve: chybný skript nebo příliš široké pravidlo může zasáhnout celé prostředí. Doporučujeme nejdřív reakci provozovat pouze v notifikačním režimu, následně na testovací skupině agentů a teprve poté ji rozšířit. U stateful akce musí test zahrnovat provedení, timeout, revert i opakovanou shodu během aktivního zásahu.

Co to znamená v praxi

Active Response už není izolované nastavení schované v ossec.conf. Stává se součástí indexerového Alerting workflow a dashboardového provozu. To umožňuje lepší viditelnost, ale přidává závislost na správné funkci datového proudu, monitoru, notification channelu a oprávnění. Test „skript existuje na agentovi“ proto není dostatečný; je nutné projít celou cestu od události přes finding až po potvrzenou reakci.

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

Jednou z největších novinek Wazuh 5.0 je vestavěný Wazuh AI Assistant. Nabízí konverzační rozhraní pro dotazy nad zranitelnostmi, findings, inventářem a stavem agentů. Odpověď může obsahovat slovní shrnutí, strukturovanou tabulku a odkaz do Discoveru, kde analytik ověří skutečná zdrojová data.

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.

Příklady vhodných dotazů:

• Kteří agenti jsou odpojení a jak dlouho?
• Která zařízení mají kritické zranitelnosti s dostupným exploitem?
• Z jakých zdrojových IP adres přichází nejvíce neúspěšných přihlášení?
• Ukaž procesy nebo naslouchající porty na vybraném agentovi.
• Shrň kritické findings za posledních 24 hodin a rozděl je podle MITRE taktiky.

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.

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.

V testované Beta 5 nabízel formulář dva typy: OpenAI-compatible a Anthropic. Zmínku o Wazuh AI Assistant Brain proto chápeme jako údaj z vývojové dokumentace, nikoli jako ověřenou třetí volbu tohoto formuláře. Externího providera ani kvalitu odpovědí jsme v pilotu netestovali.

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

Wazuh umožňuje před odesláním dat providerovi pole anonymizovat nebo úplně vyloučit. Privacy mode lze zapnout jako výchozí pro celý cluster a administrátor může zakázat, aby ho uživatel v jednotlivé konverzaci vypnul.

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:

1. Začít s privacy mode vynuceným pro všechny uživatele.
2. Zakázat odesílání event.original, secrets, tokenů, command line a volného textu, pokud nejsou pro dotaz nezbytné.
3. Pseudonymizovat identity agentů, hostname, uživatele a interní adresy.
4. Otestovat, že anonymizace funguje i v historii konverzace a v opakovaných dotazech.
5. V logu nebo síťové inspekci ověřit skutečný payload odesílaný providerovi.
6. 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.

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.

Kdy stále potřebujeme externí case-management systém

Vestavěný Case Management je vhodný pro rychlý triage a menší týmy. Nenahrazuje automaticky plnohodnotný SOAR nebo ticketovací systém s komplexním schvalováním, SLA, evidence lockerem, vazbou na CMDB a orchestrací napříč více nástroji. Pokud už organizace používá Jira, ServiceNow, TheHive nebo DFIR-IRIS, je potřeba rozhodnout, kde bude autoritativní stav incidentu a jak se zabrání dvojímu řízení.

Incident Response: viditelnost nad provedenými zásahy

Nová aplikace Incident Response zobrazuje aktivitu aktivních reakcí na monitorovaných endpointech. Analytik tak může vidět, jaká reakce byla spuštěna, na kterém agentovi, v souvislosti s jakou detekcí a s jakým výsledkem.

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

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

Bez posledního kroku organizace pouze ví, že příkaz odeslala. Neví, zda se provedl, selhal nebo byl po timeoutu vrácen. Incident Response dashboard má sloužit právě pro kontrolu této části procesu.

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.

Podporované kanály zahrnují e-mail přes SMTP nebo Amazon SES, Microsoft Teams, Slack, Amazon Chime, AWS SNS a vlastní webhooky. V balíčku jsou připravené také výchozí webhookové typy pro nástroje jako Jira, PagerDuty nebo Shuffle. Dostupnost a přesnou konfiguraci je nutné ověřit v konkrétní sestavě.

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 — pro standardní SSH dekodér jsme tuto hodnotu ověřili i v labu.

Notifikace nejsou Active Response

Alerting monitor může odeslat informaci člověku nebo vytvořit požadavek pro Active Response. Tyto dvě akce ale mají jiné riziko. U e-mailu je nejhorším běžným výsledkem spam. U automatického blokování adresy nebo deaktivace účtu může chybná podmínka způsobit výpadek.

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

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

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

Starý reporting uvnitř Wazuh dashboard pluginu byl odstraněn. Nahrazuje ho Wazuh fork OpenSearch Reporting pluginu, který je součástí indexeru. Umí vytvořit PDF nebo CSV z dashboardu a saved search, jednorázově nebo podle plánu, a výsledek doručit e-mailem.

Změna backendu znamená, že se nepřenášejí dříve vygenerované PDF reporty ani staré nastavení report brandingu. Vlastní logo, hlavička a patička starého Wazuh reportu se podle migrační dokumentace v 5.x nepodporují stejným způsobem.

Při validaci reportu kontrolujte nejen vzhled, ale i tenant, časové pásmo, time range, maximální počet CSV řádků, oprávnění účtu spouštějícího report a dostupnost e-mailového kanálu. Naplánovaný report bez přístupu k indexu může vytvořit prázdný nebo neúplný dokument, i když samotný dashboard administrátorovi funguje.

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;
• Explore pro AI Assistant a Active Response;
• 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 byly odstraněny, protože jejich roli přebírá Security Analytics a Content Manager. Starý Reporting plugin byl odstraněn. Zmizely také moduly závislé na deprecated daemonech, například OpenSCAP, CIS-CAT a Osquery v původní podobě, a některé staré části Statistics, Cluster a App Settings.

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

Agent ve Wazuh 5.0 získává větší odpovědnost za stavové moduly. File Integrity Monitoring, System Inventory a Security Configuration Assessment ukládají svůj stav lokálně na endpointu. Odstraňuje se závislost těchto modulů na rsync synchronizaci s managerem, což snižuje síťový provoz a množství práce na serveru.

Změna neznamená, že by centrální přehled zmizel. Agent posílá stav a změny do nové synchronizační pipeline a indexer je ukládá do stavových indexů. Rozdíl je v tom, kdo drží autoritativní pracovní stav a jak se řeší plný scan, změnová dávka a obnovení po výpadku spojení.

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

• vyšší výchozí limity propustnosti událostí a velikosti inventory zpráv;
• konzistentnější první čtení souboru při rotaci logů;
• Windows Event Channel posílá nativní XML vytvořené EvtRender();
• agent-start a buffer-status události používají JSON odpovídající WCS;
• Windows agent se distribuuje pouze jako MSI, starý NSIS instalátor byl odstraněn;
• zjednodušený rootcheck bez serverové databáze a starého sync/API povrchu;
• redukce zastaralých binárek a modulů;
• WPK balíčky pro vzdálený upgrade včetně arm64 variant pro Linux a macOS.

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.

Nový protokol má přinést standardnější TLS komunikaci, lepší detekci napůl uzavřených spojení a efektivnější přenos. Provozní test musí pokrýt certifikáty, hostname validation, source address v client.keys, časovou synchronizaci, proxy a firewall, reconnect po výpadku, statickou IP registraci i upgrade existujícího agenta.

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ů.

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

Instalace manageru generuje sdílené enrollment heslo a ochrana heslem je ve Wazuh 5.0 zapnutá ve výchozím stavu. Heslo je uložené v authd.pass, synchronizuje se na worker uzly a registrace při neplatném hesle selže uzavřeným způsobem. Agent dostane heslo při instalaci prostřednictvím příslušné proměnné nebo instalačního argumentu.

Sdílené heslo je lepší výchozí stav než nechráněná registrace, ale ve velkém prostředí je stále společným tajemstvím. Musí mít omezenou distribuci, bezpečné uložení a proces rotace. Nikdy ho nevkládejte přímo do veřejného skriptu, ticketu ani shell history.

Cluster je výchozí i pro jediný manager

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 místo pevné výchozí hodnoty. 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, protože na stejné infrastruktuře poběží pozdější rozšíření na více uzlů.

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

Wazuh 5.0 zpřísňuje několik výchozích nastavení:

• release notes zavádějí omezený účet wazuh-server pro spojení manageru s indexerem; efektivní účet a role je potřeba ověřit po instalaci;
• 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ý;
• enrollment vyžaduje heslo;
• 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;
• multitenancy indexeru je ve výchozím stavu vypnutá.

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

Wazuh 5.0 uklízí dlouho zastaralé části manageru. Odstraněny jsou daemony ossec-authd, wazuh-agentlessd, wazuh-maild a wazuh-dbd v jejich původní podobě a C nástroje manage_agents a agent-auth. Serverová část OpenSCAP byla odstraněna, stejně jako některé inventory a security configuration endpointy API a SELinux integrace manageru.

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, LDAP/SAML/OIDC a tenanty;
• systémy čtoucí alerts.json nebo staré indexy.

Teprve tento seznam ukáže skutečný rozsah projektu.

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

Dokumentace Wazuh 5.x doporučuje pro centrální komponenty 64bit Linux na x86_64/AMD64 nebo AARCH64/ARM64. Uvádí Amazon Linux 2023, Ubuntu 24.04 a 26.04 a Red Hat Enterprise Linux 9 a 10. Seznam je proti 4.x užší; starší distribuce nelze považovat za podporované jen proto, že na nich běžela předchozí verze.

Orientační požadavky pro jeden uzel:

All-in-one quickstart pro 1–25 agentů uvádí 4 vCPU, 8 GiB RAM a 50 GB pro 90 dní. Pro 25–50 agentů je to 8 vCPU, 16 GiB a 100 GB; pro 50–100 agentů 8 vCPU, 16 GiB a 200 GB. Jde o orientační profil, nikoli sizing pro libovolnou bezpečnostní telemetrii.

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:

1. průměrné a špičkové EPS po jednotlivých zdrojích;
2. denní přírůstek primárních dat bez replik;
3. poměr events ku findings;
4. velikost state indices a CTI obsahu;
5. dobu detektorů při reálném počtu pravidel;
6. heap pressure, CPU, fronty a indexační latenci;
7. 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
→ migrace historických dat → registrace a skupiny agentů → pilotní agenti
→ porovnání událostí/findings → produkční cutover → řízené odstavení 4.x

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

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

Migrace indexů je podporována ze zdrojového Wazuh 4.4.0 nebo novějšího. Zdrojový a cílový indexer musí mít přístup ke společnému snapshot repository, například přes NFS. Ze 4.x se vytvoří snapshot pouze požadovaných Wazuh datových indexů bez global cluster state a bez systémových indexů.

V 5.x se repository připojí read-only, snapshot se obnoví – ideálně s prefixem jako restored_ – a vytvoří se pro něj samostatný index pattern. Obnovené indexy si zachovají staré mappings. Wazuh 5.x do nich nebude zapisovat a automaticky je nepřevede do WCS.

To znamená, že jeden dotaz přes nová i historická data není automaticky jednotný. Staré dokumenty mají rule.level, nové wazuh.rule.level; staré alerty a nové findings mají jinou strukturu. Pro dlouhodobé reporty je buď potřeba dvě datové vrstvy zobrazit odděleně, nebo vytvořit vlastní transformační proces s jasně popsanou ztrátou či mapováním polí.

Do snapshotu nepatří .kibana*, .opendistro*, security index ani globální cluster state. Jejich obnova by mohla přepsat nebo poškodit 5.x systémovou konfiguraci.

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

Primární manager konfigurace se mění:

Wazuh 4.x: /var/ossec/etc/ossec.conf
Wazuh 5.x: /var/wazuh-manager/etc/wazuh-manager.conf

Starý soubor slouží pouze jako inventář. Sekce se nesmí zkopírovat jako celek. Některé jsou odstraněné nebo přesunuté:

• <alerts> nahrazují notification channels a Alerting;
• <active-response> a <command> se vytvářejí v Active Response UI;
• <ruleset> přebírá Content Manager;
• <rootcheck>, <syscheck>, <sca>, <wodle name="syscollector"> a <localfile> se z manager konfigurace přesouvají k agentové funkcionalitě nebo do nové správy;
• cesty pod /var/ossec na manageru se mění na /var/wazuh-manager.

Po vytvoření konfigurace je potřeba manager spustit, zkontrolovat syntaxi, logy všech daemonů, spojení s indexerem a cluster status. Úspěšné systemctl start ještě nepotvrzuje, že funguje normalizace a tvorba findings.

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í. Advanced Settings se spravují po tenantech nebo globálně 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. Po importu je nutné změnit wazuh-alerts-*, opravit field references a ověřit každý panel v časovém rozsahu s dostupnými daty. U multitenancy se export a import provádí samostatně pro každý tenant.

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í.

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.

Agenti na verzi starší než 4.14 vyžadují dvoukrokový vzdálený upgrade: nejdřív na 4.14.x a následně na 5.0. Před hromadnou vlnou je nutné otestovat DEB, RPM, MSI a PKG varianty používané v prostředí, včetně zařízení s pending rebootem nebo omezeným diskem.

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

1. Všechny centrální komponenty mají očekávanou verzi a sestavení a zdravý cluster.
2. Manager zapisuje normalizované události do všech používaných kategorií.
3. Standard i Custom policy jsou načtené a Content Manager hlásí konzistentní verzi.
4. Replay reprezentativních logů dává očekávané WCS dokumenty a findings.
5. Počet událostí a nálezů je vysvětlený; rozdíl není pouze „přibližně stejný“.
6. FIM, SCA, inventář a vulnerability data se po upgradu agentů plně synchronizují.
7. Vlastní dashboardy neobsahují neplatná pole ani starý wazuh-alerts-* pattern.
8. Notification channels doručují zprávy a neodhalují citlivá data.
9. Active Response je otestovaný včetně revertu a nouzového vypnutí.
10. AI Assistant respektuje RBAC, privacy policy a odkazuje na ověřitelné zdrojové dokumenty.
11. Snapshot a restore byly skutečně vyzkoušené, ne pouze nakonfigurované.
12. Staré 4.x prostředí zůstává dostupné po předem určenou rollback dobu.

Jak se na Wazuh 5.0 připravit

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 a zjistěte jejich index patterns a field dependencies;
• 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;
• určete, která data smějí opustit organizaci přes AI providera;
• 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. Nové indexy, pole, pravidla, konfigurace i role znamenají, že přechod nelze zredukovat na aktualizaci balíčků. Úspěšná migrace bude připomínat blue/green nasazení s paralelním testováním, převodem obsahu a řízeným přepojením agentů.

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.