SIEM: Wazuh und pfSense Firewall Überwachung mit JSON Syntax

Netgates pfSense® Firewalls schützen weltweit Unternehmen aller Größenordnungen ➸ zuverlässig und bewährt. Doch ihre Logs liefern weit mehr als simple „blockiert" oder „erlaubt" Meldungen: Jeder Eintrag enthält eine extreme Dichte an Netzwerkdetails, die für ein modernes SIEM besonders wertvoll sind.

Die Herausforderung: Bevor ein kritisches Asset wie die pfSense® an ein SIEM angebunden wird, müssen diese umfangreichen Log-Daten bis ins kleinste Detail verstanden werden. Erst dann kann die eigene Verarbeitung und Regel-Entwicklung beginnen. Umso wichtiger ist es, der pfSense® Firewall im SIEM-Kontext eine hochkritische Gewichtung zu geben.

Die Vielfalt der pfSense Protokolle

Netgate dokumentiert die Log-Struktur ausführlich hier. Die pfSense® unterstützt eine positiv breite Palette an Netzwerkprotokollen:

IPv4: TCP, UDP, ICMP_ECHO, ICMP_ERROR, IPsec, GRE, IGMP, OSPF, VRRP, SCTP, CARP
IPv6: TCP, UDP, ICMP_ECHO, ICMP_ERROR, IPsec, GRE,  MLD, OSPF, VRRP, SCTP, CARP
Zusätzlich: Statistiken, Unbound-DNS Logs sowie diverse Pakete und Erweiterungen

Berücksichtigt man die verfügbaren Add-ons, steigt die Zahl der Log-Quellen exponentiell. Doch schauen wir uns die Feld-Beschreibungen von IPv4 und dessen Protokolle TCP/UDP/ICMP genauer an:

Grundstruktur der Log-Daten

<log-data> ::= <rule-number>,<sub-rule-number>,<anchor>,<tracker>,<real-interface>,<reason>,<action>,<direction>,<ip-version>[,<ip-specific-data>]

Beschreibung der einzelnen Felder der Grundstruktur:

• <rule-number>     ➸ Regelnummer im PF-Ruleset
• <sub-rule-number> ➸ Sub-Regelnummer (meist nicht relevant)
• <anchor>          ➸ Anchor-Name, in dem die Regel existiert
• <tracker>         ➸ Eindeutige Regel-Tracking-ID
• <real-interface>  ➸ Physisches Interface (z.B. em0, lagg0.69, tun_wg0)
• <reason>          ➸ Grund für den Log-Eintrag (typischerweise "match")
• <action>          ➸ Aktion: "pass" oder "block"
• <direction>       ➸ Richtung: "in" oder "out"
• <ip-version>      ➸ IPv4 ("4") oder IPv6 ("6")

IPv4-spezifische Daten

<ipv4-specific-data> ::= <tos>,<ecn>,<ttl>,<id>,<offset>,<flags>,<protocol-id>,<protocol-text>

Beschreibung der IPv4 spezifischen Felder:

• <tos>             ➸ Type of Service
• <ecn>             ➸ Explicit Congestion Notification
• <ttl>             ➸ Time To Live
• <id>              ➸ Paket-ID
• <offset>          ➸ Fragment-Offset
• <flags>           ➸ IP-Flags (z.B. DF = Don't Fragment)
• <protocol-id>     ➸ IP-Protokoll-ID (6=TCP, 17=UDP, 1=ICMP)
• <protocol-text>   ➸ Protokoll-Name (tcp, udp, icmp)

Wie der Netzwerk-Experte schnell erkennt: Es wird nicht geschwurbelt, sondern technisch hoch akkurate Daten geliefert!

Syslog nach RFC 5424: Struktur und Präzision

Die pfSense® transportiert ihre Logs via TCP im klassischen Syslog RFC 3164 Format und diese werden (in diesem Use-Case) an einem zentralen syslog-ng Server in das Syslog RFC 5424 Format geparst (und später nach JSON konvertiert).

Der Vorteil vom Syslog Format nach RFC 5424 sind u.a. strukturierte Header, Mikrosekunden-Timestamps und klare Felddefinitionen.

Ein Beispiel Log-Eintrag:

<134>1 2025-10-10T18:16:19.246873+02:00 pfSense.firma.loc filterlog 4472 - -  140,,,1703442353,tun_wg0,match,pass,in,4,0x0,,64,21795,0,DF,6,tcp,60,10.255.0.3,10.0.101.250,46806,6556,0,S,1623020349,,64860,,mss;sackOK;TS;nop;wscale

Farbliche Aufschlüsselung des Syslog-Headers nach  RFC 5424:

• PRI (Priority: Facility 16 [local0] * 8 + Severity 6 [info]) ➸ <134>
• VERSION                                                      ➸ 1
• TIMESTAMP                                                    ➸ 2025-10-10T18:16:19.246873+02:00
• HOSTNAME                                                     ➸ pfSense.firma.loc
• APP-NAME                                                     ➸ filterlog
• PROCID                                                       ➸ 4472
• MSGID (nicht gesetzt)                                        ➸ -
• STRUCTURED-DATA (nicht gesetzt)                              ➸ -
• MESSAGE (pfSense filterlog payload)                          ➸ 140,,,1703442353,tun_wg0,match,pass,in,4,0x0,,64,21795,0,DF,6,tcp,60,10.255.0.3,10.0.101.250,46806,6556,0,S,1623020349,,64860,,mss;sackOK;TS;nop;wscale
  

Das MESSAGE-Feld enthält die eigentlichen pfSense Filterlog Daten ➸ ein durch Kommas getrenntes Format, das im folgenden Diagramm aufgeschlüsselt wird:

Und das ist nur  IPv4 mit  TCP. UDP, ICMP, UNBOUND, IPv6 und weitere Protokolle erweitern die Struktur zusätzlich. Vor der SIEM-Integration ist das exakte Wissen über die verwendeten Datenquellen, deren Aufbau und Bedeutung zwingend erforderlich.

Von Syslog zu JSON: Die Umwandlung als Best Practice.

Angesichts der Komplexität liegt eine Weiterverarbeitung in ein strukturelles Datenformat nahe. JSON hat sich weltweit durchgesetzt ➸ und bietet einen entscheidenden Vorteil: Seriöse SIEM-Systeme parsen JSON out-of-the-box, ohne dass bei jeder Log-Änderung Decoder und REGEX-Syntax angepasst werden müssen.

Das SIEM-System Wazuh verarbeitet JSON ohne Probleme, und der SIEM-Engineer kann sich viel stärker auf die Entwicklung von verlässlichen Regelsätzen konzentrieren.

Die Architektur: Zentral, strukturiert, sicher

Bei Gray-Hat IT-Security Consulting hat sich folgende Best Practice etabliert:

1. Zentrale Syslog-Sammlung: Alle pfSense® Logs werden via TCP an einen dedizierten syslog-ng Server gesendet.
2. Transformation mit syslog-ng: Die mächtige Anwendung syslog-ng empfängt die Datenströme und konvertiert sie mit eigenen Filtern und Pipelines nach JSON und verarbeitet alle einzelnen Informations-Felder im MESSAGE Field ➸ inklusive passenden Datentypen (eine Ganzzahl ist nun mal ein INTEGER und kein STRING 👨‍🏫 ).
3. Weiterleitung an Wazuh: Die strukturierten JSON Logs werden vom Wazuh Agenten (der auf dem syslog-ng Server operiert und bei Bedarf hunderte einzelne Logs ausliest) direkt an das Wazuh SIEM übermittelt und dort nativ mit dessen JSON Decoder weiter verarbeitet.

Schauen Sie sich folgende Grafik an:

Anbei sind drei verschiedene Beispiele abgebildet: TCP, UDP, und Unbound-DNS, alle im JSON Format. Besonderes Augenmerk sei auf die nun deutlich klarere Ausgabe gelegt. Das Message-Feld und dessen schwer zugängliche Informationen wurden in eine für Mensch und Maschine logische Struktur konvertiert. Werte besitzen jetzt klare Schlüsselbezeichnungen. Diese JSON-Datenstrukturen werden in Wazuh direkt nativ geparst ➸ vollkommen egal, wie komplex zukünftige Log-Erweiterungen ausfallen.

Datentypen: Mehr als nur Text

Innerhalb von Wazuh werden passende Datentypen für die verschiedenen Felder definiert. Denn einfach nur „Text“ auszulesen, greift zu kurz:

• Zahlen als Zahlen behandeln: Ermöglicht mathematische Operationen, Durchschnittsbildung und statistische Analysen.
• IP-Adressen als Netzwerkobjekte: Erlaubt Filterung auf ganze Subnetze statt nur Einzeladressen.
• Timestamps mit Mikrosekunden: Präzise Korrelation von Events über mehrere Datenquellen hinweg.

Die Kunst eines SIEM-Systems:
IT-Sicherheit und Business-Intelligence verschmelzen, um Anomalien aufzuspüren ➸ die nicht zwangsläufig von Hoodie-tragenden Cyber-Schurken stammen.

Visualisierung: Vom Log zur Erkenntnis
Wazuh bietet mächtige Visualisierungsmöglichkeiten, die aus Rohdaten handlungsfähige Erkenntnisse machen:

Sankey-Diagramm: Datenflüsse auf einen Blick
Verbindungen zwischen Quell- und Ziel-IP-Adressen werden als Flussdiagramm dargestellt. Auf einen Blick erkennt der Analyst:

• Welche internen Systeme mit welchen externen Zielen kommunizieren.
• Ungewöhnliche Verbindungsmuster oder plötzliche Traffic-Spikes.
• Potenzielle Lateral-Movement-Aktivitäten oder Data Exfiltration.

Schauen Sie sich die nächsten Bilder an:

Globus-Visualisierung: Geolokalisierung von Zugriffen
Durch GeoIP-Anreicherung der pfSense® Log-Daten werden blockierte und erlaubte Verbindungen auf einem interaktiven 3D-Globus dargestellt:

• Rote Markierungen: Länder, aus denen Zugriffe geblockt wurden.
• Gelbe Markierungen:  Erfolgreiche Verbindungen (die nicht immer legitim sein müssen!)
• Drill-Down: Mit dem Mauszeiger über einen Punkt zeigt Details zu IPs, Ports und Protokollen
  

Diese Darstellung ist nicht nur optisch eindrucksvoll, sondern ermöglicht auch eine schnelle Lageerfassung z. B. bei einem Incident Response oder bei der Analyse, wohin Datenströme sich bewegen.

Unbound-DNS-Analyse: Versteckte Bedrohungen erkennen
Die pfSense® integriert Unbound als DNS-Resolver. Individuelle Wazuh Pipelines können z. B. folgendes analysieren:

• Verdächtige Domain-Anfragen.
• DNS-Tunneling Versuche.
• Verbindungen zu bekannten C2-Servern.
• Download-Anfragen zu Malware-Seiten.
• Häufigkeit und Zeitpunkt einer Abfrage.
• Welche Assets waren involviert.
  

Fazit: Wazuh SIEM als strategisches Asset

Die sachgerechte Integration der pfSense® Firewall in Wazuh zeigt: Ein modernes SIEM ist weit mehr als ein Log-Sammler. Es ist ein strategisches Werkzeug für:

• Proaktive Bedrohungserkennung.
• Compliance-Erfüllung (z.B. NIS-2, ISO/IEC 27001:2022, BSI-Grundschutz und die Systeme zur Angriffserkennung (SzA) für KRITIS-Betreiber).
• Forensische Analysen nach Vorfällen.
• Ganzheitliche Analyse von bestehenden Datenströmen.
• Reifegrad-Skalierung: Von Basis-Monitoring bis zum hochautomatisierten Threat Hunting.
• Open Source: Kein Vendor Lock-in, volle Kontrolle.
• Flexibilität: Anpassbar an individuelle Infrastrukturen.
  

Die Kombination aus IT-Engineering, strukturierter Log-Verarbeitung, intelligenter Analyse und aussagekräftiger Visualisierung macht Wazuh zum idealen SIEM-System.

Meine Dienstleistungen für Sie: SIEM-Systeme, Systemhärtung und Compliance-Anforderungen

Als Wazuh-Experte und offizieller Wazuh Ambassador, biete ich mit meinem Unternehmen Gray-Hat IT-Security Consulting professionelle Unterstützung bei der Realisierung von Wazuh SIEM Projekten in Ihrer IT-Infrastruktur an. Meine Expertise umfasst nicht nur die fachgerechte Etablierung eines SIEM-Systems, sondern auch die systematische Härtung Ihrer Server und Netzwerke, sodass selbst produktive Umgebungen optimal geschützt sind. Dabei berücksichtige ich wichtige Compliance-Anforderungen wie ISO 27001:2022 und NIS-2, um sicherzustellen, dass Ihre IT-Infrastruktur nicht nur sicher, sondern auch mit Ihrer Compliance bzw. ISMS konform sind.

Falls Sie ebenfalls Ihre IT-Infrastruktur mit Wazuh optimieren, Ihre Systeme härten oder spezifische Compliance-Anforderungen erfüllen möchten, unterstütze ich Sie gerne mit meiner intensiven Praxis-Erfahrung und einem umfassenden Angebot an Lösungen.