Wazuh ako open-source SIEM a XDR pre Linux: Sprievodca nasadením a detekciou hrozieb

Úvod: Prečo potrebujete centralizovaný bezpečnostný monitoring

Predstavte si tento scenár: spravujete desiatky Linux serverov — webové servery, databázové servery, CI/CD infraštruktúru, kontajnerové klastre. Na každom máte nakonfigurovaný firewall, SSH je zabezpečené podľa najnovších odporúčaní, kontajnery bežia v rootless režime. Všetko vyzerá v poriadku.

Ale ruku na srdce — viete skutočne, čo sa na vašich serveroch deje práve teraz?

Podľa správy Mandiant M-Trends z roku 2025 je priemerný čas detekcie narušenia bezpečnosti (tzv. dwell time) stále 10 dní v organizáciách, ktoré incidenty detegujú interne. A u tých, kde narušenie odhalia externé strany? Dokonca viac ako 30 dní. Zamyslite sa nad tým — útočník má v priemere minimálne desať dní na to, aby sa pohyboval po vašej infraštruktúre, exfiltroval dáta a pripravil si perzistentný prístup. To je dosť desivé číslo.

Individuálne zabezpečenie jednotlivých serverov je samozrejme nevyhnutné, ale bez centralizovaného bezpečnostného monitoringu ste jednoducho slepí voči koordinovaným útokom, laterálnemu pohybu a sofistikovanejším hrozbám. A práve tu prichádza na scénu Wazuh — open-source platforma, ktorá kombinuje funkcie SIEM (Security Information and Event Management) a XDR (Extended Detection and Response) v jednom riešení.

V tomto článku si ukážeme, ako Wazuh nasadiť, nakonfigurovať a efektívne využívať na ochranu vašej Linux infraštruktúry. Pokryjeme všetko od inštalácie cez monitoring integrity súborov až po detekciu zraniteľností a integráciu s frameworkom MITRE ATT&CK. Tak poďme na to.

Čo je Wazuh a prečo práve on

Wazuh vznikol v roku 2015 ako fork projektu OSSEC — historicky najrozšírenejšieho open-source HIDS systému. Kým OSSEC zostal prakticky v režime údržby s minimálnym vývojom od roku 2021, Wazuh sa vyvinul do plnohodnotnej bezpečnostnej platformy s aktívnou komunitou a pravidelnými vydaniami. Najnovšia stabilná verzia je Wazuh 4.12 a musím povedať, že oproti starším verziám je to obrovský skok vpred.

Architektúra platformy

Wazuh sa skladá z troch hlavných serverových komponentov a agentov:

• Wazuh Server (Manager) — centrálny komponent, ktorý prijíma a analyzuje dáta od agentov, vyhodnocuje pravidlá, generuje upozornenia a riadi aktívnu odpoveď
• Wazuh Indexer — úložisko založené na OpenSearch, kde sa indexujú a uchovávajú všetky bezpečnostné udalosti
• Wazuh Dashboard — webové rozhranie postavené na OpenSearch Dashboards s vizualizáciami, grafmi a interaktívnymi panelmi
• Wazuh Agent — ľahký agent inštalovaný na monitorované endpointy (Linux, Windows, macOS), ktorý zbiera systémové dáta a odosiela ich na server

Kľúčové funkcie

Prečo som si Wazuh obľúbil? Pozrite sa na ten zoznam funkcií relevantných pre Linux administrátorov:

1. Detekcia narušenia (HIDS) — analýza logov a korelácia udalostí v reálnom čase
2. Monitoring integrity súborov (FIM) — detekcia zmien v kritických systémových súboroch
3. Detekcia zraniteľností — identifikácia CVE v nainštalovaných balíčkoch
4. Bezpečnostná konfiguračná analýza (SCA) — kontrola súladu s CIS benchmarkami
5. Detekcia rootkitov — vyhľadávanie skrytých procesov, súborov a anomálií
6. Aktívna odpoveď — automatická reakcia na detegované hrozby
7. Mapovanie MITRE ATT&CK — priradenie detegovaných techník k frameworku MITRE
8. Zhoda s reguláciami — podpora PCI DSS, HIPAA, NIST 800-53, GDPR

Úprimne, takéto pokrytie by ste od komerčného nástroja čakali za tisíce eur ročne.

Inštalácia Wazuh servera

Wazuh ponúka dva spôsoby inštalácie — asistovanú (pomocou inštalačného skriptu) a manuálnu (krok za krokom). Pre väčšinu nasadení odporúčam asistovanú inštaláciu, pretože automatizuje celý proces a ušetrí vám kopec času.

Systémové požiadavky

Pre produkčné nasadenie s monitoringom desiatkov agentov budete potrebovať:

• CPU: minimálne 4 jadrá (odporúčaných 8)
• RAM: minimálne 8 GB (odporúčaných 16 GB)
• Disk: minimálne 50 GB SSD (300–500 GB pre väčšie nasadenia)
• OS: Ubuntu 22.04/24.04 LTS, RHEL 8/9, CentOS Stream 9, Debian 12

Asistovaná inštalácia (all-in-one)

Na jednom serveri nainštalujete všetky tri komponenty — indexer, manager a dashboard. Je to prekvapivo jednoduché:

# Stiahnutie a spustenie inštalačného skriptu
curl -sO https://packages.wazuh.com/4.12/wazuh-install.sh
sudo bash ./wazuh-install.sh -a

Skript automaticky:

• Nainštaluje Wazuh Indexer a vygeneruje SSL certifikáty
• Nainštaluje a nakonfiguruje Wazuh Manager
• Nainštaluje Wazuh Dashboard
• Zobrazí prihlasovacie údaje do webového rozhrania

Dôležité: Prihlasovacie údaje sa zobrazia iba raz — uložte si ich bezpečne ihneď po inštalácii! Vážne, zapíšte si ich hneď, lebo potom budete musieť resetovať heslá manuálne.

# Po dokončení inštalácie sa zobrazí niečo ako:
# INFO: --- Summary ---
# INFO: You can access the web interface https://<wazuh-dashboard-ip>:443
# INFO:     User: admin
# INFO:     Password: <RANDOM_PASSWORD>

Overenie funkčnosti

Po inštalácii si skontrolujte stav všetkých služieb:

# Kontrola stavu Wazuh Managera
sudo systemctl status wazuh-manager

# Kontrola stavu Wazuh Indexera
sudo systemctl status wazuh-indexer

# Kontrola stavu Wazuh Dashboardu
sudo systemctl status wazuh-dashboard

# Overenie, že manager počúva na porte 1514 (komunikácia s agentmi)
sudo ss -tlnp | grep 1514

# Overenie, že dashboard počúva na porte 443
sudo ss -tlnp | grep 443

Nasadenie agentov na Linux servery

Samotný Wazuh server bez agentov je ako bezpečnostná kamera bez objektívu — vyzerá dobre, ale nič nevidí. Skutočná sila platformy spočíva v agentoch, ktoré zbierajú dáta z monitorovaných systémov.

Inštalácia agenta na Ubuntu/Debian

# Pridanie GPG kľúča a repozitára
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

# Inštalácia agenta s premennou WAZUH_MANAGER
sudo WAZUH_MANAGER="10.0.0.100" apt-get install wazuh-agent

# Povolenie a spustenie služby
sudo systemctl daemon-reload
sudo systemctl enable wazuh-agent
sudo systemctl start wazuh-agent

Inštalácia agenta na RHEL/CentOS/Fedora

# Pridanie repozitára
sudo rpm --import https://packages.wazuh.com/key/GPG-KEY-WAZUH

cat << EOF | sudo tee /etc/yum.repos.d/wazuh.repo
[wazuh]
gpgcheck=1
gpgkey=https://packages.wazuh.com/key/GPG-KEY-WAZUH
enabled=1
name=EL-\$releasever - Wazuh
baseurl=https://packages.wazuh.com/4.x/yum/
protect=1
EOF

# Inštalácia agenta
sudo WAZUH_MANAGER="10.0.0.100" yum install wazuh-agent

# Povolenie a spustenie služby
sudo systemctl daemon-reload
sudo systemctl enable wazuh-agent
sudo systemctl start wazuh-agent

Overenie pripojenia agenta

Na strane servera si skontrolujte, či sa agent úspešne pripojil:

# Zobrazenie pripojených agentov
sudo /var/ossec/bin/agent_control -l

# Alebo cez Wazuh API
curl -k -u admin:<heslo> "https://localhost:55000/agents?pretty"

Ak všetko funguje správne, mali by ste vidieť svojho agenta v stave „Active". Ak nie, skontrolujte firewall pravidlá — port 1514 musí byť otvorený.

Monitoring integrity súborov (FIM)

Toto je podľa mňa jedna z najdôležitejších funkcií pre detekciu narušenia bezpečnosti. FIM modul sleduje zmeny v súboroch a adresároch a generuje upozornenia, keď niekto súbor vytvorí, zmení alebo vymaže. Jednoducho povedané — ak sa niečo na vašom serveri zmení, budete o tom vedieť.

Ako FIM funguje

FIM modul pracuje v troch režimoch:

• Plánované skenovanie (Scheduled) — periodické kompletné skenovanie monitorovaných adresárov (predvolený interval: 12 hodín)
• Reálny čas (Realtime) — využíva inotify subsystém jadra Linuxu na okamžitú detekciu zmien
• Who-data — rozšírenie real-time režimu, ktoré cez auditd zachytáva aj informáciu o tom, kto zmenu vykonal (a toto je naozaj užitočné pri forenznej analýze)

Konfigurácia FIM na agentovi

Konfiguračný súbor agenta sa nachádza v /var/ossec/etc/ossec.conf. Sekcia <syscheck> definuje, čo sa má monitorovať:

<syscheck>
  <!-- Interval plánovaného skenovania (v sekundách) -->
  <frequency>3600</frequency>

  <!-- Monitorovanie kritických systémových adresárov -->
  <directories check_all="yes" realtime="yes">/etc</directories>
  <directories check_all="yes" realtime="yes">/usr/bin</directories>
  <directories check_all="yes" realtime="yes">/usr/sbin</directories>
  <directories check_all="yes" realtime="yes">/boot</directories>

  <!-- Monitorovanie webových súborov -->
  <directories check_all="yes" realtime="yes" report_changes="yes">/var/www/html</directories>

  <!-- Monitorovanie SSH konfigurácie s who-data -->
  <directories check_all="yes" whodata="yes">/etc/ssh</directories>

  <!-- Monitorovanie cron úloh -->
  <directories check_all="yes" realtime="yes">/etc/cron.d</directories>
  <directories check_all="yes" realtime="yes">/var/spool/cron</directories>

  <!-- Ignorovanie súborov generujúcich zbytočný šum -->
  <ignore>/etc/mtab</ignore>
  <ignore>/etc/resolv.conf</ignore>
  <ignore type="sregex">.log$|.swp$</ignore>

  <!-- Monitorovanie zmien v registri procesov -->
  <directories check_all="yes" realtime="yes">/proc/1/exe</directories>
</syscheck>

Atribút report_changes="yes" je obzvlášť užitočný pre textové súbory — Wazuh zaznamená presný diff zmien, takže vidíte nielen že sa súbor zmenil, ale aj čo presne sa zmenilo. To oceníte hlavne pri forenznej analýze.

Vlastné pravidlá pre FIM

Wazuh obsahuje vstavaný súbor pravidiel pre FIM, ale môžete si vytvoriť vlastné pravidlá na serveri v /var/ossec/etc/rules/local_rules.xml:

<group name="syscheck,custom_fim,">
  <!-- Kritické upozornenie pri zmene SSH konfigurácie -->
  <rule id="100200" level="12">
    <if_sid>550</if_sid>
    <field name="file">/etc/ssh/sshd_config</field>
    <description>Kritická zmena: Konfiguračný súbor SSH bol modifikovaný.</description>
    <mitre>
      <id>T1098</id>
    </mitre>
  </rule>

  <!-- Upozornenie pri zmene sudoers -->
  <rule id="100201" level="14">
    <if_sid>550</if_sid>
    <field name="file">/etc/sudoers</field>
    <description>VAROVANIE: Súbor sudoers bol zmenený — možný pokus o eskaláciu oprávnení.</description>
    <mitre>
      <id>T1548.003</id>
    </mitre>
  </rule>

  <!-- Detekcia nového SUID binárneho súboru -->
  <rule id="100202" level="13">
    <if_sid>554</if_sid>
    <field name="file">/usr/bin|/usr/sbin|/usr/local/bin</field>
    <description>Nový súbor detegovaný v systémovom adresári — vyžaduje preskúmanie.</description>
    <mitre>
      <id>T1574</id>
    </mitre>
  </rule>
</group>

Detekcia zraniteľností

Jedna z najcennejších funkcií Wazuh (a osobne tá, kvôli ktorej som ho začal používať) je automatická detekcia zraniteľností v nainštalovaných softvérových balíčkoch. Táto funkcia vám umožňuje identifikovať známe CVE vo vašej infraštruktúre bez nutnosti manuálneho skenovania.

Ako detekcia funguje

Celý proces má dve fázy:

1. Zber inventára: Wazuh agent používa modul Syscollector na zhromaždenie detailného inventára systému — informácie o OS, nainštalovaných balíčkoch a ich verziách
2. Korelácia s CVE: Wazuh server porovnáva inventár s databázou zraniteľností z platformy Wazuh Cyber Threat Intelligence (CTI), ktorá agreguje informácie z NVD, Canonical, Red Hat, Debian, Amazon Linux a ďalších zdrojov

Konfigurácia detekcie zraniteľností

Na strane servera v súbore /var/ossec/etc/ossec.conf skontrolujte, že modul detekcie zraniteľností je povolený:

<vulnerability-detection>
  <enabled>yes</enabled>
  <index-status>yes</index-status>
  <feed-update-interval>60m</feed-update-interval>
</vulnerability-detection>

Na strane agenta sa uistite, že Syscollector je aktívny:

<wodle name="syscollector">
  <disabled>no</disabled>
  <interval>1h</interval>
  <scan_on_start>yes</scan_on_start>
  <hardware>yes</hardware>
  <os>yes</os>
  <network>yes</network>
  <packages>yes</packages>
  <ports all="no">yes</ports>
  <processes>yes</processes>
</wodle>

Po konfigurácii sa v Wazuh Dashboard objavia upozornenia na zraniteľné balíčky s priradením CVE ID, CVSS skóre a odporúčaním na opravu.

Praktický príklad: Identifikácia kritickej zraniteľnosti

Keď Wazuh deteguje zraniteľný balíček, vygeneruje upozornenie podobné tomuto:

{
  "rule": {
    "level": 10,
    "description": "CVE-2024-6387 affects openssh-server 1:8.9p1-3ubuntu0.6",
    "id": "23505"
  },
  "data": {
    "vulnerability": {
      "package": {
        "name": "openssh-server",
        "version": "1:8.9p1-3ubuntu0.6"
      },
      "cve": "CVE-2024-6387",
      "title": "regreSSHion: RCE in OpenSSH server",
      "severity": "High",
      "cvss": {
        "cvss3": {
          "base_score": 8.1
        }
      },
      "reference": "https://nvd.nist.gov/vuln/detail/CVE-2024-6387",
      "status": "ACTIVE"
    }
  }
}

Takéto upozornenie vám umožní okamžite reagovať a aktualizovať zraniteľný balíček skôr, ako ho útočník zneužije. V prípade regreSSHion (CVE-2024-6387) to bolo kriticky dôležité, keďže šlo o vzdialené spustenie kódu v OpenSSH.

Bezpečnostná konfiguračná analýza (SCA) a CIS benchmarky

Wazuh obsahuje modul Security Configuration Assessment (SCA), ktorý automaticky kontroluje konfiguráciu vašich systémov voči CIS benchmarkom a ďalším bezpečnostným štandardom. Toto je niečo, čo by ste inak museli robiť manuálne alebo si kúpiť separátny nástroj.

Predvolené SCA politiky

Wazuh dodáva predvolené SCA politiky pre rôzne distribúcie:

• CIS benchmark pre Ubuntu Linux 22.04/24.04
• CIS benchmark pre RHEL 8/9
• CIS benchmark pre Debian 11/12
• CIS benchmark pre Amazon Linux 2/2023

Tieto politiky sa automaticky spúšťajú pri prvom spustení agenta a potom periodicky.

Konfigurácia SCA

V konfiguračnom súbore agenta (/var/ossec/etc/ossec.conf) môžete prispôsobiť správanie SCA modulu:

<sca>
  <enabled>yes</enabled>
  <scan_on_start>yes</scan_on_start>
  <interval>12h</interval>
  <skip_nfs>yes</skip_nfs>

  <!-- Povolenie špecifických politík -->
  <policies>
    <policy>cis_ubuntu22-04.yml</policy>
  </policies>
</sca>

Vlastné SCA kontroly

Okrem predvolených CIS benchmarkov si môžete vytvoriť vlastné SCA kontroly. To je podľa mňa jedna z najsilnejších stránok Wazuhu — môžete si nadefinovať presne tie kontroly, ktoré dávajú zmysel pre vašu infraštruktúru. Vytvorte YAML súbor v adresári /var/ossec/etc/shared/:

# /var/ossec/etc/shared/custom_linux_checks.yml
policy:
  id: "custom_linux_security"
  file: "custom_linux_checks.yml"
  name: "Vlastné bezpečnostné kontroly Linux"
  description: "Kontroly špecifické pre našu infraštruktúru"

requirements:
  title: "Kontrola, či beží na Linux systéme"
  description: "Požiadavky pre spustenie kontroly"
  condition: all
  rules:
    - 'f:/etc/os-release'

checks:
  - id: 90001
    title: "SSH: Root prihlásenie je zakázané"
    description: "Kontrola, že PermitRootLogin je nastavený na no"
    rationale: "Priame prihlásenie ako root zvyšuje riziko kompromitácie"
    remediation: "Nastavte PermitRootLogin no v /etc/ssh/sshd_config"
    condition: all
    rules:
      - 'f:/etc/ssh/sshd_config -> r:^PermitRootLogin\s+no'

  - id: 90002
    title: "Firewall: nftables je aktívny"
    description: "Kontrola, či je nftables služba aktívna"
    rationale: "Firewall je základná vrstva obrany"
    remediation: "Spustite: systemctl enable --now nftables"
    condition: all
    rules:
      - 'c:systemctl is-active nftables -> r:^active'

  - id: 90003
    title: "Audit: auditd je spustený"
    description: "Kontrola, že audit démon je aktívny"
    rationale: "Auditd poskytuje detailný záznam systémových udalostí"
    remediation: "Spustite: systemctl enable --now auditd"
    condition: all
    rules:
      - 'c:systemctl is-active auditd -> r:^active'

  - id: 90004
    title: "Kernel: Address Space Layout Randomization je povolená"
    description: "Kontrola, že ASLR je nastavená na hodnotu 2 (plná randomizácia)"
    rationale: "ASLR sťažuje exploitáciu pamäťových zraniteľností"
    remediation: "Nastavte kernel.randomize_va_space = 2 v /etc/sysctl.conf"
    condition: all
    rules:
      - 'c:sysctl kernel.randomize_va_space -> r:kernel.randomize_va_space = 2'

Detekcia rootkitov a malvéru

Wazuh agent obsahuje vstavaný modul na detekciu rootkitov, ktorý monitoruje systém pomocou databázy známych signatúr a hľadá anomálie indikujúce prítomnosť skrytého škodlivého softvéru. Nie je to plná náhrada za špecializované antimalvérové riešenia, ale ako ďalšia vrstva obrany je to rozhodne lepšie ako nič.

Konfigurácia detekcie rootkitov

<rootcheck>
  <disabled>no</disabled>
  <check_files>yes</check_files>
  <check_trojans>yes</check_trojans>
  <check_dev>yes</check_dev>
  <check_sys>yes</check_sys>
  <check_pids>yes</check_pids>
  <check_ports>yes</check_ports>
  <check_if>yes</check_if>
  <frequency>43200</frequency>

  <!-- Databázy rootkit signatúr -->
  <rootkit_files>/var/ossec/etc/shared/rootkit_files.txt</rootkit_files>
  <rootkit_trojans>/var/ossec/etc/shared/rootkit_trojans.txt</rootkit_trojans>
</rootcheck>

Integrácia FIM s YARA pravidlami

Pre pokročilú detekciu malvéru môžete integrovať Wazuh FIM s YARA skenerom. Princíp je jednoduchý — keď FIM deteguje nový alebo zmenený súbor v monitorovanom adresári, automaticky spustí YARA sken:

# Inštalácia YARA na monitorovanom serveri
sudo apt-get install yara

# Stiahnutie YARA pravidiel
sudo mkdir -p /var/ossec/active-response/yara/rules
cd /var/ossec/active-response/yara/rules
sudo wget https://valhalla.nextron-systems.com/api/v1/get -O yara_rules.yar

Následne nakonfigurujte aktívnu odpoveď na serveri (/var/ossec/etc/ossec.conf):

<command>
  <name>yara_scan</name>
  <executable>yara.sh</executable>
  <timeout_allowed>no</timeout_allowed>
</command>

<active-response>
  <command>yara_scan</command>
  <location>local</location>
  <rules_id>550,554</rules_id>
</active-response>

Aktívna odpoveď na hrozby

Wazuh dokáže nielen detegovať hrozby, ale aj automaticky na ne reagovať. A to je presne to, čo oddeľuje dobrý monitoring od skvelého. Modul aktívnej odpovede (Active Response) spúšťa predefinované akcie pri splnení podmienok pravidiel.

Automatické blokovanie brute-force útokov

Jedným z najčastejších (a najužitočnejších) scenárov je automatické blokovanie IP adries, z ktorých prichádzajú opakované neúspešné pokusy o prihlásenie:

<!-- Na strane servera: /var/ossec/etc/ossec.conf -->
<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>5710,5712,5720</rules_id>
  <timeout>1800</timeout>
  <repeated_offenders>60,120,360,720</repeated_offenders>
</active-response>

Táto konfigurácia:

• Pravidlá 5710, 5712, 5720 detegujú opakované neúspešné SSH prihlásenia
• Príkaz firewall-drop pridá blokovacie pravidlo do firewallu
• Prvé zablokovanie trvá 30 minút (1800 sekúnd)
• Pri opakovaných pokusoch sa doba blokovania progresívne predlžuje: 60 minút, 2 hodiny, 6 hodín, 12 hodín

Progresívne predlžovanie blokovania je podľa mňa geniálne riešenie — oprávnený používateľ, ktorý sa raz pomýli, čaká len pol hodiny. Ale vytrvalý útočník je zablokovaný na stále dlhšie obdobia.

Vlastný skript aktívnej odpovede

Môžete si vytvoriť vlastné skripty pre špecifické reakcie. Napríklad skript, ktorý pri detekcii kritickej zmeny odošle notifikáciu cez Slack:

#!/bin/bash
# /var/ossec/active-response/bin/slack_notify.sh

LOCAL=$(dirname $0)
cd $LOCAL
cd ../

# Čítanie vstupu od Wazuh
read INPUT_JSON

ALERT_LEVEL=$(echo $INPUT_JSON | jq -r '.parameters.alert.rule.level')
ALERT_DESC=$(echo $INPUT_JSON | jq -r '.parameters.alert.rule.description')
AGENT_NAME=$(echo $INPUT_JSON | jq -r '.parameters.alert.agent.name')
TIMESTAMP=$(echo $INPUT_JSON | jq -r '.parameters.alert.timestamp')

WEBHOOK_URL="https://hooks.slack.com/services/TXXXXX/BXXXXX/XXXXXXXXX"

# Odoslanie notifikácie
curl -s -X POST "$WEBHOOK_URL" \
  -H "Content-type: application/json" \
  -d "{
    \"text\": \"*Wazuh Alert [Level ${ALERT_LEVEL}]*\n*Server:* ${AGENT_NAME}\n*Popis:* ${ALERT_DESC}\n*Čas:* ${TIMESTAMP}\"
  }"

exit 0;

Zaregistrujte skript v konfigurácii servera:

<command>
  <name>slack-notification</name>
  <executable>slack_notify.sh</executable>
  <timeout_allowed>no</timeout_allowed>
</command>

<active-response>
  <command>slack-notification</command>
  <location>server</location>
  <level>12</level>
</active-response>

Integrácia s MITRE ATT&CK

Wazuh obsahuje vstavanú integráciu s frameworkom MITRE ATT&CK, a úprimne — toto je podľa mňa jeden z jeho najsilnejších prvkov. Detekčné pravidlá Wazuh sú mapované na konkrétne taktiky, techniky a procedúry (TTP), čo vám umožňuje:

• Vizualizovať, aké typy útokov sa vyskytujú vo vašej infraštruktúre
• Identifikovať medzery v detekcii (ktoré techniky nemáte pokryté)
• Komunikovať bezpečnostné incidenty s použitím štandardizovanej terminológie
• Korelovať udalosti naprieč viacerými servermi pre odhalenie komplexných útokov

Príklad mapovania pravidiel na MITRE ATT&CK

V pravidlách Wazuh môžete pridať MITRE mapovanie pomocou tagu <mitre>:

<group name="linux,syslog,">
  <!-- Detekcia pokusu o vytvorenie nového používateľa -->
  <rule id="100300" level="10">
    <if_sid>5901</if_sid>
    <match>useradd</match>
    <description>Nový používateľ bol pridaný do systému.</description>
    <mitre>
      <id>T1136.001</id> <!-- Create Account: Local Account -->
    </mitre>
    <group>account_created,</group>
  </rule>

  <!-- Detekcia zmeny v cron úlohách -->
  <rule id="100301" level="8">
    <if_sid>550</if_sid>
    <field name="file">/etc/cron|/var/spool/cron</field>
    <description>Zmena v plánovaných úlohách — potenciálna perzistencia.</description>
    <mitre>
      <id>T1053.003</id> <!-- Scheduled Task/Job: Cron -->
    </mitre>
  </rule>

  <!-- Detekcia stiahnutia súborov z externých zdrojov -->
  <rule id="100302" level="8">
    <if_sid>530</if_sid>
    <match>wget|curl.*-o|curl.*--output</match>
    <description>Detekcia sťahovania súborov — možný staging malvéru.</description>
    <mitre>
      <id>T1105</id> <!-- Ingress Tool Transfer -->
    </mitre>
  </rule>
</group>

Vo Wazuh Dashboard potom nájdete sekciu MITRE ATT&CK, kde vidíte prehľadnú maticu so všetkými detegovanými technikami, ich frekvenciou a dopadom na vašu infraštruktúru. Je to vynikajúci spôsob, ako získať celkový prehľad o tom, akým hrozbám čelíte.

Monitorovanie kontajnerov a Kubernetes

Ak prevádzkujete kontajnerizované workloady — čo v roku 2026 robí drvivá väčšina organizácií — Wazuh dokáže monitorovať aj kontajnerové prostredie. A je fajn, že to nepotrebuje žiadne extra moduly.

Monitorovanie Docker kontajnerov

Wazuh agent dokáže monitorovať Docker udalosti cez modul Docker listener:

<!-- Konfigurácia na agentovi -->
<wodle name="docker-listener">
  <interval>10m</interval>
  <attempts>5</attempts>
  <run_on_start>yes</run_on_start>
  <disabled>no</disabled>
</wodle>

Tento modul zachytáva udalosti ako:

• Spustenie kontajnera v privilegovanom režime
• Zmeny sieťových nastavení kontajnerov
• Pripojenie citlivých hostiteľských zväzkov
• Spustenie kontajnera s nebezpečnými capabilities

Integrácia s Kubernetes audit logmi

Pre Kubernetes prostredia môžete nakonfigurovať Wazuh na čítanie audit logov Kubernetes API servera:

<localfile>
  <log_format>json</log_format>
  <location>/var/log/kubernetes/audit/audit.log</location>
</localfile>

Wazuh potom analyzuje tieto logy a dokáže detegovať podozrivé aktivity ako:

• Neoprávnený prístup k Kubernetes secrets
• Vytvorenie privilegovaného podu
• Zmeny v RBAC politikách
• Pokus o exec do bežiaceho kontajnera

Analýza logov a vlastné dekodéry

Wazuh používa dekodéry na parsovanie príchodzích logov a pravidlá na generovanie upozornení. Pre aplikácie s vlastným formátom logov si môžete (a mali by ste) vytvoriť vlastné dekodéry.

Príklad vlastného dekodéra pre webovú aplikáciu

Povedzme, že vaša aplikácia loguje neúspešné prihlásenia v tomto formáte:

2026-02-17 10:23:45 AUTH_FAIL user=admin src_ip=192.168.1.50 reason=invalid_password

Vytvorte dekodér v /var/ossec/etc/decoders/local_decoder.xml:

<decoder name="custom_app_auth">
  <program_name>myapp</program_name>
  <prematch>AUTH_FAIL</prematch>
  <regex>AUTH_FAIL user=(\S+) src_ip=(\S+) reason=(\S+)</regex>
  <order>user,srcip,extra_data</order>
</decoder>

A pravidlo v /var/ossec/etc/rules/local_rules.xml:

<group name="custom_app,authentication,">
  <rule id="100400" level="5">
    <decoded_as>custom_app_auth</decoded_as>
    <description>Neúspešný pokus o prihlásenie do aplikácie od používateľa $(user) z IP $(srcip).</description>
    <mitre>
      <id>T1110</id>
    </mitre>
  </rule>

  <rule id="100401" level="10" frequency="5" timeframe="120">
    <if_matched_sid>100400</if_matched_sid>
    <same_source_ip />
    <description>Opakované neúspešné prihlásenia z rovnakej IP — možný brute-force útok.</description>
    <mitre>
      <id>T1110.001</id>
    </mitre>
  </rule>
</group>

Najlepšie praktiky pre produkčné nasadenie

Na záver som zostavil súbor odporúčaní, ktoré vám pomôžu vyťažiť z Wazuh maximum v produkčnom prostredí. Niektoré z nich som sa naučil na vlastnej koži.

1. Správa pravidiel a eliminácia šumu

• Začnite konzervatívne — nepovoľujte všetky pravidlá naraz. Začnite s predvolenými a postupne pridávajte vlastné
• Nastavte vhodné úrovne upozornení — v ossec.conf na serveri nastavte <alerts><log_alert_level>5</log_alert_level></alerts> a postupne znižujte
• Používajte pravidlá úrovne 0 na potlačenie falošných pozitív pre známe bezpečné operácie
• Pravidelne revidujte upozornenia a upravujte pravidlá podľa reality vašej infraštruktúry

2. Výkon a škálovateľnosť

• Distribuované nasadenie — pre viac ako 100 agentov zvážte oddelenie indexera a managera na samostatné servery
• Rotácia indexov — nakonfigurujte automatické mazanie starých indexov podľa retenčnej politiky
• Optimalizácia FIM — monitorujte len skutočne dôležité adresáre, nie celý súborový systém (to je častá chyba začiatočníkov)
• Nastavte vhodné intervaly — nie každá kontrola musí bežať každú hodinu

3. Bezpečnosť samotného Wazuh

• Zmeňte predvolené heslá okamžite po inštalácii
• Obmedzte prístup k dashboardu pomocou firewallu len na oprávnené IP adresy
• Používajte TLS komunikáciu medzi agentmi a serverom (predvolene povolené)
• Zálohujte konfiguráciu a pravidlá pravidelne
• Monitorujte samotný Wazuh server — nainštalujte agent aj na server (áno, kto stráži strážcov?)

4. Integrácia do existujúcej infraštruktúry

• SIEM integrácia — Wazuh môže posielať upozornenia do externých SIEM riešení cez Syslog alebo API
• Ticketovací systém — integrujte aktívnu odpoveď s vaším ticketovacím systémom (Jira, ServiceNow)
• ChatOps — nastavte notifikácie do Slack, Microsoft Teams alebo Mattermost pre kritické upozornenia
• Automatizácia — použite Wazuh API na automatizáciu správy agentov a pravidiel v CI/CD pipeline

Záver: Wazuh ako základ bezpečnostného monitoringu

Wazuh nie je len ďalší bezpečnostný nástroj — je to kompletná platforma, ktorá dokáže nahradiť niekoľko samostatných riešení. Kombinuje HIDS, SIEM, detekciu zraniteľností, monitoring integrity súborov, kontrolu súladu s benchmarkami a aktívnu odpoveď v jednom open-source balíku.

Pre Linux administrátorov a DevSecOps tímy predstavuje Wazuh ideálny základ bezpečnostného monitoringu. Ak ste doteraz spoliehali len na individuálne nástroje ako Fail2Ban pre SSH, AIDE pre integritu súborov alebo manuálne skenovanie zraniteľností — Wazuh vám umožní toto všetko centralizovať, korelovať a automatizovať.

Kľúčové výhody oproti komerčným alternatívam:

• Žiadne licenčné poplatky — úplne open-source pod licenciou GNU GPLv2
• Aktívna komunita — pravidelné aktualizácie, podpora a dokumentácia
• Plná kontrola nad dátami — vaše dáta zostávajú vo vašej infraštruktúre
• Flexibilita — prispôsobiteľné pravidlá, dekodéry a aktívne odpovede

Začnite s jedným serverom, nasaďte agentov na kritickú infraštruktúru a postupne rozširujte pokrytie. Investícia času do nasadenia Wazuh sa vám vráti v podobe rýchlejšej detekcie, lepšieho prehľadu a automatizovanej odpovede na bezpečnostné incidenty. A keď o pol roka budete mať desiatky agentov a prehľadný dashboard s MITRE maticou — poďakujete si, že ste začali.