HIDS - Neue Techniken: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
Zeile 1: Zeile 1:
−
=Wazuh Server=
 
−
*[[Wazuh aufsetzen Template]]
 
−
 
 
=Wazuh-Agent auf Debian- und Rocky-Clients=
 
=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.dkbi.com'''.
+
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==
 
==Agent-Installation auf Debian==
 
====Repository einrichten====
 
====Repository einrichten====
Zeile 20: Zeile 16:
 
;Agent mit Manager-Adresse und Namen installieren
 
;Agent mit Manager-Adresse und Namen installieren
 
<syntaxhighlight lang="bash">
 
<syntaxhighlight lang="bash">
−
WAZUH_MANAGER="wazuh.dkbi.com" WAZUH_AGENT_NAME="debian-host" apt install -y wazuh-agent
+
WAZUH_MANAGER="wazuh.it2XX.int" WAZUH_AGENT_NAME="debian-host" apt install -y wazuh-agent
 
</syntaxhighlight>
 
</syntaxhighlight>
 
;Dienst aktivieren und starten
 
;Dienst aktivieren und starten
Zeile 32: Zeile 28:
 
apt update
 
apt update
 
</syntaxhighlight>
 
</syntaxhighlight>
−
 
 
==Agent-Installation auf Rocky==
 
==Agent-Installation auf Rocky==
 
====Repository einrichten====
 
====Repository einrichten====
Zeile 54: Zeile 49:
 
;Agent mit Manager-Adresse und Namen installieren
 
;Agent mit Manager-Adresse und Namen installieren
 
<syntaxhighlight lang="bash">
 
<syntaxhighlight lang="bash">
−
WAZUH_MANAGER="wazuh.dkbi.com" WAZUH_AGENT_NAME="rocky-host" dnf install -y wazuh-agent
+
WAZUH_MANAGER="wazuh.it2XX.int" WAZUH_AGENT_NAME="rocky-host" dnf install -y wazuh-agent
 
</syntaxhighlight>
 
</syntaxhighlight>
 
;Dienst aktivieren und starten
 
;Dienst aktivieren und starten
Zeile 65: Zeile 60:
 
sed -i "s/^enabled=1/enabled=0/" /etc/yum.repos.d/wazuh.repo
 
sed -i "s/^enabled=1/enabled=0/" /etc/yum.repos.d/wazuh.repo
 
</syntaxhighlight>
 
</syntaxhighlight>
−
 
 
====Kontrolle (beide Clients)====
 
====Kontrolle (beide Clients)====
 
* Öffne das Wazuh-Dashboard, gehe zu ''Agent Management &rarr; Summary'' und prüfe, ob '''debian-host''' und '''rocky-host''' mit Status '''Active''' erscheinen.
 
* Öffne das Wazuh-Dashboard, gehe zu ''Agent Management &rarr; 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
 
−
<pre>
 
−
<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>
 
−
</pre>
 
−
* ''realtime="yes"'' funktioniert für Verzeichnisse (inotify) &mdash; 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 &mdash; bei einer neuen ''authorized_keys''-Zeile siehst du sofort, welcher Key hinzugefügt wurde.
 
−
;Agent neu starten
 
−
<syntaxhighlight lang="bash">
 
−
systemctl restart wazuh-agent
 
−
</syntaxhighlight>
 
−
====Kontrolle====
 
−
* Test von der Konsole des Clients:
 
−
  <pre>
 
−
  echo "ssh-ed25519 AAAA...test angreifer@kali" >> /root/.ssh/authorized_keys
 
−
  </pre>
 
−
* Ö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 &mdash; 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''
 
−
<pre>
 
−
<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>
 
−
</pre>
 
−
* ''check_pids''/''check_ports'' vergleichen, was der Kernel meldet, gegen das, was Tools wie ''ps''/''netstat'' anzeigen &mdash; 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
 
−
<syntaxhighlight lang="bash">
 
−
systemctl restart wazuh-agent
 
−
</syntaxhighlight>
 
−
====Kontrolle====
 
−
* Rootcheck lässt sich nicht einfach durch eine harmlose Aktion auslösen (das ist ja der Zweck) &mdash; zur Kontrolle reicht es, den erfolgreichen Scan-Lauf zu prüfen:
 
−
  <pre>
 
−
  tail -f /var/ossec/logs/ossec.log | grep rootcheck
 
−
  </pre>
 
−
* Im Dashboard unter ''Threat Hunting'' filtere auf ''rule.groups:rootcheck'' &mdash; 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 &mdash; für Debian und die RHEL-Familie (Rocky) gibt es jeweils eigene, mitgelieferte Policies.
 
−
;Verfügbare Policies prüfen
 
−
<syntaxhighlight lang="bash">
 
−
ls /var/ossec/ruleset/sca/
 
−
</syntaxhighlight>
 
−
;SCA in ''/var/ossec/etc/ossec.conf'' aktivieren (Policy-Datei je nach Ausgabe des obigen Befehls anpassen)
 
−
<pre>
 
−
<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>
 
−
</pre>
 
−
;Agent neu starten
 
−
<syntaxhighlight lang="bash">
 
−
systemctl restart wazuh-agent
 
−
</syntaxhighlight>
 
−
====Kontrolle====
 
−
* Im Dashboard: ''Security Configuration Assessment'' &rarr; 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 &mdash; 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
 
−
<pre>
 
−
<vulnerability-detection>
 
−
  <enabled>yes</enabled>
 
−
  <index-status>yes</index-status>
 
−
  <feed-update-interval>60m</feed-update-interval>
 
−
</vulnerability-detection>
 
−
</pre>
 
−
;Manager neu starten
 
−
<syntaxhighlight lang="bash">
 
−
systemctl restart wazuh-manager
 
−
</syntaxhighlight>
 
−
====Kontrolle====
 
−
* Im Dashboard: ''Vulnerability Detection'' &rarr; Agent auswählen (debian-host bzw. rocky-host)
 
−
* Auf so gut wie jedem frisch installierten System stehen bereits einige CVEs in der Liste &mdash; 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 &mdash; 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 &mdash; da ihr nftables nutzt, bauen wir ein eigenes Skript.
 
−
 
−
====nftables-Grundgerüst auf dem Client====
 
−
;Set und Drop-Regel anlegen (falls noch nicht vorhanden)
 
−
<pre>
 
−
table inet filter {
 
−
    set blocklist {
 
−
        type ipv4_addr
 
−
        flags timeout
 
−
    }
 
−
    chain input {
 
−
        type filter hook input priority 0; policy accept;
 
−
        ip saddr @blocklist drop
 
−
    }
 
−
}
 
−
</pre>
 
−
 
−
====Active-Response-Skript auf dem Client====
 
−
;''/var/ossec/active-response/bin/nft-drop'' anlegen
 
−
<syntaxhighlight lang="bash">
 
−
#!/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
 
−
</syntaxhighlight>
 
−
;Ausführbar machen
 
−
<syntaxhighlight lang="bash">
 
−
chmod 750 /var/ossec/active-response/bin/nft-drop
 
−
chown root:wazuh /var/ossec/active-response/bin/nft-drop
 
−
</syntaxhighlight>
 
−
 
−
====Konfiguration auf dem Manager====
 
−
;''<command>'' und ''<active-response>'' in ''/var/ossec/etc/ossec.conf'' (Manager) ergänzen
 
−
<pre>
 
−
<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>
 
−
</pre>
 
−
* 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) &mdash; wichtig, damit sich niemand dauerhaft aussperrt.
 
−
;Manager neu starten
 
−
<syntaxhighlight lang="bash">
 
−
systemctl restart wazuh-manager
 
−
</syntaxhighlight>
 
−
 
−
====Kontrolle====
 
−
* Von der Kali aus 8+ fehlgeschlagene SSH-Logins gegen den Client, z.B.:
 
−
  <pre>
 
−
  hydra -l root -P /usr/share/wordlists/rockyou.txt -t 4 -f ssh://<client-ip>
 
−
  </pre>
 
−
* Auf dem Client: ''nft list set inet filter blocklist'' &rarr; 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'' &rarr; ''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)
 
−
 
−
[[Kategorie:WAZUH]]
 

Version vom 29. Juli 2026, 15:04 Uhr

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 und Namen installieren
WAZUH_MANAGER="wazuh.it2XX.int" WAZUH_AGENT_NAME="debian-host" 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 und Namen installieren
WAZUH_MANAGER="wazuh.it2XX.int" WAZUH_AGENT_NAME="rocky-host" 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.
Abgerufen von „https://xinux.net/index.php?title=HIDS_-_Neue_Techniken&oldid=72342“