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.

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 voor bestanden, logs, processen en servicecontroles. Typische opdrachten zijn cd /log, tail -f, grep, less, df -kh, service -S en conntrack.

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

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:

system appliance_access show

Deactiveer na de test de noodmodus en controleer de status opnieuw:

system appliance_access disable
system appliance_access show

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 in /log. Ga voor een eerste overzicht naar deze map en toon de bestanden.

cd /log
ls -lah

Nuttige basisopdrachten:

• Log live volgen: tail -f /log/strongswan.log. Geschikt voor reproduceerbare VPN-fouten.
• Logbestand lezen: less /log/ips.log. Binnen less kan met /zoekterm worden gezocht.
• Naar fouten zoeken: grep -i "error" /log/ips.log. -i negeert hoofdletters en kleine letters.
• Treffers met regelnummer tonen: grep -n "192.0.2.10" /log/firewall_rule.log. Nuttig voor langere bestanden.
• Laatste regels tonen: tail -n 100 /log/syslog.log. Snel overzicht zonder livemodus.

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

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.

Verbindingen en pakketstroom controleren in Advanced Shell

Als Log Viewer en Device Console nog geen duidelijk antwoord geven, helpen enkele Advanced Shell-opdrachten bij de beoordeling van de pakketstroom.

Verbindingen controleren

In Device Console is system diagnostics utilities connections een officieel gedocumenteerde diagnosetool voor verbindingen. Controleer vooraf met ? de beschikbare opties en de uitvoer.

conntrack is een supportgerichte tool in Advanced Shell en toont actieve verbindingen die bij het stateful firewallpad bekend zijn. De precieze beschikbaarheid kan afhangen van de firmwareversie.

conntrack -L | grep "192.0.2.10"

Een ontbrekende treffer is slechts een aanwijzing, omdat timing, filterrichting of FastPath de zichtbaarheid kunnen beïnvloeden. Vergelijk het resultaat daarom met Log Viewer en Packet Capture. Als er wel een vermelding is maar de applicatie niet werkt, controleer dan aanvullend of antwoordpakketten terugkomen en of NAT, policy of applicatie correct functioneren.

tcpdump in Advanced Shell

Voor snelle livecontroles kan tcpdump ook in Advanced Shell worden gebruikt.

tcpdump -i any -nn host 192.0.2.10

Voor analyses in productie moet het filter zo nauwkeurig mogelijk zijn. Brede captures zoals tcpdump -i any, zonder host, poort of limiet, produceren snel veel uitvoer en zijn onpraktisch op zwaarbelaste firewalls.

Een veilige start is een korte capture met host, poort en pakketlimiet:

tcpdump -i any -nn -c 50 host 192.0.2.10 and port 443

Als meer gegevens nodig zijn, controleer dan vooraf de opslagruimte en kies bewust een locatie voor het PCAP-bestand.

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

Voor een aanvullende controle in Advanced Shell zijn de volgende tools beschikbaar; de beschikbaarheid kan afhangen van de firmwareversie:

df -kh
df -h /var

Andere snelle controles:

uptime
top
service -S
service -S | grep strongswan

service -S toont de status van veel services. Afzonderlijke servicenamen zijn niet altijd vanzelfsprekend. Vergelijk de service daarom met het juiste logbestand voordat een herstart wordt uitgevoerd of debug wordt geactiveerd.

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.

Debuglogging gericht activeren

Debuglogging kan helpen bij complexe fouten, maar mag alleen kort en uitsluitend voor de betrokken service actief zijn. Debug genereert aanzienlijk meer loggegevens en kan bij langdurig gebruik opslagruimte verbruiken.

Gebruik in Device Console een ondersteund subsysteem voor een duidelijk controleerbare in-/uitschakelprocedure. Toon eerst de beschikbare namen met system diagnostics subsystems ?. Sophos documenteert bijvoorbeeld de volgende procedure voor Pktcapd:

system diagnostics subsystems Pktcapd debug on
system diagnostics subsystems Pktcapd debug off

Sophos documenteert daarnaast de volgende IPS-debugopdracht voor Advanced Shell:

service ips:debug -ds nosync

Voor deze Advanced Shell-variant is geen afzonderlijke opdracht met een toegevoegde off gedocumenteerd. Gebruik deze daarom alleen als Sophos Support de exacte uitschakelmethode voor de geïnstalleerde build heeft bevestigd.

De afbeelding toont op SFOS 20.0.1 hoe dezelfde opdracht de IPS-debugmodus omschakelt en hoe service -S | grep ips de status vóór en na de test bevestigt. Ga er bij actuele versies niet zonder controle van uit dat deze toggle nog hetzelfde werkt.

Raadpleeg voor serviceherstarts en het beoordelen van services ook Sophos Firewall-services opnieuw starten. Documenteer bij supportcases het exacte tijdvenster van het debuglog.

Controleer vóór een serviceherstart welke functie wordt beïnvloed en of er op dat moment productieverkeer doorheen loopt. Een herstart van VPN-, IPS-, web- of authenticatieservices kan actieve sessies of gebruikersaanmeldingen beïnvloeden.

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.

Schrijf geen FTP-inloggegevens in opdrachten, maar draag logs via een veilige en traceerbare methode over, bijvoorbeeld met scp naar een eigen server of via een supportportal. De juiste procedure staat in Sophos Firewall-logs opslaan 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.
• Debug na de analyse actief laten: Logs groeien onnodig en kunnen opslagruimte verbruiken. Schakel debug direct weer uit.
• 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 toegang blijven actief. Schakel debug uit, controleer bestanden en verwijder tijdelijke SSH-toegang.

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 ping, dnslookup, traceroute, drop-packet-capture of tcpdump gericht gebruikt.
• Debug slechts kort geactiveerd en met de gedocumenteerde uitschakelopdracht van het gekozen subsysteem weer gedeactiveerd.
• 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