HIDS - Neue Techniken

Wazuh Server

• Wazuh aufsetzen Template

Wazuh-Agent auf Debian- und Rocky-Clients

Debian und Rocky sind hier reine Hardening-Übungsclients (kein Webserver, keine spezifische Rolle) — der Agent liefert Host-Telemetrie ans SIEM und führt bei den letzten beiden POCs auch aktiv Gegenmaßnahmen aus (HIPS-Teil). Die Installation unterscheidet sich nur beim Paketmanager (apt vs. dnf), danach läuft auf beiden Distributionen exakt dieselbe Konfiguration. Manager in diesem Artikel: wazuh.it2XX.int.

Agent-Installation auf Debian

Repository einrichten

GPG-Schlüssel importieren

curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --no-default-keyring --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import
chmod 644 /usr/share/keyrings/wazuh.gpg

Repository hinzufügen

echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" > /etc/apt/sources.list.d/wazuh.list
apt update

Agent installieren

Agent mit Manager-Adresse installieren

WAZUH_MANAGER="wazuh.it2XX.int" apt install -y wazuh-agent

Dienst aktivieren und starten

systemctl daemon-reload
systemctl enable --now wazuh-agent

Repository deaktivieren (verhindert ungewollte Updates)

sed -i "s/^deb /#deb /" /etc/apt/sources.list.d/wazuh.list
apt update

Agent-Installation auf Rocky

Repository einrichten

GPG-Schlüssel importieren

rpm --import https://packages.wazuh.com/key/GPG-KEY-WAZUH

Repository hinzufügen

cat > /etc/yum.repos.d/wazuh.repo << 'EOF'
[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

Agent installieren

Agent mit Manager-Adresse installieren

WAZUH_MANAGER="wazuh.it2XX.int" dnf install -y wazuh-agent

Dienst aktivieren und starten

systemctl daemon-reload
systemctl enable --now wazuh-agent

Repository deaktivieren (verhindert ungewollte Updates)

sed -i "s/^enabled=1/enabled=0/" /etc/yum.repos.d/wazuh.repo

Kontrolle (beide Clients)

• Öffne das Wazuh-Dashboard, gehe zu Agent Management → Summary und prüfe, ob debian-host und rocky-host mit Status Active erscheinen.

---

POC 1: Syscheck (FIM) auf sicherheitsrelevante Pfade

FIM (File Integrity Monitoring) überwacht die Integrität kritischer Dateien auf jedem Host – es erkennt, wenn Dateien wie SSH-Keys, Cron-Jobs, sudoers oder die Passwort-/Shadow-Datei unerwartet verändert werden. Das sind klassische Ziele, über die sich Angreifer dauerhaften Zugriff verschaffen oder Rechte ausweiten (z.B. ein zusätzlicher SSH-Key in authorized_keys, ein neuer Cron-Job als Persistenz-Mechanismus, oder eine manipulierte sudoers-Datei für Privilege Escalation).

Ergänze in /var/ossec/etc/ossec.conf den syscheck-Block

<syscheck>
  <directories check_all="yes" report_changes="yes" realtime="yes">/etc/ssh, /root/.ssh, /home/*/.ssh</directories>
  <directories check_all="yes" realtime="yes">/etc/cron.d, /etc/cron.daily, /var/spool/cron</directories>
  <directories check_all="yes" realtime="yes">/etc/sudoers.d</directories>
  <directories check_all="yes">/etc/passwd, /etc/shadow, /etc/sudoers</directories>
</syscheck>

• realtime="yes" funktioniert für Verzeichnisse (inotify) — einzelne Dateien wie /etc/passwd werden weiterhin nur im periodischen Scan geprüft (Standard: alle 12h), da inotify hier nicht greift.
• report_changes="yes" zeigt bei Textdateien ein Diff im Alert — bei einer neuen authorized_keys-Zeile siehst du sofort, welcher Key hinzugefügt wurde.

Agent neu starten

systemctl restart wazuh-agent

Kontrolle

• Test von der Konsole des Clients:

  echo "ssh-ed25519 AAAA...test angreifer@kali" >> /root/.ssh/authorized_keys
  

• Öffne im Dashboard Threat Hunting und filtere auf rule.groups:syscheck
• Alert "File modified" (Rule 550/554-Familie) für authorized_keys muss erscheinen, im Diff steht die neue Zeile.

POC 2: Rootcheck (Rootkit-/Anomalieerkennung)

Rootcheck ist Wazuhs eingebauter Scanner für versteckte Prozesse/Ports und bekannte Trojaner-Signaturen — der Teil, der rkhunter/chkrootkit ersetzt. Er läuft standardmäßig aktiv, Frequenz und Umfang lassen sich anpassen.

Prüfe/ergänze in /var/ossec/etc/ossec.conf

<rootcheck>
  <disabled>no</disabled>
  <check_unixaudit>yes</check_unixaudit>
  <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>
  <frequency>3600</frequency>
</rootcheck>

• check_pids/check_ports vergleichen, was der Kernel meldet, gegen das, was Tools wie ps/netstat anzeigen — die klassische Rootkit-Erkennungsmethode (Prozess versteckt sich vor Userland-Tools, ist aber im Kernel sichtbar).
• check_trojans matcht Systembinaries gegen bekannte Trojaner-Signaturen (/var/ossec/etc/shared/rootkit_trojans.txt).
• frequency auf 3600s runtergesetzt, damit ihr in der Übung nicht 12h auf den nächsten Scan warten müsst.

Agent neu starten

systemctl restart wazuh-agent

Kontrolle

• Rootcheck lässt sich nicht einfach durch eine harmlose Aktion auslösen (das ist ja der Zweck) — zur Kontrolle reicht es, den erfolgreichen Scan-Lauf zu prüfen:

  tail -f /var/ossec/logs/ossec.log | grep rootcheck
  

• Im Dashboard unter Threat Hunting filtere auf rule.groups:rootcheck — auf einem sauberen Client i.d.R. wenige/keine Alerts, das ist der Normalzustand.

POC 3: Security Configuration Assessment (SCA)

SCA prüft die Systemkonfiguration gegen CIS-Benchmarks — für Debian und die RHEL-Familie (Rocky) gibt es jeweils eigene, mitgelieferte Policies.

Verfügbare Policies prüfen

ls /var/ossec/ruleset/sca/

SCA in /var/ossec/etc/ossec.conf aktivieren (Policy-Datei je nach Ausgabe des obigen Befehls anpassen)

<sca>
  <enabled>yes</enabled>
  <scan_on_start>yes</scan_on_start>
  <interval>12h</interval>
  <policies>
    <policy>cis_debian_linux.yml</policy>  <!-- auf Rocky entsprechend: cis_rhel9_linux.yml o.ä. -->
  </policies>
</sca>

Agent neu starten

systemctl restart wazuh-agent

Kontrolle

• Im Dashboard: Security Configuration Assessment → Agent auswählen
• Zeigt Pass/Fail-Quote pro Policy sowie jeden einzelnen Check (z.B. "Ensure permissions on /etc/passwd are configured") mit Remediation-Hinweis
• Guter Vergleichspunkt Debian vs. Rocky: beide Policies prüfen ähnliche Punkte, aber mit unterschiedlichen Default-Ergebnissen (z.B. SELinux-Checks tauchen nur bei Rocky auf)

POC 4: Vulnerability Detection

Anders als die vorherigen POCs wird dieses Modul zentral auf dem Manager aktiviert, nicht im Agent-ossec.conf. Es matched installierte Pakete gegen CVE-Feeds — bei Debian den Debian Security Tracker, bei Rocky die Red-Hat-OVAL-Daten.

Auf dem Manager in /var/ossec/etc/ossec.conf prüfen/aktivieren

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

Manager neu starten

systemctl restart wazuh-manager

Kontrolle

• Im Dashboard: Vulnerability Detection → Agent auswählen (debian-host bzw. rocky-host)
• Auf so gut wie jedem frisch installierten System stehen bereits einige CVEs in der Liste — kein künstlicher Test nötig, ihr müsst nur nach Severity (Critical/High) sortieren
• Guter Vergleichspunkt: dieselbe Software (z.B. OpenSSL) taucht bei Debian und Rocky ggf. mit unterschiedlichem Patch-Stand und damit unterschiedlichen CVEs auf

POC 5: Active Response — SSH-Brute-Force mit nftables blocken

Das ist der eigentliche HIPS-Teil: Wazuh löst bei erkanntem Brute-Force selbstständig eine Gegenmaßnahme auf dem Client aus. Das mitgelieferte firewall-drop-Skript zielt auf iptables — da ihr nftables nutzt, bauen wir ein eigenes Skript.

nftables-Grundgerüst auf dem Client

Set und Drop-Regel anlegen (falls noch nicht vorhanden)

table inet filter {
    set blocklist {
        type ipv4_addr
        flags timeout
    }
    chain input {
        type filter hook input priority 0; policy accept;
        ip saddr @blocklist drop
    }
}

Active-Response-Skript auf dem Client

/var/ossec/active-response/bin/nft-drop anlegen

#!/bin/bash
read -r INPUT_JSON
COMMAND=$(echo "$INPUT_JSON" | jq -r .command)
IP=$(echo "$INPUT_JSON" | jq -r .parameters.alert.data.srcip)

case ${COMMAND} in
  add)
    nft add element inet filter blocklist "{ ${IP} timeout 30m }"
    ;;
  delete)
    nft delete element inet filter blocklist "{ ${IP} }"
    ;;
esac

Ausführbar machen

chmod 750 /var/ossec/active-response/bin/nft-drop
chown root:wazuh /var/ossec/active-response/bin/nft-drop

Konfiguration auf dem Manager

<command> und <active-response> in /var/ossec/etc/ossec.conf (Manager) ergänzen

<command>
  <name>nft-drop</name>
  <executable>nft-drop</executable>
  <timeout_allowed>yes</timeout_allowed>
</command>

<active-response>
  <command>nft-drop</command>
  <location>local</location>
  <rules_id>5712</rules_id>
  <timeout>1800</timeout>
</active-response>

• Rule 5712 ist Wazuhs eingebaute Brute-Force-Regel: 8 fehlgeschlagene SSH-Logins von derselben Quell-IP innerhalb von 120 Sekunden.
• timeout_allowed=yes + <timeout>1800</timeout> heißt: nach 30 Minuten entfernt Wazuh den Block automatisch selbst (ruft das Skript nochmal mit delete auf) — wichtig, damit sich niemand dauerhaft aussperrt.

Manager neu starten

systemctl restart wazuh-manager

Kontrolle

• Von der Kali aus 8+ fehlgeschlagene SSH-Logins gegen den Client, z.B.:

  hydra -l root -P /usr/share/wordlists/rockyou.txt -t 4 -f ssh://<client-ip>
  

• Auf dem Client: nft list set inet filter blocklist → Angreifer-IP muss mit Timeout auftauchen
• tail -f /var/ossec/logs/active-responses.log auf dem Client zeigt den add-Aufruf
• Im Dashboard: Threat Hunting → rule.id:5712 (Erkennung) und rule.id:651 (Active-Response ausgelöst)
• Weiterer SSH-Versuch von der Kali muss jetzt ins Leere laufen (Connection timeout, kein Reset)