Sophos Firewall Syslog sicher an SIEM senden

Mit Syslog sendet eine Sophos Firewall Ereignisse an einen externen Logserver, ein SIEM oder SOC. Damit die Anbindung wirklich nutzbar ist, müssen vier Dinge zusammenpassen: Transport, Logauswahl, Format und Parser. Dieser Artikel beginnt deshalb direkt mit der Konfiguration und zeigt danach, wie man fehlende oder falsch interpretierte Logs erkennt.

Der lokale Log viewer bleibt für die Live-Analyse wichtig. Central Firewall Reporting eignet sich für Sophos-Central-Reports; Syslog ist die richtige Wahl für eigene Aufbewahrung, herstellerübergreifende Korrelation und SIEM-Detection.

Syslog-Server konfigurieren

Vorher müssen Ziel-IP oder FQDN, Port, Transport, erwartetes Logformat und ein passender Parser feststehen. Die Firewall benötigt eine Route zum Collector, beide Systeme eine funktionierende Zeitquelle. UDP 514 ist üblich; bei TLS wird häufig TCP 6514 verwendet, massgebend ist aber die Konfiguration des Collectors.

System services > Log settings öffnen.
Add auswählen.
Einen eindeutigen Namen wie siem-primary vergeben.
Unter IP address/domain den Collector eintragen.
Port, Facility, Severity level und Format passend zum Zielsystem wählen.
Bei vorbereitetem TLS-Collector Secure log transmission aktivieren.
Speichern.
Unter Log settings die gewünschten Logtypen in der Spalte dieses Syslog-Servers aktivieren.

SFOS unterstützt bis zu fünf externe Syslog-Server. Mehrere Ziele sind sinnvoll, wenn sie unterschiedliche Aufgaben haben, etwa lokales Archiv und MDR-Collector. Alle Logs blind an jedes Ziel zu senden erhöht dagegen Volumen, Kosten und Datenschutzrisiko.

Facility, Severity und Format

Facility: LOCAL0 bis LOCAL7 können Firewalls oder Standortgruppen unterscheiden. Die Zuordnung muss im Collector und in der Dokumentation identisch sein.
Severity level: Die Auswahl ist die Mindestschwere. Error sendet auch Critical, Alert und Emergency, aber keine Information- oder Notice-Events. Gerade Anmeldungen und normale Betriebsereignisse können dadurch fehlen.
Format: Zur Auswahl stehen Standard syslog protocol und Device standard format (legacy). Entscheidend ist, welches Format der SIEM-Parser erwartet. Ein späterer Wechsel kann Suchen, Dashboards und Detection-Regeln brechen.

Secure log transmission

Für produktive Verbindungen über unsichere oder geteilte Netze ist TLS sinnvoll, weil Logs interne Adressen, Benutzernamen, URLs und Security-Ereignisse enthalten können. Der Haken allein genügt jedoch nicht: Der Collector muss TLS auf dem gewählten Port annehmen und beide Seiten müssen die Zertifikate prüfen können.

Für die von Sophos dokumentierte Secure-Syslog-Verbindung gilt:

Das Serverzertifikat des Collectors und seine Zertifikatskette müssen für die Firewall vertrauenswürdig sein.
Der konfigurierte FQDN muss zum Zertifikat passen. Ohne LINCE prüft SFOS den Common Name; mit LINCE darf Common Name oder Subject Alternative Name passen.
Unter Certificates > Certificate authorities wird die Sophos-CA Default heruntergeladen. Der Collector muss der daraus extrahierten Default.pem vertrauen, weil Sophos diese CA für seine Seite der Verbindung verwendet.
Erst danach wird Secure log transmission mit dem vorbereiteten TLS-Port aktiviert.

Im offiziellen syslog-ng-Beispiel liegen Default.pem und die externe CA im CA-Verzeichnis des Collectors; peer_verify(required-trusted) erzwingt die Zertifikatsprüfung. Andere Collector-Produkte haben dafür eigene Trust Stores. Ein FQDN, der nur im SAN steht, funktioniert ohne LINCE nicht, und eine eingetragene IP-Adresse passt nicht zu einem reinen DNS-Zertifikat.

Unterstützt ein Cloud-SIEM dieses Verfahren nicht direkt, kann die Firewall intern an einen lokalen Collector senden und dieser verschlüsselt weiterleiten. Eine unverschlüsselte Teilstrecke sollte kurz, segmentiert und dokumentiert sein.

Logtypen und Sichtbarkeit festlegen

Das Ziel wird in zwei Stufen aktiviert:

Die jeweilige Regel oder Funktion muss das Ereignis erzeugen. Bei Firewall-Regeln ist dafür Log firewall traffic, bei SSL/TLS-Inspection-Regeln Log connections erforderlich.
Unter System services > Log settings muss der zugehörige Logtyp in der Spalte des Syslog-Servers ausgewählt sein.

Fehlt eine der beiden Stufen, kann der Collector das Ereignis nicht erhalten. Für einen Pilot genügt zunächst ein bewusst kleines Set:

Firewall und Events: Regelereignisse, Admin- und Benutzeraktivität sowie Authentifizierungs-, VPN-, DHCP- und DNS-Ereignisse.
IPS, Content filtering, Web server protection und Zero-day protection: Security- und Policy-Entscheidungen.
Active threat response: Treffer von MDR, NDR Essentials, Sophos X-Ops und Third-Party Threat Feeds.
System health, Wireless, Heartbeat und SD-WAN: zusätzlicher Betriebszustand, wenn diese Module genutzt werden.

Weitere Module kommen erst hinzu, wenn ein Such-, Alarm- oder Audit-Zweck besteht. Wer DoS-Ereignisse auswertet, sollte auch die Spoof- und DoS-Konfiguration prüfen. Für Third-Party Threat Feeds sowie NDR und Active Threat Response braucht es ausser dem Logtransport konkrete Suchabfragen und Alarme.

Häufige Sichtbarkeitsfallen

Log Suppression: SFOS kann gleiche aufeinanderfolgende Firewall-Events zusammenfassen. Das wirkt auf Log Viewer, Sophos Central und Syslog. Parser und Detection müssen deshalb auch log_occurrence berücksichtigen.
Active Threat Response: Remote Source Match für eingehenden DNAT- oder WAF-Traffic ist nicht standardmässig aktiv. Ohne diese Auswahl fehlen entsprechende Quelltreffer.
Wireless: Access-Point- und SSID-Logs sind nicht im lokalen Log Viewer verfügbar. Sie müssen gezielt an Sophos Central oder Syslog gesendet und dort geprüft werden.
Content filtering und SSL/TLS: Der ausgewählte Logtyp ersetzt das Logging in der dazugehörigen Firewall- oder Inspection-Regel nicht.

Format und Parser prüfen

Ein Parser-Test darf nicht nur zeigen, dass irgendein Text ankommt. Die zentralen Werte müssen als eigene Felder suchbar sein. Dieses gekürzte, anonymisierte Beispiel entspricht dem Standard syslog protocol für ein Firewall-Regelereignis:

device_name="BRANCH-01" timestamp="2026-08-03T09:15:21+0200" device_model="XGS136" device_serial_id="C00000000000000" log_id="010101600001" log_type="Firewall" log_component="Firewall Rule" log_subtype="Allowed" log_version=1 severity="Information" fw_rule_id="12" fw_rule_name="LAN_to_WAN_Web" nat_rule_id="4" src_ip="10.10.20.25" dst_ip="203.0.113.10" protocol="TCP" src_port=53144 dst_port=443 con_event="Stop" log_occurrence="1"

Das Legacy-Format verwendet dagegen unter anderem device, date, time, timezone, device_id und priority. Felder wie status, user_name, nat_rule_id oder log_occurrence hängen zusätzlich vom Logtyp und Ereignis ab. Sie dürfen nicht als obligatorisch für jedes Standardformat-Event behandelt werden.

Für die Abnahme sind je nach Use Case besonders wichtig:

Identität: device_name, device_model, device_serial_id
Klassifikation: log_id, log_type, log_component, log_subtype, severity
Policy: fw_rule_id, fw_rule_name, nat_rule_id
Verbindung: src_ip, dst_ip, Ports, Protokoll und Benutzer
Zeit und Häufigkeit: timestamp, Zeitzone und log_occurrence

log_id enthält Logtyp, Komponente, Subtyp, Severity und Message-ID. Dadurch sind Detection-Regeln stabiler als reine Freitextsuchen. Welche Felder ein bestimmtes Modul liefert, muss trotzdem anhand eines echten Events dieses Logtyps geprüft werden.

Das Syslog-Modul Events ist nicht identisch mit configuration-audit.log. Vorher-/Nachher-Werte stehen dort nur für unterstützte Schlüsselobjekte wie Firewall-Regeln, Interfaces und IP-Hosts zur Verfügung, nicht für jede Konfigurationsänderung. Umfang und Auswertung werden im Artikel zu den Audit Trail Logs behandelt.

Mehrere Firewalls und HA

In einer Umgebung mit mehreren Appliances muss jedes Event eindeutig zu Firewall, Standort, Kunde und HA-Cluster gehören. Hostname, Seriennummer, Modell und Facility sollten deshalb dokumentiert und im SIEM filterbar sein.

Nach HA-Failover, Restore oder Hardwaretausch ist zu prüfen, ob Events weiterhin dem bestehenden Asset zugeordnet werden oder als neues beziehungsweise doppeltes System erscheinen. Dasselbe gilt nach einer Änderung des Hostnamens oder Syslog-Formats.

Anbindung mit echten Ereignissen testen

Ein grüner Collector beweist weder die richtige Logauswahl noch einen funktionierenden Parser. Für die Abnahme:

Eine Pilot-Firewall und das konfigurierte Format dokumentieren.
Zunächst Firewall und Events an das Ziel senden.
Eine geloggte Testregel mit definiertem Source, Destination und Service auslösen.
Im SIEM Gerät, Zeit, Logtyp, Aktion, Rule ID, Source und Destination prüfen.
Einen definierten Drop und eine VPN-An- und Abmeldung erzeugen.
Mindestens ein Security-Ereignis aus IPS, Content filtering oder Active threat response testen, sofern das Modul produktiv genutzt wird.
Danach weitere Logtypen schrittweise aktivieren und Volumen sowie Parser-Ergebnis beobachten.

Beim Regeltest hilft die Anleitung zu Log Viewer, Policy Test und Packet Capture. Wichtig ist auch ein negativer Test: Eine erwartete Verbindung wird bewusst blockiert und muss als Drop mit der richtigen Regel erscheinen.

Für HA- oder Migrationsprojekte gehört ein Failover-, Restore- oder Hardwaretausch-Test zur Abnahme. Das SOC muss danach weiterhin erkennen, welches Gerät und welcher Standort das Event erzeugt hat.

Betrieb, Aufbewahrung und Ausfälle

Eine Syslog-Anbindung braucht einen Owner, definierte Aufbewahrung und eine Reaktion auf Alarme. Zusätzlich muss feststehen, wer Fehlalarme bewertet und Detection-Regeln anpasst. Firewall-Logs können personenbezogene Daten, interne Adressen, Benutzernamen, URLs und VPN-Aktivität enthalten. Zugriffsrechte, Löschfristen, Mandantentrennung und SIEM-Kosten sollten deshalb vor dem breiten Rollout geklärt sein.

Der Betrieb muss nicht nur Angriffe, sondern auch fehlende Daten erkennen:

pro Firewall eine erwartete Mindestaktivität überwachen;
wichtige Logtypen wie Firewall, Events, IPS oder Active threat response separat auf Aktualität prüfen;
zentrale Parser-Felder auf leere oder plötzlich umbenannte Werte überwachen;
Zertifikatsablauf und Collector-Zustand alarmieren;
nach Firmware-, Parser- und Zertifikatsupdates erneut Testevents erzeugen.

Die Überwachung selbst muss ebenfalls getestet werden: Bleibt ein erwarteter Logtyp oder eine Firewall bewusst aus, muss der definierte Ausfallalarm auslösen.

Rohdaten ohne geparste Felder sind ebenfalls ein Ausfall. Ein Parser-Update kann den Transport intakt lassen, während Dashboards und Detection-Regeln keine Treffer mehr liefern.

Syslog ersetzt weder lokale Service-Logs noch ein Troubleshooting-Archiv für den Support. Für v5-Records aus gezielt geloggten Firewall-Regeln passt NetFlow, für Interface-Samples und Traffic-Muster sFlow. Hardware- und Interface-Zustände lassen sich zusätzlich per SNMP überwachen.

Fehler gezielt eingrenzen

Es kommen keine Logs an: Ziel, Port, Transport, Routing und Gegenfirewall prüfen. Danach kontrollieren, ob der gewünschte Logtyp in der Syslog-Spalte aktiviert ist. Liegt der Collector hinter VPN oder Managementnetz, auch Route, SD-WAN-Policy und Source-NAT berücksichtigen.

Nur bestimmte Ereignisse fehlen: Zuerst das Logging in der betroffenen Firewall- oder Inspection-Regel prüfen, danach den Logtyp unter Log settings. Bei ATR zusätzlich den benötigten Match-Typ kontrollieren.

Rohlogs kommen an, Felder fehlen: Eingestelltes Format, Parser-Version und Firmwarestand vergleichen. Standard- und Legacy-Felder dürfen nicht im selben Parserprofil erwartet werden.

TLS verbindet nicht: TLS-Port und Serverdienst prüfen, danach Zertifikatskette, FQDN, Common Name, SAN und LINCE-Modus. Zusätzlich muss der Collector der Sophos-CA Default.pem vertrauen. Bei Zertifikatswechseln beide Trust Stores und den Erneuerungsprozess kontrollieren.

Zeitstempel stimmen nicht: NTP auf Firewall und Collector, Zeitzone des SIEM sowie Parser-Normalisierung prüfen. Falsche Zeiten verhindern eine zuverlässige Korrelation mit Endpoint-, Server- und Identity-Logs.

Zu viele Logs oder zu viel Rauschen: Nicht pauschal alles deaktivieren. Zuerst nicht genutzte Logtypen, unnötig laute Regeln, SIEM-Use-Cases und log_occurrence auswerten; danach die Auswahl gezielt reduzieren.