Wazuh SIEM Linux Útmutató 2026

Frissítve: 2026. június 18.

A Wazuh egy nyílt forráskódú SIEM és XDR platform, amely központosított naplóelemzést, fájlintegritás-monitorozást, sebezhetőség-detektálást és MITRE ATT&CK-alapú fenyegetésvadászatot biztosít Linux, Windows és macOS rendszereken. A platform három fő részből áll (Wazuh manager, Wazuh indexer és Wazuh dashboard), az ügynökök pedig telemetriát küldenek a managernek. Ebben a 2026-os útmutatóban egy production-ready Wazuh 4.x telepítést építünk fel Ubuntu 24.04 LTS és RHEL 9 szervereken, és lépésről lépésre konfiguráljuk a legfontosabb modulokat. Bevallom, az első Wazuh klaszteremet még 2021-ben húztam fel egy ügyfél hibrid környezetére, és azóta sokat tisztult a telepítési folyamat, főleg az all-in-one szkript óta.

A Wazuh három szerverkomponensből (manager, indexer, dashboard) és egy egységes ügynökből áll, és OpenSearch-alapú indexálást használ a 4.4-es kiadás óta.
Az all-in-one telepítőszkript néhány perc alatt felhúz egy működő példányt, de production környezetben szétválasztott node-okra van szükség a skálázhatósághoz.
A Wazuh FIM modulja syscall-szintű (audit-alapú) változáskövetést kínál, és real-time figyelmeztet a kritikus fájlok módosítására.
A beépített megfelelőségi sablonok lefedik a PCI DSS 4.0, NIST 800-53, HIPAA, GDPR és TSC kontrollokat, auditra exportálható jelentésekkel.
Az aktív válasz modul képes automatikusan blokkolni támadó IP-címeket nftables, firewalld vagy Windows Firewall segítségével.
A Wazuh szabályai több mint 700 MITRE ATT&CK technikához vannak leképezve, ami leegyszerűsíti a fenyegetésvadászatot a dashboardon.

Mi az a Wazuh és hogyan működik?

Szóval, kezdjük az alapoknál. A Wazuh hivatalos dokumentációja szerint a platform egy egyesített XDR és SIEM, amely OSSEC-forkként indult 2015-ben, és 2026-ra a legaktívabban karbantartott nyílt forráskódú biztonsági platformmá vált. Több mint 23 ezer GitHub-csillaggal és heti több ezer letöltéssel egészen impozáns a community körülötte. Egy könnyűsúlyú ügynököt telepítünk a végpontokra, ami naplókat, fájlváltozásokat, syscall-eseményeket, futó folyamatokat és csomaglistákat küld TLS-en a Wazuh managernek. A manager dekódolja és szabályokkal kiértékeli az eseményeket, majd a Wazuh indexer (egy OpenSearch fork) tárolja őket, a dashboard pedig vizualizálja a riasztásokat.

A Wazuh különlegessége, hogy egyetlen ügynök sok különböző biztonsági funkciót lefed: naplógyűjtés, fájlintegritás-monitorozás (FIM), rootkit-detektálás, sebezhetőség-felismerés, megfelelőségi audit és aktív válasz. Az osquery, az auditd és a sysmon integrációkkal mély telemetriát kapunk anélkül, hogy külön ügynököket kellene karbantartani. Hasonlóan az eBPF-alapú Falco és Tetragon megoldásokhoz, a Wazuh is real-time képes detektálni gyanús viselkedést, csak épp szélesebb spektrumon, beleértve a klasszikus logelemzést is.

A Wazuh architektúra és komponensek

Mielőtt nekiállnánk telepíteni, érdemes tisztában lenni a Wazuh három szerverkomponensének szerepével. Production-ben ezek általában külön node-okra kerülnek a skálázhatóság és a kiesés-tűrés érdekében:

Wazuh manager: fogadja az ügynökök adatait, dekódolja, szabályokkal kiértékeli, riasztásokat generál. Egy klaszterben több manager működhet master/worker módban.
Wazuh indexer: OpenSearch-alapú elosztott keresőmotor, amely tárolja a riasztásokat és az archivált eseményeket. Production HA-hoz legalább 3 indexer node ajánlott.
Wazuh dashboard: OpenSearch Dashboards alapú webes felület a riasztások vizualizálására, jelentések készítésére és az ügynökök kezelésére.
Wazuh agent: minimális erőforrásigényű, C nyelven írt komponens, amely Linux, Windows, macOS, AIX, Solaris és HP-UX rendszereken fut.

Wazuh telepítése Linux szerverre lépésről lépésre

Production-előtti tesztekhez a leggyorsabb módszer a hivatalos all-in-one telepítőszkript, ami egy gépen futtatja mindhárom szerverkomponenst. Egy minimum 4 vCPU, 8 GB RAM, 50 GB SSD-vel rendelkező Ubuntu 24.04 LTS vagy RHEL 9 szerverre van szükség, root jogosultsággal és nyitott 443/TCP, 1514/TCP, 1515/TCP, 55000/TCP portokkal. Lab környezetben szoktam egy KVM VM-en kipróbálni mindent, mielőtt élesbe rakom a klasztert.

# 1) Frissítsük a rendszert és töltsük le a telepítőt
sudo apt update && sudo apt -y upgrade
curl -sO https://packages.wazuh.com/4.11/wazuh-install.sh

# 2) Generáljunk konfigurációs fájlt a saját node-nevekkel
sudo bash wazuh-install.sh --generate-config-files

# 3) Indítsuk el az all-in-one telepítést
sudo bash wazuh-install.sh --all-in-one

# A telepítő végén kiírja az admin jelszót:
# User: admin
# Password: <generált jelszó>

A folyamat 8–12 percig tart, és a végén a https://<szerver-ip> címen elérhető a Wazuh dashboard. Production környezetben viszont szétválasztott telepítést érdemes választani: a --wazuh-server, --wazuh-indexer és --wazuh-dashboard kapcsolókkal külön node-okra telepíthetjük a komponenseket. A klaszter konfigurációja a config.yml fájlban deklaratív, és a hivatalos dokumentáció részletesen leírja a multi-node setup lépéseit.

Wazuh ügynök telepítése és regisztrálása

Az ügynökök kétféleképpen regisztrálhatók: jelszavas regisztrációval (authd protokollal) vagy a dashboardon keresztül generált csoport-kulccsal. Production-ben a tanúsítvány-alapú TLS kölcsönös hitelesítés a javasolt módszer. Az alábbi szkript egy új Debian/Ubuntu ügynököt csatlakoztat a managerhez:

# Wazuh repó hozzáadása
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | \
  sudo gpg --no-default-keyring --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import
sudo chmod 644 /usr/share/keyrings/wazuh.gpg
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] \
  https://packages.wazuh.com/4.x/apt/ stable main" | \
  sudo tee /etc/apt/sources.list.d/wazuh.list

# Telepítés a manager IP-jével
sudo apt update
WAZUH_MANAGER="10.0.1.10" WAZUH_AGENT_GROUP="linux-prod" \
  sudo -E apt install wazuh-agent

# Szolgáltatás indítása és aktiválása
sudo systemctl daemon-reload
sudo systemctl enable --now wazuh-agent

# Állapot ellenőrzése
sudo /var/ossec/bin/wazuh-control status

A sikeres regisztráció után az ügynöknek zöld active állapotban kell megjelennie a dashboard Agents nézetében. RHEL-alapú rendszereken (RHEL 9, Rocky Linux, AlmaLinux) dnf-fel megy a telepítés, és érdemes egy systemd drop-in fájlt is létrehozni, hogy az ügynök automatikusan újrainduljon hálózati hiba esetén. Ezt a kis részletet sokszor kihagyják, aztán csodálkoznak, miért tűnik el egy node a panelről egy rövid hálózati glitch után.

Fájlintegritás-monitorozás (FIM) konfigurálása

A FIM modul kritikus rendszerfájlok módosításának észlelésére szolgál, és őszintén szólva egyike a leghatékonyabb védelmi rétegeknek webkiszolgálók, konfigurációs könyvtárak és binárisok ellen. A Wazuh syscall-szintű whodata módja az auditd alrendszerre épül, és valós időben jelzi, ki és milyen folyamattal módosított egy fájlt. Ha az auditd alapok már megvannak, ez a réteg természetes folytatás.

<!-- /var/ossec/etc/ossec.conf részlet -->
<syscheck>
  <disabled>no</disabled>
  <frequency>43200</frequency> <!-- 12 óra -->

  <!-- Real-time, syscall-szintű figyelés -->
  <directories check_all="yes" realtime="yes" whodata="yes">/etc</directories>
  <directories check_all="yes" realtime="yes" whodata="yes">/usr/bin,/usr/sbin</directories>
  <directories check_all="yes" realtime="yes" whodata="yes">/var/www</directories>

  <!-- Kizárt fájlok -->
  <ignore>/etc/mtab</ignore>
  <ignore type="sregex">.log$|.tmp$</ignore>

  <!-- Riasztás új fájlok létrehozására is -->
  <alert_new_files>yes</alert_new_files>
  <auto_ignore frequency="10" timeframe="3600">yes</auto_ignore>
</syscheck>

A változások a dashboard Integrity monitoring moduljában jelennek meg, ahol minden eseményhez látható a régi és új hash (SHA-256), a fájl tulajdonosa és a módosító folyamat (whodata esetén). Ez különösen hasznos webhost környezetben: a Wazuh azonnal jelez, ha egy hátsó ajtót próbálnak elhelyezni a webgyökérben. Egy ügyfelünknél pont így vettünk észre egy PHP webshellt, mielőtt bármi kár történt volna.

Sebezhetőség-detektálás bekapcsolása

A Wazuh 4.8 óta a sebezhetőség-detektálás integráltan használja a Wazuh GitHub kiadásokban publikált, OVAL- és CPE-alapú feedeket, és nem igényel külön külső szkennert. A modul az ügynökön gyűjtött csomaginformációkat összeveti a Canonical, Red Hat, Debian, ALAS és NVD adatbázisaival, majd CVSS-pontszámmal súlyozott riasztásokat generál.

<!-- Wazuh manager: /var/ossec/etc/ossec.conf -->
<vulnerability-detection>
  <enabled>yes</enabled>
  <index-status>yes</index-status>
  <feed-update-interval>60m</feed-update-interval>
</vulnerability-detection>

Konfiguráció után a manager újraindítását követően kb. 30–60 percen belül megjelennek a riasztások a Vulnerabilities modulban, csomagszinten, CVE-azonosítóval. A Wazuh integrálható patch-management megoldásokkal is (pl. Ansible playbook trigger): minden kritikus CVE-riasztás automatikusan elindíthat egy javítási folyamatot. Ha mélyebb scannelést szeretnél konténerekre és image-ekre, érdemes a Wazuh-t kombinálni dedikált eszközökkel, erről részletesen szól a Linux sebezhetőség-vizsgálati automatizációs útmutatónk.

MITRE ATT&CK leképezés és fenyegetésvadászat

A Wazuh szabálykészlete több mint 700 detektálási logikát tartalmaz, amelyek a MITRE ATT&CK keretrendszer technikáihoz vannak leképezve (pl. T1078 Valid Accounts, T1059 Command and Scripting Interpreter vagy T1110 Brute Force). A dashboard MITRE ATT&CK moduljában mátrix nézetben látjuk, mely taktikák és technikák ellen érkezett riasztás az utóbbi órákban. Ez nagyban felgyorsítja a fenyegetésvadászatot és a kockázati priorizálást.

Saját szabály létrehozására példa, egy gyanús sudo használat detektálására:

<!-- /var/ossec/etc/rules/local_rules.xml -->
<group name="local,sudo,">
  <rule id="100100" level="10">
    <if_sid>5402</if_sid>
    <match>COMMAND=/usr/bin/wget|COMMAND=/usr/bin/curl</match>
    <description>Sudo: gyanús letöltő parancs futtatása rootként</description>
    <mitre>
      <id>T1105</id> <!-- Ingress Tool Transfer -->
      <id>T1059.004</id> <!-- Unix Shell -->
    </mitre>
    <group>privilege_escalation,</group>
  </rule>
</group>

A szabály újratöltése után (systemctl restart wazuh-manager) minden sudo wget vagy sudo curl futás 10-es szintű riasztást generál, és automatikusan megjelenik a megfelelő MITRE ATT&CK technikák alatt a dashboardon.

Megfelelőségi auditálás: PCI DSS, GDPR, HIPAA, NIST

A Wazuh kiemelkedő erőssége a beépített megfelelőségi sablonkönyvtár. Minden szabály címkézve van azzal, hogy mely keretrendszer melyik követelményéhez kapcsolódik, így a meglévő detektálási logikák egyúttal auditbizonyítékot is szolgáltatnak. A támogatott keretrendszerek 2026-ban:

PCI DSS 4.0: fizetési kártya iparági biztonsági szabvány, kiemelten a 10. és 11. követelmények (naplózás, behatolás-észlelés).
NIST 800-53 Rev. 5: szövetségi USA biztonsági kontrollok, AU, SI, AC családok teljes lefedettsége.
HIPAA: egészségügyi adatvédelem (US), különösen a 164.312 technikai biztonsági kontrollok.
GDPR: uniós adatvédelmi rendelet, jogalap-megfelelési és incidenskezelési riasztások.
TSC (Trust Services Criteria): SOC 2 jelentésekhez.
GPG 13: brit kormányzati naplózási irányelv.

A dashboard Regulatory Compliance moduljában minden keretrendszerhez külön dashboard tartozik. Egy PCI DSS auditra felkészüléshez például kiválasztjuk a PCI nézetet, és időszaki riportot generálhatunk, amely listázza az összes kontrollt és a kapcsolódó eseményeket. Ezek a riportok PDF-be exportálhatók, és az auditor által közvetlenül felhasználhatók. Egy PCI auditom előtt ez kb. három hét manuális dokumentációt spórolt meg, ami önmagában megérte a setupot.

Aktív válasz: automatizált támadásblokkolás

Az aktív válasz (Active Response) modul lehetővé teszi, hogy egy riasztásra a Wazuh automatikusan szkriptet futtasson a célgépen: blokkoljon egy IP-címet, felfüggesszen egy felhasználói fiókot vagy karanténba helyezzen egy fájlt. Az alábbi konfiguráció minden 10-es szinten túli SSH brute-force kísérletre 1 órára blokkolja a támadó IP-jét nftables segítségével:

<!-- Wazuh manager: ossec.conf -->
<command>
  <name>nft-block</name>
  <executable>firewall-drop</executable>
  <timeout_allowed>yes</timeout_allowed>
</command>

<active-response>
  <command>nft-block</command>
  <location>local</location>
  <rules_id>5712,5710</rules_id> <!-- SSH brute force szabályok -->
  <timeout>3600</timeout>
</active-response>

Wazuh vs Elastic Security és más SIEM-ek

2026-ban a nyílt forráskódú SIEM piacon a Wazuh, az Elastic Security és a Graylog versengenek elsősorban. Az alábbi összehasonlító táblázat a legfontosabb kritériumokat foglalja össze production szempontból:

Jellemző	Wazuh 4.11	Elastic Security 8.x	Graylog Open 6.x
Licenc	Apache 2.0 (teljes)	Elastic 2.0 (vegyes)	SSPL
Beépített EDR/HIDS	Igen (FIM, rootkit, syscall)	Igen (Elastic Agent)	Nincs (külső ügynök kell)
MITRE ATT&CK leképezés	700+ szabály	1100+ detection rules	Korlátozott (community)
Megfelelőségi sablonok	PCI, NIST, HIPAA, GDPR, TSC	Részben fizetős	Bővítményekkel
Sebezhetőség-szkennelés	Beépített, ügynök-alapú	Nincs natív	Nincs
Erőforrásigény (manager)	4 vCPU / 8 GB RAM	8 vCPU / 16 GB RAM	4 vCPU / 8 GB RAM
Tanulási görbe	Közepes	Meredek	Enyhe
Kereskedelmi támogatás	Wazuh Inc., partnerek	Elastic Inc.	Graylog Inc.

A Wazuh azoknak ideális, akik egy egységes platformban szeretnének SIEM-et, XDR-t, FIM-et és megfelelőségi auditálást, különösen, ha a költségvetés korlátozott, mert a teljes funkciókészlet ingyenes. Az Elastic Security fejlettebb ML-alapú detektálást és nagyobb sebességet kínál nagy adatmennyiségnél, de a fontos funkciók (pl. session view, cloud security posture) csak fizetős előfizetésben elérhetők.

Skálázási és üzemeltetési tippek production-ben

Egy egyetlen Wazuh manager kb. 2500–3000 ügynököt képes kiszolgálni, ha a hardver megfelelő (16 vCPU, 32 GB RAM, NVMe SSD). Ennél nagyobb környezetben Wazuh klasztert érdemes építeni master/worker topológiával, és az indexer rétegben legalább 3 OpenSearch node-ot kell beállítani, hot–warm–cold lifecycle policy-vel.

Index lifecycle management (ILM): állítsd be a Wazuh dashboardon, hogy a 30 napnál régebbi indexek warm node-ra kerüljenek, és 90 nap után automatikusan törlődjenek vagy snapshotba kerüljenek.
Csoportonkénti konfiguráció: használj agent-groups elnevezést (pl. linux-prod, linux-dev, k8s-nodes), így csoportonként eltérő FIM és naplószabályok érvényesíthetők.
Backup: heti rendszerességgel mentsd a /var/ossec/etc könyvtárat, és az OpenSearch snapshot API-t használd a riasztás-index mentéséhez.
Monitorozás: Wazuh agentet telepíts a manager szerverre is, így a Wazuh monitorozza önmagát, és riaszt, ha az indexer queue megtelik.
Frissítés: a Wazuh minor verziók (pl. 4.10 → 4.11) automatizálhatók Ansible-lel; major upgrade előtt mindig készíts indexer snapshotot.

Gyakran ismételt kérdések

Mi a különbség a Wazuh és az OSSEC között?

A Wazuh az OSSEC HIDS forkja, amely 2015 óta fejlődik önállóan. Lényegesen kibővített funkciókészletet kínál: webes dashboardot, OpenSearch-alapú indexálást, sebezhetőség-detektálást, MITRE ATT&CK leképezést és megfelelőségi sablonokat. Új projektekhez 2026-ban már egyértelműen a Wazuh az ajánlott, az OSSEC-et nem érdemes új környezetekben telepíteni.

Hogyan védjem a Wazuh manager és ügynök közötti kommunikációt?

A Wazuh alapból TLS 1.2/1.3-mal titkosítja a kommunikációt, és kölcsönös tanúsítvány-alapú hitelesítést támogat. Production-ben tiltsd le a jelszavas regisztrációt (authd), és csak előre kiosztott TLS tanúsítványokkal engedélyezz új ügynököket. A 1514-es TCP portot zárd le tűzfallal a publikus internet felé.

Lehet a Wazuh-t Kubernetes-ben futtatni?

Igen, hivatalos Helm chart elérhető, amely külön Deploymentekbe telepíti a managert, az indexert és a dashboardot. Ezen felül a DaemonSet-ként telepített Wazuh ügynök monitorozza a node-okat és a konténereket. eBPF-alapú runtime megoldásokkal kombinálva mély konténer-szintű láthatóság érhető el.

Mennyi tárolóhely szükséges a Wazuh indexerhez?

Általános ökölszabály: 200–500 MB nyers napló / nap / ügynök. Tehát 100 ügynöknél kb. 30–50 GB / nap, vagyis ha 90 napos retention-t tartunk, 3–5 TB SSD szükséges. ILM policy-vel és warm node-okra mozgatással ez nagyban csökkenthető. Mindig hagyj 30% szabad helyet az OpenSearch shard rebalance-hoz.

A Wazuh helyettesíti a tűzfalat és vírusirtót?

Nem, a Wazuh kiegészíti, nem helyettesíti ezeket. A tűzfal (pl. nftables, firewalld) hálózati szinten szűr, a Wazuh pedig host-szinten figyel és reagál. Bár az aktív válasz modul tud csomagokat blokkolni, ez nem helyettesít egy dedikált perimeter tűzfalat vagy az endpoint-on futó AV-t. A három réteg együtt ad teljes védelmet.