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.

Utför en fullständig omstart endast som en planerad åtgärd

En fullständig omstart är inte ett diagnostikkommando. Spara först relevanta loggar, systemtid, uptime, HA-roller och det aktuella feltillståndet. Om endast WebAdmin eller en enskild tjänst påverkas ska man kontrollera om en riktad omstart av WebAdmin eller tjänsteomstart räcker.

SFOS 22 dokumenterar följande syntax i Device Console:

system restart [all]

Hakparenteserna är inte en del av kommandot utan markerar det valfria argumentet all. Kontrollera först vilken form den installerade builden erbjuder med system restart ?. Kommandot startar om brandväggen och avbryter sessioner, VPN-tunnlar och administrationsåtkomst. Efter körning finns ingen CLI-rollback, så underhållsfönster, konsolåtkomst och en testad returväg för administration måste vara klara före bekräftelsen.

Enligt Sophos utlöser system restart en failover i ett HA-kluster. Detta garanterar inte oavbrutna anslutningar. Peer, synkronisering, roller och HA-länk måste först vara stabila. Efter omstarten kontrolleras båda noderna, roller, synkronisering, uptime, WAN, routing, DNS, VPN, publicerade tjänster och ett verkligt applikationsflöde. En lyckad boot bevisar inte att den ursprungliga orsaken är löst.

Stäng av endast med en förberedd startväg

För en kontrollerad avstängning används exakt detta kommando i Device Console:

system shutdown

Sophos dokumenterar inga alternativ för kommandot. Lägg därför inte till all, ett nodnamn eller en antagen HA-växel i syntaxen. Före bekräftelsen ska loggar och konfiguration bevaras, beroende team informeras och det ska vara klarlagt hur enheten startas igen via fysisk åtkomst, fjärrhantering eller virtualiseringsplattformen. Shutdown-sidan lämnar ingen garanti om HA-beteende; en klusternod ska därför endast stängas av enligt den avsedda HA-underhållsproceduren och peer ska därefter kontrolleras uttryckligen.

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 med fullständig åtkomst till systemkomponenter. Den här artikeln begränsar användningen till diagnostikkommandon som Sophos dokumenterar: cd /log, tail, grep, less och service -S.

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.

Device Console samlar globala parametrar för paketinspektion, TCP, UDP, WAN-åtkomst och specialvägar under advanced-firewall. Deras effekt och ett säkert ändringsförfarande beskrivs i Kontrollera Advanced Firewall Settings säkert.

DNS-testet visar tydligt varför konsolområdet spelar roll. I Device Console är det officiellt dokumenterade kommandot:

dnslookup host example.com

example.com är ett säkert dokumentationsvärde; byt ut det mot berört FQDN i ett verkligt test. Svaret bekräftar bara namnuppslagning ur brandväggens perspektiv. Vid ett klientfel måste även klientens DNS-server, svar och nätverksväg kontrolleras.

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:

Dokumenterat default är Disable. Med enable accepterar alla portar inkommande anslutningar och den normala nåbarhetsbegränsningen i Device Access försvinner tillfälligt. Autentiseringen i respektive tjänst är fortfarande en separat kontroll, men gör inte denna breda exponering ofarlig.

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. Sophos dokumenterar först byte till den katalogen i Advanced Shell:

cd /log

Användbara grundkommandon:

• Följ en logg i realtid: tail -f ips.log. Låt den löpande utdatan vara öppen endast under det dokumenterade testfönstret.
• Läs en loggfil: less ips.log. Loggraderna visas då i avsnitt.
• Sök efter ett begrepp: grep error ips.log. Anpassa begreppet och filen till felet.

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.

tcpdump och drop-packet-capture fortsätter tills de stoppas med Ctrl+C. Bestäm först filter och testfönster, följ utdatan och stoppa fångsten direkt efteråt. Kommandona ändrar inte konfigurationen, men deras belastning beror på trafikvolym, filtrets bredd och körtid.

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.

Nätverkskontroller i WebAdmin utan CLI

Under Diagnostics > Tools kan samma grundfrågor testas utan konsolåtkomst. Ping låter administratören välja IPv4 eller IPv6, utgående gränssnitt och paketstorlek. Sophos använder 32 byte som standard och tillåter värden från 1 till 65 507 byte. En lyckad ping bekräftar ICMP-nåbarhet från det valda brandväggsgränssnittet, men inte att en applikationstjänst fungerar.

För Ping i SFOS 22 och SFOS 23 kan IP address or hostname innehålla en IPv4-adress, IPv6-adress eller ett FQDN. IP family anger adressfamiljen, Interface det utgående gränssnittet och Size paketstorleken. För ett FQDN krävs dessutom namnuppslagning; för att avgränsa ett DNS-problem bör samma test även jämföras med ett test mot den förväntade IP-adressen.

Ping-utdata visar om svar kommer fram, hur många paket som har skickats och tagits emot, paketförlusten och Round-Trip Time (RTT). RTT är tiden för förfrågan och svar, inte den enkelriktade överföringstiden. Om inget svar kommer visas 100 procent paketförlust. Detta bevisar inte i sig att värden är avstängd: kontrollera destinationsadressen, det valda gränssnittet, routningen och om ICMP är tillåtet, och använd vid behov en snäv Packet Capture. Ett lyckat test måste fortfarande motsvara det faktiska applikationsflödet.

Traceroute accepterar också IPv4, IPv6 eller ett FQDN samt ett medvetet valt utgående gränssnitt. Uteblivna svar från enskilda hopp bevisar inget avbrott om senare hopp eller destinationen svarar. För en vägfråga bedöms därför destinationens nåbarhet, det sista svarande hoppet och det parallellt uppmätta paketflödet tillsammans.

I WebAdmin under Diagnostics > Tools > Traceroute anges destinationen i IP address or hostname, adressfamiljen i IP version och det utgående gränssnittet i Interface; starta förfrågan med Traceroute. För SFOS 22 och SFOS 23 beskriver Sophos utdata med de routrar som passeras, det maximala antalet hopp och paketets totala returtid i millisekunder. Det maximala antalet hopp begränsar sökningen efter vägen; det är inget bevis på att destinationen har nåtts. Tidsvärdena beskriver diagnostiksvaren och bevisar ingen applikationsgenomströmning. I 4. Device Console kompletterar traceroute6 2001:db8::10 IPv4-exemplet ovan; ersätt dokumentationsadressen med den faktiska IPv6-destinationsadressen.

De efterföljande beteckningarna Name lookup och Lookup using all configured servers gäller för SFOS 22. De ändrade beteckningarna DNS lookup och All configured servers i SFOS 23 samt de ytterligare serveralternativen och deras förutsättningar förklaras i Jämför enskilda resolvrar under Diagnostics.

Name lookup frågar en vald DNS-server. Med Lookup using all configured servers kan alla DNS-servrar som är konfigurerade på brandväggen och deras svarstider jämföras. Ett enda snabbt resultat är ännu inget skäl att ändra DNS-prioriteten; även svarsinnehåll, tillförlitlighet och den berörda klientvägen måste stämma.

Route lookup visar via vilket gränssnitt brandväggen skulle routa en IPv4- eller IPv6-destination. Utdata bevisar varken brandväggsregel, NAT, SD-WAN-beslut eller en fungerande returväg. Valideringen fortsätter därför med en verklig anslutning, Connection List eller Packet Capture.

Kontrollera anslutningar utan att ändra deras tillstånd

Filtrera aktuella IPv4- och IPv6-anslutningar under Current activities > Live connections och Diagnostics > Connection list. Connection list visar bland annat inkommande och utgående gränssnitt, källa och destination, Rule ID, NAT ID, översatta adresser, status samt Rx-/Tx-räknare. Det är en bättre första åtgärd än ett odokumenterat Advanced Shell-verktyg.

I Device Console dokumenteras även detta anslutningsverktyg:

system diagnostics utilities connections

Kontrollera tillgängliga argument före körning med system diagnostics utilities connections ?. Eftersom Connection list är en ögonblicksbild ska testflödet reproduceras samtidigt som vyn uppdateras. Om anslutningen fortfarande saknas körs en snäv Packet Capture; om den syns fortsätter analysen med Rule ID, NAT ID, gränssnitt, översättning och svarsräknare.

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

system diagnostics show version-info visar även serienummer och Device ID. Maskera dessa identifierare innan utdata eller skärmbilder delas.

Ytterligare skrivskyddade mål är interrupts, syslog, sysmsg, subsystem-info och ctr-log-lines. De besvarar olika frågor och ska inte behandlas som utbytbara hälsovärden:

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

På XGS Appliances finns även system diagnostics selftest för grundläggande tester av nätverkskortet. Kommandot gäller inte andra plattformar och ersätter inte kabeltest, genomströmningsmätning eller paketinsamling. Eftersom Sophos inte anger påverkan på produktionstrafik på kommandosidan körs självtestet bara som en planerad åtgärd eller på instruktion från support och jämförs med länkstatus, gränssnittsräknare och verklig trafik.

Under system diagnostics utilities samlar SFOS ytterligare verktyg för ARP, bandbredd, anslutningar, DNS, drop capture, nätverkskonfiguration, ping, processer, rutter och traceroute, inklusive IPv6-varianter där Sophos erbjuder dem. Kontrollera den exakta syntaxen på den installerade builden med Tab-komplettering. Vissa verktyg läser bara status, medan andra genererar testtrafik eller startar kontinuerlig utdata.

För en kompletterande skrivskyddad tjänstekontroll dokumenterar Sophos i Advanced Shell:

service -S
service -S | grep ips

Den första varianten visar många tjänstestatusar; den andra använder IPS-exemplet som Sophos dokumenterar. En saknad träff är inte skäl för en omstart: jämför först tjänstenamnet och loggfilen med Sophos aktuella logglista.

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.

Samla bara in debugloggar med en bekräftad returväg

SFOS 22 aktiverar debugläget i Device Console, inte i WebAdmin. För ett kontrollerat test med Sophos dokumenterade Pktcapd-exempel ska ledigt lagringsutrymme och testtid först antecknas. Kör sedan:

system diagnostics subsystems Pktcapd debug on

Reproducera problemet en gång och hämta sedan loggfilen eller en Consolidated Troubleshooting Report (CTR) under Diagnostics > Tools > Troubleshooting logs. Debug ökar loggfilernas storlek och förblir aktivt tills det stängs av. Kör därför den dokumenterade återställningen direkt efter hämtningen:

system diagnostics subsystems Pktcapd debug off

Dokumentera båda kommandona och deras CLI-utdata. Om ett kommando avvisas ska inget annat delsystems- eller tjänstekommando improviseras: kontrollera syntaxen med ? och kontakta Sophos Support. Debug i Advanced Shell utelämnas medvetet, eftersom den generella tjänstesyntaxen inte erbjuder ett universellt avstängningskommando för varje debugläge.

För tjänsteomstarter och deras effekter, se Starta om tjänster i Sophos Firewall. Omstart av VPN-, IPS-, webb- eller autentiseringstjänster kan avbryta aktiva sessioner eller inloggningar.

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 inloggningsuppgifter i skalkommandon hämtas enskilda loggar eller en CTR under Diagnostics > Tools > Troubleshooting logs och lämnas via överenskommen supportportal. Följ Samla in 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, ping, traceroute, drop-packet-capture eller tcpdump använts målinriktat i Device Console.
• Debug aktiverades endast kortvarigt under Diagnostics > Tools > Troubleshooting logs, avaktiverades därefter och normalt tillstånd kontrollerades.
• 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