Sophos Firewall CLI-troubleshooting: belangrijke opdrachten

Bij troubleshooting op een Sophos Firewall is Log Viewer vaak voldoende voor de eerste afbakening. Zodra een service niet goed start, VPN-verbindingen instabiel zijn, afzonderlijke pakketten niet aankomen of support gedetailleerde gegevens nodig heeft, wordt de CLI belangrijk.

Dit overzicht toont de belangrijkste opdrachten voor dagelijks gebruik: waar ze worden uitgevoerd, wat ze laten zien en wanneer een gespecialiseerd artikel geschikter is. Raadpleeg voor veilige SSH-toegang eerst Via SSH verbinding maken met Sophos Firewall. Een public key, controle van de host key en een beperkte Device Access-toegang zijn belangrijker dan snel vanaf elke locatie kunnen inloggen.

⚠️ Belangrijk: CLI- en Advanced Shell-opdrachten mogen alleen vanuit vertrouwde beheernetwerken en met een duidelijk doel worden uitgevoerd. Vooral debug, tcpdump, bestandsbewerkingen en serviceopdrachten kunnen de opslagruimte, prestaties of actieve verbindingen beïnvloeden.

Eerst WebAdmin, daarna de CLI

De CLI is niet altijd het snelste startpunt. Voor rule matching, NAT of afzonderlijke verbindingen leveren Log Viewer, Policy Test en Packet Capture in WebAdmin vaak sneller een duidelijk resultaat.

Goede startpunten:

• Welke firewallregel wordt toegepast? Gebruik eerst Log Viewer, Policy Test en Packet Capture. De CLI is pas nodig als Log Viewer te weinig details toont of live logs nodig zijn.
• Komen pakketten bij de firewall aan? Gebruik eerst Packet Capture in WebAdmin. De CLI is nuttig wanneer een nauwkeurige capture of een PCAP-bestand voor support nodig is.
• Heeft een service een probleem? Controleer eerst het dashboard, Log Viewer en de servicelogs. De CLI wordt belangrijk wanneer de servicestatus, debug of logbestanden rechtstreeks moeten worden gecontroleerd.
• Is er iets gewijzigd? Controleer eerst Audit Trail Logs. Daarna helpt de CLI om een configuratieverschil met logs of back-ups te vergelijken.

Het doel is niet om zo snel mogelijk naar Advanced Shell te gaan. Een navolgbaar proces werkt beter: controleer eerst zichtbare gebeurtenissen en open daarna gericht het juiste logbestand of de juiste capture.

CLI-bevindingen bruikbaar documenteren

CLI-uitvoer is alleen nuttig als later nog duidelijk is bij welke test deze hoort. Los gekopieerde foutmeldingen zonder tijdvenster, IP-adressen of betrokken functie leiden vaak tot aanvullende vragen en dubbel onderzoek.

Een korte notitie per test is meestal voldoende:

• Tijdvenster: begin, einde en tijdzone van de test.
• Testflow: Source IP, Destination IP of FQDN, poort, gebruiker of VPN-peer.
• Hulpmiddel: Device Console, Advanced Shell, Log Viewer of Packet Capture.
• Opdracht of filter: uitgevoerde opdracht, gebruikte grep-zoekterm of capturefilter.
• Resultaat: treffer, foutmelding, ontbrekende logvermelding, pakket zichtbaar of pakket niet zichtbaar.
• Volgende conclusie: bijvoorbeeld regelprobleem, DNS-probleem, retourpad, servicefout of supportcase.

Controleer vóór verzending naar Sophos Support, Avanet of een externe partner of de uitvoer gevoelige gegevens bevat: openbare IP-adressen, interne hostnamen, gebruikersnamen, VPN-parameters, serienummers, tokens, e-mailadressen of klantnamen. Voor een technische analyse hoeven gegevens niet onnodig breed te worden verspreid; belangrijk is het kleinste fragment dat de bevinding aantoont.

Vóór de eerste opdracht

CLI-troubleshooting wordt veel betrouwbaarder als het kader vóór de eerste opdracht vaststaat. Anders ontstaan al snel logfragmenten zonder tijdsaanduiding, te brede captures of debuglogs die later niet meer duidelijk aan een test kunnen worden gekoppeld.

Leg vóór CLI-tests in een productieomgeving het volgende vast:

• Probleemtijd: logs kunnen gericht binnen het testvenster worden doorzocht.
• Source IP, Destination IP en poort: grep, tcpdump en Packet Capture blijven nauwkeurig en leesbaar.
• Betrokken gebruiker of peer: authenticatie, VPN en User Matching kunnen beter worden toegewezen.
• Verwachte module: zoek eerst in het juiste logbestand in plaats van in alle logs.
• Geplande actie: debug, servicecontrole of capture blijft niet per ongeluk actief.
• Rollback- of afbreekcriterium: beëindig de test bij belasting, volle opslag of neveneffecten.
• Actuele back-up bij wijzigingen: serviceherstarts of configuratiewijzigingen kunnen beter worden afgedekt.

De eerste stap moet waar mogelijk alleen-lezen zijn: controleer Log Viewer, bekijk het juiste logbestand, lees service -S of start een nauwkeurige capture. Herstarts, debugmodus en brede captures horen pas daarna in een bewust gepland testvenster.

Bij HA-clusters moet bovendien duidelijk zijn welke appliance momenteel actief is. Logs, debug en captures moeten worden gecontroleerd op het knooppunt waar het relevante verkeer daadwerkelijk doorheen loopt.

Voer een volledige herstart alleen als geplande actie uit

Een volledige herstart is geen diagnosecommando. Bewaar eerst relevante logs, systeemtijd, uptime, HA-rollen en de huidige fouttoestand. Als alleen WebAdmin of één service is getroffen, controleer dan of een gerichte WebAdmin-herstart of serviceherstart volstaat.

SFOS 22 documenteert de volgende syntaxis in de Device Console:

system restart [all]

De vierkante haken horen niet bij het commando, maar markeren het optionele argument all. Controleer eerst de vorm die de geïnstalleerde build aanbiedt met system restart ?. Het commando herstart de firewall en onderbreekt sessies, VPN-tunnels en managementtoegang. Na uitvoering bestaat geen CLI-rollback, zodat het onderhoudsvenster, consoletoegang en een geteste terugweg voor beheer vóór de bevestiging gereed moeten zijn.

Volgens Sophos veroorzaakt system restart in een HA-cluster een failover. Dit garandeert geen ononderbroken verbindingen. Peer, synchronisatie, rollen en HA-link moeten eerst stabiel zijn. Controleer na de herstart beide nodes, rollen, synchronisatie, uptime, WAN, routing, DNS, VPN, gepubliceerde services en een echte applicatieflow. Een succesvolle boot bewijst niet dat de oorspronkelijke oorzaak is opgelost.

Sluit alleen af met een voorbereid inschakelpad

Gebruik voor een gecontroleerde shutdown exact dit Device Console-commando:

system shutdown

Sophos documenteert hiervoor geen opties. Voeg daarom geen all, nodenaam of veronderstelde HA-schakelaar aan de syntaxis toe. Bewaar vóór de bevestiging logs en configuratie, informeer afhankelijke teams en leg vast hoe de appliance weer wordt ingeschakeld via fysieke toegang, remote management of het virtualisatieplatform. De shutdown-pagina garandeert geen HA-gedrag; sluit een clusternode daarom alleen af volgens de voorziene HA-onderhoudsprocedure en controleer daarna uitdrukkelijk de peer.

Device Console of Advanced Shell?

Sophos Firewall heeft twee verschillende consoleomgevingen. Veel fouten ontstaan doordat een opdracht in de verkeerde omgeving wordt ingevoerd.

De omgevingen hebben verschillende taken:

• Device Console: Sophos CLI voor netwerk-, systeem- en diagnoseopdrachten. Typische opdrachten zijn ping, dnslookup, traceroute, tcpdump, drop-packet-capture en show.
• Advanced Shell: Linux-achtige shell met volledige toegang tot systeemcomponenten. Dit artikel beperkt het gebruik tot de door Sophos gedocumenteerde diagnosecommando’s cd /log, tail, grep, less en service -S.

Na het inloggen via SSH toont de firewall eerst het consolemenu. Voor Device Console wordt doorgaans 4. Device Console gekozen. Voor Advanced Shell wordt 5. Device Management > 3. Advanced Shell gebruikt.

De Device Console bundelt globale parameters voor pakketinspectie, TCP, UDP, WAN-toegang en speciale paden onder advanced-firewall. Hun werking en een veilige wijzigingsprocedure staan in Advanced Firewall Settings veilig controleren.

De DNS-test laat goed zien waarom de consoleomgeving belangrijk is. In de Device Console is dit het officieel gedocumenteerde commando:

dnslookup host example.com

example.com is een veilige documentatiewaarde; vervang deze voor een echte test door de betrokken FQDN. Het antwoord bevestigt alleen naamomzetting vanuit de firewall. Controleer bij een clientprobleem ook de DNS-server, het antwoord en het netwerkpad van die client.

De officiële Sophos CLI-help ondersteunt Tab en ? voor syntaxiscontrole. Dit is nuttig in Device Console, omdat niet elke opdracht op dezelfde manier is opgebouwd.

Vooral in Device Console mogen opdrachten niet gedeeltelijk of op basis van een gok worden uitgevoerd. Sophos waarschuwt dat een onvolledige opdracht access_server kan blokkeren. Laat daarom eerst met Tab of ? de syntaxis zien en voer daarna bewust de volledige opdracht uit.

Directe configuratiewijzigingen in Advanced Shell zijn niet persistent en worden niet in back-ups opgenomen. Daarom wordt Advanced Shell in deze handleiding alleen voor diagnoseopdrachten gebruikt.

Vóór noodtoegang: Laat doel, verantwoordelijke persoon, betrokken appliance en een kort noodvenster met eindtijd en afbreekcriterium expliciet goedkeuren; houd rekening met de onderbreking van internetforwarding. Open vooraf daadwerkelijk een onafhankelijk herstelpad en controleer de beheerderstoegang, bijvoorbeeld via een lokale console, de console van het virtualisatieplatform of out-of-band-management. Deze toegang mag niet afhangen van het defecte netwerkpad of de noodmodus en moet beschikbaar blijven om de modus uit te schakelen. Niet activeren zonder goedkeuring of een werkend onafhankelijk herstelpad; stem eerst het herstel af met de verantwoordelijke persoon of Sophos Support.

Een speciale noodopdracht is system appliance_access enable. Deze omzeilt de Device Access-configuratie en geeft toegang tot alle lokale firewallservices, inclusief oudere services zoals Telnet. Belangrijk: zolang deze modus actief is, stuurt de firewall geen uitgaand verkeer meer door naar internet. Dit is geen normale troubleshootingstap, maar uitsluitend bedoeld voor korte noodsituaties. Controleer vóór activering de status:

De gedocumenteerde default is Disable. Met enable accepteren alle poorten inkomende verbindingen en valt de normale bereikbaarheidsbeperking van Device Access tijdelijk weg. Authenticatie door de afzonderlijke service blijft een aparte controle, maar maakt deze brede blootstelling niet onschuldig.

system appliance_access show

Schakel zodra de beoogde volledige beheerderstoegang is hersteld de noodmodus onmiddellijk uit in 4. Device Console en controleer de status opnieuw; wacht niet op het einde van verdere diagnostiek. Schakel ook via het voorbereide onafhankelijke herstelpad uit als de procedure wordt afgebroken of de goedgekeurde eindtijd is bereikt:

system appliance_access disable
system appliance_access show

Daarna moet show de status Disable bevestigen. Test ook een nieuwe WebAdmin- of SSH-aanmelding vanuit het beoogde beheernetwerk onder de normale Device Access-regels en controleer dat eerder geblokkeerde toegang geblokkeerd blijft. Test vanaf een betrokken client achter de firewall een echte uitgaande internetverbinding, bijvoorbeeld een HTTPS-verzoek naar een goedgekeurd doel, met een succesvolle respons; een ping vanaf de firewall of alleen show bewijst niet dat forwarding is hersteld. Sluit bij mislukte controles of een onduidelijke status de zaak niet als opgelost af: houd het onafhankelijke herstelpad open, bewaar de CLI-respons en testbevindingen en stem af met de verantwoordelijke persoon of Sophos Support in plaats van brede noodtoegang opnieuw in te schakelen als permanente oplossing.

Als een opdracht niet wordt herkend, controleer dan eerst de consoleomgeving. Een verkeerde omgeving is waarschijnlijker dan een defecte opdracht.

Logs controleren in Advanced Shell

De belangrijkste logbestanden staan onder /log. Sophos documenteert eerst de overstap naar deze map in de Advanced Shell:

cd /log

Nuttige basisopdrachten:

• Log live volgen: tail -f ips.log. Laat de doorlopende uitvoer alleen tijdens het vastgelegde testvenster open.
• Logbestand lezen: less ips.log. Hiermee worden logregels in delen weergegeven.
• Naar een term zoeken: grep error ips.log. Pas de term en het bestand aan het probleem aan.

In Sophos Firewall-troubleshooting: services en logs staat welk logbestand bij welke module hoort.

Houd bij live logs de testperiode kort en noteer de tijd. Dit is vooral belangrijk als later een logarchief aan Sophos Support of Avanet wordt verstrekt.

Device Console voor snelle netwerkcontroles

Device Console is geschikt voor snelle tests vanuit het perspectief van de firewall. Hiermee kan worden gecontroleerd of DNS, routing of bereikbaarheid in principe werkt.

Snelle controles:

• Host bereiken: ping 192.0.2.10 count 4 controleert de ICMP-bereikbaarheid.
• DNS in Device Console controleren: dnslookup host example.com controleert de naamomzetting vanuit het perspectief van de firewall.
• Route controleren: traceroute 192.0.2.10 toont het pad naar de bestemming.
• Interfacestatus bekijken: show interfaces toont informatie over interfaces.
• Drop Capture starten: drop-packet-capture 'host 192.0.2.10' toont pakketten die door firewallregels worden geweigerd.
• Pakketcapture starten: tcpdump 'host 192.0.2.10 and port 443' controleert of pakketten op de firewall zichtbaar zijn.

Voor IPv6 zijn de overeenkomstige opdrachten ping6, dnslookup6 en traceroute6 beschikbaar.

tcpdump en drop-packet-capture blijven actief totdat ze met Ctrl+C worden gestopt. Leg eerst het filter en testvenster vast, volg de uitvoer en stop de capture direct daarna. Deze opdrachten wijzigen de configuratie niet, maar hun belasting hangt af van het verkeersvolume, de breedte van het filter en de looptijd.

drop-packet-capture is vooral nuttig wanneer onduidelijk is of de firewall pakketten actief weigert. Het vervangt echter geen applicatieanalyse. Als een server antwoordt maar de applicatie nog steeds niet werkt, moeten ook Log Viewer, NAT, Packet Capture of applicatielogs worden gecontroleerd.

Voor langere captures en PCAP-bestanden is het aparte artikel Sophos Firewall: logs verzamelen met TCPDump voor analyse geschikter. Plan daarbij ook hoe groot het bestand mag worden, waar het wordt opgeslagen en hoe het veilig wordt overgedragen.

Netwerkcontroles in WebAdmin zonder CLI

Onder Diagnostics > Tools kunnen dezelfde basisvragen zonder consoletoegang worden getest. Bij Ping kunnen IPv4 of IPv6, de uitgaande interface en de pakketgrootte worden gekozen. Sophos gebruikt standaard 32 bytes en staat waarden van 1 tot 65.507 bytes toe. Een geslaagde ping bevestigt ICMP-bereikbaarheid vanaf de geselecteerde firewallinterface, maar nog niet dat een applicatieservice werkt.

Voor Ping in SFOS 22 en SFOS 23 kan IP address or hostname een IPv4-adres, IPv6-adres of FQDN bevatten. IP family bepaalt de adresfamilie, Interface de uitgaande interface en Size de pakketgrootte. Bij een FQDN is daarnaast naamomzetting nodig; vergelijk ter afbakening van een DNS-probleem dezelfde test ook met het verwachte IP-adres.

De Ping-uitvoer toont of antwoorden binnenkomen, hoeveel pakketten zijn verzonden en ontvangen, het pakketverlies en de Round-Trip Time (RTT). De RTT is de tijd voor het verzoek en het antwoord, niet de eenzijdige looptijd. Als geen enkel antwoord binnenkomt, wordt 100 procent pakketverlies weergegeven. Dat alleen bewijst niet dat de host is uitgeschakeld: controleer het doeladres, de gekozen interface, de routing en of ICMP is toegestaan, en gebruik indien nodig een nauwkeurig afgebakende Packet Capture. De geslaagde test moet nog steeds aansluiten bij de daadwerkelijke applicatieflow.

Traceroute accepteert eveneens IPv4, IPv6 of een FQDN en een bewust gekozen uitgaande interface. Ontbrekende antwoorden van afzonderlijke hops bewijzen geen onderbreking als latere hops of het doel wel antwoorden. Voor een padvraag worden daarom de bereikbaarheid van het doel, de laatste antwoordende hop en de parallel gemeten pakketstroom samen beoordeeld.

Stel in WebAdmin onder Diagnostics > Tools > Traceroute het doel in bij IP address or hostname, de adresfamilie bij IP version en de uitgaande interface bij Interface; start de query met Traceroute. Voor SFOS 22 en SFOS 23 beschrijft Sophos de uitvoer aan de hand van de doorlopen routers, het maximale aantal hops en de totale retourtijd van het pakket in milliseconden. Het maximale aantal hops begrenst het zoeken naar het pad; het bewijst niet dat het doel is bereikt. De tijdwaarden beschrijven de diagnoseantwoorden en bewijzen geen applicatiedoorvoer. In 4. Device Console vult traceroute6 2001:db8::10 het IPv4-voorbeeld hierboven aan; vervang het documentatieadres door het daadwerkelijke IPv6-doeladres.

De onderstaande benamingen Name lookup en Lookup using all configured servers gelden voor SFOS 22. De gewijzigde SFOS-23-benamingen DNS lookup en All configured servers, evenals de aanvullende serveropties en hun vereisten, worden uitgelegd in Afzonderlijke resolvers vergelijken onder Diagnostics.

Name lookup bevraagt een geselecteerde DNS-server. Met Lookup using all configured servers kunnen alle op de firewall geconfigureerde DNS-servers en hun responstijden worden vergeleken. Eén snel resultaat is nog geen reden om de DNS-prioriteit te wijzigen; ook de antwoordinhoud, betrouwbaarheid en het getroffen clientpad moeten kloppen.

Route lookup toont via welke interface de firewall een IPv4- of IPv6-doel zou routeren. De uitvoer bewijst noch de firewallregel, NAT, de SD-WAN-beslissing, noch een werkend retourpad. Voor de validatie volgen daarom een echte verbinding, Connection List of Packet Capture.

Verbindingen controleren zonder de status te wijzigen

Filter actuele IPv4- en IPv6-verbindingen onder Current activities > Live connections en Diagnostics > Connection list. Connection list toont onder meer inkomende en uitgaande interfaces, bron en bestemming, Rule ID, NAT ID, vertaalde adressen, status en Rx-/Tx-tellers. Dit is een beter begin dan een niet-gedocumenteerde Advanced Shell-tool.

In de Device Console is ook dit verbindingshulpmiddel gedocumenteerd:

system diagnostics utilities connections

Controleer vóór de uitvoering de beschikbare argumenten met system diagnostics utilities connections ?. Connection list is een momentopname; reproduceer daarom de testflow terwijl de weergave wordt vernieuwd. Ontbreekt de verbinding nog steeds, voer dan een nauwkeurige Packet Capture uit. Is ze aanwezig, ga dan verder met Rule ID, NAT ID, interfaces, vertaling en antwoordtellers.

Opslagruimte en systeemstatus controleren

Controleer de vrije opslagruimte vóór debuglogging, grote logarchieven of langere pakketcaptures.

Device Console biedt hiervoor de volgende alleen-lezen, officieel gedocumenteerde systeemcontroles:

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 toont ook het serienummer en de Device ID. Maak deze identificatoren onleesbaar voordat uitvoer of screenshots worden gedeeld.

Aanvullende alleen-lezen doelen zijn interrupts, syslog, sysmsg, subsystem-info en ctr-log-lines. Ze beantwoorden verschillende vragen en mogen niet als onderling uitwisselbare gezondheidswaarden worden behandeld:

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

Op XGS Appliances is ook system diagnostics selftest beschikbaar voor basistests van de netwerkkaart. De opdracht geldt niet voor andere platforms en vervangt geen kabeltest, doorvoermeting of packet capture. Omdat Sophos op de opdrachtpagina niets zegt over de invloed op productieverkeer, wordt de zelftest alleen gepland of op aanwijzing van support uitgevoerd en vergeleken met linkstatus, interfacecounters en echt verkeer.

Onder system diagnostics utilities groepeert SFOS aanvullende hulpmiddelen voor ARP, bandbreedte, verbindingen, DNS, drop capture, netwerkconfiguratie, ping, processen, routes en traceroute, inclusief IPv6-varianten waar Sophos die aanbiedt. Controleer de exacte syntaxis op de geïnstalleerde build met Tab-aanvulling. Sommige hulpmiddelen lezen alleen status, terwijl andere testverkeer genereren of doorlopende uitvoer starten.

Voor een aanvullende alleen-lezen servicecontrole documenteert Sophos in de Advanced Shell:

service -S
service -S | grep ips

De eerste variant toont veel servicestatussen; de tweede gebruikt het door Sophos gedocumenteerde IPS-voorbeeld. Geen treffer is geen reden voor een herstart: vergelijk eerst de servicenaam en het logbestand met de actuele Sophos-loglijst.

Als de opslagruimte al krap is, mogen debuglogging en een langere pakketcapture niet worden gestart. Bepaal eerst welke logs of rapporten veilig kunnen worden opgeslagen en opgeruimd.

Verzamel debuglogs alleen met een bevestigde terugweg

Voor SFOS 22 en SFOS 23 is het in- en uitschakelen van de hier getoonde debugmodus voor servicesubsystemen gedocumenteerd in de Device Console, niet in WebAdmin. Pktcapd is het gedocumenteerde voorbeeld, geen algemene schakelaar voor alle services. Leg vooraf de geïnstalleerde build, de betrokken HA-node, de vrije opslagruimte, het testvenster en de juiste uitschakelprocedure vast; controleer de syntaxis en het beschikbare subsysteem met ? of Tab. Debug vergroot logbestanden en blijft actief totdat het wordt uitgeschakeld. Schakel debug alleen in voor een kort, afgestemd analysevenster:

Vóór debug on: Bepaal en documenteer de bestaande debugstatus voor precies dit subsysteem op precies deze HA-node met een voor de geïnstalleerde build ondersteunde, alleen-lezen methode of met Sophos Support. Stel daarnaast vast wie verantwoordelijk is voor een bestaande diagnose en of er een gegevensverzameling loopt. system diagnostics show subsystem-info is slechts een aanvullende systeemcontrole; de gedocumenteerde syntaxis garandeert noch een uniform veld voor de debugstatus, noch een betrouwbaar bewijs dat debug is uitgeschakeld.

Stop bij actieve debug of een onduidelijke uitgangsstatus of onduidelijke verantwoordelijkheid: Voer deze On/Off-procedure niet uit en gebruik met name niet uit voorzorg debug off om een uitgangsstatus te creëren. Stem eerst met de diagnoseverantwoordelijke of Sophos Support het doel, de verantwoordelijkheid en de terugweg af; ga pas verder met een expliciet goedgekeurde en bevestigde inactieve uitgangsstatus. Alleen een afgesproken testvenster geeft geen toestemming om een andere lopende diagnostische gegevensverzameling te beëindigen. Schakel pas dan debug voor deze procedure nieuw in en leg de eigen verantwoordelijkheid voor activering en deactivering vast:

system diagnostics subsystems Pktcapd debug on

Reproduceer het probleem eenmaal. Selecteer afzonderlijke logs onder Diagnostics > Tools > Troubleshooting logs en download ze met Download als gecomprimeerd archief. Selecteer voor een Consolidated troubleshooting report (CTR) in plaats daarvan onder Diagnostics > Tools > Consolidated troubleshooting report de benodigde opties System snapshot en All log files, voer de reden in en kies Generate en daarna Download. Het CTR wordt versleuteld gedownload; System snapshot vereist geen debugmodus. Bij sommige CTR-logs beperkt de CLI-instelling het aantal opgenomen logregels, waardoor een CTR niet automatisch de volledige loggeschiedenis bevat.

Deactiveer direct na het downloaden de debugmodus in 4. Device Console uitsluitend voor de servicesubsystemen waarvoor deze procedure debug vanuit de bevestigde inactieve uitgangsstatus nieuw heeft geactiveerd en waarvoor deze procedure nog steeds verantwoordelijk is. Laat de status van andere lopende diagnoses ongewijzigd. Voor het op deze manier geactiveerde voorbeeld is de terugweg precies:

system diagnostics subsystems Pktcapd debug off

Beëindig de test bij een afgebroken reproductie, een mislukte download, hoge belasting of weinig beschikbare opslagruimte en deactiveer uitsluitend de debug die door deze procedure vanuit de bevestigde inactieve uitgangsstatus nieuw is geactiveerd en waarvoor u zelf nog steeds verantwoordelijk bent, in plaats van op een geslaagde export te wachten. Beëindig geen lopende diagnostische gegevensverzamelingen van anderen; stem bij onduidelijke verantwoordelijkheid af met de diagnoseverantwoordelijke of Sophos Support en schakel niet op goed geluk uit. Een beëindigde SSH-sessie of een logdownload is geen vervanging voor het eigen Off-commando. Logs en rapporten worden niet tussen HA-nodes gesynchroniseerd; verzamel gegevens en ruim op op de node waarop deze procedure debug nieuw heeft geactiveerd.

Documenteer de in- en uitschakelopdracht, het tijdstip, de node en de volledige CLI-respons. Controleer na de uitschakelopdracht of de CLI de deactivering bevestigt of een fout meldt; vergelijk daarnaast de uitvoer van de alleen-lezen systeemcontrole system diagnostics show subsystem-info met de vóór de test vastgelegde toestand. De gedocumenteerde syntaxis garandeert niet dat elke build een uniform debugstatusveld bevat. Ontbreekt een eenduidige bevestiging, vink de status dan niet af als ‘uitgeschakeld’, maar bespreek de uitvoer met Sophos Support. Controleer bij een geweigerde opdracht de syntaxis met ? en ga niet verder met gegokte subsysteem-, herstart- of serviceopdrachten. Pas de syntaxis voor servicesubsystemen met name niet toe op CSC, waarvoor de debugopdracht anders is gedocumenteerd. Debug in Advanced Shell wordt hier bewust niet getoond, omdat de generieke servicesyntaxis niet voor elke debugmodus een uniforme uitschakelopdracht biedt.

Zie voor serviceherstarts en hun effecten Sophos Firewall-services opnieuw starten. Een herstart van VPN-, IPS-, web- of authenticatieservices kan actieve sessies of aanmeldingen onderbreken.

Logs veilig aanleveren

Losse logfragmenten zijn bij complexe gevallen vaak niet voldoende. Voor Sophos Support, Avanet of een externe analyse is een volledig logarchief meestal nuttiger.

Verzamel de bestanden in WebAdmin in plaats van inloggegevens in shellopdrachten te schrijven: selecteer Diagnostics > Tools > Troubleshooting logs voor afzonderlijke logbestanden en kies Download. Maak een CTR daarentegen onder Diagnostics > Tools > Consolidated troubleshooting report met de benodigde opties System snapshot en All log files en een reden; kies vervolgens Generate en Download. Controleer vóór het delen of het archief of het versleutelde rapport daadwerkelijk is gedownload en verstrek het uitsluitend via het afgesproken supportportal. Een mislukte export is geen reden om de debug die door deze procedure vanuit een bevestigde inactieve uitgangsstatus nieuw is geactiveerd en waarvoor u zelf nog steeds verantwoordelijk bent, actief te laten; een andere lopende diagnostische gegevensverzameling mag hierdoor niet worden beëindigd. De bijbehorende instructies staan in Sophos Firewall-logs veiligstellen voor support en analyse.

Logbestanden kunnen gevoelige informatie bevatten: interne en openbare IP-adressen, hostnamen, gebruikersnamen, VPN-parameters en foutmeldingen. Vóór overdracht moet duidelijk zijn wie de gegevens ontvangt en hoe lang ze worden bewaard.

Veelvoorkomende fouten bij CLI-troubleshooting

• Opdracht in de verkeerde consoleomgeving: Device Console en Advanced Shell ondersteunen verschillende syntaxis. Controleer eerst de omgeving.
• Eigen debug na de analyse actief laten: Logs groeien onnodig en kunnen opslagruimte verbruiken. Deactiveer direct weer uitsluitend de debug die door deze procedure vanuit een bevestigde inactieve uitgangsstatus nieuw is geactiveerd en waarvoor u zelf nog steeds verantwoordelijk bent; beëindig geen diagnostische gegevensverzamelingen van anderen.
• Brede tcpdump zonder filter: Veel uitvoer, hoge belasting en moeilijk te analyseren gegevens. Beperk host, poort, interface of aantal pakketten.
• FTP-inloggegevens in de shellgeschiedenis: Inloggegevens kunnen in logs, screenshots of de geschiedenis terechtkomen. Gebruik een veilige overdracht en tijdelijke inloggegevens.
• Slechts één logbestand controleren: Veel problemen hebben betrekking op meerdere modules. Combineer Log Viewer, de juiste servicelogs en Packet Capture.
• Tijdstip niet documenteren: Support moet onnodig grote logbereiken doorzoeken. Noteer tijd, testactie en betrokken IP-adressen.
• Na de test niet opruimen: Debug, tijdelijke bestanden of ruime toegangsrechten blijven actief. Schakel uitsluitend de debug uit die door deze procedure vanuit een bevestigde inactieve uitgangsstatus nieuw is geactiveerd en waarvoor u zelf nog steeds verantwoordelijk bent, controleer bestanden en verwijder tijdelijke SSH-toegangsrechten; beëindig geen diagnostische gegevensverzamelingen van anderen.

Controlelijst

• SSH-toegang alleen toegestaan vanuit vertrouwde beheernetwerken.
• SSH-fingerprint en toegang voor admin vóór de analyse gecontroleerd.
• Juiste consoleomgeving gekozen: Device Console of Advanced Shell.
• Probleemtijd, Source IP, Destination IP, poort en gebruiker gedocumenteerd.
• CLI-bevinding met tijdvenster, opdracht, filter en resultaat gedocumenteerd.
• Eerst alleen-lezen opdrachten gebruikt voordat debug, serviceherstarts of langere captures werden gestart.
• Log Viewer eerst gecontroleerd.
• Juist logbestand in /log geïdentificeerd.
• tail, grep of less met een nauwkeurige zoekterm gebruikt.
• Bij netwerkproblemen zijn dnslookup, ping, traceroute, drop-packet-capture of tcpdump gericht in de Device Console gebruikt.
• Vóór debug voor een servicesubsysteem in SFOS 22/23 de bestaande status en de diagnoseverantwoordelijke voor precies dat subsysteem en die HA-node vastgesteld en een expliciet goedgekeurde inactieve uitgangsstatus bevestigd en gedocumenteerd; bij een actieve of onduidelijke status de On/Off-procedure niet uitgevoerd, maar afgestemd met de verantwoordelijke of Support. Alleen vanuit deze uitgangsstatus kort nieuw geactiveerd in 4. Device Console; in het voorbeeld met system diagnostics subsystems Pktcapd debug on en daarna met system diagnostics subsystems Pktcapd debug off uitsluitend de debug gedeactiveerd die door deze procedure nieuw is geactiveerd en waarvoor u zelf nog steeds verantwoordelijk bent. Diagnostische gegevensverzamelingen van anderen ongewijzigd gelaten. Off-respons en aanvullende systeemstatus gecontroleerd; onduidelijke status met Support opgehelderd, niet als gedeactiveerd afgevinkt.
• Opslagruimte vóór debug of PCAP gecontroleerd.
• Logarchief veilig overgedragen en tijdelijke bestanden verwijderd.
• Tijdelijke Device Access- of SSH-uitzonderingen na de supportcase verwijderd.

Veelgestelde vragen