Sophos Firewall CLI Troubleshooting: wichtige Befehle

Bei Sophos Firewall Troubleshooting reicht der Log Viewer oft für die erste Eingrenzung. Sobald ein Dienst nicht sauber startet, VPN-Verbindungen instabil sind, einzelne Pakete nicht ankommen oder der Support detaillierte Daten benötigt, wird die CLI wichtig.

Diese Übersicht zeigt die wichtigsten Befehle für den Alltag: wo man sie ausführt, was sie zeigen und wann man besser zu einem spezialisierten Artikel wechselt. Für den sicheren Zugriff per SSH sollte zuerst Sophos Firewall per SSH verbinden geprüft werden. Dabei sind Public Key, Host-Key-Prüfung und eine enge Device-Access-Freigabe wichtiger als ein schneller Login von irgendwo.

⚠️ Wichtig: CLI- und Advanced-Shell-Befehle sollten nur aus vertrauenswürdigen Admin-Netzen und mit klarer Zielsetzung ausgeführt werden. Besonders Debug, tcpdump, Dateioperationen und Service-Kommandos können Speicherplatz, Performance oder laufende Verbindungen beeinflussen.

Erst WebAdmin, dann CLI

Die CLI ist nicht immer der schnellste Einstieg. Wenn es um Regel-Matching, NAT oder einzelne Verbindungen geht, liefern Log Viewer, Policy Test und Packet Capture im WebAdmin oft schneller einen sauberen Befund.

Gute Einstiege:

• Welche Firewall-Regel greift? Zuerst Log Viewer, Policy Test und Packet Capture nutzen. CLI wird erst nötig, wenn der Log Viewer zu wenig Details zeigt oder Live-Logs benötigt werden.
• Kommen Pakete auf der Firewall an? Zuerst Packet Capture im WebAdmin verwenden. CLI ist sinnvoll, wenn ein enger Capture oder eine PCAP-Datei für Support gebraucht wird.
• Hat ein Dienst ein Problem? Zuerst Dashboard, Log Viewer und Service-Logs prüfen. CLI wird wichtig, wenn Dienststatus, Debug oder Logdateien direkt geprüft werden müssen.
• Wurde etwas geändert? Zuerst Audit Trail Logs prüfen. CLI hilft danach, wenn ein Konfigurationsunterschied mit Logs oder Backups verglichen wird.

Das Ziel ist nicht, möglichst schnell in die Advanced Shell zu springen. Besser ist ein nachvollziehbarer Ablauf: erst sichtbare Ereignisse prüfen, dann gezielt die passende Logdatei oder den passenden Capture öffnen.

CLI-Befunde verwertbar dokumentieren

CLI-Ausgaben sind nur dann hilfreich, wenn später noch klar ist, zu welchem Test sie gehören. Einzelne kopierte Fehlermeldungen ohne Zeitfenster, IP-Adressen oder betroffene Funktion führen oft zu Rückfragen und doppelter Analyse.

Eine kurze Notiz pro Test reicht meistens:

• Zeitfenster: Start, Ende und Zeitzone des Tests.
• Testflow: Source IP, Destination IP oder FQDN, Port, Benutzer oder VPN-Peer.
• Werkzeug: Device Console, Advanced Shell, Log Viewer oder Packet Capture.
• Befehl oder Filter: ausgeführter Befehl, verwendeter grep-Suchbegriff oder Capture-Filter.
• Ergebnis: Treffer, Fehlermeldung, fehlender Logeintrag, Paket sichtbar oder Paket nicht sichtbar.
• Nächster Schluss: zum Beispiel Regelproblem, DNS-Problem, Rückweg, Dienstfehler oder Supportfall.

Vor der Weitergabe an Support, Avanet oder externe Partner sollte man prüfen, ob Ausgaben sensible Daten enthalten: öffentliche IPs, interne Hostnamen, Benutzernamen, VPN-Parameter, Seriennummern, Token, E-Mail-Adressen oder Kundenbezeichnungen. Für eine technische Analyse müssen Daten nicht beliebig breit verteilt werden; wichtig ist der kleinste Ausschnitt, der den Befund belegt.

Vor dem ersten Befehl

CLI-Troubleshooting wird deutlich zuverlässiger, wenn der Rahmen vor dem ersten Befehl feststeht. Sonst entstehen schnell Logausschnitte ohne Zeitbezug, zu breite Captures oder Debug-Logs, die später niemand mehr sauber zuordnen kann.

Vor produktiven CLI-Tests sollte man festhalten:

• Problemzeit: Logs lassen sich gezielt nach dem Testfenster durchsuchen.
• Source IP, Destination IP und Port: grep, tcpdump und Packet Capture bleiben eng und lesbar.
• Betroffener Benutzer oder Peer: Authentifizierung, VPN und User Matching lassen sich besser zuordnen.
• Erwartetes Modul: Man sucht zuerst in der passenden Logdatei statt in allen Logs.
• Geplante Aktion: Debug, Service-Check oder Capture wird nicht aus Versehen zum Dauerzustand.
• Rollback oder Abbruchkriterium: Bei Last, vollem Speicher oder Nebenwirkungen wird der Test beendet.
• Aktuelles Backup bei Änderungsarbeiten: Service-Neustarts oder Konfigurationsänderungen lassen sich sauberer absichern.

Der erste Schritt sollte möglichst lesend sein: Log Viewer prüfen, passende Logdatei ansehen, service -S lesen oder einen engen Capture starten. Neustarts, Debug-Modus und breit laufende Mitschnitte gehören erst danach in ein bewusstes Testfenster.

Bei HA-Clustern sollte zusätzlich klar sein, welche Appliance gerade aktiv ist. Logs, Debug und Captures müssen auf dem Node geprüft werden, über den der relevante Traffic tatsächlich läuft.

Einen kompletten Neustart nur als geplante Aktion ausführen

Ein vollständiger Neustart ist kein Diagnosebefehl. Vorher werden relevante Logs, Systemzeit, Uptime, HA-Rollen und der aktuelle Fehlerzustand gesichert. Wenn nur WebAdmin oder ein einzelner Dienst betroffen ist, wird zuerst geprüft, ob ein gezielter WebAdmin-Neustart oder Service-Neustart ausreicht.

SFOS 22 dokumentiert in der Device Console folgende Syntax:

system restart [all]

Die eckigen Klammern gehören nicht in den Befehl, sondern kennzeichnen die optionale Angabe all. Die auf dem installierten Build angebotene Form wird vorher mit system restart ? geprüft. Der Befehl startet die Firewall und unterbricht Sessions, VPN-Tunnel sowie den Managementzugriff. Nach dem Ausführen gibt es keinen CLI-Rollback; Wartungsfenster, Konsolenzugriff und ein getesteter Management-Rückweg müssen deshalb vor der Bestätigung stehen.

In einem HA-Cluster löst system restart laut Sophos ein Failover aus. Das ist keine Zusicherung unterbrechungsfreier Verbindungen. Vorher müssen Peer, Synchronisierung, Rollen und HA-Link stabil sein. Nach dem Wiederanlauf werden beide Nodes, Rollen, Synchronisierung, Uptime, WAN, Routing, DNS, VPN, publizierte Dienste und ein echter Anwendungsflow geprüft. Ein erfolgreicher Boot beweist nicht, dass die ursprüngliche Ursache behoben ist.

Shutdown nur mit vorbereitetem Einschaltweg

Ein kontrolliertes Herunterfahren erfolgt in der Device Console mit genau diesem Befehl:

system shutdown

Sophos dokumentiert dafür keine Optionen. Ein angehängtes all, ein Node-Name oder ein vermuteter HA-Schalter gehört daher nicht in die Syntax. Vor der Bestätigung müssen Logs und Konfiguration gesichert, Abhängigkeiten informiert und der spätere Einschaltweg über physischen Zugriff, Remote Management oder die Virtualisierungsplattform geklärt sein. Die Shutdown-Seite macht keine Zusage zum HA-Verhalten; ein Cluster-Node wird deshalb nur nach dem vorgesehenen HA-Wartungsablauf heruntergefahren und der Peer danach ausdrücklich kontrolliert.

Device Console oder Advanced Shell?

Sophos Firewall hat zwei unterschiedliche Konsolenbereiche. Viele Fehler entstehen, weil ein Befehl im falschen Bereich eingegeben wird.

Die Bereiche haben unterschiedliche Aufgaben:

• Device Console: Sophos CLI für Netzwerk-, System- und Diagnosebefehle. Typische Befehle sind ping, dnslookup, traceroute, tcpdump, drop-packet-capture und show.
• Advanced Shell: Linux-nahe Shell mit vollem Zugriff auf Systemkomponenten. Dieser Artikel beschränkt sie auf die von Sophos dokumentierten Diagnosebefehle cd /log, tail, grep, less und service -S.

Nach dem Login per SSH zeigt die Firewall zuerst das Konsolenmenü. Für die Device Console wählt man normalerweise 4. Device Console. Für die Advanced Shell verwendet man 5. Device Management > 3. Advanced Shell.

Globale Parameter für Paketprüfung, TCP, UDP, WAN-Zugriff und Sonderpfade bündelt die Device Console unter advanced-firewall. Ihre Wirkung und einen sicheren Änderungsablauf erklärt Advanced Firewall Settings sicher prüfen.

Der DNS-Test ist ein gutes Beispiel dafür, warum der Konsolenbereich zählt. In der Device Console lautet der offiziell dokumentierte Befehl:

dnslookup host example.com

example.com ist ein sicherer Dokumentationswert und wird für den realen Test durch den betroffenen FQDN ersetzt. Die Antwort bestätigt nur die Auflösung aus Sicht der Firewall; für einen Clientfehler müssen zusätzlich dessen DNS-Server, Antwort und Netzwerkpfad geprüft werden.

Die offizielle Sophos CLI-Hilfe unterstützt Tab und ? zur Syntaxprüfung. Das ist in der Device Console hilfreich, weil nicht jeder Befehl gleich aufgebaut ist.

Gerade in der Device Console sollte man Befehle nicht halb geraten ausführen. Sophos weist darauf hin, dass ein unvollständiger Befehl den access_server blockieren kann. Deshalb zuerst mit Tab oder ? die Syntax anzeigen lassen und dann den vollständigen Befehl bewusst ausführen.

Direkte Konfigurationsänderungen in der Advanced Shell sind nicht persistent und werden nicht in Backups übernommen. In dieser Anleitung wird sie deshalb nur für Diagnosebefehle verwendet.

Ein spezieller Notfallbefehl ist system appliance_access enable. Er übersteuert die Device-Access-Konfiguration und erlaubt Zugriff auf alle lokalen Firewall-Dienste, einschliesslich Legacy-Diensten wie Telnet. Wichtig: Solange dieser Modus aktiv ist, leitet die Firewall keinen ausgehenden Traffic mehr ins Internet weiter. Das ist kein normaler Troubleshooting-Schritt, sondern nur für kurze Notfälle gedacht. Vor der Aktivierung den Zustand prüfen:

Der dokumentierte Default ist Disable. Bei enable nehmen alle Ports eingehende Verbindungen an; damit fällt die normale Einschränkung durch Device Access vorübergehend weg. Die jeweilige Dienst-Authentifizierung bleibt ein separater Kontrollpunkt, macht die breite Erreichbarkeit aber nicht unkritisch.

system appliance_access show

Nach dem Test den Notfallmodus deaktivieren und den Zustand erneut prüfen:

system appliance_access disable
system appliance_access show

Wenn ein Befehl nicht erkannt wird, zuerst den Konsolenbereich prüfen. Ein falscher Bereich ist wahrscheinlicher als ein sofort defekter Befehl.

Logs in der Advanced Shell prüfen

Die wichtigsten Logdateien liegen unter /log. Sophos dokumentiert für die Advanced Shell zuerst den Wechsel in dieses Verzeichnis:

cd /log

Nützliche Basisbefehle:

• Log live verfolgen: tail -f ips.log. Die fortlaufende Ausgabe nur während des dokumentierten Testfensters geöffnet lassen.
• Logdatei lesen: less ips.log. Damit werden Logzeilen abschnittsweise angezeigt.
• Nach einem Begriff suchen: grep error ips.log. Den Begriff und die Datei passend zum Fehlerbild ersetzen.

Welche Logdatei zu welchem Modul gehört, ist in Sophos Firewall Troubleshooting: Services und Logs zusammengefasst.

Bei Live-Logs sollte man den Testzeitraum kurz halten und die Uhrzeit notieren. Das ist besonders wichtig, wenn später ein Logarchiv an Sophos Support oder Avanet gegeben wird.

Device Console für schnelle Netzwerkchecks

Die Device Console eignet sich für schnelle Tests aus Sicht der Firewall. Damit lässt sich prüfen, ob DNS, Routing oder Erreichbarkeit grundsätzlich funktionieren.

Schnelle Checks:

• Host erreichen: ping 192.0.2.10 count 4 prüft ICMP-Erreichbarkeit.
• DNS in der Device Console prüfen: dnslookup host example.com prüft die Namensauflösung aus Sicht der Firewall.
• Route prüfen: traceroute 192.0.2.10 zeigt den Pfad zum Ziel.
• Interface-Status ansehen: show interfaces zeigt Interface-Informationen.
• Drop Capture starten: drop-packet-capture 'host 192.0.2.10' zeigt Pakete, die von Firewall-Regeln verworfen werden.
• Paketmitschnitt starten: tcpdump 'host 192.0.2.10 and port 443' prüft, ob Pakete auf der Firewall sichtbar sind.

Für IPv6 stehen die entsprechenden Befehle ping6, dnslookup6 und traceroute6 zur Verfügung.

tcpdump und drop-packet-capture laufen weiter, bis man sie mit Ctrl+C beendet. Deshalb Filter und Testzeit vor dem Start festlegen, die Ausgabe beobachten und den Mitschnitt unmittelbar danach stoppen. Die Befehle ändern keine Konfiguration; ihre Last hängt aber von Trafficmenge, Filterbreite und Laufzeit ab.

drop-packet-capture ist besonders nützlich, wenn unklar ist, ob die Firewall Pakete aktiv verwirft. Es ersetzt aber keine Applikationsanalyse. Wenn ein Server antwortet, aber die Anwendung trotzdem nicht funktioniert, braucht es zusätzlich Log Viewer, NAT-Prüfung, Packet Capture oder Applikationslogs.

Für längere Paketmitschnitte und PCAP-Dateien ist der eigene Artikel Sophos Firewall: Logs mit TCPDump für Analyse sammeln besser geeignet. Dort sollte man auch planen, wie gross die Datei werden darf, wo sie gespeichert wird und wie sie sicher übertragen wird.

Netzwerkchecks ohne CLI im WebAdmin

Unter Diagnostics > Tools stehen dieselben Grundfragen ohne Konsolenzugriff zur Verfügung. Beim Ping lassen sich IPv4 oder IPv6, das Ausgangsinterface und die Paketgrösse wählen. Sophos verwendet standardmässig 32 Byte und erlaubt Werte von 1 bis 65'507 Byte. Ein erfolgreicher Ping bestätigt ICMP-Erreichbarkeit aus Sicht des gewählten Firewall-Interfaces, aber noch keinen funktionierenden Anwendungsdienst.

Für Ping in SFOS 22 und SFOS 23 kann IP address or hostname eine IPv4-Adresse, IPv6-Adresse oder einen FQDN enthalten. IP family legt die Adressfamilie fest, Interface das Ausgangsinterface und Size die Paketgrösse. Bei einem FQDN wird zusätzlich die Namensauflösung benötigt; zur Eingrenzung eines DNS-Problems denselben Test auch mit der erwarteten IP-Adresse vergleichen.

Die Ping-Ausgabe zeigt, ob Antworten eintreffen, wie viele Pakete gesendet und empfangen wurden, den Paketverlust und die Round-Trip Time (RTT). Die RTT ist die Zeit für Anfrage und Antwort, nicht die einseitige Laufzeit. Bleibt jede Antwort aus, werden 100 Prozent Paketverlust angezeigt. Das allein beweist nicht, dass der Host ausgeschaltet ist: Zieladresse, gewähltes Interface, Routing und die Zulässigkeit von ICMP prüfen und bei Bedarf einen engen Packet Capture verwenden. Der erfolgreiche Test muss weiterhin zum tatsächlichen Anwendungsflow passen.

Traceroute akzeptiert ebenfalls IPv4, IPv6 oder einen FQDN und ein bewusst gewähltes Ausgangsinterface. Fehlende Antworten einzelner Hops beweisen keine Unterbrechung, wenn spätere Hops oder das Ziel antworten. Für eine Pfadfrage werden deshalb Zielerreichbarkeit, letzter antwortender Hop und der parallel gemessene Paketfluss gemeinsam betrachtet.

Im WebAdmin unter Diagnostics > Tools > Traceroute das Ziel in IP address or hostname, die Adressfamilie in IP version und das Ausgangsinterface in Interface festlegen; mit Traceroute die Abfrage starten. Für SFOS 22 und SFOS 23 beschreibt Sophos die Ausgabe mit den durchlaufenen Routern, der maximalen Hop-Zahl und der gesamten Rücklaufzeit des Pakets in Millisekunden. Die maximale Hop-Zahl begrenzt die Pfadsuche; sie ist kein Nachweis, dass das Ziel erreicht wurde. Die Zeitwerte beschreiben die Diagnoseantworten und beweisen keinen Anwendungsdurchsatz. In 4. Device Console ergänzt traceroute6 2001:db8::10 das IPv4-Beispiel oben; die Dokumentationsadresse durch die tatsächliche IPv6-Zieladresse ersetzen.

Die nachfolgenden Bezeichnungen Name lookup und Lookup using all configured servers gelten für SFOS 22. Die geänderten SFOS-23-Bezeichnungen DNS lookup und All configured servers sowie die zusätzlichen Serveroptionen und ihre Voraussetzungen erklärt Einzelne Resolver unter Diagnostics vergleichen.

Name lookup fragt einen ausgewählten DNS-Server ab. Mit Lookup using all configured servers lassen sich alle auf der Firewall konfigurierten DNS-Server und ihre Antwortzeiten vergleichen. Ein einzelner schneller Treffer ist noch keine Empfehlung, die DNS-Reihenfolge zu ändern; zuerst müssen Antwortinhalt, Zuverlässigkeit und der betroffene Clientpfad stimmen.

Route lookup zeigt, über welches Interface die Firewall eine IPv4- oder IPv6-Zieladresse routen würde. Die Ausgabe beweist weder Firewall-Regel, NAT, SD-WAN-Entscheidung noch einen funktionierenden Rückweg. Für die Abnahme folgen deshalb eine echte Verbindung, Connection List oder Packet Capture.

Verbindungen ohne Eingriff in den Zustand prüfen

Unter Current activities > Live connections und Diagnostics > Connection list lassen sich aktuelle IPv4- und IPv6-Verbindungen filtern. Connection list zeigt unter anderem eingehendes und ausgehendes Interface, Source und Destination, Rule ID, NAT ID, übersetzte Adressen, Status sowie Rx-/Tx-Zähler. Das ist der bessere erste Schritt als ein nicht dokumentiertes Advanced-Shell-Werkzeug.

In der Device Console ist zusätzlich dieses Verbindungswerkzeug dokumentiert:

system diagnostics utilities connections

Die verfügbaren Argumente werden vor dem Aufruf mit system diagnostics utilities connections ? geprüft. Da Connection list eine Momentaufnahme zeigt, wird der Testflow parallel reproduziert und die Ansicht aktualisiert. Fehlt die Verbindung weiterhin, folgt ein enger Packet Capture; ein vorhandener Eintrag wird anhand von Rule ID, NAT ID, Interfaces, Übersetzung und Antwortzählern weiter eingegrenzt.

Speicherplatz und Systemzustand prüfen

Vor Debug-Logging, grossen Logarchiven oder längeren Paketmitschnitten sollte der freie Speicherplatz geprüft werden.

Die Device Console bietet dafür lesende, offiziell dokumentierte Systemchecks:

system diagnostics show cpu
system diagnostics show memory
system diagnostics show disk
system diagnostics show uptime
system diagnostics show version-info

system diagnostics show version-info gibt auch Seriennummer und Device ID aus. Vor Screenshots oder Weitergabe werden diese Identifikatoren deshalb geschwärzt.

Zusätzliche lesende Ziele sind interrupts, syslog, sysmsg, subsystem-info und ctr-log-lines. Sie beantworten unterschiedliche Fragen und werden deshalb nicht als austauschbare Gesundheitswerte behandelt:

system diagnostics show interrupts
system diagnostics show syslog
system diagnostics show sysmsg
system diagnostics show subsystem-info
system diagnostics show ctr-log-lines

Auf XGS Appliances steht ausserdem system diagnostics selftest für grundlegende Tests der Netzwerkkarte zur Verfügung. Der Befehl gilt nicht für andere Plattformen und ersetzt weder Kabeltest noch Durchsatzmessung oder Paketmitschnitt. Da Sophos auf der Befehlsseite keine Aussage zu Auswirkungen auf produktiven Traffic macht, wird der Selbsttest nur geplant oder auf Anweisung des Supports ausgeführt und mit Linkstatus, Interfacezählern und realem Traffic abgeglichen.

Unter system diagnostics utilities bündelt SFOS weitere Werkzeuge für ARP, Bandbreite, Verbindungen, DNS, Drop Capture, Netzwerkkonfiguration, Ping, Prozesse, Routen und Traceroute, jeweils auch mit IPv6-Varianten, wo Sophos sie anbietet. Die genaue Syntax wird auf dem installierten Build mit Tab-Vervollständigung geprüft. Einige Werkzeuge lesen nur, andere erzeugen Testtraffic oder starten eine laufende Ausgabe.

Für einen ergänzenden, lesenden Dienstcheck dokumentiert Sophos in der Advanced Shell:

service -S
service -S | grep ips

Die erste Variante zeigt viele Dienstzustände; die zweite verwendet das von Sophos dokumentierte IPS-Beispiel. Ein fehlender Treffer ist kein Auftrag zum Neustart: zuerst Dienstname und passende Logdatei mit der aktuellen Sophos-Logübersicht abgleichen.

Wenn Speicherplatz bereits knapp ist, sollte kein Debug-Logging und kein längerer Paketmitschnitt gestartet werden. Zuerst klären, welche Logs oder Reports sicher gesichert und bereinigt werden können.

Debug-Logs nur mit gesichertem Rückweg erfassen

SFOS 22 aktiviert den Debug-Modus nicht in WebAdmin, sondern in der Device Console. Für einen kontrollierten Test mit dem von Sophos dokumentierten Beispiel Pktcapd zuerst freien Speicher und Testzeit notieren und dann ausführen:

system diagnostics subsystems Pktcapd debug on

Danach den Fehler einmal reproduzieren und unter Diagnostics > Tools > Troubleshooting logs die Logdatei oder einen Consolidated Troubleshooting Report (CTR) herunterladen. Debug vergrössert Logdateien und bleibt aktiv, bis man ihn ausschaltet. Deshalb direkt nach dem Download den dokumentierten Rückweg ausführen:

system diagnostics subsystems Pktcapd debug off

On- und Off-Befehl samt CLI-Ausgabe dokumentieren. Wird ein Befehl abgelehnt, nicht mit einem geratenen Subsystem- oder Service-Kommando fortfahren, sondern Syntax mit ? prüfen und Sophos Support einschalten. Advanced-Shell-Debug wird hier bewusst nicht gezeigt, weil die generische Service-Syntax keinen einheitlichen Off-Befehl für jeden Debug-Modus bietet.

Für Service-Neustarts und ihre Auswirkungen passt Sophos Firewall Services neu starten. Ein Neustart von VPN-, IPS-, Web- oder Authentifizierungsdiensten kann aktive Sitzungen oder Anmeldungen unterbrechen.

Logs sicher bereitstellen

Einzelne Logausschnitte reichen bei komplexen Fällen oft nicht aus. Für Sophos Support, Avanet oder eine externe Analyse ist ein vollständiges Logarchiv meistens sinnvoller.

Statt Zugangsdaten in Shell-Befehle zu schreiben, werden einzelne Logs oder ein CTR unter Diagnostics > Tools > Troubleshooting logs heruntergeladen und über das vereinbarte Supportportal bereitgestellt. Die passende Anleitung steht unter Sophos Firewall Logs für Support und Analyse sichern.

Logdateien können sensible Informationen enthalten: interne IP-Adressen, öffentliche IPs, Hostnamen, Benutzernamen, VPN-Parameter und Fehlermeldungen. Vor einer Weitergabe sollte klar sein, wer die Daten erhält und wie lange sie gespeichert werden.

Typische Fehler bei CLI-Troubleshooting

• Befehl im falschen Konsolenbereich: Device Console und Advanced Shell unterstützen unterschiedliche Syntax. Zuerst Bereich prüfen.
• Debug nach der Analyse aktiv lassen: Logs wachsen unnötig und können Speicherplatz verbrauchen. Debug direkt wieder deaktivieren.
• Breiter tcpdump ohne Filter: Sehr viel Ausgabe, hohe Last und schwer auswertbare Daten. Host, Port, Interface oder Count einschränken.
• FTP-Zugangsdaten in der Shell-History: Zugangsdaten können in Logs, Screenshots oder History landen. Sichere Übertragung und temporäre Credentials verwenden.
• Nur eine Logdatei prüfen: Viele Probleme betreffen mehrere Module. Log Viewer, passende Service-Logs und Packet Capture kombinieren.
• Zeitpunkt nicht dokumentieren: Support muss unnötig grosse Logbereiche durchsuchen. Uhrzeit, Testaktion und beteiligte IPs notieren.
• Nach dem Test nicht aufräumen: Debug, temporäre Dateien oder breite Zugänge bleiben aktiv. Debug ausschalten, Dateien prüfen und temporäre SSH-Freigaben entfernen.

Checkliste

• SSH-Zugriff nur aus vertrauenswürdigen Admin-Netzen erlaubt.
• SSH-Fingerprint und admin Zugriff vor der Analyse geprüft.
• Richtigen Konsolenbereich gewählt: Device Console oder Advanced Shell.
• Problemzeitpunkt, Quell-IP, Ziel-IP, Port und Benutzer dokumentiert.
• CLI-Befund mit Zeitfenster, Befehl, Filter und Ergebnis dokumentiert.
• Erst lesende Befehle genutzt, bevor Debug, Service-Neustarts oder längere Captures gestartet wurden.
• Log Viewer zuerst geprüft.
• Passende Logdatei unter /log identifiziert.
• tail, grep oder less mit engem Suchbegriff verwendet.
• Bei Netzwerkproblemen dnslookup, ping, traceroute, drop-packet-capture oder tcpdump gezielt in der Device Console eingesetzt.
• Debug nur kurz unter Diagnostics > Tools > Troubleshooting logs aktiviert, danach ausgeschaltet und der Normalzustand kontrolliert.
• Speicherplatz vor Debug oder PCAP geprüft.
• Logarchiv sicher übertragen und temporäre Dateien entfernt.
• Temporäre Device-Access- oder SSH-Ausnahmen nach dem Supportfall entfernt.

FAQ