Använda Sophos Firewall Packet Capture i WebAdmin

Packet Capture är ett av de viktigaste felsökningsverktygen i WebAdmin för Sophos Firewall. Det visar om paket anländer till ett gränssnitt, om de vidarebefordras, vilken regel eller NAT-ID som är inblandad och om ett paket släpps.

Log Viewer visar brandväggens beslut. Packet Capture visar paketflödet. Tillsammans är de ofta det snabbaste sättet att hitta orsaken. Om en brandväggsregel ska testas specifikt, passar dessutom processen i Testa Sophos Firewall-regel med Log Viewer, Policy tester och Packet Capture.

Det är viktigt att placera detta i rätt sammanhang: Denna artikel beskriver WebAdmin-versionen av Packet Capture. För en första kontroll är den idealisk eftersom man direkt i webbläsaren kan se om paket anländer, vidarebefordras eller släpps. För längre inspelningar, mycket exakta filter, PCAP-export eller supportärenden är en tcpdump via SSH ofta bättre lämpad.

Val av verktyg

Vilken artikel passar?

Packet Capture är särskilt stark när det verkliga paketflödet är oklart. För relaterade frågor kan en annan ingång vara snabbare:

Denna uppdelning är viktig: Packet Capture visar paket och status på paketnivå. Det ersätter dock inte Log Viewer för policybeslut, inte NAT-artikeln för översättningslogik och inte tcpdump när en analyserbar PCAP-fil behövs.

När Packet Capture är meningsfullt

Packet Capture hjälper särskilt med frågor som:

• Kommer trafiken överhuvudtaget till brandväggen?
• Går trafiken ut på det förväntade gränssnittet?
• Matchar en brandväggsregel?
• Matchar en NAT-regel?
• Släpps ett paket av policy, IPS eller routing?
• Kommer ett svar från målsystemet tillbaka?
• Används en annan port eller ett annat protokoll än förväntat?

Om inget är synligt i Log Viewer är Packet Capture ofta nästa steg. Då ser man om problemet ligger före brandväggen eller om brandväggen hanterar trafiken.

Om fokus ligger på drops, Violation, Rule ID, NAT ID eller släppta paket, passar dessutom Analysera släppta paket på Sophos Firewall.

Menyväg

Verktyget finns under:

Diagnostics > Packet capture

Packet Capture öppnas direkt i WebAdmin. Beroende på SFOS-version och webbläsarvy kan det verka som ett eget diagnosfönster inom WebAdmin-vyn.

Innan du öppnar det bör testfallet redan vara fastställt. Verktyget är som starkast när man reproducerar ett enskilt flöde och inte först under inspelningen funderar på vad man letar efter.

Efter att ha öppnat bör du först använda Configure och sätta Capture-filtret innan testet utlöses. Om destination, CDN-mål eller NAT-syn fortfarande är oklara är ett första filter på Source IP ofta bättre än ett för snävt filter med fel mål-IP. Efter det reproducerade testet bör inspelningen stoppas igen så att vyn inte fylls med bakgrundstrafik.

Log Viewer, Packet Capture eller tcpdump?

Log Viewer, Packet Capture i WebAdmin och tcpdump besvarar olika frågor. Den som väljer fel verktyg först söker ofta på fel plats.

Ett bra exempel är en ping. I Log Viewer ser man ofta bara en post eller ett sammanfattat beslut om anslutningen. I Packet Capture ser man däremot de enskilda ICMP-paketen: Echo Request till målet och Echo Reply tillbaka. Windows skickar med ping som standard fyra ICMP Echo Requests. I Packet Capture förväntar man sig därför flera fram- och återpaket. Om bara Requests är synliga men inga Replies kommer tillbaka är det ett annat problem än om ingen Request når brandväggen.

För praktiken innebär det:

• Log Viewer svarar: Vilken regel eller vilket modul beslutade?
• Packet Capture svarar: Kom paketen verkligen fram och vilken väg tog de?
• Vid routing-, NAT-, VLAN-, gateway- eller returvägsproblem är Packet Capture ofta mer talande.
• Vid webfilter-, Application Control-, IPS- eller SSL/TLS-inspektionsbeslut behöver man dessutom Log Viewer.
• För inspelningar som går till Sophos Support eller externa analysparter är tcpdump oftast bättre än en skärmdump från WebAdmin.

Förbered Capture

Avgränsa noggrant innan start

Packet Capture bör inte startas ofiltrerat. I produktionsnätverk genereras annars mycket data och utmatningen blir oöverskådlig.

⚠️ Packet Capture bör aldrig köras som en bred kontinuerlig inspelning på produktionsbrandväggar. Ett snävt filter, ett kort test och en tydlig tidpunkt minskar datamängden, dataskyddsrisken och feltolkningar.

I förväg bör du notera:

• Source IP
• Destination IP eller FQDN
• Protokoll
• Source Port, om relevant
• Destination Port
• Gränssnitt eller zon
• Testtid
• Berörd applikation
• Förväntad brandväggsregel eller NAT-regel, om känd
• Förväntat resultat: tillåtet, blockerat, DNAT, SNAT, VPN, webpolicy eller IPS

För ett webbtest kan avgränsningen till exempel se ut så här:

I praktiken bör man alltid bara reproducera ett testfall åt gången. Flera parallella ändringar av brandväggsregel, NAT, routing och klientkonfiguration gör Capture-utmatningen svår att utvärdera. Om testet gäller ett användarproblem bör du dessutom notera den inloggade användaren, den berörda enheten och den exakta tiden.

Konfigurera Capture-filter

Via Configure sätter man ett så snävt filter som möjligt.

Typiska filter:

• Source IP för klienten
• Destination IP för servern
• Destination Port
• Protokoll TCP, UDP eller ICMP
• Gränssnitt

Om du inte känner till målservern kan du först bara filtrera efter Source IP. Om för många paket är synliga efter det, begränsa ytterligare.

Sophos Firewall använder Berkeley Packet Filter Syntax, kort BPF. Capture-filtret bestämmer vilka paket som överhuvudtaget skrivs till Capture-bufferten. Det bör därför sättas så noggrant som möjligt innan testet.

Typiska BPF-exempel:

För ett mycket riktat webbtest kan ett filter till exempel se ut så här:

host 172.16.10.25 and host 93.184.216.34 and port 443

För ett ping-test räcker ofta:

host 172.16.10.25 and proto ICMP

Om filtret är för snävt

Ett snävt Capture-filter är viktigt, men det får inte dölja felet. Särskilt vid DNS, NAT, CDN och returvägar bör man medvetet besluta om man först filtrerar brett nog eller omedelbart mycket precist.

Typiska fallgropar:

För den första körningen är ett filter på Source IP ofta mer meningsfullt än ett för precist filter med fel mål-IP. När det relevanta flödet är synligt kan man i andra körningen filtrera snävare. Vid NAT-fel bör man dessutom kontrollera om man just nu betraktar synen före eller efter översättningen.

I WebAdmin-vyn ser man efter att ha sparat den aktiva BPF-strängen ovanför paketlistan. Den första skärmdumpen visar filterkonfigurationen, den andra skärmdumpen resultatlistan med aktivt filter.

⚠️ PCAP-data kan innehålla IP-adresser, värdnamn, protokolldetaljer och beroende på protokoll även nyttolast. Inspelningar bör endast delas med personer eller partners som får se dessa data.

Kör Capture

Starta och reproducera Capture

1. Sätt filter.
2. Slå på Packet Capture med skjutreglaget.
3. Reproducera problemet.
4. Stoppa Capture igen.
5. Analysera resultaten.
6. Töm Capture om ett nytt test startas.

Sophos Firewall visar status och buffert:

Om bufferten är full stoppas inspelningen automatiskt. Därefter måste man tömma med Clear innan det är meningsfullt att spela in igen. Därför är ett snävt filter viktigt.

I filterinställningarna kan man dessutom ange hur många byte per paket som ska fångas. För många första analyser räcker header-information. Om man behöver mer nyttolast måste man fånga fler byte, men bör hålla dataskydd och buffertstorlek i åtanke.

Tolka utdata

Förstå viktiga kolumner

Packet Capture visar många fält. För praktiken är dessa särskilt viktiga:

Dessa fält är värdefulla eftersom de fyller gapet mellan “Regeln ser rätt ut” och “Trafiken går verkligen så”.

Via Show additional properties eller detaljvyn ser man beroende på version ytterligare information som Connection ID, Web filter ID, Application ID, Web category ID, Gateway ID, Username eller andra policy-ID. Dessa detaljer hjälper när ett paket inte bara behandlas av en brandväggsregel utan också av Web, Application Control, IPS eller andra moduler.

Tolka status korrekt

Om man bara ser Incoming och inget Forwarded, fastnar paketet troligen på brandväggen. Då bör man kontrollera brandväggsregel, NAT, routing och säkerhetsfunktioner.

Om Forwarded är synligt men inget svar kommer tillbaka ligger problemet ofta hos målsystemet, returvägen, NAT eller en motpart.

Vid en lyckad ping ser man vanligtvis paket i båda riktningarna. Om Windows skickar fyra pings ser man flera ICMP Echo Requests från klienten till målet och flera Echo Replies tillbaka. Om Replies saknas, kontrollera returväg, målsystem, lokal brandvägg på målsystemet, NAT eller en motpart. Om Requests redan saknas, kontrollera klient, gateway, VLAN, switch-port eller om trafiken överhuvudtaget når Sophos Firewall.

Läs Consumed och Generated korrekt

Consumed och Generated tolkas lätt fel. Dessa status betyder inte automatiskt att en vanlig brandväggsregel saknas.

Exempel på Consumed är åtkomst till WebAdmin, User Portal, VPN Portal, SSH, DNS, SNMP, IPsec eller SSL VPN för brandväggen själv. Sådan trafik behandlas inte som vanlig genomgångstrafik genom en LAN-to-WAN- eller WAN-to-DMZ-regel. Om ett paket i Capture visar Consumed bör man därför först klargöra om klienten verkligen ville nå brandväggen själv.

För dessa fall är Administration > Device access och Local Service ACL viktigare än en vanlig brandväggsregel. Härdningen av dessa åtkomster beskrivs i Säkra åtkomst till Sophos Firewall: Konfigurera Device Access korrekt.

Använd Display Filter

Capture-filtret begränsar vilka paket som spelas in. Display filter filtrerar däremot den redan inspelade vyn. Det är praktiskt när man medvetet startat Capture något bredare och sedan bara vill visa vissa paket.

I Display Filter kan man bland annat filtrera efter dessa fält:

• Gränssnittets namn
• Ethernet-typ, till exempel IPv4, IPv6 eller ARP
• Pakettyp
• Source IP och Source port
• Destination IP och Destination port
• Reason
• Status
• Rule ID
• User
• Connection ID

För felsökning är särskilt Status, Reason, Rule ID, Source IP, Destination IP och Destination port hjälpsamma. Om många paket finns i Capture kan man snabbt reducera till den relevanta delen utan att behöva starta om testet omedelbart.

Läs NAT i Packet Capture

Vid NAT måste man beakta att ett paket ser olika ut före och efter NAT. Packet Capture kan göra NAT ID, Rule ID och de ändrade adresserna synliga.

Vid NAT-problem bör man kontrollera:

• Ser man paketet med originaladressen?
• Ser man paketet efter översättningen?
• Visas det förväntade NAT ID?
• Går paketet över det förväntade Out-gränssnittet?
• Kommer ett svar tillbaka?

För DNAT gäller dessutom: Brandväggsregeln använder målzonen efter NAT, men mål-IP före NAT. Det kan först verka ovant.

Mer om detta: Förstå NAT på Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Kombinera Packet Capture och Log Viewer

Det bästa förfarandet är:

1. Öppna Log Viewer.
2. Starta Packet Capture med snävt filter.
3. Reproducera testet.
4. Kontrollera i Packet Capture om paket anländer och går vidare.
5. Kontrollera i Log Viewer vilken regel eller vilket modul som beslutade.
6. Vid behov byta till lämplig loggfil.

Log Viewer visar till exempel brandvägg, web, SSL/TLS-inspektion, IPS eller Application Control-händelser. Packet Capture visar däremot paketflödet på gränssnittsnivå.

Särskilt vid ping eller enkla TCP-anslutningar är kombinationen viktig. Log Viewer kan bara visa att en anslutning tilläts eller blockerades. Packet Capture visar dessutom om svarspaketen kommer tillbaka, om NAT träder i kraft, om rätt Out-gränssnitt används och om returvägen är korrekt.

Typiska analysfall

Klient når inte internet: Sätt Capture på Source IP och TCP 443. Om inget paket anländer, kontrollera klient, VLAN, gateway eller switch. Om paket anländer men inte går ut, kontrollera brandväggsregel, NAT eller routing.

DNAT fungerar inte: Sätt Capture på offentlig mål-IP och extern port. Om inget paket anländer, kontrollera leverantörsrouter, portvidarebefordran, Cloud Security Group eller WAN. Om paket anländer men inte går till intern server, kontrollera DNAT-regel och brandväggsregel.

VPN-trafik fungerar inte: Sätt Capture på tunnelgränssnitt, XFRM-gränssnitt eller relevanta käll-/mål-nätverk. Kontrollera dessutom strongswan.log, charon.log eller xfrmi.log.

Webfilter blockerar oväntat: I Packet Capture ser man oftast bara paketflödet. Beslutet själv kontrolleras bättre i Log Viewer under Web, Application Control eller SSL/TLS-inspektion.

Små tester fungerar, stora överföringar hänger: Sätt Capture på den berörda klienten och målet och var uppmärksam på retransmissions, saknade svar eller märkbara paketstorlekar. Om ping, inloggning eller små HTTP-förfrågningar fungerar men större nedladdningar, RDP, VoIP eller VPN-applikationer hänger, bör man dessutom kontrollera MTU, MSS, PPPoE, VPN-overhead och fragmentering. Förfarandet finns i Kontrollera MTU och MSS på Sophos Firewall vid VPN-problem.

Typiska feltolkningar

Packet Capture visar mycket, men inte alltid det man först förväntar sig. Några feltolkningar är särskilt vanliga i supportärenden.

Om Packet Capture visar ett oväntat Rule ID bör man inte omedelbart ändra flera regler. Bättre är först en jämförelse med Log Viewer och regelposition. För systematisk matchning passar Sophos Firewall-regel matchar inte: Kontrollera orsaker.

Begränsningar, dataskydd och delning

Dataskydd och delning av inspelningar

Packet-Capture-data är driftdata. Även om ofta bara header är synliga kan de avslöja interna IP-adresser, offentliga mål, användarnamn, värdnamn, portar, protokoll och kommunikationsrelationer. Vid okrypterade protokoll kan dessutom nyttolast vara synlig.

Innan delning bör man därför kontrollera:

• Innehåller inspelningen kundnamn, interna värdnamn eller offentliga IP-adresser?
• Är användare, system eller applikationer igenkännbara?
• Är mottagaren behörig att se denna information?
• Räcker en skärmdump av de relevanta raderna eller behövs verkligen en PCAP-fil?
• Måste inspelningen först förkortas eller anonymiseras?

För supportärenden är ofta en riktad tcpdump-inspelning med rent filter bättre än en bred WebAdmin-inspelning. Om dessutom loggfiler behövs, hjälper Säkra Sophos Firewall-loggar för support och analys.

När tcpdump är bättre

WebAdmin Packet Capture är idealiskt för snabba analyser direkt i webbläsaren. Man ser snabbt om paket anländer, vidarebefordras, konsumeras, genereras eller släpps. För en första avgränsning är det oftast rätt start.

tcpdump är bättre när inspelningen inte bara behövs som skärmbild utan som en analyserbar fil eller som en längre teknisk spår.

Den viktigaste skillnaden: tcpdump visar paket, men inga Sophos-specifika beslut. Om man behöver veta vilken brandväggsregel, NAT-regel, webpolicy, IPS-policy eller SSL/TLS-inspektionsregel som var inblandad, behöver man fortfarande Log Viewer, WebAdmin Packet Capture eller den lämpliga loggfilen.

Innan tcpdump bör SSH eller Advanced Shell medvetet aktiveras. Inspelningen bör filtreras snävt, tidsbegränsas och tas bort efter analysen. En bred PCAP på en produktionsbrandvägg kan snabbt innehålla känsliga data och onödigt mycket sidotrafik.

Mer om detta: Sophos Firewall tcpdump: Spela in paket via CLI.

Checklista

• Notera testfall med Source, Destination, Port, Protokoll och tid.
• Känn till förväntad brandväggsregel och NAT-regel, om möjligt.
• Sätt Capture-filter snävt.
• Vid DNS, NAT eller CDN-mål, kontrollera om filtret verkligen fångar både fram- och återriktning.
• Reproducera bara ett testfall åt gången.
• Stoppa Packet Capture efter testet.
• Distingera medvetet mellan Incoming, Forwarded, Consumed, Generated och Violation.
• Jämför Rule ID och NAT ID med Log Viewer.
• Vid saknat svar, kontrollera returväg, NAT, målsystem och motpart.
• Vid hängande stora överföringar, kontrollera MTU/MSS, fragmentering och VPN-overhead.
• Kontrollera inspelningar för känsliga data innan delning.
• Använd tcpdump för längre inspelningar eller PCAP-filer.

FAQ