Wazuh Rule 533 optimieren: Port-Änderungen verständlich darstellen statt vollständiger Netstat-Dumps

von

Einleitung

Die Überwachung offener Ports gehört zu den klassischen Sicherheitsmaßnahmen in Wazuh. Mit der integrierten Regel 533 („Listened ports status changed – netstat“) erkennt Wazuh zuverlässig Änderungen im Listening-Port-Status eines Systems. In der Praxis zeigt sich jedoch schnell ein Problem: Die Alerts enthalten komplette Snapshots der vorherigen und aktuellen Netstat-Ausgaben. Gerade auf Systemen mit vielen offenen Ports wird die Analyse dadurch unübersichtlich und zeitaufwendig. Für Security-Teams ist jedoch nicht der vollständige Zustand entscheidend, sondern die konkrete Änderung – also welche Ports neu geöffnet oder geschlossen wurden.

Ausgangslage / Problemstellung

Die bestehende Regel 533 funktioniert technisch korrekt. Sie erkennt Veränderungen und löst Alerts aus, sobald sich der Zustand der Listening-Ports ändert. Allerdings liefert sie im Feld full_log sowohl den vorherigen als auch den aktuellen Zustand als vollständige Ausgabe.

Das führt zu mehreren Herausforderungen:

  • Große Logmengen pro Alert bei vielen offenen Ports
  • Manuelle Diff-Analyse notwendig
  • Keine direkte Hervorhebung der tatsächlichen Änderung
  • Eingeschränkte Nutzbarkeit für automatisierte Reaktionen

Ziel ist daher eine Darstellung nach dem Prinzip:

OPENED_PORT tcp 0.0.0.0:12345
CLOSED_PORT tcp 0.0.0.0:54321

Technische Analyse

Der entscheidende Punkt liegt in der internen Funktionsweise von Wazuh:

  • Die Regel 533 basiert auf Command Monitoring (netstat bzw. ss)
  • Wazuh speichert dabei den vorherigen Zustand (previous_output)
  • Der Vergleich erfolgt intern, aber nicht granular auf Feldebene
  • Der Standard-Decoder (ossec) verarbeitet das Ergebnis und stellt es als vollständigen Log dar

Das bedeutet:
Wazuh erkennt Änderungen, führt aber keine semantische Diff-Analyse durch, sondern vergleicht lediglich den gesamten Output als String.

Ein direktes Anpassen der Regel 533 oder des zugrunde liegenden Decoders ist aus mehreren Gründen nicht empfehlenswert:

  • Built-in Decoder sind nicht update-sicher modifizierbar
  • Die Logstruktur enthält keine klar trennbaren Felder für Ports
  • Regex-basierte Extraktion aus vollständigen Dumps ist fehleranfällig

Auch Index-Templates helfen hier nicht weiter, da sie lediglich beeinflussen, was indexiert wird – nicht, wie Alerts entstehen.

Lösung / Best Practices

Die saubere Lösung besteht darin, die Diff-Logik vor Wazuh zu verlagern – konkret auf den Agenten. Statt Wazuh komplette Snapshots vergleichen zu lassen, erzeugt ein Script bereits die gewünschten Delta-Events.

1. Script zur Port-Differenz-Erkennung

Auf dem Agenten wird ein Script implementiert, das aktuelle und vorherige Portzustände vergleicht:

#!/bin/bashSTATE="/var/tmp/ports_prev"
CURRENT="/var/tmp/ports_now"
LOG="/var/log/netstat_port_changes.log"ss -tuln | awk 'NR>1 {print $5}' | sort > $CURRENTif [ -f "$STATE" ]; then
    comm -13 $STATE $CURRENT | while read p; do
        echo "$(date '+%Y-%m-%dT%H:%M:%S') OPENED_PORT $p" >> $LOG
    done    comm -23 $STATE $CURRENT | while read p; do
        echo "$(date '+%Y-%m-%dT%H:%M:%S') CLOSED_PORT $p" >> $LOG
    done
fimv $CURRENT $STATE

Dieses Script nutzt comm, um Differenzen zwischen zwei sortierten Listen zu berechnen:

  • Neue Ports → OPENED_PORT
  • Entfernte Ports → CLOSED_PORT

2. Ausführung über Wazuh Command Monitoring

Integration in die Agent-Konfiguration:

<wodle name="command">
  <disabled>no</disabled>
  <tag>port_monitor</tag>
  <command>/usr/local/bin/port_delta.sh</command>
  <interval>60s</interval>
  <ignore_output>yes</ignore_output>
  <run_on_start>yes</run_on_start>
  <timeout>0</timeout>
</wodle>

Damit wird das Script regelmäßig ausgeführt, ohne selbst Output an Wazuh zu senden.

3. Monitoring der generierten Logdatei

<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/netstat_port_changes.log</location>
</localfile>

Jetzt übernimmt Wazuh wieder seine Kernkompetenz: strukturierte Analyse von Logs.

4. Custom Decoder

<decoder name="port_change">
  <prematch>_PORT</prematch>
  <regex>\d\d\d\d-\d\d-\d\dT\d\d:\d\d:\d\d (\w+)_PORT (\S+):(\d+)</regex>
  <order>status,ip,port</order>
</decoder>

5. Custom Rules

<group name="port_change">
  <rule id="100200" level="6">
    <decoded_as>port_change</decoded_as>
    <field name="status">OPENED</field>
    <description>Port $(port) wurde geöffnet ($(ip))</description>
  </rule>  <rule id="100201" level="6">
    <decoded_as>port_change</decoded_as>
    <field name="status">CLOSED</field>
    <description>Port $(port) wurde geschlossen ($(ip))</description>
  </rule>
</group>

6. Optional: Regel 533 deaktivieren

Falls die neuen Alerts ausreichend sind:

<rule id="533" level="0">

Lessons Learned / Best Practices

Dieser Fall zeigt eine zentrale Designgrenze von Wazuh:

Wazuh ist stark in der Erkennung von Zustandsänderungen, aber nicht in der semantischen Interpretation komplexer Diffs innerhalb unstrukturierter Outputs.

Daraus ergeben sich wichtige Best Practices:

  • Komplexe Vergleiche möglichst vor der Übergabe an Wazuh durchführen
  • Wazuh für Parsing, Korrelation und Alerting nutzen, nicht für Rohdatenanalyse
  • Built-in Regeln nur überschreiben, nicht umbauen
  • Delta-basierte Logs sind operativ deutlich wertvoller als Zustands-Snapshots

Ein weiterer Vorteil des Script-Ansatzes ist die Flexibilität:

  • Erweiterung um Protokolle (TCP/UDP)
  • Whitelisting bestimmter Ports
  • Integration in Incident-Response-Workflows

Fazit

Die Standardregel 533 erfüllt ihren Zweck, ist aber für operative Analysen oft zu grobgranular. Eine direkte Anpassung innerhalb von Wazuh ist weder praktikabel noch stabil. Der entscheidende Schritt ist daher, die Diff-Logik aus Wazuh herauszulösen und bereits auf Agent-Seite in klare, strukturierte Events zu überführen.

Mit einem einfachen Script, Command Monitoring und Custom Rules entsteht so eine deutlich präzisere und besser nutzbare Überwachung von Portänderungen – genau abgestimmt auf die Anforderungen moderner Security-Teams.

Quellenverweis

https://documentation.wazuh.com/current/user-manual/capabilities/command-monitoring/configuration.html
https://documentation.wazuh.com/current/user-manual/capabilities/log-data-collection/monitoring-log-files.html
https://documentation.wazuh.com/current/user-manual/ruleset/rules/index.html
https://documentation.wazuh.com/current/user-manual/ruleset/rules/custom.html#changing-existing-rules

Mehr zu Wazuh …
https://wazuh.com/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program

Mehr zum Wazuh Ambassador Program …
https://wazuh.com/ambassadors-program/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program

https://wazuh.slack.com/archives/C07CCCCGHHP/p1775711643821979