Sophos Firewall Syslog 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:

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.

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.
• 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.

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:

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.

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.

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.

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. Sophos prüft je nach Modus den Common Name oder den Subject Alternative Name des Zertifikats gegen die Domain des Syslog-Servers. Wenn in der Firewall eine IP-Adresse eingetragen wird, das Zertifikat aber nur einen DNS-Namen enthält, kann die Verbindung scheitern. Darum sollte man für produktive TLS-Syslog-Ziele einen stabilen FQDN, ein passendes Serverzertifikat und eine dokumentierte Zertifikatsverlängerung einplanen.

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 ebenfalls Logging in der passenden Inspection Rule aktiv sein. Die Logauswahl unter Log settings bestimmt danach, wohin diese Logs gesendet werden.

Typische Logtypen für ein SIEM:

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.

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. Der SFOS-Syslog-Guide beschreibt unter anderem Felder wie device_name, device_model und device_serial_id.

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.

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.

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.

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?
• 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.

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.

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, Zertifikatskette und Port prüfen. Wenn die Firewall einen DNS-Namen erwartet, der Syslog-Server aber nur über IP-Adresse eingetragen wurde, kann die Zertifikatsprüfung scheitern. Zusätzlich kontrollieren, ob das Zielsystem wirklich TLS auf dem konfigurierten Port annimmt.

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.
• 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.
• Zeitstempel und Zeitzone stimmen.
• Monitoring erkennt, wenn keine Logs mehr ankommen.
• Nach Firmware-Updates wird die Parser-Funktion geprüft.

FAQ