Felsökning via Sophos Firewall CLI: viktiga kommandon

Vid felsökning av Sophos Firewall räcker Log Viewer ofta för en första avgränsning. När en tjänst inte startar korrekt, VPN-anslutningar är instabila, enskilda paket inte kommer fram eller supporten behöver detaljerade data blir CLI viktig.

Den här översikten visar de viktigaste kommandona i det dagliga arbetet: var de körs, vad de visar och när det är bättre att gå vidare till en specialiserad artikel. För säker åtkomst via SSH bör man först läsa Anslut till Sophos Firewall via SSH. Publik nyckel, verifiering av värdnyckeln och en strikt Device Access-behörighet är viktigare än en snabb inloggning från valfri plats.

⚠️ Viktigt: CLI- och Advanced Shell-kommandon bör endast köras från betrodda administrationsnät och med ett tydligt syfte. Särskilt debug, tcpdump, filåtgärder och tjänstkommandon kan påverka lagringsutrymme, prestanda eller pågående anslutningar.

Först WebAdmin, sedan CLI

CLI är inte alltid den snabbaste utgångspunkten. Vid regelmatchning, NAT eller enskilda anslutningar ger Log Viewer, Policy Test och Packet Capture i WebAdmin ofta snabbare ett tydligt resultat.

Bra utgångspunkter:

• Vilken brandväggsregel matchar? Använd först Log Viewer, Policy Test och Packet Capture. CLI behövs först när Log Viewer visar för få detaljer eller när loggar i realtid krävs.
• Kommer paketen fram till brandväggen? Använd först Packet Capture i WebAdmin. CLI är lämpligt när en snävare fångst eller en PCAP-fil behövs för support.
• Har en tjänst problem? Kontrollera först Dashboard, Log Viewer och tjänsteloggarna. CLI blir viktig när tjänststatus, debug eller loggfiler måste granskas direkt.
• Har något ändrats? Kontrollera först Audit Trail Logs. Därefter hjälper CLI till att jämföra en konfigurationsskillnad med loggar eller säkerhetskopior.

Målet är inte att gå in i Advanced Shell så snabbt som möjligt. Ett spårbart arbetsflöde är bättre: kontrollera först synliga händelser och öppna sedan målmedvetet rätt loggfil eller fångst.

Dokumentera CLI-resultat så att de går att använda

CLI-utdata är bara användbara om det senare fortfarande framgår vilket test de hör till. Enskilda kopierade felmeddelanden utan tidsintervall, IP-adresser eller berörd funktion leder ofta till följdfrågor och upprepad analys.

En kort anteckning per test räcker oftast:

• Tidsintervall: Testets start, slut och tidszon.
• Testflöde: Käll-IP, destinations-IP eller FQDN, port, användare eller VPN-peer.
• Verktyg: Device Console, Advanced Shell, Log Viewer eller Packet Capture.
• Kommando eller filter: Kört kommando, sökterm som användes med grep eller fångstfilter.
• Resultat: Träff, felmeddelande, saknad loggpost, synligt paket eller paket som inte syns.
• Fortsatt bedömning: Till exempel regelproblem, DNS-problem, returväg, tjänstfel eller supportärende.

Innan utdata lämnas till supporten, Avanet eller externa partner bör man kontrollera om de innehåller känsliga uppgifter: publika IP-adresser, interna värdnamn, användarnamn, VPN-parametrar, serienummer, token, e-postadresser eller kundbeteckningar. Vid en teknisk analys behöver uppgifterna inte spridas mer än nödvändigt; det viktiga är det minsta utdrag som styrker resultatet.

Före det första kommandot

CLI-felsökning blir betydligt mer tillförlitlig om ramarna är fastställda före det första kommandot. Annars uppstår snabbt loggutdrag utan tidsreferens, alltför breda fångster eller debugloggar som senare inte kan kopplas tydligt till ett test.

Före CLI-tester i produktion bör man dokumentera:

• Tidpunkt för problemet: Loggarna kan sökas igenom specifikt för testintervallet.
• Käll-IP, destinations-IP och port: grep, tcpdump och Packet Capture förblir snäva och läsbara.
• Berörd användare eller peer: Autentisering, VPN och User Matching kan kopplas samman lättare.
• Förväntad modul: Sök först i rätt loggfil i stället för i alla loggar.
• Planerad åtgärd: Debug, tjänstekontroll eller fångst blir inte oavsiktligt ett permanent tillstånd.
• Återställnings- eller avbrottskriterium: Testet avslutas vid hög belastning, fullt lagringsutrymme eller bieffekter.
• Aktuell säkerhetskopia vid ändringsarbete: Tjänsteomstarter eller konfigurationsändringar kan säkras på ett kontrollerat sätt.

Det första steget bör om möjligt vara skrivskyddat: kontrollera Log Viewer, granska rätt loggfil, läs service -S eller starta en snäv fångst. Omstarter, debugläge och breda fångster hör först därefter hemma i ett planerat testfönster.

I HA-kluster måste det dessutom vara tydligt vilken enhet som för närvarande är aktiv. Loggar, debug och fångster måste kontrolleras på den nod som den aktuella trafiken faktiskt passerar.

Device Console eller Advanced Shell?

Sophos Firewall har två olika konsolområden. Många fel uppstår eftersom ett kommando matas in i fel område.

Områdena har olika uppgifter:

• Device Console: Sophos CLI för nätverks-, system- och diagnostikkommandon. Typiska kommandon är ping, dnslookup, traceroute, tcpdump, drop-packet-capture och show.
• Advanced Shell: Linux-liknande skal för filer, loggar, processer och tjänstekontroller. Typiska kommandon är nslookup, cd /log, tail -f, grep, less, df -kh, service -S och conntrack.

Efter inloggning via SSH visar brandväggen först konsolmenyn. För Device Console väljer man normalt 4. Device Console. För Advanced Shell använder man 5. Device Management > 3. Advanced Shell.

DNS-testet visar skillnaden särskilt tydligt. Kommandona kan inte användas omväxlande:

Device Console:

dnslookup host example.com

Advanced Shell:

nslookup example.com

Det här meddelandet är inte ett DNS-testresultat. Om /bin/sh: dnslookup: not found visas i Advanced Shell är dnslookup inte tillgängligt där. Använd i stället nslookup; dess utdata visar sedan om DNS-namnupplösningen fungerar.

Den officiella Sophos CLI-hjälpen stöder Tab och ? för syntaxkontroll. Det är användbart i Device Console eftersom kommandona inte alltid har samma struktur.

Särskilt i Device Console bör man inte köra ett halvfärdigt eller gissat kommando. Sophos varnar för att ett ofullständigt kommando kan blockera access_server. Visa därför först syntaxen med Tab eller ? och kör därefter medvetet det fullständiga kommandot.

Direkta konfigurationsändringar i Advanced Shell är inte beständiga och tas inte med i säkerhetskopior. Därför används Advanced Shell i den här guiden endast för diagnostikkommandon.

Ett särskilt nödkommando är system appliance_access enable. Det åsidosätter Device Access-konfigurationen och tillåter åtkomst till alla lokala brandväggstjänster, inklusive äldre tjänster som Telnet. Viktigt: så länge läget är aktivt vidarebefordrar brandväggen inte utgående trafik till internet. Det här är inte ett normalt felsökningssteg utan endast avsett för kortvariga nödsituationer. Kontrollera status före aktiveringen:

system appliance_access show

Efter testet ska nödläget avaktiveras och status kontrolleras igen:

system appliance_access disable
system appliance_access show

Om ett kommando inte känns igen bör man först kontrollera konsolområdet. Det är mer sannolikt att kommandot körs i fel område än att kommandot i sig är trasigt.

Kontrollera loggar i Advanced Shell

De viktigaste loggfilerna finns under /log. För en första överblick byter man till katalogen och listar filerna.

cd /log
ls -lah

Användbara grundkommandon:

• Följ en logg i realtid: tail -f /log/strongswan.log. Lämpligt för reproducerbara VPN-fel.
• Läs en loggfil: less /log/ips.log. I less kan man söka med /sökterm.
• Sök efter fel: grep -i "error" /log/ips.log. -i ignorerar skillnaden mellan stora och små bokstäver.
• Visa träffar med radnummer: grep -n "192.0.2.10" /log/firewall_rule.log. Praktiskt för längre filer.
• Visa de senaste raderna: tail -n 100 /log/syslog.log. Ger en snabb överblick utan realtidsläge.

Vilken loggfil som hör till vilken modul sammanfattas i Sophos Firewall-felsökning: tjänster och loggar.

Vid realtidsloggning bör testperioden hållas kort och tiden antecknas. Det är särskilt viktigt om ett loggarkiv senare ska lämnas till Sophos Support eller Avanet.

Device Console för snabba nätverkskontroller

Device Console lämpar sig för snabba tester ur brandväggens perspektiv. Där går det att kontrollera om DNS, routning eller nåbarhet fungerar i grunden.

Snabba kontroller:

• Nå en värd: ping 192.0.2.10 count 4 kontrollerar ICMP-nåbarhet.
• Kontrollera DNS i Device Console: dnslookup host example.com kontrollerar namnuppslagning ur brandväggens perspektiv.
• Kontrollera vägen: traceroute 192.0.2.10 visar vägen till målet.
• Visa gränssnittsstatus: show interfaces visar information om gränssnitten.
• Starta fångst av kasserade paket: drop-packet-capture 'host 192.0.2.10' visar paket som kasseras av brandväggsregler.
• Starta en paketfångst: tcpdump 'host 192.0.2.10 and port 443' kontrollerar om paketen är synliga på brandväggen.

För IPv6 finns motsvarande kommandon ping6, dnslookup6 och traceroute6.

drop-packet-capture är särskilt användbart när det är oklart om brandväggen aktivt kasserar paket. Det ersätter dock inte en applikationsanalys. Om en server svarar men applikationen ändå inte fungerar behövs även Log Viewer, NAT-kontroll, Packet Capture eller applikationsloggar.

För längre paketfångster och PCAP-filer passar den särskilda artikeln Sophos Firewall: samla in loggar med TCPDump för analys bättre. Där bör man även planera hur stor filen får bli, var den ska lagras och hur den ska överföras säkert.

Kontrollera anslutningar och paketflöde i Advanced Shell

Om Log Viewer och Device Console ännu inte ger ett tydligt svar kan några Advanced Shell-kommandon hjälpa till att bedöma paketflödet.

Kontrollera anslutningar

Innan Advanced Shell-verktyg används ska flödet filtreras under Current activities > Live connections och Diagnostics > Connection list. Dessa dokumenterade WebAdmin-vyer visar Rule ID, NAT ID, gränssnitt, användare, gateway och översatta adresser utan att ändra sessionen.

I Device Console är system diagnostics utilities connections ett officiellt dokumenterat diagnostikverktyg för anslutningar. Kontrollera tillgängliga alternativ och utdata i förväg med ?.

conntrack är ett supportnära verktyg i Advanced Shell och visar aktiva anslutningar som brandväggens tillståndsbaserade flöde känner till. Den exakta tillgängligheten kan bero på firmwareversionen.

conntrack -L | grep "192.0.2.10"

En saknad träff är bara en indikation, eftersom tidpunkt, filterriktning eller FastPath kan påverka synligheten. Jämför därför resultatet med Log Viewer och Packet Capture. Om det finns en post men applikationen inte fungerar måste man dessutom kontrollera om svarspaketen kommer tillbaka och om NAT, policy eller applikation fungerar korrekt.

tcpdump i Advanced Shell

För snabba realtidskontroller kan tcpdump även användas i Advanced Shell.

tcpdump -i any -nn host 192.0.2.10

Vid analyser i produktion bör filtret vara så snävt som möjligt. Breda fångster som tcpdump -i any utan värd, port eller paketgräns ger snabbt mycket utdata och är opraktiska på hårt belastade brandväggar.

En säker utgångspunkt är en kort fångst med värd, port och paketgräns:

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

Om mer data behövs bör lagringsutrymmet först kontrolleras och en plats för PCAP-filen väljas medvetet.

Kontrollera lagringsutrymme och systemstatus

Före debugloggning, stora loggarkiv eller längre paketfångster bör det lediga lagringsutrymmet kontrolleras.

Device Console erbjuder följande skrivskyddade och officiellt dokumenterade systemkontroller:

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

För en kompletterande kontroll i Advanced Shell finns följande verktyg. Tillgängligheten kan bero på firmwareversionen:

df -kh
df -h /var

Fler snabba kontroller:

uptime
top
service -S
service -S | grep strongswan

service -S visar status för många tjänster. Enskilda tjänstenamn är inte alltid självförklarande. Därför bör tjänsten jämföras med rätt loggfil innan en omstart genomförs eller debug aktiveras.

Om lagringsutrymmet redan är begränsat bör ingen debugloggning eller längre paketfångst startas. Fastställ först vilka loggar eller rapporter som kan säkerhetskopieras och rensas på ett säkert sätt.

Aktivera debugloggning specifikt

Debugloggning kan hjälpa vid komplexa fel, men bör bara vara aktiv under en kort tid och endast för den berörda tjänsten. Debug genererar betydligt mer loggdata och kan förbruka lagringsutrymme om det körs länge.

För en tydligt kontrollerad aktivering och avaktivering använder man ett delsystem som stöds i Device Console. Visa först de tillgängliga namnen med system diagnostics subsystems ?. Sophos dokumenterar exempelvis följande förlopp för Pktcapd:

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

I Advanced Shell dokumenterar Sophos dessutom följande IPS-debugkommando:

service ips:debug -ds nosync

För den här Advanced Shell-varianten finns inget separat kommando med tillägget off dokumenterat. Den bör därför endast användas när Sophos Support har bekräftat den exakta återställningen för den installerade buildversionen.

Bilden visar hur samma kommando i SFOS 20.0.1 växlar IPS-debugläget och hur service -S | grep ips bekräftar status före och efter testet. I aktuella versioner bör man inte utgå från den här växlingsfunktionen utan att kontrollera den.

För tjänsteomstarter och för att förstå tjänsternas funktion passar även Starta om tjänster i Sophos Firewall. Vid supportärenden bör den exakta tidsperioden för debugloggen dokumenteras.

Före en tjänsteomstart bör man kontrollera vilken funktion som påverkas och om produktionstrafik för närvarande använder den. En omstart av VPN-, IPS-, webb- eller autentiseringstjänster kan påverka aktiva sessioner eller användarinloggningar.

Tillhandahåll loggar på ett säkert sätt

Enskilda loggutdrag räcker ofta inte vid komplexa ärenden. För Sophos Support, Avanet eller en extern analys är ett fullständigt loggarkiv oftast mer användbart.

I stället för att skriva FTP-inloggningsuppgifter i kommandon bör loggar överföras via en säker och spårbar metod, exempelvis med scp till en egen server eller via en supportportal. Rätt tillvägagångssätt finns i Spara Sophos Firewall-loggar för support och analys.

Loggfiler kan innehålla känsliga uppgifter: interna och publika IP-adresser, värdnamn, användarnamn, VPN-parametrar och felmeddelanden. Före överföringen måste det vara tydligt vem som tar emot uppgifterna och hur länge de lagras.

Vanliga fel vid CLI-felsökning

• Kommandot körs i fel konsolområde: Device Console och Advanced Shell stöder olika syntax. Kontrollera området först.
• Debug lämnas aktivt efter analysen: Loggarna växer i onödan och kan förbruka lagringsutrymme. Avaktivera debug direkt efter testet.
• Brett tcpdump utan filter: Mycket utdata, hög belastning och svårtolkade data. Begränsa efter värd, port, gränssnitt eller paketantal.
• FTP-inloggningsuppgifter i skalhistoriken: Inloggningsuppgifter kan hamna i loggar, skärmbilder eller historik. Använd säker överföring och tillfälliga inloggningsuppgifter.
• Endast en loggfil kontrolleras: Många problem berör flera moduler. Kombinera Log Viewer, rätt tjänsteloggar och Packet Capture.
• Tidpunkten dokumenteras inte: Supporten måste söka igenom onödigt stora loggintervall. Anteckna tid, teståtgärd och berörda IP-adresser.
• Ingen rensning efter testet: Debug, tillfälliga filer eller breda åtkomster förblir aktiva. Avaktivera debug, kontrollera filerna och ta bort tillfälliga SSH-behörigheter.

Checklista

• SSH-åtkomst endast tillåten från betrodda administrationsnät.
• SSH-fingeravtryck och åtkomst med admin kontrollerade före analysen.
• Rätt konsolområde valt: Device Console eller Advanced Shell.
• Tidpunkt för problemet, käll-IP, destinations-IP, port och användare dokumenterade.
• CLI-resultat dokumenterat med tidsintervall, kommando, filter och resultat.
• Skrivskyddade kommandon använda innan debug, tjänsteomstarter eller längre fångster startades.
• Log Viewer kontrollerad först.
• Rätt loggfil identifierad under /log.
• tail, grep eller less använt med en snäv sökterm.
• Vid nätverksproblem har dnslookup använts i Device Console eller nslookup i Advanced Shell, tillsammans med ping, traceroute, drop-packet-capture eller tcpdump efter behov.
• Debug endast aktiverat kortvarigt och avaktiverat med det dokumenterade off-kommandot för det valda delsystemet.
• Lagringsutrymme kontrollerat före debug eller PCAP.
• Loggarkiv överfört säkert och tillfälliga filer borttagna.
• Tillfälliga undantag för Device Access eller SSH borttagna efter supportärendet.

FAQ