Sophos Firewall Syslog sicher an SIEM senden

Mit Syslog kann eine Sophos Firewall Ereignisse an einen externen Logserver, ein SIEM oder eine Security-Plattform senden. Das ist besonders wichtig, wenn Logs länger aufbewahrt, zentral durchsucht, mit anderen Systemen korreliert oder für Audits und Incident Response genutzt werden sollen.

Der lokale Log viewer ist gut für die schnelle Analyse direkt auf der Firewall. Central Firewall Reporting ist praktisch, wenn Sophos Central als Reporting-Plattform genutzt wird. Syslog ist dagegen die bessere Wahl, wenn ein eigenes SIEM, ein SOC, ein Managed Detection Prozess oder eine herstellerübergreifende Logarchitektur vorhanden ist.

Welcher Logging-Artikel passt?

Logging auf Sophos Firewall besteht aus mehreren Ebenen. Je nach Frage ist Syslog nicht immer der beste Einstieg:

• Einzelne Verbindung, Rule ID oder Web-/IPS-Entscheidung live analysieren: Sophos Firewall Regel testen mit Log Viewer, Policy tester und Packet Capture.
• Lokale Logdateien und Dienste zuordnen: Sophos Firewall Troubleshooting: Services und Logs.
• Logs für Support oder externe Analyse sichern: Sophos Firewall Logs für Support und Analyse sichern.
• Konfigurationsänderungen und Admin-Aktionen nachvollziehen: Sophos Firewall Audit Trail Logs prüfen.
• Sophos-Central-basierte Reports über mehrere Firewalls nutzen: Sophos Firewall Central Reporting aktivieren und betreiben.
• Logs langfristig an SIEM, SOC oder Logserver senden: Dieser Artikel.
• Traffic-Flows statt einzelner Firewall-Events analysieren: sFlow Monitoring auf Sophos Firewall konfigurieren.
• Hardware- und Interface-Zustand per Monitoring prüfen: Sophos Firewall SNMP Hardware Monitoring einrichten.

So bleibt die Auswertung sauber: Der Log Viewer beantwortet den aktuellen Paket- oder Policy-Fall, lokale Logs helfen bei tieferer Moduldiagnose, Central Reporting ist bequem für Sophos-Auswertungen, und Syslog liefert die externe Langzeit- und SIEM-Schicht.

Wann Syslog sinnvoll ist

Syslog lohnt sich nicht nur für grosse Umgebungen. Schon bei wenigen Firewalls kann ein zentraler Logserver helfen, Ereignisse länger und unabhängig von der Appliance aufzubewahren.

Typische Anwendungsfälle:

• zentrale Logaufbewahrung über Wochen, Monate oder Jahre
• Korrelation mit Endpoint-, Server-, Identity-, Proxy-, Cloud- oder Switch-Logs
• SIEM Use Cases für Angriffe, Portscans, VPN-Anmeldungen, WAF-Events oder Threat-Feed-Treffer
• externe Auswertung durch SOC, MDR oder interne Security-Teams
• Nachvollziehbarkeit nach Firmware-Updates, Failover, Restore oder Hardwaretausch
• Forensik, wenn lokale Firewall-Logs nicht mehr ausreichen

Für akute Troubleshooting-Fälle bleiben lokale Logs trotzdem wichtig. Welche lokale Logdatei zu welchem Firewall-Modul gehört, steht in Sophos Firewall Troubleshooting: Services und Logs. Wenn Logs für Support oder eine externe Analyse gesichert werden sollen, passt Sophos Firewall Logs für Support und Analyse sichern.

Syslog, Central Reporting oder lokale Logs?

Die drei Wege beantworten unterschiedliche Fragen. In der Praxis nutzt man oft mehrere davon parallel.

• Log viewer: schnelle Live-Analyse auf der Firewall, aber keine langfristige zentrale Architektur.
• Lokale Logdateien: Detailanalyse per Advanced Shell oder Supportfall, aber abhängig vom Zustand und Speicher der Firewall.
• Central Firewall Reporting: Sophos-Central-Reports und einfache Übersicht über mehrere Firewalls, aber an Sophos Central, Lizenz und Speicherrahmen gebunden.
• Syslog / SIEM: eigene Aufbewahrung, Korrelation, Detection und Audit. Dafür braucht es Parser, Betrieb, Monitoring und klare Use Cases.

Syslog ersetzt also nicht den Log Viewer. Es ergänzt ihn. Der Log Viewer zeigt schnell, welche Regel oder welches Modul entschieden hat. Syslog sorgt dafür, dass diese Informationen später noch extern verfügbar sind.

Voraussetzungen

Vor der Konfiguration sollten diese Punkte geklärt sein:

• Syslog-Server oder SIEM ist erreichbar.
• Ziel-IP oder FQDN ist stabil und dokumentiert.
• Port und Transport sind festgelegt, häufig UDP 514 oder TLS auf einem eigenen Port.
• Firewall kann den Syslog-Server routen und erreichen.
• Im Zielsystem existiert ein passender Parser oder zumindest eine Rohdatenablage.
• NTP auf Firewall und Zielplattform funktioniert.
• Aufbewahrungsdauer und Datenschutzanforderungen sind definiert.
• Es ist klar, welche Logtypen wirklich gebraucht werden.

Bei externen oder cloudbasierten SIEM-Zielen sollte man besonders auf Transportverschlüsselung, Quell-IP, Routing, DNS und Zertifikatsprüfung achten. Einige SIEM- oder MDR-Anbieter erwarten bewusst unverschlüsseltes Syslog zu einem lokalen Collector oder Sensor, der die Daten danach weiterleitet. Dann sollte die unverschlüsselte Strecke kurz, intern segmentiert und dokumentiert sein.

Datenschutz, Aufbewahrung und Zuständigkeit klären

Syslog ist nicht nur eine technische Weiterleitung. Firewall-Logs können interne IP-Adressen, Benutzernamen, Zielsysteme, URLs, Kategorien, VPN-Anmeldungen, Admin-Ereignisse und Security-Treffer enthalten. Deshalb sollte vor der produktiven Anbindung klar sein, wer diese Daten sehen darf und wie lange sie gespeichert werden.

Vor dem Rollout klären:

• Aufbewahrung: Wie lange müssen Logs für Betrieb, Audit oder Incident Response verfügbar bleiben?
• Zugriff: Welche Personen oder Teams dürfen Rohlogs, Suchabfragen und Dashboards sehen?
• Datenschutz: Enthalten Logs personenbezogene Daten, Benutzer-IDs, Quell-IP-Adressen oder URLs?
• Mandantenfähigkeit: Sind Standorte, Kunden, Tenants oder HA-Cluster im SIEM sauber getrennt?
• Kosten: Werden Logvolumen, EPS, Speicher oder Suchabfragen beim SIEM-Anbieter verrechnet?
• Alarmierung: Wer reagiert auf Alarme und in welchem Zeitfenster?
• Löschung: Wie werden alte Logs nach Ablauf der Aufbewahrungsfrist entfernt?

Gerade bei MSP-, SOC- oder MDR-Modellen sollte diese Zuständigkeit nicht offen bleiben. Ein SIEM ohne klare Besitzer erzeugt zwar Daten, aber keine verlässliche Reaktion.

Rollout in Phasen planen

Für produktive Firewalls ist ein kleiner Pilot besser als sofort alle Logtypen an alle Ziele zu senden. So lassen sich Parser, Feldnamen, Rauschen und Kosten kontrollieren, bevor das SIEM als verlässliche Quelle eingeplant wird.

Ein sinnvoller Ablauf:

1. Als erstes wird eine Pilot-Firewall ausgewählt.
2. Hostname, Zeitquelle, Firmwarestand und Logformat werden dokumentiert.
3. Das Syslog-Ziel wird mit sicherem Transport konfiguriert.
4. Der Start erfolgt mit wenigen Logtypen, zum Beispiel Firewall, Events und VPN.
5. Definierte Testereignisse werden erzeugt und im Zielsystem geprüft.
6. Parser, Felder, Zeitstempel, Zeitzone und device_name werden validiert.
7. Logvolumen und Rauschen werden über einige Tage beobachtet.
8. Danach werden weitere Logtypen wie IPS, Web, WAF, Active threat response oder System health ergänzt.
9. Erst nach erfolgreichem Pilot wird auf weitere Firewalls ausgerollt.

Bei mehreren Firewalls sollte man nicht nur prüfen, ob Daten ankommen. Wichtig ist, ob jedes Event dem richtigen Standort, Gerät, HA-Node, Kunden oder Tenant zugeordnet wird.

Der Pilot sollte mindestens ein normales Betriebsereignis, ein Security-Ereignis und ein Fehlerereignis enthalten. Sonst wirkt der Transport zwar gesund, aber die später wichtigen Felder fehlen erst im Ernstfall.

Syslog-Server hinzufügen

Die Konfiguration erfolgt in der Sophos Firewall Weboberfläche.

1. System services > Log settings öffnen.
2. Add auswählen.
3. Einen eindeutigen Namen vergeben, zum Beispiel siem-primary oder syslog-soc.
4. IP address/domain des Syslog-Servers eintragen.
5. Port passend zum Zielsystem setzen.
6. Facility bewusst wählen.
7. Severity level festlegen.
8. Format auswählen.
9. Optional Secure log transmission aktivieren, wenn das Ziel TLS unterstützt.
10. Speichern.

Sophos Firewall kann mehrere externe Syslog-Server konfigurieren. In der aktuellen Dokumentation sind bis zu fünf Syslog-Server vorgesehen. Trotzdem sollte man nicht wahllos jedes Ziel anbinden, sondern pro Ziel festlegen, welcher Zweck dahintersteht.

Bei mehreren Zielen sollte man die Logauswahl pro Ziel bewusst trennen. Ein lokaler Logserver braucht vielleicht alle Firewall- und VPN-Logs, während ein MDR-Collector nur Security-relevante Logtypen erwartet. Wenn alle Ziele blind dieselben Daten erhalten, steigen Kosten, Datenschutzrisiko und Parser-Rauschen.

Wichtige Einstellungen

Facility

Die Facility hilft dem Syslog-Server, Logquellen oder Kategorien zu unterscheiden. In einfachen Umgebungen reicht oft ein Standardwert. In grösseren Umgebungen kann es sinnvoll sein, Firewalls oder Standortgruppen über unterschiedliche LOCAL0 bis LOCAL7 Werte zu trennen.

Wichtig ist, dass SIEM-Regeln, Parser und Dokumentation dieselbe Logik verwenden. Wenn jede Firewall zufällig eine andere Facility nutzt, wird die Auswertung unnötig schwer.

Severity level

Die Severity legt fest, ab welcher Schwere Logs gesendet werden. Für Security- und Troubleshooting-Zwecke ist eine zu hohe Schwelle gefährlich, weil dann wichtige Informations- oder Notice-Ereignisse fehlen können. Für sehr laute Umgebungen kann eine zu niedrige Schwelle dagegen unnötig viel Rauschen erzeugen.

Sinnvoll ist meist ein Pilot mit breiterer Logauswahl, danach eine bewusste Reduktion anhand echter Treffer und SIEM-Use-Cases.

Die Schwelle ist als Mindestschwere zu verstehen. Wenn zum Beispiel Error gewählt wird, sendet die Firewall auch kritischere Meldungen wie Critical, Alert und Emergency, aber keine normalen Informationsereignisse. Für viele SIEM-Use-Cases sind gerade Information- und Notice-Events wichtig, weil VPN-Anmeldungen, Regelereignisse oder Systemzustände sonst fehlen können.

Format

Sophos Firewall bietet laut aktueller Dokumentation zwei Formate:

• Standard syslog protocol
• Device standard format (legacy)

Für neue Integrationen sollte zuerst geprüft werden, welches Format das Zielsystem oder der vorhandene Parser erwartet. Wenn ein SIEM bereits einen Sophos-Firewall-Parser hat, ist dessen Erwartung massgebend. Ein Formatwechsel nach dem Produktivstart kann Dashboards, Suchabfragen und Detection-Regeln brechen.

Secure log transmission

Wenn Secure log transmission aktiv ist, werden Logs verschlüsselt an den Syslog-Server gesendet. Dafür muss das Zielsystem TLS auf dem konfigurierten Port annehmen, ein passendes Serverzertifikat ausliefern und eine Zertifikatskette verwenden, der die Firewall vertraut. Vor dem Go-live sollte deshalb nicht nur der Haken in der Firewall gesetzt werden, sondern auch Zertifikatsname, Trust Chain, Port, Parser und Erneuerungsprozess des Syslog-Ziels geprüft werden.

Für interne Labors kann UDP technisch reichen. Für produktive SIEM- oder SOC-Anbindungen ist unverschlüsseltes Syslog über unsichere Netze aber keine gute Grundlage, weil Logdaten interne IP-Adressen, Benutzer, Ziele, URLs oder Security-Ereignisse enthalten können.

Bei TLS ist der Name des Syslog-Ziels wichtig. Ohne aktivierten LINCE-Compliance-Modus prüft Sophos Firewall den Common Name des Zertifikats gegen die Domain des Syslog-Servers; der Subject Alternative Name wird in diesem Standardfall nicht als Ersatz verwendet. Mit aktiviertem LINCE kann Common Name oder Subject Alternative Name passen. Wenn in der Firewall eine IP-Adresse eingetragen wird, das Zertifikat aber nur einen DNS-Namen enthält, oder wenn ein Zertifikat nur per SAN passt, kann die Verbindung je nach Modus scheitern. Darum sollte man für produktive TLS-Syslog-Ziele einen stabilen FQDN, ein passendes Serverzertifikat und eine dokumentierte Zertifikatsverlängerung einplanen.

Gleichzeitig muss das Zielsystem das gewählte Verfahren wirklich verstehen. Manche SIEM-Integrationen setzen einen lokalen Collector voraus und unterstützen Secure log transmission der Firewall nicht direkt. Dann ist die bessere Lösung oft: Firewall sendet intern an den Collector, der Collector verschlüsselt weiter zur Cloud oder SOC-Plattform. Diese Architektur sollte im Betriebsdokument stehen, sonst wird später fälschlicherweise angenommen, alle Teilstrecken seien verschlüsselt.

Logtypen auswählen

Nach dem Hinzufügen des Syslog-Servers ist die Arbeit noch nicht fertig. Man muss unter System services > Log settings festlegen, welche Logtypen an dieses Ziel gesendet werden.

Wichtig: Eine Firewall-Regel erzeugt nur dann sinnvolle Traffic-Logs, wenn in der Regel Log firewall traffic aktiviert ist. Für SSL/TLS Inspection muss in der passenden Inspection Rule Log connections aktiv sein. Die Logauswahl unter Log settings bestimmt danach, wohin diese Logs lokal, nach Sophos Central oder an Syslog-Server gesendet werden.

Typische Logtypen für ein SIEM:

• Firewall: erlaubte und verworfene Verbindungen, Regel-Matching und DoS-Ereignisse.
• IPS: erkannte oder blockierte Angriffe.
• Web / Content filtering: Webzugriffe, Kategorien und Web-Policy-Ereignisse.
• SSL/TLS inspection: TLS-Inspection-Entscheidungen und Fehler.
• Web server protection: WAF-Ereignisse für veröffentlichte Dienste.
• Authentication / Events: Admin-, Benutzer- und Systemereignisse.
• VPN: Remote Access und Site-to-Site-VPN-Ereignisse.
• Active threat response: Treffer durch MDR Threat Feeds, NDR Essentials, Sophos X-Ops und Third-Party Threat Feeds.
• System health: CPU, Speicher, Benutzer, Interfaces und Partitionen.

Wenn DoS- oder Spoof-Ereignisse ausgewertet werden sollen, sollte die technische Härtung selbst ebenfalls geprüft sein. Der Ablauf steht in Sophos Firewall Spoof Protection und DoS Settings prüfen.

Wenn Third-Party Threat Feeds, NDR und Active Threat Response oder WAF genutzt werden, sollte das SIEM diese Ereignisse gezielt auswerten. Nur Logs zu senden reicht nicht. Es braucht klare Suchabfragen, Alarme, Verantwortlichkeiten und Tuning gegen Fehlalarme.

Parser-Felder bewusst prüfen

Sophos-Syslog-Events enthalten je nach Logtyp unterschiedliche Felder. Für Parser und Dashboards sind besonders log_id, log_type, log_component, log_subtype, severity, status, device_name, device_model, device_serial_id, fw_rule_id, fw_rule_name, nat_rule_id, src_ip, dst_ip, user_name und Zeitstempel relevant.

log_id ist dabei mehr als eine zufällige Nummer. Die ID setzt sich aus Logtyp, Komponente, Subtyp, Severity und Message ID zusammen. Das ist hilfreich, wenn ein SIEM nicht nur Freitext auswertet, sondern stabile Detection-Regeln, Dashboards oder Normalisierungen bauen soll.

Für die Abnahme sollte man deshalb nicht nur prüfen, ob Rohdaten ankommen. Entscheidend ist, ob die Felder wirklich als eigene Felder im SIEM landen. Wenn fw_rule_id oder nat_rule_id nur im Rohtext steckt, funktionieren spätere Suchen und Alarme oft schlechter als erwartet.

Ein anonymisiertes Firewall-Event kann im Rohformat zum Beispiel so aussehen:

date=2026-07-01 time=14:23:11 log_type="Firewall" log_component="Firewall Rule" log_subtype="Allowed" status="Allow" device_name="SFOS-XGS" device_serial_id="C00000000000000" 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" dst_port="443" user_name="AVANET\\test.user"

Das Beispiel ersetzt keine offizielle Feldreferenz. Es zeigt aber, welche Informationen beim Parser-Test als eigene Felder sichtbar sein sollten.

Typisches Startset für SIEM-Pilot

Für einen Pilot ist ein kleines, bewusstes Startset besser als eine Vollaktivierung ohne Auswertung.

• Start: Firewall, Events und VPN aktivieren. Damit lassen sich Grundrauschen, Regelereignisse, Admin- und VPN-Sichtbarkeit prüfen.
• Security: IPS, Web, Web server protection und Active threat response ergänzen. Ziel ist die Validierung von Security Use Cases und Parser-Feldern.
• Betrieb: System health, DHCP, DNS und Authentication ergänzen. So entsteht mehr Betriebs- und Identitätskontext.
• Feintuning: Weitere Module nur nach Bedarf aktivieren, wenn es einen Such-, Alarm- oder Audit-Zweck gibt.

Nach jeder Phase sollte geprüft werden, ob das SIEM die Felder sauber erkennt und ob jemand die neuen Ereignisse tatsächlich nutzt. Ungeprüfte Logtypen sind kein Mehrwert, sondern nur zusätzliches Volumen.

Wichtige Sichtbarkeitsfallen

Bei Syslog-Projekten entstehen viele Lücken nicht im Transport, sondern vorher: Die Firewall erzeugt das erwartete Event gar nicht, der Logtyp wird nicht an den Syslog-Server gesendet oder das SIEM interpretiert die Felder falsch.

Regel- und Modul-Logging

Firewall-Regeln und SSL/TLS-Inspection-Regeln müssen selbst Logging erzeugen. Unter System services > Log settings wählt man danach aus, ob diese Logs lokal, in Sophos Central oder an Syslog-Server gesendet werden. Wenn eine Firewall-Regel kein Log firewall traffic hat, kann der Syslog-Server keinen vollständigen Firewall-Traffic-Verlauf anzeigen.

Für Web-Policy-Ereignisse ist ebenfalls relevant, ob die zugehörige Firewall-Regel Traffic-Logging erzeugt. Sonst sieht man im SIEM möglicherweise weniger Web- oder Content-Filtering-Ereignisse als erwartet.

Log Suppression

Sophos Firewall kann mehrere gleiche aufeinanderfolgende Logeinträge unterdrücken. Das spart Speicher und Verarbeitung, kann aber bei SIEM Use Cases verwirren, wenn Zählwerte, Häufigkeit oder Burst-Verhalten ausgewertet werden sollen. Die Funktion wirkt auf Log Viewer, Sophos Central und externe Syslog-Server.

Vor einem produktiven SIEM-Rollout sollte man deshalb festlegen:

• Welche Firewall-Events dürfen unterdrückt werden?
• Welche Detection-Regeln brauchen jede einzelne Verbindung?
• Wird im SIEM mit Zählwerten oder nur mit einzelnen Events gearbeitet?
• Wie wird dokumentiert, dass Log Suppression aktiv ist?

Active Threat Response

Active-Threat-Response-Logs sind besonders nützlich, wenn Threat Feeds, NDR Essentials oder externe Feeds eingesetzt werden. Sophos unterscheidet dabei verschiedene Match-Typen, zum Beispiel Zieltreffer bei ausgehendem Traffic und Quelltreffer bei eingehendem Traffic.

Wichtig: Remote Source Match für eingehenden Traffic ist nicht automatisch aktiv. Wenn WAF- oder DNAT-Traffic gegen Threat Feeds überwacht werden soll, muss diese Sichtbarkeit bewusst geprüft werden. Sonst fehlen genau die eingehenden Treffer, die ein SOC oft erwartet.

Wireless-Logs

Wireless-Logs sind nicht automatisch im lokalen Log Viewer sichtbar. Access-Point- und SSID-Logs sollten gezielt an Sophos Central oder Syslog gesendet und im Zielsystem separat geprüft werden, wenn Wireless-Ereignisse für Betrieb, Support oder Compliance relevant sind.

Multi-Firewall-Umgebungen

In Umgebungen mit mehreren Firewalls muss jedes Event eindeutig einer Appliance zugeordnet werden können. Dafür sind Hostname, Seriennummer, Modell und andere Felder relevant. In Syslog-Events können je nach Logtyp Felder wie device_name, device_model und device_serial_id auftauchen. Das SIEM sollte diese Felder nicht nur speichern, sondern für Filter, Dashboards und Alarme nutzbar machen.

Praktische Empfehlungen:

• Firewall-Hostname sauber setzen.
• Standort oder Rolle im Hostnamen berücksichtigen.
• Einheitliche Facility- oder Tagging-Strategie definieren.
• Im SIEM prüfen, ob Events nach Firewall, Standort und Cluster gefiltert werden können.
• HA-Cluster und Standalone-Firewalls sauber unterscheiden.

Gerade nach einem Hardwaretausch oder Restore ist diese Zuordnung wichtig. Sonst wirken Events im SIEM wie neue oder doppelte Systeme.

Bei HA-Clustern sollte zusätzlich getestet werden, wie Events nach einem Failover erscheinen. Entscheidend ist, ob Betrieb und SOC weiterhin denselben Standort erkennen oder ob plötzlich ein anderer Hostname, eine andere Seriennummer oder ein neues Asset im SIEM auftaucht.

Konfiguration testen

Nach dem Speichern sollte die Anbindung bewusst getestet werden. Ein grünes Zielsystem allein beweist noch nicht, dass die richtigen Logs mit den richtigen Feldern ankommen.

Testpunkte:

1. Auf der Firewall System services > Log settings öffnen.
2. Sicherstellen, dass der Syslog-Server sichtbar ist.
3. Für einen ungefährlichen Logtyp testweise Syslog aktivieren.
4. Eine definierte Aktion auslösen, zum Beispiel eine geloggte Firewall-Regel oder einen Testzugriff.
5. Im Zielsystem prüfen, ob das Event ankommt.
6. Felder wie Zeit, Hostname, device_name, Source, Destination, Rule ID, Action und Logtyp prüfen.
7. Zeitstempel und Zeitzone im SIEM kontrollieren.
8. Bei Firewall-Events prüfen, ob fw_rule_id, fw_rule_name, nat_rule_id, src_ip, dst_ip, status und log_occurrence separat suchbar sind.

Für Regeltests ist Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture hilfreich. Wenn gar keine Events entstehen, liegt die Ursache oft nicht beim Syslog-Transport, sondern bei deaktiviertem Logging in der Regel oder beim falschen Logtyp.

Sinnvolle Testereignisse

Ein guter Abnahmetest erzeugt nicht nur irgendein Log, sondern genau die Ereignisse, die später gesucht werden.

• Geloggte Testregel erlaubt eine Verbindung: Source, Destination, Service, Action, Rule ID und Firewall sollten eindeutig sichtbar sein.
• Definierte Drop-Regel trifft: Das Drop-Event sollte mit korrekter Richtung und Zeit erscheinen.
• VPN-Benutzer verbindet und trennt: Benutzer, Tunneltyp, Zeit und Firewall sollten erkannt werden.
• Web-Policy oder IPS-Testereignis: Logtyp, Kategorie oder Signatur sollte vom Parser richtig aufgelöst werden.
• ATR- oder Threat-Feed-Test, falls verfügbar: Der Treffer sollte im erwarteten Use Case erscheinen und keinen falschen Alarm erzeugen.
• HA-Failover oder Restore-Test, falls geplant: Events sollten Standort, Cluster und Appliance nachvollziehbar zugeordnet bleiben.

Für produktive SIEM-Regeln sollte man zusätzlich ein negatives Testergebnis dokumentieren: Was passiert, wenn ein erwartetes Event nicht kommt? Nur dann fällt später auf, ob ein Parser, Collector oder Logtyp still ausgefallen ist.

Betrieb und Monitoring

Eine Syslog-Anbindung ist kein einmaliger Haken. Der Betrieb muss überwacht und regelmässig geprüft werden.

Mindestens diese Punkte sollten dokumentiert sein:

• Wer ist Owner der Logplattform?
• Welche Firewalls senden Logs?
• Welche Logtypen werden gesendet?
• Welche Aufbewahrungsdauer gilt?
• Welche Parser, Dashboards und Alarme hängen daran?
• Wie erkennt man, dass keine Logs mehr ankommen?
• Wie werden Formatänderungen nach Firmware-Updates geprüft?
• Wie werden Zertifikatsablauf, Collector-Updates und Parser-Änderungen überwacht?
• Wer bewertet Fehlalarme und passt SIEM-Regeln an?

Nach Firmware-Updates sollte stichprobenartig geprüft werden, ob wichtige Events noch korrekt geparst werden. Das gilt besonders für produktive SIEM-Regeln, die auf bestimmte Feldnamen, Logtypen oder Formate angewiesen sind.

Stillen Logausfall erkennen

Eine Syslog-Anbindung kann technisch teilweise ausfallen, ohne dass sofort jemand einen Fehler sieht. Der Collector läuft vielleicht noch, aber ein Logtyp fehlt. Oder Rohdaten kommen an, werden aber nach einem Parser-Update nicht mehr in die erwarteten Felder zerlegt.

Für den Betrieb sollte deshalb ein einfacher Ausfallindikator existieren:

• Pro Firewall: Erwartete Mindestanzahl an Events pro Zeitraum definieren, zum Beispiel Firewall- oder Systemereignisse.
• Pro wichtigem Logtyp: Prüfen, ob Firewall, VPN, Web, IPS oder Active threat response noch regelmässig Events liefern.
• Pro Parser: Überwachen, ob zentrale Felder wie device_name, Source, Destination, Action und Rule ID weiterhin befüllt werden.
• Pro Collector: Erkennen, ob ein lokaler Collector keine Daten mehr annimmt oder nicht mehr weiterleitet.
• Nach Changes: Firmware-Update, Parser-Update, Zertifikatswechsel, Firewall-Restore und HA-Failover als Anlass für einen erneuten Abnahmetest nutzen.

Ein guter SIEM-Betrieb alarmiert also nicht nur bei verdächtigen Events, sondern auch bei fehlenden Events. Wenn eine produktive Firewall plötzlich keine Logs mehr liefert, ist das selbst ein Betriebsereignis.

Troubleshooting

Keine Logs kommen im SIEM an

Zuerst IP-Adresse, Port, Routing und Firewall-Regeln zwischen Sophos Firewall und Syslog-Server prüfen. Danach kontrollieren, ob unter System services > Log settings der richtige Logtyp für den Syslog-Server aktiviert ist.

Wenn der Syslog-Server über einen VPN-Tunnel oder ein separates Managementnetz erreichbar ist, zusätzlich Route, SD-WAN-Policy, Source-NAT und Gegenfirewall prüfen. Aus Sicht der Sophos Firewall ist Syslog normaler ausgehender Traffic; er muss den Collector auch tatsächlich erreichen.

Nur bestimmte Events fehlen

Dann ist oft das Modul- oder Regel-Logging nicht aktiv. Bei Firewall-Regeln muss Log firewall traffic gesetzt sein. Bei Web- oder SSL/TLS-Ereignissen muss zusätzlich die passende Policy oder Inspection Rule Logging erzeugen.

Logs kommen an, werden aber falsch geparst

Format, Parser-Version und Firmwarestand prüfen. Wenn zwischen Standard syslog protocol und Device standard format (legacy) gewechselt wurde, muss der SIEM-Parser dazu passen.

TLS-Syslog verbindet nicht

FQDN, Zertifikat, Common Name, Subject Alternative Name, LINCE-Modus, Zertifikatskette und Port prüfen. In den meisten Umgebungen ohne LINCE muss der Common Name zur konfigurierten Domain passen; ein nur im SAN passender Name reicht dann nicht. Wenn die Firewall einen DNS-Namen erwartet, der Syslog-Server aber nur über IP-Adresse eingetragen wurde, kann die Zertifikatsprüfung ebenfalls scheitern. Zusätzlich kontrollieren, ob das Zielsystem wirklich TLS auf dem konfigurierten Port annimmt.

Wenn ein SIEM-Anbieter Secure log transmission nicht direkt unterstützt, sollte man nicht versuchen, den Parser mit zufälligen Formaten zu retten. Besser ist ein unterstützter lokaler Collector, ein anderes Transportdesign oder eine klare Entscheidung, welche interne Strecke unverschlüsselt bleibt.

Zeitstempel stimmen nicht

NTP auf der Firewall, Zeitzone im SIEM und Parser-Logik prüfen. Falsche Zeiten machen Korrelation mit Endpoint-, Server- oder Identity-Logs unzuverlässig.

Zu viele Logs oder zu viel Rauschen

Nicht sofort alles deaktivieren. Zuerst prüfen, welche Logtypen wirklich gebraucht werden, welche Regeln unnötig viel loggen und ob Log suppression sinnvoll ist. Danach gezielt reduzieren.

Checkliste

• Syslog-Server oder SIEM ist erreichbar.
• Transport, Port und Verschlüsselung sind festgelegt.
• Bei TLS: FQDN, Zertifikat, Trust Chain und Erneuerung sind geprüft.
• Format passt zum SIEM-Parser.
• Facility-Strategie ist dokumentiert.
• Relevante Logtypen sind unter System services > Log settings aktiviert.
• Wichtige Firewall-Regeln haben Log firewall traffic aktiv.
• SSL/TLS-Inspection-Regeln erzeugen bei Bedarf eigene Logs.
• Log Suppression ist bewusst bewertet und dokumentiert.
• Active-Threat-Response-Match-Typen passen zu den SIEM Use Cases.
• Datenschutz, Zugriff und Aufbewahrungsdauer sind geklärt.
• Pilot-Firewall, Testevents und SIEM-Parser wurden validiert.
• Testevents kommen im Zielsystem an.
• Felder wie Hostname, device_name, Source, Destination, Action und Rule ID werden korrekt erkannt.
• Wichtige Parser-Felder wie log_id, log_type, log_component, fw_rule_id, nat_rule_id, src_ip, dst_ip, user_name, severity und status sind separat suchbar.
• HA-, Restore- oder Hardwaretausch-Szenario ist bei Bedarf im SIEM-Zuordnungsmodell berücksichtigt.
• Zeitstempel und Zeitzone stimmen.
• Monitoring erkennt, wenn keine Logs mehr ankommen.
• Monitoring erkennt, wenn wichtige Logtypen oder Parser-Felder still ausfallen.
• Nach Firmware-Updates wird die Parser-Funktion geprüft.

FAQ