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, erwartetes Logformat und ein passender Parser feststehen. Die Firewall benötigt eine Route zum Collector, beide Systeme eine funktionierende Zeitquelle. SFOS verwendet für Syslog normalerweise UDP 514. In der Maske gibt es keine separate Transportauswahl: Secure log transmission schaltet die TLS-verschlüsselte Übertragung ein oder aus. Im offiziellen syslog-ng-Beispiel für TLS wird Port 6514 verwendet; Port und Listener müssen immer zum eigenen Collector passen.

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: Zur Auswahl gehören DAEMON, KERNEL, USER und LOCAL0 bis LOCAL7. Für eigene Zuordnungen können beispielsweise LOCAL1 und LOCAL2 zwei Firewalls unterscheiden. Die Zuordnung muss im Collector und in der Betriebsdokumentation identisch sein.
Severity level: Die Auswahl ist die Mindestschwere. Error sendet auch Critical, Alert und Emergency, aber keine Information- oder Notice-Events. Debug schliesst alle Schweregrade ein. Gerade Anmeldungen und normale Betriebsereignisse können mit einem zu hohen Mindestwert 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.

Facilities kennzeichnen die Herkunft eines Logs: DAEMON steht für als Dienst laufende Prozesse, KERNEL für Kernel-Prozesse und USER für von angemeldeten Benutzern gestartete Prozesse. LOCAL0 bis LOCAL7 sind für eigene Zuordnungen gedacht. Bei der Severity ist Alert schwerer als Critical und verlangt sofortige Massnahmen. Standard syslog protocol hiess zuvor Central Reporting Format; Central Reporting verwendet ausschliesslich dieses Format. Im Device standard format (legacy) variiert die Anzahl der Datenfelder je nach Modul.

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.

Wer LINCE dafür aktivieren muss, sollte vorher die Zertifizierungsgrenze, zulässigen Algorithmen und den SSH-Neustart des LINCE-Modus prüfen. Der Modus ist kein reiner Syslog-Schalter und darf nicht ohne unabhängigen Adminzugang aktiviert werden.

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.

TLS-Collector mit syslog-ng vorbereiten

Das folgende Beispiel setzt einen Linux-Collector mit syslog-ng, aktivierter TLS-Unterstützung und einem von einer externen CA ausgestellten Serverzertifikat voraus. Die Firewall ist der sendende Client. ExternalCertificate.pem ist das Serverzertifikat, ExternalPrivateKey.key dessen privater Schlüssel und ExternalCA.pem die ausstellende CA. Diese Dateinamen sind Beispielnamen; Pfade und Zertifikate müssen zum eigenen Collector passen. Der private Schlüssel bleibt geschützt auf dem Collector; die private Schlüsseldatei der Firewall-CA wird dafür nicht benötigt.

Unter Certificates > Certificate authorities > Default die vorhandene CA prüfen. Ihr Name lässt sich nicht ändern. Die Attribute Country name, State und Locality name beschreiben Land, Region und Ort; Organization name und Organization unit name den Inhaber und die Abteilung. Common name enthält einen Namen oder FQDN, Email address einen Kontakt. Private key password erlaubt die Änderung eines vorhandenen CA-Passworts. Key type bietet RSA oder Elliptic curve: Bei RSA wird Key length, bei Elliptic curve Curve name gewählt; Secure hash legt den Hashalgorithmus fest. Key length ist die RSA-Schlüssellänge in Bit; grössere Schlüssel bieten mehr Sicherheitsreserve, erhöhen aber den Rechenaufwand. Beispiele für die CA-Identität sind Example AG, IT Security und fw01.example.com; sie werden durch Inhaber, Abteilung und freigegebene Namenskonvention der eigenen Umgebung ersetzt. Diese CA-Attribute sind nicht das Serverzertifikat des Collectors und ersetzen dessen passenden FQDN nicht.

Bestehende CA schützen: Nicht allein für Syslog die Default-CA ändern oder regenerieren. Eine notwendige CA-Änderung wird mit Backup, Wartungsfenster und Prüfung der abhängigen Dienste geplant; die Folgen erklärt Default-CA erneuern. Save regeneriert die Default-CA beim Aktualisieren ihrer Einstellungen automatisch und verändert damit den Trust Anchor. Nur freigegebene Attributänderungen im geplanten Wartungsfenster speichern. Anschliessend über die Download-Schaltfläche das tar.gz-Archiv herunterladen und das öffentliche CA-Zertifikat Default.pem extrahieren.

Auf dem Collector Default.pem und ExternalCA.pem in /etc/syslog-ng/ca.d/ ablegen. ExternalCertificate.pem und ExternalPrivateKey.key gehören nach /etc/syslog-ng/cert.d/. Vorher Verzeichnisse und vorhandene Dateien prüfen; vorhandene Zertifikate nicht ungeplant überschreiben. Nur der zuständige Dienst und autorisierte Administratoren dürfen den privaten Schlüssel lesen.

Die folgenden Befehle werden auf dem Linux-Collector, nicht in der SFOS Device Console, ausgeführt. Der erste liest das Zertifikat. Der zweite erstellt im CA-Verzeichnis einen Symlink und benötigt dort Schreibrechte:

cd /etc/syslog-ng/ca.d/
openssl x509 -noout -hash -in Default.pem

Den tatsächlich ausgegebenen Hash verwenden, nicht blind 52412b66 übernehmen. Für die Beispielausgabe 52412b66 lautet der Befehl:

ln -s Default.pem 52412b66.0

Bei einem bereits vorhandenen .0-Eintrag zuerst dessen Ziel prüfen, statt ihn zu überschreiben. Nach einem Zertifikatswechsel den Hash und die Zuordnung erneut kontrollieren.

Das folgende syslog-ng.conf-Beispiel zeigt einen TLS-Listener und zwei lokale Ausgaben. @version: 3.15 ist die Versionsangabe des dokumentierten Beispiels, keine Empfehlung für eine veraltete Installation. Syntax, Module und Versionsangabe vor der Übernahme gegen die installierte syslog-ng-Version prüfen. Die Konfiguration in die bestehende Collector-Konfiguration integrieren, nicht deren andere Quellen und Ziele ersetzen.

@version: 3.15
@include "scl.conf"
source s_src {
    network(ip(0.0.0.0) port(6514)
        transport("tls")
        tls( key-file("/etc/syslog-ng/cert.d/ExternalPrivateKey.key")
             cert-file("/etc/syslog-ng/cert.d/ExternalCertificate.pem")
             ca-dir("/etc/syslog-ng/ca.d")
             peer_verify(required-trusted))
    ); };
destination d_local {
    file("/var/log/messages");
    file("/var/log/messages-kv.log" template("$ISODATE $HOST $(format-welf --scope all-nv-pairs)\n") frac-digits(3));
};
log { source(s_src);
    destination(d_local);
};

0.0.0.0 bindet alle IPv4-Adressen des Collectors. Für den Betrieb möglichst die vorgesehene Empfangsadresse einsetzen und TCP 6514 per Host-Firewall auf die sendenden Firewalls begrenzen. Port 6514 muss später im SFOS-Eintrag identisch sein. key-file und cert-file verweisen auf die Serveridentität, ca-dir auf die beiden CA-Zertifikate; peer_verify(required-trusted) darf nicht zur Fehlerumgehung abgeschaltet werden. Die beiden Dateiziele zeigen Rohlogs und eine zusätzliche Key-Value-Ausgabe mit Millisekundenpräzision; Pfade, Schreibrechte, Rotation und Speicherbedarf an den eigenen Betrieb anpassen.

Vor dem Start die Collector-Konfiguration mit der Validierungsfunktion der installierten Version prüfen. Den Dienst erst im freigegebenen Fenster starten beziehungsweise Änderungen kontrolliert übernehmen; bei Problemen zur gesicherten Konfiguration zurückkehren. Danach auf SFOS unter System services > Log settings > Add den Collector, Port 6514 und Secure log transmission setzen und mit Save speichern. In der Server-Spalte die benötigten Module auswählen. Erfolg bedeutet: TLS-Verbindung ohne Vertrauensfehler, ein bewusst erzeugtes Firewall-Ereignis in den konfigurierten Ausgabedateien und korrekt geparste Felder im SIEM. Dieses Beispiel ist dokumentarische Anleitung, kein hier durchgeführter Appliance- oder Collector-Test.

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.

ATR-Geltungsbereich: Remote-Source-Logging nur für nachweislich unterstützte Kombinationen aus Modul und Traffic-Pfad aktivieren. Sophos’ ATR-Fliesstext und die SVG-Traffic-Matrix widersprechen sich bei X-Ops-Match-Richtungen; dieser Konflikt bleibt ungeklärt. Aussagen zu MDR, NDR oder Drittanbieter-Feeds belegen keine entsprechende X-Ops-Unterstützung. Restriktive Firewall-, DNAT/WAF- und Device-Access-Kontrollen unabhängig vom umstrittenen Feed-Verhalten beibehalten. Strittige Fälle benötigen eine autorisierte, kontrollierte Prüfung von Modul, Match-Richtung, Logs und tatsächlicher Wirkung sowie eine belastbare Klärung; bis dahin darf der Schutz nicht vom strittigen Verhalten abhängen. Den sicheren Kontext erläutert NDR und Active Threat Response.

XML-API: Collector, Logauswahl und Suppression trennen

Wer Syslog per XML-API verwaltet, muss diese drei Ebenen getrennt behandeln. Die Add-/Update-Beispiele für SFOS 22.0 und SFOS 23.0 unterscheiden:

Collector-Einstellungen: Zieladresse, Port, TLS, Facility, Severity und Format bestimmen Empfänger und Übertragung. Ein angelegter oder ausgewählter Collector aktiviert nicht automatisch alle Logs.
Versand nach Gruppe und Submodul: Innerhalb von LogSettings steht SendLogs für die Gruppenebene; einzelne Submodule können diese Auswahl überschreiben. Das Beispiel warnt ausdrücklich davor, SendLogs anzugeben, wenn alle Submodule aufgelistet sind. Diese Formen daher nicht zu einer pauschalen Aktivierung zusammenziehen. Bei PolicyRules nennt der Beispielkommentar Disable als Default; daraus folgt keine automatische Freigabe aller Regelereignisse. Das Logging in der jeweiligen Regel bleibt zusätzlich erforderlich.
Suppression: Log_suppress ist im Beispiel separat vom Versand aufgeführt. Die Zusammenfassung wiederholter Ereignisse ist nicht dasselbe wie die Auswahl ihres Empfängers oder eines Severity-Filters.

Die Parametertabelle führt Name doppelt auf und beschreibt die zweite Zeile als Suppression-Status; zudem steht dort wörtlich uiui als Default. Das ist keine belastbare Grundlage für einen Betriebsdefault oder eine stillschweigende Umbenennung des Felds. Daraus keinen vollständigen Suppression-Payload ableiten; unklare API-Felder zuerst mit der Hilfe des konkreten Builds oder Sophos Support klären. Vor und nach einer freigegebenen Änderung dieselben repräsentativen Ereignisse erzeugen und am Collector Rohlogs, im SIEM Parser-Felder sowie erwartete Logtypen und log_occurrence vergleichen. Eine bestehende Verbindung allein beweist die richtige Logauswahl nicht.

Häufige Sichtbarkeitsfallen

Log Suppression: SFOS kann gleiche aufeinanderfolgende Firewall-Events zusammenfassen. Das wirkt auf Log Viewer, Sophos Fusion (ehemals 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 bei unterstützten Modul-/Traffic-Pfaden. Den ATR-Geltungsbereich oben auch bei der Suche nach fehlenden Match-Typen beachten; die Auswahl beweist keine Unterstützung strittiger X-Ops-Richtungen.
Wireless: Access-Point- und SSID-Logs sind nicht im lokalen Log Viewer verfügbar. Sie müssen gezielt an Sophos Fusion 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.
Web-Proxy: Bei Webverkehr auf Port 80 oder 443 kann der Firewall-Log Allowed zeigen, während der Web-Filter denselben Zugriff blockiert. Für die tatsächliche Policy-Entscheidung müssen deshalb Firewall- und Web-Filter-Event gemeinsam korreliert werden.

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. Die folgende Liste ist eine Use-Case-abhängige Prüfliste, kein universelles Pflichtschema. Pflichtfelder werden für jeden aktivierten Logtyp separat anhand seines versionspassenden Schemas und eines repräsentativen echten Events festgelegt. Regel- und NAT-Felder gelten nur für die entsprechenden bestätigten Ereignistypen; Verbindungs- und Benutzerfelder sowie log_occurrence werden nur ausgewertet, wenn sie geliefert werden. Fehlende, für den Ereignistyp nicht anwendbare Felder dürfen gültige Events weder verwerfen lassen noch als Parserfehler gelten.

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.

Die zwölf Zeichen sind positionsgebunden: Zeichen 1 und 2 bilden die Log Type ID, 3 und 4 die Component ID, 5 und 6 die Subtype ID, Zeichen 7 die Priority ID und Zeichen 8 bis 12 die Message ID. 010101600001 wird damit als 01 / 01 / 01 / 6 / 00001 gelesen. Ein Parser muss führende Nullen und feste Feldbreiten erhalten; zur Kontrolle werden zusätzlich log_type, log_component, log_subtype und severity ausgewertet.

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.

Im dokumentierten Beispiel 010101600001 bedeutet die erste 01 Security policy, die zweite 01 Firewall rule, die dritte 01 Allowed, 6 Information und 00001 Firewall traffic allowed. Die positionsgebundenen IDs und die ausgegebenen Textfelder erfüllen unterschiedliche Aufgaben; die Textfelder nicht ungeprüft aus einer numerischen ID ableiten. Für weitere Message IDs wird ein zur eigenen SFOS-Version passender Syslog-Referenzkatalog benötigt; die obige Zerlegung allein erklärt nicht jeden Ereignistyp.

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. Seit SFOS 22.0 identifiziert device_name den Hostnamen der erzeugenden Firewall; nach einem Upgrade muss geprüft werden, ob der Parser dieses Feld übernimmt und nicht weiterhin nur device_serial_id oder den Syslog-Header als Asset-Schlüssel verwendet.

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 den Ausgangszustand dokumentieren: Servername, Ziel, Port, TLS, Facility, Severity, Format und alle aktivierten Logtypen in der Server-Spalte.
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.

Änderung ohne Datenlücke zurücknehmen

Format, Mindestschwere und Logauswahl sollten nie gleichzeitig geändert werden. Ist einer der maximal fünf Serverplätze frei, wird für einen Parser- oder Collector-Wechsel ein zweites Ziel angelegt und zunächst parallel betrieben. So kann man Rohdaten, Feldbelegung, Zeitstempel und Volumen vergleichen, ohne das funktionierende Ziel anzutasten.

Erst nach bestandener Abnahme werden in der Spalte des alten Ziels die Logtypen deaktiviert. Der Servereintrag bleibt während einer vereinbarten Beobachtungszeit erhalten. Bei fehlenden Events, Parserfehlern oder unerwartetem Volumen aktiviert man dort exakt die zuvor dokumentierten Logtypen wieder und nimmt die Auswahl am neuen Ziel zurück. Gibt es keinen freien Serverplatz, werden vor jeder Einzeländerung die bisherigen Werte festgehalten und bei einem Fehler vollständig wiederhergestellt; der Eintrag wird nicht gelöscht und der Parser nicht gleichzeitig umgestellt.

API-Löschung ist kein Abschalten der Logspalte: Die Delete-Tabellen für SFOS 22.0 und SFOS 23.0 nennen nur Name als nicht obligatorisch, beschreiben es aber als Suppression-Status und zeigen keinen Zielselektor. Diese widersprüchliche Tabelle belegt weder eine sichere Zielwahl bei weggelassenem Namen noch die Gleichwertigkeit von Collector-Löschung und Deaktivierung seiner Logtypen. Den funktionierenden Collector während der Migration behalten. Vor einer API-Löschung müssen die eindeutige, freigegebene Identität des zu entfernenden Eintrags und die Löschsyntax anhand der API-Hilfe des konkreten Builds oder mit Sophos Support geklärt sein; keinen Selektor erraten.

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.

Dabei zuerst klären, ob Modul und Traffic-Pfad nachweislich unterstützt sind. Es gilt der ATR-Geltungsbereich oben: Fehlende Logs klären den X-Ops-Konflikt nicht, und für strittige Richtungen dürfen nicht einfach weitere Match-Typen aktiviert werden.

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.