Använd Sophos Firewall tcpdump säkert

tcpdump är rätt verktyg när man på Sophos Firewall behöver se mer exakt vilka paket som verkligen anländer, vilket gränssnitt de går igenom och om ett problem uppstår före, på eller bakom brandväggen. Det kompletterar Log Viewer, WebAdmin Packet Capture och Service Logs, men ersätter dem inte.

För snabba webbläsaranalyser är det ofta bekvämare att använda Sophos Firewall Packet Capture i WebAdmin. För längre inspelningar, mycket exakta filter, PCAP-filer eller supportärenden är tcpdump via SSH oftast bättre lämpat.

⚠️ Viktigt: Paketfångster kan innehålla känslig data: interna IP-adresser, hostnames, användarnamn, DNS-frågor, certifikatdetaljer eller okrypterad nyttolast. Därför bör de filtreras snävt, endast spelas in så länge som nödvändigt, dokumenteras och endast delas via säkra kanaler. En ofiltrerad inspelning på any kan generera mycket data på produktiva firewalls.

Val av verktyg och förutsättningar

Vilken artikel passar?

tcpdump är inte det första steget för varje analys. Beroende på frågan är en annan startpunkt snabbare:

• Snabbt se i WebAdmin om paket anländer, vidarebefordras eller avvisas: Sophos Firewall Packet Capture i WebAdmin.
• Firewall-regel ska valideras med Log Viewer, Policy tester och Packet Capture: Testa Sophos Firewall-regel korrekt.
• Fokus på Drop, Violation, Rule ID, NAT ID eller Drop Reasons: Analysera tappade paket på Sophos Firewall.
• Passande lokal loggfil för VPN, Web, IPS, GUI eller systemtjänster behövs: Sophos Firewall Service Logs: rätt loggfil.
• SSH eller Advanced Shell ska förberedas: Anslut till Sophos Firewall via SSH.
• Supportfall med /log-arkiv, IPsec-data eller Debug Logs ska förberedas: Säkra Sophos Firewall-loggar för support och analys.
• PCAP-fil, lång inspelning eller mycket exakta CLI-filter behövs: Denna artikel.

Denna uppdelning sparar tid och minskar risken. tcpdump ger starka paketdata, men ingen Sophos-specifik policybeslut. Rule ID, NAT ID, Drop Reason, Web Policy, IPS eller SSL/TLS-inspektion måste parallellt kontrolleras i Log Viewer, WebAdmin Packet Capture eller i lämpliga loggfiler.

Förutsättningar

För denna guide behöver man:

• Administrativ åtkomst till Sophos Firewall.
• SSH-åtkomst till brandväggen eller åtkomst till Advanced Shell.
• Käll-IP, mål-IP, målport och det berörda protokollet.
• Tillräckligt med ledigt lagringsutrymme om en PCAP-fil ska skrivas.
• Wireshark eller ett annat analysverktyg på admin-klienten om en PCAP-fil ska utvärderas.

Hur man förbereder SSH säkert finns i Anslut till Sophos Firewall via SSH. För allmänna CLI-grunder passar även Sophos Firewall CLI Felsökning: viktiga kommandon.

När tcpdump är rätt nästa steg

tcpdump bör inte automatiskt vara det första steget. Om man bara vill veta vilken brandväggsregel, NAT-regel, Web Policy eller SSL/TLS-inspektionsregel som har beslutat, är Log Viewer snabbare och mer lättläst. Om man i webbläsaren vill se om enskilda paket anländer, vidarebefordras eller avvisas, räcker ofta Packet Capture i WebAdmin.

tcpdump blir särskilt användbart när något av dessa punkter gäller:

• Inspelningen ska utvärderas som en PCAP-fil i Wireshark eller av support.
• WebAdmin-capture är för kort, för oöverskådlig eller bufferten blir full.
• Testet måste köras längre under ett underhållsfönster, ett telefonsamtal eller ett reproducerbart användarfel.
• Det behövs precisa CLI-filter, till exempel för VoIP, DNS, IPsec, flera värdar eller portområden.
• Den relevanta trafiken ska först jämföras på any och sedan på ett specifikt gränssnitt.

Viktigt är förväntningen: tcpdump visar paket, men ingen Sophos-specifik Rule ID, NAT ID, Drop Reason eller Web-Policy-beslut. Denna information måste parallellt kontrolleras via Log Viewer, WebAdmin Packet Capture eller lämpliga loggfiler.

Advanced Shell eller Device Console?

tcpdump kan förekomma i två CLI-sammanhang på Sophos Firewall. Sophos Device Console innehåller ett eget tcpdump-kommando med Sophos-syntax och alternativ som filedump. Advanced Shell erbjuder dessutom det mer Linux-liknande tcpdump, vilket ofta är mer praktiskt i supportfall eftersom processhantering, scp, /tmp och andra shellverktyg finns tillgängliga.

Denna åtskillnad är viktig:

• Device Console: lämplig för Sophos CLI-kommandot tcpdump. Kontrollera syntaxen med Tab eller ? före körning. Enligt Sophos sparas utdata som skapas med filedump under /tmp.
• Advanced Shell: lämplig för klassiska shellflöden med tcpdump, ps, df, grep, scp, filåtkomst och medvetet stopp av körande processer.

Den här artikeln använder medvetet Advanced Shell eftersom PCAP-filer, bakgrundsprocesser, scp och städning efteråt hänger ihop tydligare där. Om tcpdump används i Device Console gäller samma grundregler: snäva filter, kort capture-fönster, kontroll av ledigt utrymme och jämförelse med Log Viewer eller WebAdmin Packet Capture.

Om det är oklart vilken konsol man befinner sig i, hjälper översikten Sophos Firewall Felsökning: Tjänster och loggar.

Förbered Capture

Begränsa innan start

Innan en capture bör man notera analysparametrarna:

• Source IP: till exempel 172.16.10.25.
• Destination IP: till exempel 198.51.100.20.
• Protokoll: till exempel TCP.
• Destination Port: till exempel 443.
• Förväntat Interface: LAN, WAN eller VPN-Interface.
• Testtidpunkt: exakt tid med tidszon.
• Förväntat resultat: anslutning tillåten, blockerad, DNAT, SNAT, VPN eller Drop.
• Parallell kontroll: Log Viewer, Packet Capture, Service Log eller supportticket.

Ju snävare filter, desto bättre resultat. En capture utan filter är oftast bara meningsfull på mycket lugna brandväggar.

Testet bör vara reproducerbart. Om flera personer samtidigt ändrar inställningar eller flera klienter testar, blir inspelningen svår att tolka. Bättre är en enda testklient, en snäv tidsram och en klar fråga: Kommer paketet fram? Går det ut? Kommer svaret tillbaka? Vilken regel, NAT-regel eller Policy var parallellt synlig?

För regeltester passar även Testa Sophos Firewall-regel med Log Viewer och Packet Capture. Om det främst handlar om Drop, Violation, Rule ID eller NAT ID, är Analysera tappade paket på Sophos Firewall den bättre uppföljningsartikeln.

Kör tcpdump

Kör tcpdump live

För en första live-kontroll räcker ofta ett värdfilter:

tcpdump -i any -nn host 198.51.100.20

Parametrarna:

• -i any: fånga på alla interfaces.
• -nn: ingen DNS- eller portnamnupplösning.
• host 198.51.100.20: visa endast paket från eller till denna IP.

För ett webbtest är ett ytterligare portfilter användbart:

tcpdump -i any -nn 'host 198.51.100.20 and port 443'

Filteruttryck med and, or eller not bör sättas inom enkla citattecken. Detta håller uttrycket intakt och förhindrar att det delas upp av shellen.

Vanliga filterexempel

• Specifik host: tcpdump -i any -nn 'host 198.51.100.20'
• Specifik Source IP: tcpdump -i any -nn 'src host 172.16.10.25'
• Specifik Destination IP: tcpdump -i any -nn 'dst host 198.51.100.20'
• Specifikt nät: tcpdump -i any -nn 'net 172.16.10.0/24'
• Specifik port: tcpdump -i any -nn 'port 443'
• Host och port: tcpdump -i any -nn 'host 198.51.100.20 and port 443'
• ICMP / Ping: tcpdump -i any -nn 'proto ICMP'
• DNS: tcpdump -i any -nn 'port 53'
• Alla portar utom SSH: tcpdump -i any -nn 'host 198.51.100.20 and port not 22'

Vid VPN-, VLAN- eller routingproblem kan det vara användbart att inte använda any, utan att begränsa till ett specifikt Interface. Interface-namnen måste passa den aktuella brandväggen. Praktiskt är ofta denna ordning:

1. Kontrollera kort på any om förväntad host eller port över huvud taget syns.
2. Spela därefter in på misstänkt ingående Interface.
3. Spela därefter in på misstänkt utgående Interface.
4. Jämför de tre observationerna med Log Viewer, NAT ID, Rule ID eller Drop Reason.

Så ser man snabbare om trafiken inte når brandväggen, stoppas på brandväggen eller saknar svar på returvägen.

Begränsa inspelning

En capture bör begränsas så att den inte körs onödigt länge.

Med -c stoppar tcpdump efter ett fast antal paket:

tcpdump -i any -nn -c 100 'host 198.51.100.20 and port 443'

För korta tester är detta ofta renare än en bakgrundsprocess. Man startar capture, reproducerar problemet och får sedan automatiskt utdata.

Skriv PCAP-fil

Om inspelningen senare ska analyseras i Wireshark eller av support, skriver man en PCAP-fil till /tmp.

tcpdump -i any -nn -s 0 -w /tmp/sophos-capture.pcap 'host 198.51.100.20 and port 443'

Viktiga parametrar:

• -s 0: fånga fullständiga paket.
• -w /tmp/sophos-capture.pcap: skriv utdata till en PCAP-fil.
• -nn: inaktivera namnupplösning.

-s 0 är användbart när en fullständig inspelning behövs. Samtidigt ökar detta dataskyddsrisken eftersom mer paketinnehåll fångas. För rena flödes- eller headerfrågor räcker ofta en live-capture utan PCAP-fil eller en kort inspelning med snäv filtrering.

Innan större inspelningar bör det lediga lagringsutrymmet kontrolleras:

df -h /tmp
df -h /var

Om problemet bara behöver reproduceras kort kan även här -c läggas till:

tcpdump -i any -nn -s 0 -c 500 -w /tmp/sophos-capture.pcap 'host 198.51.100.20 and port 443'

Efter start bör man omedelbart reproducera testet och inte låta capture köra onödigt länge. En PCAP som innehåller fem minuter för mycket är inte bara större, utan innehåller ofta också mer känslig information.

För supportfall bör filnamnet innehålla neutral kontext, men inga kundnamn, användarnamn eller konfidentiella hostnames. Bättre är namn som /tmp/ticket-12345-wan-443.pcap eller /tmp/vpn-test-20260629.pcap.

Starta och stoppa bakgrundsprocess

Ibland måste en capture köras medan ett annat test utförs. Då kan tcpdump startas i bakgrunden.

tcpdump -i any -nn -s 0 -w /tmp/voip-test.pcap 'host 192.0.2.50 and portrange 5060-5090' &

Visa pågående jobb:

jobs

Avsluta jobb:

kill %1

Om flera tcpdump-processer körs eller jobbet inte längre är synligt i den aktuella shellen, kontrollera först processerna:

ps | grep tcpdump

Avsluta sedan den passande processen. killall tcpdump bör endast användas om det är klart att inga andra viktiga inspelningar körs.

Efter stopp bör man kontrollera om PCAP-filen har skrivits och har en rimlig storlek:

ls -lh /tmp/*.pcap

Om en bakgrunds-capture planeras för ett supportmöte bör det i förväg vara klart vem som startar den, vem som stoppar den och var filen hamnar efteråt. En bortglömd inspelning är inget ovanligt felsökningsproblem, utan en undvikbar driftsrisk.

Exempel: Analysera VoIP eller 3CX

Vid VoIP-problem är SIP-signalering och RTP-medieström ofta separata att betrakta. En enda capture på port 5060 visar bara en del av problemet.

För ett första 3CX-test kan man fånga PBX-värden:

tcpdump -i any -nn -s 0 -w /tmp/3cx-test.pcap 'host 192.0.2.50'

Om trafiken är för bred kan man mer specifikt begränsa till SIP:

tcpdump -i any -nn -s 0 -w /tmp/3cx-sip.pcap 'host 192.0.2.50 and portrange 5060-5090'

För ljudproblem måste dessutom det faktiskt använda RTP-portområdet kontrolleras. Detta beror på telefonväxeln och dess konfiguration.

Vid Sophos Firewall VoIP-ämnen bör även Optimera VoIP-inställningar på Sophos Firewall kontrolleras.

Utvärdering och städning

Ladda ner och rensa PCAP-fil

En PCAP-fil kan kopieras till en intern server via scp:

scp /tmp/sophos-capture.pcap adminuser@192.0.2.10:/tmp/

Beroende på miljö kan även en annan säker överföringsmetod användas. FTP med fasta inloggningsuppgifter bör undvikas.

Efter lyckad överföring bör filen tas bort från brandväggen:

rm /tmp/sophos-capture.pcap

För fullständiga loggarkiv och supportärenden är Säkra Sophos Firewall-loggar för support och analys den mer passande guiden.

Kontext för support eller extern analys

En PCAP-fil utan kontext är svår att utvärdera. För Sophos Support, Avanet eller en extern analyspartner bör minst dessa uppgifter följa med:

• Tidsfönster: till exempel 2026-06-29, 14:05-14:08 Europe/Zurich.
• Förväntat Flow: till exempel klient 172.16.10.25 till server 198.51.100.20:443.
• Berörd funktion: DNAT, IPsec, SSL VPN, Webfilter, VoIP, DNS eller Routing.
• Observation: till exempel SYN synlig, inget SYN-ACK, Drop i Log Viewer eller inget svar från målet.
• Parallellt kontrollerat: Rule ID, NAT ID, Packet Capture och relevanta Service Logs.
• Ändring före felet: firmware, regeländring, providerbyte, certifikat eller SD-WAN route.

Före vidarebefordran bör man kontrollera om filen innehåller interna namn, privata adresser, offentliga kund-IP-adresser eller okrypterat innehåll. Om innehållet inte kan anonymiseras måste mottagare, överföringsväg och lagring beslutas medvetet.

Utvärdera tcpdump korrekt

Vid utvärdering handlar det inte bara om huruvida paket är synliga. Avgörande är vad som saknas.

• Inga paket från klienten synliga: Problemet ligger före brandväggen. Kontrollera klient, VLAN, gateway, switch eller routing till brandväggen.
• Paket kommer in, men går inte ut: Kontrollera brandväggsregel, NAT, routing, Security Feature eller Policy.
• Paket går ut, men inget svar kommer tillbaka: Kontrollera målsystem, returväg, motbrandvägg, NAT eller provider.
• Endast SYN, inget SYN-ACK: Mål eller returväg svarar inte.
• ICMP Request synlig, Reply saknas: Kontrollera returväg, målbrandvägg eller motpart.
• DNS-fråga synlig, inget svar: Kontrollera DNS-server, rutt, regel eller Upstream.
• Paket syns bara på any, men inte på väntat Interface: Kontrollera Interface-antagande, zon, route eller tunnelkoppling.
• Paket syns på ingående Interface, men inte på utgående Interface: Kontrollera regel, NAT, route, Security Feature eller Drop Reason.

tcpdump visar paketflödet. Själva policybeslutet kontrolleras parallellt i Log Viewer. Vid brandväggs- och NAT-frågor är ofta kombinationen av Log Viewer, Packet Capture och tcpdump snabbast.

För NAT-fel bör man dessutom förstå att NAT endast översätter trafiken, men inte tillåter den. Den passande grunden är Förstå NAT på Sophos Firewall: SNAT, DNAT, MASQ, PAT. Vid IPsec-tunnlar hjälper parallellt Sophos Firewall IPsec VPN Felsökning och de passande VPN-loggarna.

Vanliga fel och checklista

Typiska fel

• Capture utan filter: För mycket data, svårt att utvärdera. Begränsa alltid med host, nät, port eller protokoll.
• Capture inte stoppad: Lagringsutrymme och prestanda kan påverkas. Använd -c eller avsluta bakgrundsprocessen korrekt.
• Endast any utvärderad: Interface- eller tunnelproblem förblir dolt. Jämför ingående och utgående Interface riktat efter första träffen.
• Endast riktning ut kontrollerad: Returvägsproblem förbises. Betrakta båda riktningar.
• Fel Interface valt: Relevanta paket saknas. Använd först any, begränsa sedan till specifikt Interface.
• PCAP delad oskyddad: Känslig data kan avslöjas. Använd säker överföring och minimal mottagargrupp.
• Fil kvar efter supportärende: Onödig lagringsförbrukning och datarisk. Ta bort PCAP efter överföring.

Checklista

• Source IP, Destination IP, Port och Protokoll kända.
• SSH-åtkomst till brandväggen säkert upprättad.
• Tidigare beslutat om Log Viewer eller WebAdmin Packet Capture skulle räcka.
• Filter valda så snävt som möjligt.
• Capture begränsad med -c eller tydlig stopp-process.
• PCAP-fil endast skriven vid behov.
• Vid Interface-frågor först any, därefter ingående och utgående Interface jämförda.
• Problem reproducerat specifikt under capture.
• Testtid dokumenterad.
• Log Viewer kontrollerad parallellt.
• Rule ID, NAT ID, Drop Reason eller Service Log noterad, om synlig.
• PCAP säkert överförd.
• Temporär PCAP-fil borttagen från brandväggen.

FAQ