Sophos Firewall Logs für Support und Analyse sichern

Bei Störungen, VPN-Problemen oder unklaren Firewall-Ereignissen reichen einzelne Screenshots aus der Weboberfläche oft nicht aus. Für eine fundierte Analyse braucht ein Supportfall nachvollziehbare Zeitangaben, passende Logdateien und manchmal zusätzlich einen Paketmitschnitt.

Der offizielle Download- und Diagnoseablauf gilt für SFOS 22 und SFOS 23. Die ergänzenden manuellen Archive bleiben ein gesonderter Analyseweg, kein bestätigter Standardexport für beide Versionen. Diese Anleitung beschreibt den offiziellen Weg über Diagnostics > Tools und trennt ihn vom ergänzenden Rohlog-Weg über die Advanced Shell. Für Sophos Support ist der Consolidated Troubleshooting Report (CTR) meist der sauberste Einstieg, weil er Logdateien und einen System-Snapshot in einem verschlüsselten Archiv sammelt. Ein manuell erzeugtes /log-Archiv bleibt nützlich, wenn vollständige Rohlogs, IPsec-Zusatzdaten oder eine eigene Analyse benötigt werden. Es ist aber kein verschlüsselter CTR und nicht der von Sophos dokumentierte Standardexport.

Der Ablauf ersetzt nicht die erste Eingrenzung im Log Viewer. Wenn noch unklar ist, welches Modul betroffen ist, hilft zuerst die Übersicht Sophos Firewall Troubleshooting: Services und Logs.

Supportfall zuerst eingrenzen

Ein grosses Archiv ist nicht automatisch ein gutes Supportpaket. Zuerst muss klar sein, welcher Test fehlgeschlagen ist, wann er ausgeführt wurde und welche Komponente wahrscheinlich beteiligt ist.

Erst analysieren oder bereits Daten sichern?

Je nach Fehlerbild ist ein anderer Einstieg schneller:

• Konkreten Verbindungsversuch prüfen: Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture, wenn Regel, NAT-Regel oder Route unklar sind.
• Lokale Logdateien zuordnen: Sophos Firewall Troubleshooting: Services und Logs, wenn zuerst geklärt werden muss, welches Log zu VPN, Web, IPS, GUI oder Systemdiensten gehört.
• Fehler ist bekannt und die Daten sollen weitergegeben werden: Dann passt der Ablauf in diesem Artikel mit CTR, gezielten Logs oder einem Rohlog-Archiv.

Für historische Reports oder wiederkehrende Ereignisse eignet sich Central Firewall Reporting. Für die langfristige Aufbewahrung und Korrelation braucht es Syslog oder SIEM. Ein akutes Supportarchiv ersetzt beides nicht.

Datenpaket nach Fehlerbild wählen

Nicht jedes Problem braucht sofort ein vollständiges Logarchiv. Je klarer der Fehler eingegrenzt ist, desto kleiner und nützlicher werden die Daten.

• Firewall-Regel oder NAT-Regel greift unerwartet: Uhrzeit, Source IP, Destination IP, Rule ID, NAT ID, Log-Viewer-Export und bei Bedarf Packet Capture.
• Dienst startet nicht oder WebAdmin zeigt Fehler: Consolidated Troubleshooting Report, betroffener Dienst, Uhrzeit und letzter Konfigurationsschritt.
• IPsec-Tunnel baut nicht auf oder fällt aus: normales Logarchiv, IPsec-Diagnosedaten, Peer-IP, lokale und entfernte Netze, Zeitpunkt des Verbindungsversuchs.
• Traffic kommt nicht am Ziel an: Log Viewer, Packet Capture oder bei längeren Analysen tcpdump-PCAP.
• Problem nach Konfigurationsänderung: Audit Trail, ungefährer Änderungszeitpunkt, beteiligter Admin, betroffene Objekte und bei Bedarf CTR.

Für viele Tickets ist die Kombination aus Problemzeitpunkt, kurzer Fehlerbeschreibung, Logarchiv und einem gezielten Zusatznachweis besser als ein sehr breites Datenpaket ohne Kontext. Wenn ein offizielles Sophos-Ticket erstellt wird, passt zusätzlich Sophos Supportticket eröffnen: Vorbereitung und Portal.

Voraussetzungen

Für diese Anleitung benötigt man:

• Administrativen Zugriff auf die Sophos Firewall
• Zugriff auf Diagnostics > Tools im WebAdmin
• Für Rohlog-Archive zusätzlich Zugriff auf die Advanced Shell
• Einen Zielserver, ein Supportportal oder eine andere sichere Möglichkeit, um Archive zu übertragen
• Genügend freien Speicherplatz auf der Firewall für temporäre Archive

Die CLI-Befehle werden direkt auf der Firewall ausgeführt. Man sollte daher sorgfältig arbeiten und keine Dateien löschen, wenn nicht klar ist, wofür sie verwendet werden.

Falls der Zugriff auf die Shell noch nicht eingerichtet ist, erklärt die Anleitung Sophos Firewall per SSH verbinden, wie man eine SSH-Verbindung zur Firewall herstellt.

⚠️ Logarchive und PCAP-Dateien können sensible Informationen enthalten. Solche Dateien sollten nur kurz auf der Firewall liegen, sicher übertragen und nach erfolgreicher Übergabe wieder entfernt werden.

Logs sammeln

Je nach Supportfall reicht ein gezielter WebAdmin-Download, ein CTR oder ein Rohlog-Archiv aus der Advanced Shell. Der Ablauf sollte mit dem kleinsten Datensatz beginnen, der den Fehler noch sauber erklärt.

Die lokale Aufbewahrung ist durch den Speicherplatz pro Subsystem und das Firewall-Modell begrenzt. Erreicht eine Logdatei ihr Grössenlimit, wird sie mit gzip komprimiert; ist das Speicherlimit des Subsystems erreicht, werden die ältesten .gz-Rotationen zuerst gelöscht. Reagiert die Firewall nicht mehr, können ausserdem Logdaten verloren gehen, die noch im RAM liegen und nicht ins Dateisystem geschrieben wurden. Relevante Logs sollte man deshalb möglichst zeitnah sichern: Ein Export enthält nur noch verfügbare Daten und kann verlorene Einträge nicht zurückholen.

Troubleshooting Logs liegen auf der Partition /var und werden über /log gelesen. Kritische Komponenten erhalten mehr Speicher; je nach Subsystem werden zwei oder mehr komprimierte Rotationen aufbewahrt. Nach der Rotation schreibt die Firewall unter dem ursprünglichen Dateinamen weiter. Bei einer XGS Appliance hängt die verfügbare Historie deshalb auch vom Modell und Dienst ab, nicht von einer einheitlichen Aufbewahrungsdauer.

Standardweg: CTR im WebAdmin erzeugen

Für viele Supportfälle sollte man zuerst den Consolidated Troubleshooting Report erzeugen. Der CTR enthält einen System-Snapshot und Logdateien in einem verschlüsselten Archiv. Sophos Support kann dieses Archiv direkt im Supportfall auswerten.

So erstellt man den CTR:

1. Fehler möglichst reproduzieren und die genaue Uhrzeit notieren.
2. Im WebAdmin Diagnostics > Tools öffnen.
3. Unter Consolidated troubleshooting report die benötigten Optionen auswählen.
4. Für einen breiten Supportfall System snapshot und All log files aktivieren.
5. Einen kurzen Grund eintragen, zum Beispiel Ticketnummer, Fehlerbild und Zeitfenster.
6. Generate auswählen.
7. Nach der Erstellung Download auswählen.
8. Die Datei über das Supportportal, den vereinbarten sicheren Upload oder den internen Analyseweg bereitstellen.

System snapshot benötigt keinen Debug-Modus und erfasst den aktuellen Systemzustand, unter anderem aktive Prozesse und Ressourcennutzung. Der dokumentierte Dateiname lautet CTR_<APPKEY>_<MM_DD_YY>_<HH_MM_SS>: APPKEY ist die Seriennummer der Firewall; die weiteren Felder sind Erstellungsdatum in Monat/Tag/Jahr und Uhrzeit in Stunde/Minute/Sekunde. Auch der Dateiname ist deshalb vertraulich. Das ist praktisch, wenn mehrere Firewalls oder mehrere Versuche in einem Ticket landen.

Die Zeilengrenze betrifft nur Service subsystem logs; Default subsystem logs sind vollständig enthalten, soweit die Daten noch verfügbar sind. Einen verschlüsselten CTR prüft man nicht mit dem später gezeigten tar -tzf: Downloadabschluss, plausible Dateigrösse, Gerät und Testzeit kontrollieren und die Datei geschützt dem Supportfall zuordnen. Entschlüsselung und Inhaltsprüfung benötigen eine eigene Funktionskontrolle. Schlägt die Erstellung oder der Download fehl, den Fehler dokumentieren und zunächst die betroffenen Einzellogs sichern, statt Logs zu löschen.

⚠️ Der CTR ist nicht dasselbe wie ein vollständiger Rohdaten-Dump. Service-Subsystem-Logs enthalten standardmässig höchstens 10’000 Zeilen; diese Grenze gilt nur für den CTR. Wenn ältere oder vollständige Rohlogs benötigt werden, sollte man die betroffenen Troubleshooting Logs einzeln herunterladen oder die Dateien über die Advanced Shell sichern.

CTR-Zeilenlimit an der Device Console prüfen

Das Zeilenlimit für Service-Subsystem-Logs im CTR lässt sich getrennt von den Rohlogs anzeigen und setzen. Dazu im CLI-Hauptmenü 4. Device Console öffnen. SFOS 22 und SFOS 23 erlauben 250 bis 10000 Zeilen und verwenden standardmässig 10000:

system diagnostics show ctr-log-lines
system diagnostics ctr-log-lines 5000

Normalerweise muss man den Standardwert nicht ändern. 5000 zeigt lediglich die Syntax für einen bewusst kleineren CTR; der zulässige Bereich ist fest, der gewählte Wert hängt vom Supportfall ab. Vor einer Änderung wird der aktuelle Wert mit show dokumentiert. Danach wird der CTR erzeugt und der vorherige Wert mit demselben Set-Befehl wiederhergestellt. Diese Einstellung verändert nur künftige CTR-Dateien, nicht die vollständigen Rohlogs, und stellt keine bereits gelöschten oder überschriebenen Logdaten wieder her.

Einzelne Troubleshooting Logs herunterladen

Wenn das Modul bereits bekannt ist, ist ein gezielter Logexport oft besser als ein sehr breiter Datensatz.

1. Diagnostics > Tools öffnen.
2. Unter Troubleshooting logs die relevanten Logdateien auswählen.
3. Download auswählen.
4. Die erzeugte komprimierte Datei zusammen mit Fehlerzeitpunkt, Testfall und betroffener Firewall weitergeben.

Dieser Weg passt, wenn zum Beispiel nur strongswan.log, charon.log, sslvpn.log, reverseproxy.log, applog.log oder ein anderer klar betroffener Dienst benötigt wird. Anders als beim CTR gilt die Zeilenbegrenzung für diese Einzeldownloads nicht. Welche Datei zu welchem Modul gehört, steht in Sophos Firewall Troubleshooting: Services und Logs.

Advanced Shell öffnen

Auf der Sophos Firewall anmelden und die Advanced Shell öffnen:

1. Im CLI-Hauptmenü 5. Device Management auswählen.
2. Danach 3. Advanced Shell öffnen.
3. Den Zugriff bestätigen, falls die Firewall eine zusätzliche Abfrage anzeigt.

Nach dem Login befindet man sich auf der Shell der Firewall. Von dort aus können die Logdateien archiviert werden.

Einen kurzen Live-Logausschnitt sichern

In der Advanced Shell kann man neue Einträge während eines eingegrenzten Tests mitlesen:

cd /log
tail -f /log/charon.log

charon.log ist ein konkretes IPsec-Beispiel; bei anderen Fehlern die passende vorhandene Datei aus der Service-Log-Übersicht wählen. Testbeginn, Ende und Zeitzone notieren, den Fehler reproduzieren und die Ausgabe in eine geschützte Textdatei auf dem Admin-Rechner kopieren. Ctrl+C beendet die Anzeige, nicht den Firewall-Dienst. tail -f zeigt letzte vorhandene und neue Zeilen, keinen vollständigen Export. Fehlen Treffer, zuerst Knoten, Dateiname, Zeit und Dienst prüfen; bei Bedarf die vollständige Einzeldatei herunterladen. Den Ausschnitt samt Kontext zum Supportfall hochladen.

Vor dem Sichern gezielt Logs sammeln

Wenn ein Problem reproduzierbar ist, sollte es nach Möglichkeit direkt vor dem Archivieren der Logs nochmals ausgelöst werden. Dadurch landen die relevanten Einträge möglichst aktuell in den Logdateien.

Bei komplexeren Problemen reichen die normalen Logs manchmal nicht aus. In diesem Fall kann es sinnvoll sein, vor dem Archivieren für den betroffenen Dienst ein Debug-Log zu aktivieren. Debug sollte nur gezielt und kurz laufen und nach dem Sammeln wieder deaktiviert werden, weil Logdateien sonst schnell wachsen können. Wie das funktioniert, ist im Abschnitt Debug-Log gezielt aktivieren beschrieben.

Welche Logdatei zu welchem Firewall-Modul gehört, ist in Sophos Firewall Troubleshooting: Services und Logs zusammengefasst. Diese Übersicht ist hilfreich, wenn man gezielt prüfen möchte, ob für ein Problem eher VPN-, IPS-, Web-, Mail-, GUI- oder System-Logs relevant sind.

Wenn nicht ein Dienstproblem, sondern der Paketfluss selbst unklar ist, ist ein Logarchiv allein oft nicht genug. Für kurze Tests passt Packet Capture im WebAdmin. Für PCAP-Dateien, längere Mitschnitte oder Supportanalysen ist tcpdump auf der Sophos Firewall das passende Werkzeug.

Debug mit kontrolliertem Rückweg erfassen

Debug ist standardmässig aus. Vor einer Änderung trotzdem mit Administratoren und Support klären, ob bereits eine Erfassung läuft; Knoten, freien Speicher und ein kurzes Testfenster dokumentieren. Nur ein unterstütztes Subsystem nach dem anderen bearbeiten. Debug-Daten sind über Einzeldownload, CTR und CLI verfügbar. Für das dokumentierte Service-Beispiel in 4. Device Console ausführen:

Für andere unterstützte Dienste ist das Schema system diagnostics subsystems <subsystem> debug on beziehungsweise system diagnostics subsystems <subsystem> debug off. <subsystem> durch einen auf dem konkreten Build bestätigten CLI-Namen ersetzen, nicht durch einen Logdateinamen. Läuft bereits eine Debug-Erfassung für einen anderen Supportfall, ihren Zustand ohne Absprache nicht verändern.

system diagnostics subsystems Pktcapd debug on

Nur den geplanten Test ausführen, das Log oder den fertiggestellten CTR herunterladen und danach in derselben Device Console ausschalten:

system diagnostics subsystems Pktcapd debug off

On-/Off-Ausgaben und Zeiten dokumentieren; mit einem kurzen Folgetest prüfen, dass keine neuen Debug-Einträge entstehen und Logwachstum sowie Speicherverbrauch wieder normal sind. Bei Ablehnung keine Namen raten: Build-Syntax prüfen und Support einschalten. Ausschalten löscht keine gesammelten Dateien.

Für den System Controller nennt die Log-Anleitung beim Ein- und Ausschalten denselben Befehl system diagnostics subsystems CSC debug, ohne on oder off. Diesen Umschalter nicht als Statusabfrage verwenden oder blind zweimal ausführen. Ist Ausgangszustand oder Rückweg unklar, CSC-Debug nicht ändern; den kontrollierten CSC-Ablauf mit Support verwenden. Logdateinamen sind keine CLI-Subsystemnamen.

Die SFOS-22/23-Diagnoseübersicht führt folgende Default logs für Debug auf; diese Gruppe ist zugleich vom CTR-Zeilenlimit ausgenommen:

syslog.log, postgres.log, reportdb.log, applog.log, access_server.log, awarrenhttp.log, awed.log, charon.log, csc.log, garner.log, heartbeatd.log, ips.log, iview.log, msync.log, nSXLd.log, networkd.log, red.log, reverseproxy.log, smtpd_main.log, sslvpn.log, tomcat.log, u2d.log, up2date_av.log, npu-startup.log.prev, npu_syslog.log, syslog-ng.log, xgs-healthmond.log, xgs-host.log, xgs-npu-fw.log, xgs-pport-wait.log.

Als Service logs sind aufgeführt:

awarrenhttp_access.log, httplogd.log, bwm.log, awarrensmtp.log, pktcapd.log, warren.log.

Die Liste beschreibt unterstützte Debug-Logdateien, nicht alle Logs und keine garantierte Präsenz auf jeder Plattform. NPU- und XGS-Dateien im Kontext der jeweiligen XGS Appliance prüfen. Gross-/Kleinschreibung erhalten: pktcapd.log ist nicht der Befehlsparameter Pktcapd.

Vor einer Logbereinigung zuerst Beweise sichern

Ein Purge ist keine Voraussetzung für CTR oder Einzeldownload. Die Diagnoseanleitung nennt das Leeren eines Subsystems vor der Reproduktion nur optional. Zuerst Beweise, Support- und Aufbewahrungsanforderungen klären und benötigte Dateien ausserhalb der Firewall sichern. Anders als das spätere Löschen eigener Archive entfernt ein Purge Diagnosehistorie; es gibt keinen Rollback.

Die globalen Device-Console-Befehle sind system diagnostics purge-old-logs für alle komprimierten .gz-Logs und system diagnostics purge-all-logs für alle Loginhalte. Laut CLI-Hilfe bleiben beim vollständigen Purge leere Dateien zurück. Globale Aktionen betreffen auch andere Subsysteme und laufende Supportfälle.

Syntaxkonflikt beim einzelnen Subsystem: Die SFOS-22/23-Administratorhilfe nennt system diagnostics <subsystem> purge-log und system diagnostics <subsystem> purge-old-log; die CLI-Hilfe dokumentiert dagegen system diagnostics subsystems <subsystem> purge-log und system diagnostics subsystems <subsystem> purge-old-log. Die unterstützte Form anhand der installierten Version bestimmen. Vor einer freigegebenen Bereinigung in 4. Device Console vollständige Syntax und Namen mit CLI-Hilfe oder Tab-Vervollständigung prüfen und den Konflikt mit Support klären. Nicht beide Varianten versuchsweise ausführen.

Bei unklarer Syntax, Dateiherkunft oder laufender Erfassung stoppen und den Ablauf zur Speicheranalyse und kontrollierten Bereinigung nutzen. Nach einer abgestimmten Aktion freien Speicher, neue normale Logeinträge und Dienstzustand prüfen; weniger belegter Speicher beweist keine behobene Ursache. Systemlogs nicht manuell mit rm oder Wildcards löschen.

Rohlogs über die Advanced Shell sichern

Wenn der CTR nicht reicht oder alle derzeit verfügbaren Rohlogs für eine eigene Analyse benötigt werden, kann man das Verzeichnis /log manuell archivieren. Dieser Shell-Weg ist kein Ersatz für den offiziellen CTR oder den Einzeldownload unter Troubleshooting logs. Vor dem Archivieren sollte geprüft werden, ob unter /var genügend freier Speicherplatz vorhanden ist:

Vor diesem ergänzenden Shell-Weg die tatsächlich vorhandenen Verzeichnisse und den freien Speicher prüfen. Falls /log ein symbolischer Link ist, enthält der unten gezeigte tar-Befehl möglicherweise nur den Link statt der Logdateien: Dann nicht mit einem scheinbar fertigen Archiv fortfahren, sondern den offiziellen Einzeldownload verwenden oder den Archivweg mit Support klären. Auch ein laufend beschriebenes Verzeichnis ist keine konsistente Datensicherung. Fehlende Pfade, Lesefehler oder Speicherprobleme zuerst klären; keine Systemlogs zur Platzbeschaffung löschen. Den manuellen Archivweg vor der Übernahme in den Betrieb für den installierten SFOS-Build kontrollieren.

ls -ld /log
df -h /var

Anschliessend ein komprimiertes Archiv mit den Dateien aus dem Verzeichnis /log erstellen:

tar -cvzf /var/Sophos-Firewall-Logs.tar.gz -C / log

Der Befehl erstellt die Datei:

/var/Sophos-Firewall-Logs.tar.gz

Die wichtigsten Bestandteile des Befehls:

• tar erstellt ein Archiv.
• -c erstellt ein neues Archiv.
• -v zeigt die verarbeiteten Dateien an.
• -z komprimiert das Archiv mit gzip.
• -f gibt den Dateinamen des Archivs an.
• -C / wechselt für den Archivvorgang in das Root-Verzeichnis.
• log ist das Verzeichnis mit den Logdateien der Sophos Firewall.

Der Vorteil von -C / ist, dass der Befehl unabhängig vom aktuellen Arbeitsverzeichnis funktioniert. Ein vorheriges cd / ist dadurch nicht nötig. Falls die Datei bereits existiert, wird sie durch den Befehl überschrieben.

Je nach Grösse und Auslastung der Firewall kann der Archivvorgang einige Zeit dauern. Die Ausgabe von tar zeigt währenddessen, welche Dateien in das Archiv geschrieben werden.

Anschliessend kann die Archivgrösse geprüft werden:

ls -lh /var/Sophos-Firewall-Logs.tar.gz

Zusätzlich sollte man kurz prüfen, ob das Archiv lesbar ist und tatsächlich das Logverzeichnis enthält:

tar -tzf /var/Sophos-Firewall-Logs.tar.gz

Die Ausgabe sollte Pfade unter log/ zeigen. Wenn der Befehl einen Fehler meldet oder das Archiv ungewöhnlich klein ist, sollte das Archiv nicht weitergegeben werden. Dann zuerst freien Speicherplatz, Schreibrechte und den vorherigen tar-Lauf prüfen.

Logarchiv auf einen Linux-Server kopieren

Wenn ein Linux-Server per SSH erreichbar ist, kann das Archiv mit scp übertragen werden.

Beispiel:

scp /var/Sophos-Firewall-Logs.tar.gz root@192.0.2.10:/root/

Dabei müssen die IP-Adresse, der Benutzer und der Zielpfad an die eigene Umgebung angepasst werden.

Nach der Übertragung liegt das Archiv auf dem Zielserver unter:

/root/Sophos-Firewall-Logs.tar.gz

Von dort kann es intern weitergegeben oder dem Sophos Support beziehungsweise Avanet zur Verfügung gestellt werden.

IPsec Diagnosedaten separat sichern

Bei VPN- oder IPsec-Problemen können zusätzlich die IPsec-Verbindungsdaten aus /tmp/ipsec/connections/ hilfreich sein. Die geprüften SFOS-22/23-Anleitungen beschreiben diesen manuellen Archivweg nicht als Standardexport. Deshalb nur für die eigene Analyse oder nach konkreter Anweisung des Supports verwenden und zuerst prüfen, ob das Verzeichnis tatsächlich vorhanden ist.

Dafür ein separates Archiv erstellen:

ls -ld /tmp/ipsec/connections
tar -cvzf /var/Sophos-Firewall-IPsec-Connections.tar.gz -C /tmp/ipsec connections

Auch hier kann die erzeugte Datei kurz geprüft werden:

ls -lh /var/Sophos-Firewall-IPsec-Connections.tar.gz

Dieses Archiv kann ebenfalls per scp auf einen Zielserver kopiert werden:

scp /var/Sophos-Firewall-IPsec-Connections.tar.gz root@192.0.2.10:/root/

Gerade bei IPsec Fehlern ist es sinnvoll, dieses Archiv zusammen mit den normalen Firewall Logs bereitzustellen, damit Tunnelstatus, Verbindungsinformationen und Logeinträge gemeinsam ausgewertet werden können.

Was ein Supportarchiv nicht ersetzt

CTR und /log-Archiv sind Momentaufnahmen der lokalen Firewall. Sie helfen bei Dienst- und Systemfehlern, liefern aber weder automatisch eine Langzeithistorie noch den Beweis, dass ein bestimmtes Paket die Firewall passiert hat. Für Verlauf und Suche dienen Central Firewall Reporting oder Syslog und SIEM. Konfigurationsänderungen lassen sich gezielter über die Audit Trail Logs nachvollziehen.

Paketmitschnitte separat behandeln

Logarchive und Paketmitschnitte sind unterschiedliche Beweismittel. Das Logarchiv zeigt Dienstmeldungen, Fehler, VPN-Zustände und Systemereignisse. Ein Packet Capture oder tcpdump zeigt dagegen, ob Pakete wirklich ankommen, weitergeleitet werden oder ob Antworten fehlen.

Für Supportfälle sollte man Paketmitschnitte nicht ungefiltert mitsenden. Besser ist:

1. Testfall mit Source IP, Destination IP, Port, Protokoll und Uhrzeit notieren.
2. Erst Log Viewer und WebAdmin Packet Capture prüfen, wenn das ausreicht.
3. Nur bei Bedarf einen engen tcpdump-Mitschnitt als PCAP erstellen.
4. PCAP-Datei sicher übertragen.
5. PCAP-Datei nach erfolgreicher Übertragung von der Firewall entfernen.

Die PCAP-Datei gehört nicht in das /log-Archiv, sondern wird separat erstellt und übertragen. Dadurch bleibt klar, welche Datei Service-Logs enthält und welche Datei Netzwerkpakete enthält.

Sicherheit, Datenschutz und Aufräumen

Logdateien können sensible Informationen enthalten, zum Beispiel:

• Öffentliche und interne IP-Adressen
• Benutzernamen
• Hostnamen
• VPN Informationen
• Fehlermeldungen mit technischen Details
• Hinweise auf interne Netzwerkstrukturen

Logarchive sollten daher nur über sichere Kanäle übertragen und nur Personen oder Organisationen bereitgestellt werden, die an der Analyse beteiligt sind. Wenn Logs an einen externen Partner gesendet werden, sollte vorher intern geklärt sein, ob die Weitergabe gemäss den eigenen Datenschutz- und Sicherheitsrichtlinien erlaubt ist.

Bei HA-Clustern muss man zusätzlich beachten: Logs und Reports werden nicht automatisch zwischen Primary und Auxiliary synchronisiert. Jede Appliance enthält Logs und Reports für den Traffic, den sie verarbeitet. Für HA-Probleme oder Failover-Zeitfenster sollte deshalb festgehalten werden, von welchem Knoten das Archiv stammt und ob zusätzlich Logs vom zweiten Knoten benötigt werden.

Temporäre Archive wieder entfernen

Nachdem das Archiv erfolgreich übertragen und auf dem Zielsystem geprüft wurde, sollte es von der Firewall gelöscht werden, damit kein unnötiger Speicherplatz belegt wird. Die folgenden Befehle löschen ausschliesslich die in dieser Anleitung erstellten, fest benannten Archive:

rm /var/Sophos-Firewall-Logs.tar.gz

Falls auch ein separates IPsec Archiv erstellt wurde, sollte dieses ebenfalls entfernt werden:

rm /var/Sophos-Firewall-IPsec-Connections.tar.gz

Vor dem Löschen sollte geprüft werden, ob die Dateien erfolgreich auf dem Zielsystem angekommen sind.

Checkliste für Supportfälle

• Problem kurz beschrieben: Was funktioniert nicht, seit wann, wie oft?
• Exakte Uhrzeit mit Zeitzone notiert.
• Betroffene Source IP, Destination IP, Benutzer, Dienst oder Tunnelname notiert.
• Relevantes Modul im Log Viewer geprüft.
• Falls nötig: Debug nur kurz aktiviert und wieder deaktiviert.
• CTR unter Diagnostics > Tools erstellt, wenn Sophos Support oder ein System-Snapshot benötigt wird.
• Bei Bedarf einzelne Troubleshooting Logs oder vollständiges /log-Archiv erstellt.
• Bei IPsec-Problemen zusätzlich IPsec-Diagnosedaten gesichert.
• Bei Paketflussproblemen Packet Capture oder tcpdump separat erstellt.
• Nur manuelle gzip-Archive mit tar -tzf auf tatsächliche Logdateien geprüft; beim verschlüsselten CTR Download, Gerät und Zeit kontrolliert.
• Bei HA geprüft, von welchem Node die Logs stammen.
• Archiv und PCAP nur über sichere Kanäle übertragen.
• Temporäre Dateien auf der Firewall nach erfolgreicher Übertragung entfernt.

FAQ