B15 Erkennung von Portscans am Perimeter – vertikal (mit Wazuh + Maltrail)

Einleitung

Der Use-Case B15 zielt darauf ab, vertikale Portscans am Perimeter zu erkennen – also Scans, bei denen eine externe Quelle (meist aus dem Internet) ein einzelnes Zielsystem (eine Ziel-IP) auf viele unterschiedliche Ports prüft. Das dient Angreifern typischerweise dazu, offene Dienste zu identifizieren und daraus einen Angriffsplan abzuleiten.

Wichtig: Ein Portscan ist nicht automatisch ein Angriff, aber ein sehr relevanter Reconnaissance-Indikator. Entsprechend empfiehlt der Katalog, Trends und Häufigkeiten zu beobachten und kontextabhängig zu bewerten.

Was B15 beinhaltet (fachlich)

Detektionslogik (Kurzform)

B15 beschreibt im Kern folgendes Muster:

  • Ereignisse aus dem Netzwerk-/Perimeter-Kontext (z. B. Firewall / Netzwerk-Events)
  • Quell-IP scannt ein konstantes Ziel (Ziel-IP bleibt gleich)
  • Ziel-Ports variieren (viele unterschiedliche Ports)
  • Überschreitung eines Schwellwerts (z. B. “Ports pro Sekunde”)

Empfohlener Start-Schwellwert: 100 Portanfragen/Sekunde

Benötigte Informationen / Felder

Der Katalog nennt u. a.:

  • Eventcodes (NET01/NET02)
  • Quell-IP, Ziel-IP
  • Ziel-Port(s)/Portrange
  • optional: automatische Erkennung von Scan-Arten
  • Schwellenwert “Port-Anzahl pro Zeiteinheit”

Listenlogik (Um False Positives zu reduzieren)

  • Negativlisten für erlaubte Scan-Quellen / erlaubte Zielsysteme (z. B. Pentester, explizit exponierte Systeme)
  • Positivlisten für verbotene Quellen / verbotene Ziele (immer alarmieren)

Warum Wazuh allein das nicht zuverlässig erkennen kann

Wazuh ist in der Praxis ein log-/hostzentriertes SIEM/HIDS: Es erkennt nur das, was als Log/Telemetry bei ihm ankommt. Bei Portscan-Erkennung am Perimeter entstehen zwei typische Lücken:

  1. Nicht jede Scan-Art taucht in Perimeter-Logs sauber auf
    Der Katalog weist explizit darauf hin, dass z. B. SYN-Scans am Perimeter nicht zuverlässig protokolliert werden und dann Network Monitoring (z. B. Netflow) nötig ist. ISACA-Leitfaden_-_Use_Case_Kata…
  2. Für “Portscan” brauchst du Traffic-Sicht (Flows/Packets), nicht nur Host-Logs
    Ohne Netflow/PCAP/IDS-Sensorik kann Wazuh allein “nur” vorhandene Firewall-Logs korrelieren – das ist je nach Gerät/Policy/Log-Level oft unvollständig oder zu grob.

Konsequenz: Für B15 brauchst du in der Regel eine zusätzliche Software, die Netzwerkverkehr/Flows auswertet und Portscan-Heuristiken liefert.

Lösung: B15 mit der Open-Source IDS-Komponente Maltrail erkennen

Maltrail ist ein Open-Source “malicious traffic detection system” und bringt u. a. heuristische Erkennung mit. In der Doku wird explizit beschrieben, dass Maltrail bei “zu vielen Verbindungsversuchen zu vielen unterschiedlichen TCP-Ports” auf „potential port scanning“ warnt. GitHub

Architektur (empfohlen)

  1. Maltrail Sensor an eine Traffic-Quelle hängen:
    • SPAN/Mirror-Port am Switch (Perimeter-Uplink / DMZ-Segment)
    • alternativ mit einer OPNsense Firewall und dem Plugin os-maltrail
  2. Maltrail Server/UI (optional getrennt), sammelt und visualisiert Alerts, sendet Syslog an Wazuh Agent
  3. Wazuh Agent auf dem Maltrail-System:
    • liest Maltrail-Logs
    • normalisiert via Decoder
    • alarmiert via Rules

So bekommst du:

  • Netzwerksicht (Maltrail) +
  • zentrale Korrelation/Alerting/Threat Hunting (Wazuh)

Implementierung (Wazuh + Maltrail) – pragmatischer Ablauf

1) Maltrail installieren und Portscan-Heuristik nutzen

  • Maltrail so platzieren, dass es Perimeter-Traffic sieht (Mirror/SPAN).
  • Sensor laufen lassen und Alerts generieren lassen (z. B. durch Test-Scan in einer freigegebenen Testzone).

Wichtig: Der “B15-Use-Case” meint vertikal (1 Ziel, viele Ports). Maltrail meldet “potential port scanning” heuristisch – das passt sehr gut als Rohsignal, das du dann in Wazuh weiter veredelst (z. B. “nur DMZ”, “nur produktive Ziele”, “Whitelist Pentest-IPs”, usw.). GitHub

2) Maltrail Logs in Wazuh einsammeln

  • Wazuh Agent auf dem Maltrail-Host installieren
  • Maltrail-Logfile(s) als localfile im Agent einbinden (Dateipfad je nach Setup/Distribution)

3) Decoder & Rules für Maltrail in Wazuh hinterlegen

Es gibt ein fertiges Beispiel-Repo für Maltrail Decoder & Rules für Wazuh, inkl. Hinweis auf Ablagepfade unter /var/ossec/etc/decoders/. GitHub

Allgemein gilt: Wazuh unterstützt Custom Rules, um Events aus Drittquellen sauber zu matchen und zu klassifizieren. documentation.wazuh.com

Typisch ist dann eine Einordnung in eine Rule-Group wie z. B. Maltrail und ein Feld wie data.category, das den Erkennungstyp transportiert (z. B. “potential port scanning”).

Threat Hunting / Dashboard: Wazuh Suchfilter für B15 (Maltrail)

Wenn Decoder & Rules so greifen, wie geplant, kannst du in Wazuh (Discover / Threat Hunting) z. B. so filtern:

rule.groups: "Maltrail" and data.category: "potential port scanning"

Optional (Praxis-Tipp):

  • zusätzlich auf Perimeter-/DMZ-Agents oder Interfaces einschränken
  • bekannte Pentest-Quellen ausschließen
  • Ziel-IP auf kritische Systeme fokussieren

Betrieb: Was du für “saubere” B15-Qualität brauchst

  • Whitelist/Negativlisten: autorisierte Scanner/Pentester, erlaubte Zielsysteme (Wartungsfenster etc.)
  • Schwellwerte: nicht nur “Events pro Sekunde”, sondern ggf. “Ports pro Minute” je nach Rauschen
  • Coverage prüfen: SYN-Scan/Stealth-Scan-Verhalten kann in klassischen Firewall-Logs fehlen → dafür ist die Sensorik (Maltrail/Netflow) zentral.