Sophos Firewall CLI Felsökning: viktiga kommandon

Vid felsökning av Sophos Firewall räcker Log Viewer ofta för initial isolering. Så fort en tjänst inte startar smidigt, VPN-anslutningar är instabila, enskilda paket kommer inte fram eller support behöver detaljerad data, blir CLI viktig.

Den här översikten visar de viktigaste kommandona för vardagen: var de ska utföras, vad de visar och när det är bättre att byta till en specialiserad artikel. För säker åtkomst via SSH bör Anslut Sophos Firewall via SSH först kontrolleras. Offentliga nycklar, värdnyckelkontroller och strikt godkännande av enhetsåtkomst är viktigare än en snabb inloggning var som helst.

⚠️ Viktigt: CLI- och Advanced Shell-kommandon bör endast köras från betrodda administratörsnätverk och med ett tydligt mål. I synnerhet kan debug, tcpdump, filoperationer och tjänstkommandon påverka lagringsutrymme, prestanda eller körande anslutningar.

Först WebAdmin, sedan CLI

CLI är inte alltid det snabbaste sättet att komma igång. När det kommer till regelmatchning, NAT eller individuella anslutningar, ger Log Viewer, Policy Test och Packet Capture i WebAdmin ofta ett rent resultat snabbare.

Bra introduktioner:

• Vilken brandväggsregel gäller? Använd först Log Viewer, Policy Test och Packet Capture. CLI blir bara nödvändigt när Log Viewer visar för få detaljer eller liveloggar krävs.
• Kommer paket till brandväggen? Använd först Packet Capture i WebAdmin. CLI är användbart när en tight capture- eller PCAP-fil behövs för support.
• Har en tjänst problem? Kontrollera först instrumentpanelen, Log Viewer och serviceloggarna. CLI blir viktigt när tjänststatus, felsökning eller loggfiler måste kontrolleras direkt.
• Blev något ändrat? Kontrollera först Audit Trail Logs. CLI hjälper då när man jämför en konfigurationsskillnad med loggar eller säkerhetskopior.

Målet är inte att hoppa in i Advanced Shell så snabbt som möjligt. Det är bättre att ha en begriplig process: först kontrollera synliga händelser, öppna sedan lämplig loggfil eller fånga.

Dokumentera CLI-resultat på ett användbart sätt

CLI-utgång är bara användbar om det senare framgår vilket test den tillhör. Individuella kopierade felmeddelanden utan tidsfönster, IP-adresser eller påverkad funktion leder ofta till frågor och dubbelanalys.

En kort notering per test räcker vanligtvis:

• Tidsfönster: Testets start, slut och tidszon.
• Testflöde: Källa IP, Destination IP eller FQDN, Port, User eller VPN peer.
• Verktyg: Device Console, Advanced Shell, Log Viewer eller Packet Capture.
• Kommando eller filter: kommandot kört, grep sökterm eller fångstfilter används.
• Resultat: Träff, felmeddelande, saknad loggpost, paketet synligt eller paketet inte synligt.
• Nästa slutsats: till exempel regelproblem, DNS-problem, retursökväg, servicefel eller supportärende.

Innan du delar med support, Avanet eller externa partners, kontrollera om utdata innehåller känsliga data: offentliga IP-adresser, interna värdnamn, användarnamn, VPN-parametrar, serienummer, tokens, e-postadresser eller kundidentifierare. För en teknisk analys behöver data inte distribueras godtyckligt brett; Det som är viktigt är det minsta avsnittet som bevisar fyndet.

Före det första kommandot

CLI-felsökning blir mycket mer tillförlitlig om ramen fixeras före det första kommandot. Annars uppstår snabbt loggutdrag utan någon referens till tid, fångar som är för breda eller felsökningsloggar som ingen tydligt kan tilldela senare. Innan produktiv CLI-testning bör du notera:

• Problemtid: Loggar kan sökas specifikt för testfönstret.
• Källa IP, Destination IP och port: grep, tcpdump och Packet Capture förblir smala och läsbara.
• ** Berörd användare eller peer:** Autentisering, VPN och användarmatchning är bättre att tillskriva.
• Förväntad modul: Du söker först i lämplig loggfil istället för alla loggar.
• Planerad åtgärd: Felsökning, servicekontroll eller fångst blir inte av misstag permanent.
• Återställnings- eller avslutningskriterier: Testet avslutas vid belastning, fullt minne eller biverkningar.
• Aktuell säkerhetskopiering för ändringsarbete: Tjänsten startar om eller konfigurationsändringar kan säkerhetskopieras på ett renare sätt. Det första steget bör vara att läsa om möjligt: ​​kontrollera Log Viewer, visa lämplig loggfil, läs service -S eller starta en närbild. Omstarter, felsökningsläge och omfattande inspelningar hör bara hemma i ett medvetet testfönster efteråt.

För HA-kluster bör det också framgå vilken apparat som för närvarande är aktiv. Loggar, debug och fångar måste kontrolleras på den nod som den relevanta trafiken faktiskt går igenom.

Device Console eller Advanced Shell?

Sophos Firewall har två olika konsolområden. Många fel uppstår på grund av att ett kommando har skrivits in i fel område.

Områdena har olika uppgifter:

• Device Console: Sophos CLI för nätverk, system och diagnostiska kommandon. Typiska kommandon är ping, dnslookup, traceroute, tcpdump, drop-packet-capture och show.
• Advanced Shell: Linux-liknande skal för filer, loggar, processer och servicekontroller. Typiska kommandon är 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 du vanligtvis 4. Device Console. För Advanced Shell använd 5. Device Management > Advanced Shell.

Den officiella Sophos CLI-hjälpen stöder Tab och ? för syntaxkontroll. Detta är användbart i Device Console eftersom inte alla kommandon är strukturerade på samma sätt.

Särskilt i Device Console bör kommandon inte köras halvt gissade. Sophos påpekar att ofullständiga kommandon kan ha bieffekter. Visa därför först syntaxen och kör sedan det fullständiga kommandot medvetet.

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 detta läge är aktivt slutar brandväggen att vidarebefordra utgående trafik till internet. Detta är inte ett normalt felsökningssteg, utan endast avsett för korta nödsituationer. När åtkomsten har återställts måste tillståndet återställas:

system appliance_access disable

Om ett kommando inte känns igen, kontrollera först konsolområdet. Ett fel intervall är mer sannolikt än ett omedelbart brutet kommando.

Kontrollera loggar i Advanced Shell

De viktigaste loggfilerna finns under /log. För initial orientering, byt till den här katalogen och lista filerna.

cd /log
ls -lah

• Spårlogg live: tail -f /log/strongswan.log. Bra för reproducerbara VPN-fel.
• Läs loggfil: less /log/ips.log. Inom less kan du söka med /Suchbegriff.
• Kontrollera efter fel: grep -i "error" /log/ips.log. -i är skiftlägesokänslig.
• Träffa med radnummer: grep -n "192.0.2.10" /log/firewall_rule.log. Användbar för längre filer.
• Visa sista raderna: tail -n 100 /log/syslog.log. Snabböversikt utan liveläge.

Vilken loggfil som hör till vilken modul sammanfattas i Sophos Firewall Felsökning: Services och loggar.

Med liveloggar bör du hålla testperioden kort och notera tiden. Detta är särskilt viktigt om ett loggarkiv senare ges till Sophos Support eller Avanet.

Device Console för snabba nätverkskontroller

Device Console är lämplig för snabba tester ur ett brandväggsperspektiv. Detta låter dig kontrollera om DNS, routing eller tillgänglighet i princip fungerar.

Snabbkontroller:

• Reach-värd: ping 192.0.2.10 count 4 kontrollerar ICMP-tillgänglighet.
• Kontrollera DNS: dnslookup example.com kontrollerar namnupplösning ur brandväggens perspektiv.
• Kontrollera rutt: traceroute 192.0.2.10 visar sökvägen till destinationen.
• Visa gränssnittsstatus: show interfaces visar gränssnittsinformation.
• Starta Drop Capture: drop-packet-capture 'host 192.0.2.10' visar paket som släpps av brandväggsregler.
• Starta paketinsamling: tcpdump 'host 192.0.2.10 and port 443' kontrollerar om paket är synliga på brandväggen. drop-packet-capture är särskilt användbart när det är oklart om brandväggen aktivt släpper paket. Den ersätter dock inte applikationsanalys. Om en server svarar men applikationen fortfarande inte fungerar behöver den också Log Viewer, NAT-kontroll, Packet Capture eller applikationsloggar.

För längre paketinspelningar och PCAP-filer är den separata artikeln Sophos Firewall: Samla loggar med TCPDump för analys mer lämplig. Du bör också planera hur stor filen kan vara, 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 inte ger ett tydligt svar, kommer några avancerade skalkommandon att hjälpa dig att förstå paketflödet.

Conntrack

conntrack visar aktiva anslutningar som den stateful brandväggssökvägen känner till. Detta är användbart om du vill kontrollera om en anslutning ens visas i anslutningsspårning.

conntrack -L | grep "192.0.2.10"

Om en post saknas kan det indikera routing, NAT, felaktig källa, saknad brandväggsregel eller testning på fel väg. Om det finns en post men applikationen inte fungerar måste en extra kontroll göras för att se om svarspaket returneras och om NAT, policy eller applikation fungerar korrekt.

tcpdump i Advanced Shell

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

tcpdump -i any -nn host 192.0.2.10

För produktiva analyser bör filtret vara så smalt som möjligt. Breda inspelningar som tcpdump -i any utan värd, port eller antal producerar snabbt mycket utdata och är opraktiska på upptagna brandväggar.

En säker start är en kort inspelning med värd-, port- och paketgräns:

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

If more data is required, storage space should be checked beforehand and a PCAP storage location should be deliberately chosen.

Kontrollera lagringsutrymme och systemtillstånd

Before debug logging, large log archives or longer packet recordings, the free storage space should be checked.

df -kh
df -h /var

Andra snabba kontroller:

uptime
top
service -S
service -S | grep strongswan

service -S visar status för många tjänster. Individuella tjänstnamn är inte alltid självförklarande. Du bör därför jämföra tjänsten med lämplig loggfil innan du aktiverar omstarter eller felsöker.

Om lagringsutrymmet redan är begränsat bör felsökningsloggning och långpaketinspelning inte startas. Förklara först vilka loggar eller rapporter som säkert kan säkerhetskopieras och rensas upp.

Aktivera felsökningsloggen specifikt

Felsökningsloggning kan hjälpa till med komplexa fel, men bör endast vara aktiv under en kort tid och endast för den berörda tjänsten. Debug genererar betydligt mer loggdata och kan konsumera lagringsutrymme om det körs under en längre tid.

Exempel för IPS-felsökning:

service ips:debug -ds nosync

Återskapa problemet, notera den relevanta tiden och avaktivera sedan felsökningen igen:

service ips:debug -ds nosync off

Innan du startar om en tjänst bör du kontrollera vilken funktion som påverkas och om produktiv trafik för närvarande körs genom den. Omstart av VPN, IPS, webb eller autentiseringstjänster kan påverka aktiva sessioner eller användarinloggningar.

Leverera loggar säkert

Individuella loggutdrag räcker ofta inte för komplexa fall. För Sophos Support, Avanet eller extern analys är ett komplett loggarkiv oftast mer användbart. Istället för att skriva in FTP-åtkomstdata i kommandon bör du överföra loggar via ett säkert och spårbart sätt, till exempel via scp till din egen server eller via en supportportal. Lämpliga instruktioner finns på Sophos Firewall Säkerhetskopiera loggar för support och analys.

Loggfiler kan innehålla känslig information: interna IP-adresser, offentliga IP-adresser, värdnamn, användarnamn, VPN-parametrar och felmeddelanden. Innan du delar den bör det vara klart vem som kommer att ta emot data och hur länge den kommer att lagras.

Typiska CLI-felsökningsfel

• Kommando i fel konsolområde: Device Console och Advanced Shell stöder olika syntax. Kontrollera området först.
• Låt felsökningen vara aktiv efter analys: Loggar växer i onödan och kan konsumera lagringsutrymme. Inaktivera debug igen omedelbart.
• Bred tcpdump utan filter: Mycket output, hög belastning och data som är svår att utvärdera. Begränsa värd, port, gränssnitt eller antal.
• FTP-uppgifter i skalhistoriken: Inloggningsuppgifter kan hamna i loggar, skärmdumpar eller historik. Använd säker överföring och tillfälliga referenser.
• Kontrollera endast en loggfil: Många problem påverkar flera moduler. Kombinera Log Viewer, matchande serviceloggar och Packet Capture.
• Dokumentera inte tiden: Support måste söka i onödigt stora stockområden. Notera tiden, teståtgärden och IP-adresserna.
• Rengör inte efter testning: Felsökning, temporära filer eller breda åtkomster förblir aktiva. Stäng av felsökning, kontrollera filer och ta bort tillfälliga SSH-resurser.

Checklista

• SSH-åtkomst tillåts endast från betrodda administratörsnätverk.
• SSH-fingeravtryck och admin-åtkomst kontrolleras före analys.
• Korrekt konsolområde valt: Device Console eller Advanced Shell.
• Problemtid, källa IP, destination IP, port och användardokumenterad.
• CLI-fynd dokumenterade med tidsfönster, kommando, filter och resultat.
• Läs kommandon som användes först innan felsökning, omstart av tjänsten eller längre infångningar startades.
• Log Viewer kontrolleras först.
• Matchande loggfil identifierad under /log.
• tail, grep eller less används med en smal sökterm.
• Används specifikt för nätverksproblem ping, dnslookup, traceroute, drop-packet-capture eller tcpdump.
• Debug aktiverades endast kort och avaktiverades igen.
• Diskutrymme kontrolleras före felsökning eller PCAP.
• Överför säkert loggarkiv och ta bort temporära filer.
• Tillfällig enhetsåtkomst eller SSH-undantag togs bort efter supportärende.

Vanliga frågor