Wazuh + Suricata — Netzwerk-IDS und SIEM zusammengebracht

Wazuh überwacht Hosts: Dateiänderungen, Auth-Events, Prozesse, Vulnerability-Scans. Das ist mächtig — aber es hat eine strukturelle Grenze. Was zwischen den Hosts passiert, bleibt unsichtbar. Ein Portscanner, der alle 10 Minuten dasselbe Subnetz abtastet, hinterlässt auf dem Zielsystem vielleicht keine Spur — im Netzwerkverkehr aber sehr wohl.

Suricata füllt diese Lücke. Das Open-Source-IDS/IPS analysiert Netzwerkpakete in Echtzeit, erkennt bekannte Angriffsmuster und schreibt strukturierte Events — Alerts, DNS-Anfragen, HTTP-Verbindungen, TLS-Metadaten — in eine JSON-Datei. Wazuh kann diese Datei einlesen und die Netzwerk-Events mit Host-Events korrelieren.

Das Ergebnis: ein Alert, der nicht nur sagt “da war ein Netzwerk-Scan”, sondern gleichzeitig zeigt, ob auf dem betroffenen Host in derselben Zeitspanne Dateien geändert wurden.

Suricata und das EVE-JSON-Format

Suricata schreibt alle Events nach /var/log/suricata/eve.json. Das Format heißt EVE — Extensible Event Format — und ist eine JSON-Datei, eine Zeile pro Event. Wazuh kann JSON-formatierte Logs direkt einlesen und verarbeiten.

Relevante Event-Typen in EVE:

Ein typischer Alert-Event (gekürzt):

{
  "timestamp": "2025-10-31T09:14:23.123456+0100",
  "event_type": "alert",
  "src_ip": "192.168.1.55",
  "src_port": 54321,
  "dest_ip": "10.0.0.1",
  "dest_port": 80,
  "proto": "TCP",
  "alert": {
    "action": "allowed",
    "gid": 1,
    "signature_id": 2010935,
    "rev": 3,
    "signature": "ET SCAN Nmap Scripting Engine User-Agent",
    "category": "Web Application Attack",
    "severity": 1
  }
}

Wazuh dekodiert diesen Event automatisch — der eingebaute Suricata-Decoder mappt alle Felder auf data.*-Attribute.

Suricata installieren

Suricata läuft idealerweise auf dem Host oder Gateway, der den relevanten Netzwerkverkehr sieht. Für ein Homelab-Setup ist das oft derselbe Host wie der Wazuh-Manager oder ein dedizierter Sensor.

# Debian/Ubuntu
apt-get install suricata -y

# Suricata-Update für aktuelle Regelwerke
apt-get install suricata-update -y
suricata-update

# Suricata starten
systemctl enable --now suricata

Suricata muss auf dem richtigen Interface lauschen. In /etc/suricata/suricata.yaml:

af-packet:
  - interface: eth0    # Anpassen auf das eigene Interface

# EVE-Output aktivieren (ist meist Standard)
outputs:
  - eve-log:
      enabled: yes
      filetype: regular
      filename: /var/log/suricata/eve.json
      types:
        - alert
        - dns
        - http
        - tls
        - flow

Nach Änderungen: systemctl restart suricata. Ob Suricata läuft und Events schreibt, prüft man mit:

tail -f /var/log/suricata/eve.json | python3 -m json.tool | head -50

Wazuh-Agent für Suricata konfigurieren

Der Wazuh-Agent auf dem Suricata-Host muss eve.json einlesen. Die Konfiguration kommt entweder direkt in die lokale /var/ossec/etc/ossec.conf des Agents oder — sauberer — in eine Agent-Gruppe auf dem Manager.

Über Agent-Gruppe (empfohlen):

<!-- /var/ossec/etc/shared/suricata-sensors/agent.conf -->
<agent_config>
  <localfile>
    <log_format>json</log_format>
    <location>/var/log/suricata/eve.json</location>
  </localfile>
</agent_config>

Agent der Gruppe zuweisen:

/var/ossec/bin/agent_groups -a -i <agent-id> -g suricata-sensors

Decoder prüfen: Wazuh bringt eingebaute Decoder für Suricata EVE-JSON mit. Zu finden unter:

grep -r "suricata" /var/ossec/ruleset/decoders/

Das liefert die Decoder-Dateien, die Wazuh automatisch lädt. Kein eigener Decoder nötig — Suricata-Logs werden out-of-the-box erkannt.

Eingebaute Rules prüfen:

grep -r "suricata" /var/ossec/ruleset/rules/ -l

Im Dashboard sind die Suricata-Events unter Modules → Threat Hunting sichtbar, gefiltert nach rule.groups: suricata.

Erste Tests

Sobald der Agent läuft und Suricata Events schreibt, tauchen erste Alerts im Dashboard auf. Ein einfacher Test mit Nmap vom eigenen Netz aus:

nmap -sV 10.0.0.1

Suricata sollte den Scan-User-Agent von Nmap erkennen (ET SCAN Nmap). Im Wazuh-Dashboard erscheint der Alert innerhalb von Sekunden unter Security Events.

Zur manuellen Prüfung: ein Suricata-Event in wazuh-logtest einspeisen:

cat /var/log/suricata/eve.json | head -1 | /var/ossec/bin/wazuh-logtest

Phase 2 sollte decoder: suricata zeigen, Phase 3 eine passende Rule.

Eigene Korrelations-Rules

Das ist der eigentliche Mehrwert: Netzwerk-Event auf einem Host plus Host-Event auf demselben Host — korreliert in einem einzigen Alert.

Szenario: Suricata schlägt auf einem Host Alarm (Netzwerkangriff), und kurz danach ändert sich auf demselben Host eine Datei (FIM-Alert). Isoliert sind das zwei unremarkable Events. Zusammen ist es ein Indicator of Compromise.

<!-- /var/ossec/etc/rules/local_rules.xml -->
<group name="correlation,">

  <rule id="100010" level="12" timeframe="300">
    <if_matched_sid>550</if_matched_sid>   <!-- FIM: Datei geändert -->
    <same_field>agent.name</same_field>
    <field name="data.event_type">alert</field>
    <description>Korrelation: Netzwerkangriff UND Dateiänderung auf $(agent.name) in 5 Minuten</description>
    <group>correlation,attack,</group>
    <mitre>
      <id>T1565</id>
    </mitre>
  </rule>

</group>

Was diese Rule macht:

• Sie feuert, wenn innerhalb von 300 Sekunden Rule 550 (FIM-Änderung) und ein Suricata-Alert auf demselben Agent auftreten
• <same_field>agent.name</same_field> — Korrelation nur, wenn beide Events vom selben Host kommen
• Level 12 — erscheint sofort prominent im Dashboard

Rule-IDs der eingebauten FIM-Rules über das Dashboard oder grep herausfinden:

grep -r "File added\|File modified\|File deleted" /var/ossec/ruleset/rules/ | grep "id=" | head -10

Threat Hunting im Dashboard

Mit Suricata-Daten im System lohnt sich das Dashboard als Investigationstool:

Filter setzen:

rule.groups: suricata AND data.alert.severity: 1

Das zeigt nur High-Severity-Alerts (Severity 1 ist bei Suricata die höchste Stufe).

Top Quell-IPs nach Alert-Kategorie — im Visualize-Tab eine Data Table bauen:

• Bucket: data.src_ip (Terms-Aggregation, Top 10)
• Metric: Count
• Split Series: data.alert.category

Saved Queries für häufige Suricata-Kategorien anlegen:

• ET SCAN — aktive Scans
• ET POLICY — Policy-Verletzungen (z.B. Tor-Nutzung)
• ET MALWARE — bekannte Malware-Kommunikation

Regelwerk aktuell halten

Suricata ist nur so gut wie seine Signaturen. suricata-update zieht die ET Open Rules — die sind kostenfrei und werden täglich aktualisiert.

Als Cron-Job einrichten:

# /etc/cron.d/suricata-update
0 3 * * * root /usr/bin/suricata-update && systemctl reload suricata

systemctl reload suricata lädt die neuen Regeln ohne Neustart und ohne Verbindungsunterbrechung.

Zusätzliche Quellen, die suricata-update unterstützt:

# Verfügbare Quellen anzeigen
suricata-update list-sources

# Quelle aktivieren (Beispiel: abuse.ch SSL-Blacklist)
suricata-update enable-source etpro/open  # kostenlos

Was bleibt zu tun

Diese Serie hat das Fundament gelegt: Architektur und Installation, eigenes Regelwerk, Netzwerk-Integration. Was darauf aufbaut:

• Wazuh Vulnerability Assessment — automatischer CVE-Abgleich gegen installierte Pakete, ohne Agent-Update
• Compliance-Module — PCI-DSS, HIPAA, GDPR-Checks out-of-the-box
• Wazuh API — Programmgesteuerte Abfragen, Alerting in eigene Systeme, Automatisierung

Für den Einstieg in eine eigene SIEM-Infrastruktur — ohne Cloud, ohne Lizenzkosten, ohne externe Abhängigkeiten — ist Wazuh + Suricata ein solider, praxiserprobter Stack.