Sophos Firewall analysera tappade paket

Om Sophos Firewall tappar paket är detta inte automatiskt ett fel. Ofta är det exakt det önskade säkerhetsbeslutet: en regel passar inte, en policy blockerar, ett paket tillhör inte en känd anslutning eller en modul som webbfilter, IPS eller Application Control fungerar.

Saker och ting blir svåra när en tjänst inte fungerar och det är oklart om brandväggen blockerar den, om trafiken inte kommer alls eller om returtrafiken går via en annan rutt. Då behövs en ren sekvens: först Log Viewer, sedan Packet Capture, sedan vid behov serviceloggar eller CLI.

För generell regelmatchning passar Testa brandväggsregel med Log Viewer, Policy Test och Packet Capture. Den här artikeln fokuserar på droppar och tappade paket.

Vilken felsökningsartikel är lämplig?

Inte alla anslutningsproblem är ett droppproblem. Beroende på din observation är ett annat sätt att börja snabbare:

• Släpp, Invalid traffic, Violation eller Firewall ID 0 synlig: Den här artikeln är rätt ställe att börja.
• Förväntad brandväggsregel uppfylls inte: Sophos Firewall-regeln gäller inte: kontrollera orsaker.
• Regeln bör valideras efter en ändring: Sophos Firewall Testregel med Log Viewer och Packet Capture.
• Paket bör checkas in i WebAdmin med ett smalt filter: Sophos Firewall använder Packet Capture i WebAdmin.
• WebAdmin visar för lite och loggfiler behövs: Sophos Firewall Felsökning: tjänster och loggar.
• Loggar bör hållas längre eller centralt korrelerade: Sophos Firewall skicka syslog till SIEM.
• WebAdmin, SSH, DNS, VPN Portal eller SNMP till själva brandväggen påverkas: Sophos Firewall Säker åtkomst: konfigurera Device Access korrekt.
• IPsec-tunneln är uppe, men trafiken flyter inte korrekt: Sophos Firewall IPsec VPN-felsökning.
• Stora överföringar hänger sig eller enskilda applikationer kraschar: Sophos Firewall Kontrollera MTU och MSS för VPN-problem.

Detta val sparar tid eftersom inte alla problem behandlas som ett brandväggsregelfel. Först måste det framgå om brandväggen ser trafiken, vilken regel eller modul som fattar beslutet och om returvägen faktiskt går över samma rutt.

Alla droppar är inte likadana

För analysen bör man först urskilja vilken typ av drop som finns. Annars söker man snabbt på fel ställe.

• Avsiktligt drop: Brandväggen blockerar enligt regel, webbpolicy, IPS eller threat feed. Då måste man kontrollera om policyn är tekniskt korrekt.
• Oväntat släpp: Legitim trafik släpps av en regel eller modul. Rule ID, NAT ID, kontrollera modul och skäl i Log Viewer eller Packet Capture.
• Inga brandväggsavbrott: Trafiken når inte brandväggen alls eller så tar svaret en annan väg. Kontrollera klient, VLAN, switch, gateway, rutt, SD-WAN eller returväg.

Denna klassificering förhindrar onödiga undantag. Om droppen önskas kräver den ingen teknisk reparation, utan snarare ett policybeslut. Om trafiken inte når brandväggen alls hjälper inte en ny brandväggsregel. Om en säkerhetsmodul blockeras bör en bred brandväggsregel inte skapas i blindo.

Första klassificeringen

Innan analysen startar bör felet isoleras så specifikt som möjligt.

Viktiga frågor:

• Vilken käll-IP och destinations-IP påverkas?
• Vilken port och vilket protokoll används?
• Är det klientinternet, site-to-site VPN, fjärråtkomst, DNAT, WAF eller intern trafik?
• Är felet permanent eller sporadiskt?
• Påverkar det bara en applikation, bara en användare eller ett helt nätverk?
• Har en brandväggsregel, NAT regel, rutt, SD-WAN regel, TLS Inspection eller webbpolicy ändrats nyligen?

Utan denna information söker man ofta för brett i Log Viewer. Ett reproducerbart test med tid, IP-adresser och förväntad riktning är bättre.

Använd Log Viewer korrekt

Log Viewer är den första startpunkten. Den visar händelseloggar och kan filtreras efter modul, tid, fält och fritext.

Log Viewer öppnas uppe till höger i WebAdmin-gränssnittet. Beroende på fallet är dessa moduler viktiga för droppar:

• Brandvägg: Regelmatchning, tillåtna och avvisade anslutningar.
• Webb: Webbpolicy, kategori, URL-grupp och skanning av skadlig programvara.
• SSL/TLS inspektion: Dekryptering, TLS fel och undantag.
• Applikationsfilter: Programkontrollträffar.
• IPS: Intrusion Prevention och DPI-beslut.
• Aktivt hotsvar: Threat Feeds, NDR Essentials eller andra ATR-träffar.
• Webbserverskydd: WAF, omvänd proxy och publicerade webbtjänster.
• VPN: IPsec, SSL VPN och fjärråtkomsthändelser.

Brandväggsregler loggar vanligtvis sessioner när brandväggen tar emot en Destroy-händelse och stänger anslutningen. Om en anslutning avslutas utan denna händelse kommer den inte alltid att visas som förväntat. För SSL/TLS-anslutningar loggas anslutningen efter handskakningen och när den stängs.

Loggkonfigurationen är också viktig. Om en loggtyp inte är aktiverad under Systemtjänster > Logginställningar syns den inte tillförlitligt lokalt, i Sophos Central eller i syslog. För långsiktig utvärdering är Sophos Firewall skicka syslog till SIEM eller Aktivera central brandväggsrapportering lämpligt.

Klassificera ogiltiga trafikhändelser

Invalid traffic är ett viktigt fynd, men inte en fullständig orsaksanalys. Brandväggen rapporterar alltså trafik som inte tydligt matchar en giltig anslutning eller policybeslut. Typiska exempel är paket utanför ett förväntat sessionstillstånd, asymmetriska vägar, utgångna sessioner, oväntade TCP-flaggor eller returtrafik som inte följer samma väg.

För sådana händelser bör man inte skapa en tillåtsregel först. Denna process är bättre:

1. Anta källa, destination, hamn och tid från evenemanget.
2. Kontrollera i Log Viewer om en brandvägg Rule ID, NAT Rule ID eller en modul är synlig.
3. Använd Packet Capture för att testa om båda riktningarna går genom samma brandvägg.
4. Kontrollera rutt, SD-WAN, VPN vägar, HA roll och returrutt.
5. Bestäm först då om en regel, NAT logik, rutt eller en säkerhetsprofil behöver justeras.

Invalid traffic är särskilt värdefull som en indikation på status eller problem med returvägen. Om bara Tillåt-regeln utökas, kvarstår ofta grundorsaken.

Använd Packet Capture korrekt

Menysökvägen är:

Diagnostics > Packet capture

Packet Capture visar om paket kommer till ett gränssnitt, vidarebefordras, bearbetas av själva brandväggen eller tappas. Detta är särskilt viktigt om inget tydligt visas i Log Viewer.

Grundläggande process:

1. Begränsa testfallet: anteckna käll-IP, destinations-IP, port och protokoll.
2. Öppna Diagnostics > Packet capture.
3. Ställ in fångstfiltren så smala som möjligt.
4. Aktivera Packet Capture.
5. Reproducera problem.
6. Sluta fånga.
7. Kontrollera poster efter källa, destination, Rule ID, NAT ID, status och orsak.

Packet Capture visar bland annat Rule ID, NAT ID, Status, Orsak, Anslutnings-ID, Webbfilter-ID, Applikations-ID, IPS policy-ID och Användarnamn. Dessa fält hjälper när inte bara en brandväggsregel utan även webbfilter, IPS, Application Control eller NAT är inblandade.

För att använda verktyget är Packet Capture i WebAdmin de mer detaljerade instruktionerna.

Förstå paketfångststatus

Statusvärdena är avgörande för analysen. Sophos Firewall erbjuder sex statusvärden i visningsfiltret: Allowed, Violation, Consumed, Generated, Incoming och Forwarded.

• Incoming: Paketet kommer till ett WAN- eller LAN-gränssnitt. Källan når brandväggen.
• Allowed: Paketet tilläts av den tillämpliga brandväggsregeln eller policyn. Denna status överlappar ofta med Forwarded i praktiken; om ett paket visas som Allowed men inte som Forwarded är det värt att kontrollera routing, returvägen eller en efterföljande säkerhetsmodul.
• Forwarded: Paketet vidarebefordras. Brandväggen tillåter i princip att paketet passerar igenom.
• Consumed: Paketet är avsett för själva brandväggen. Då är Device Access, VPN Portal, DNS, DHCP eller annan lokal tjänst relevanta.
• Generated: Paketet genereras av brandväggen. Detta är svar eller systemtrafik från brandväggen.
• Violation: Paketet tappas på grund av en policyöverträdelse. Regel, modul eller säkerhetsfunktion blockerad.

En enda Incoming utan en matchande Forwarded kan betyda att brandväggen släpper paketet, bearbetar det själv eller att filtret inte visar hela flödet. Det är därför man alltid ska titta åt båda hållen.

Ett undantag bör inte skapas omedelbart efter den första statusen. Det är bättre att härleda nästa test från statusen:

• Endast Incoming synlig: Kontrollera filtret, upptäck motsatt riktning, sök efter Rule ID och exkludera Firewall ID 0.
• Incoming och Forwarded men inget svar: Kontrollera returrutt, destinationssystem, lokal serverbrandvägg, NAT och asymmetrisk routing.
• Consumed synlig: Device Access, kontrollera ACL för lokal tjänst och påverkad lokal brandväggstjänst.
• Generated synlig: Kontrollera om brandväggen svarar själv eller genererar systemtrafik.
• Violation synlig: Matcha orsak, Rule ID, NAT ID och påverkad modul i Log Viewer.

Detta är en analys som går att reproducera: statusar är tillgängliga på samma sätt som de används. För Violation är Log Viewer, de interna finländarna är inte desamma som viktiga att återvända och Packet Capture, för Consumed är Device Access tillgänglig för varumärkesregler.

Snabb symtomtriage

I praktiken sparar en snabb symtomtriage mycket tid innan man gräver djupare i stockar eller skal:

• Log Viewer visar Invalid traffic: Fokusera på sessionstillstånd, returväg och asymmetrisk routing. Kontrollera båda riktningarna med Packet Capture.
• Packet Capture visar bara Incoming: Fokusera på släpp, lokal service, standardregel eller ofullständigt filter. Utöka filtret, kör Policy Test och kontrollera Firewall ID 0.
• Packet Capture visar Forwarded men inget svar: Fokusera på målsystem, returväg, NAT eller extern brandvägg. Kontrollera svarspaket och returväg.
• Packet Capture visar Consumed: Fokusera på trafik till själva brandväggen. Kontrollera Device Access och ACL för lokal tjänst.
• Packet Capture visar Violation: Fokusera på regel, säkerhetsmodul eller policyöverträdelse. Jämför Reason, Rule ID, NAT ID och modullogg.
• Log Viewer och Packet Capture visar ingenting: Trafiken når förmodligen inte brandväggen. Kontrollera klient, VLAN, switch, gateway eller felaktigt testmål.

Firewall ID 0 och explicit släppregel

Om inga explicita brandväggsregler matchas, avvisar Sophos Firewall trafiken med den inbyggda slutregeln med Firewall ID 0 eller policy-ID 0. Denna regel finns alltid i slutet av brandväggsreglerna. Viktigt för felsökning och SIEM: Den inbyggda drop-all-regeln loggar inte själva trafiken. Om alla avbrutna anslutningar ska vara spårbara behövs en egen explicit drop-regel med aktiv loggning.

Om drops via standardregeln inte syns är policybeslutet inte automatiskt fel. I Packet Capture syns då kanske bara Incoming, men ingen matchande Violation Firewall-post. Problemet är då spårbarheten vid felsökning, inte nödvändigtvis själva drop-beslutet.

Om ett testfall inte matchar några regler och fortfarande ingen drop syns, bör man också kontrollera:

1. Använd Policy Test och kontrollera om testet faller på Firewall ID 0 eller standardregeln.
2. Kontrollera regelordningen och se till att ingen annan regel högre upp oväntat matchas.
3. Skapa en explicit släppregel i slutet av regelbasen om släpp ska loggas eller skickas vidare till Central Reporting eller syslog.
4. Kör testet igen och se om minskningen nu är synlig med det explicita regel-ID:t.
5. Inkludera den explicita släppregeln i ändringsdokumentationen och regelgranskning så att den inte senare missförstås som en normal tillåt/neka-regel.

När slutregeln skapas bör zonerna väljas medvetet. Sophos rekommenderar individuella käll- och destinationszoner och inte Any som allmän zon, så att interna tjänster inte påverkas i onödan. Den uttryckliga slutregeln är till hjälp för en revisionssäker miljö. Den ersätter dock inte en ren regelstruktur. Om mycket legitim trafik hamnar på slutregeln saknas förmodligen en mer exakt tillåtande regel högre upp eller så klassificeras ett nätverk felaktigt.

Läs viktiga fält i Packet Capture

När det kommer till droppar är det inte bara statusen som är viktig. De ytterligare fälten visar vilken del av brandväggen som behandlade trafiken.

• Rule ID: Matchad brandväggsregel. Kontrollera om den matchar den förväntade regeln.
• NAT ID: Matchad NAT-regel. Kontrollera om NAT förväntades, saknades eller om en felaktig NAT-regel gäller.
• Orsak: Orsak till släpp eller Violation. Läs inte isolerat utan jämför med status och modul.
• Webbfilter-ID: Webpolicybeslut. Kontrollera kategori, URL-grupp och användarkontext.
• Applikations-ID: Upptäckt applikation. Application Control kan besluta annorlunda än porten föreslår.
• IPS policy ID: Tillämpad IPS policy. Kontrollera signatur, regelkontext och falsk positiv risk.
• Användarnamn: Igenkänd användare. Utvärdera endast användarmatchning om användaren faktiskt är synlig.

Om Rule ID eller NAT ID är oväntade, bör man inte omedelbart skapa ett undantag. Först måste det vara klart om testfallet definierades korrekt, om en mer allmän regel matchades ovan eller om NAT ändrar synen på källa och destination.

Använd Reason som vägledning

Värdet Reason är inte en fullständig grundorsaksrapport, men är en bra guide till nästa modul. Firewall talar mer för regelbas, standardregel eller zonlogik. LOCAL_ACL matchar Device Access och ACL för lokal tjänst. INVALID_TRAFFIC indikerar sessionstillstånd, returväg eller asymmetrisk routing. APPLICATION_FILTER, IPS, USER_IDENTITY, IP_SPOOF, SSL_VPN_ACL_VIOLATION eller VIRTUAL_HOST visar att brandväggsregeln inte är den enda kontrollpunkten.

En kort trestegsprocess hjälper därför: läs först statusen, klassificera sedan Reason och öppna därefter rätt modul i Log Viewer. På så sätt blir en enskild Violation-post ett spårbart kontrollspår istället för en inbjudan till ett brett undantag.

Consumed och lokala brandväggstjänster

Consumed är inte ett normalt fall. Statusen betyder att paketet är avsett för själva brandväggen. Typiska mål är WebAdmin, User Portal, VPN Portal, SSH, DNS, DHCP, IPsec, SSL VPN eller SNMP.

I sådana fall är det ofta inte den vanliga brandväggsregeln som är avgörande, utan snarare Device Access och Local service ACL. Om WebAdmin, SSH, VPN portal eller SNMP inte kan nås bör man därför inte bara söka under Rules and policies > Firewall rules. Rätt startpunkt är vanligtvis Administration > Device access.

För härdning och felsökning av lokala brandväggstjänster är Sophos Firewall säker åtkomst: konfigurera Device Access korrekt lämplig.

Vanliga dropporsaker

Ingen lämplig brandväggsregel

Den vanligaste orsaken är en regel som inte matchas. Orsakerna kan vara:

• fel källzon
• fel källnätverk
• fel destinationszon
• Destinations-IP vid DNAT har tolkats fel
• bristande service eller felaktigt protokoll
• Användaren är inte autentiserad
• Schemat passar inte
• en mer specifik regel placeras under en mer allmän regel

För regelstrukturen hjälper Sophos Firewall förstå och konfigurera regler korrekt. Om DNAT är inblandad, bör publicera server via DNAT till Sophos Firewall också kontrolleras.

NAT eller returvägen passar inte

Ibland tillåter brandväggen svaret, men svaret kommer tillbaka på ett annat sätt eller är felaktigt översatt.

Typiska punkter:

• SNAT eller MASQ saknas.
• DNAT pekar på fel intern värd.
• En länkad NAT-regel har inaktiverats.
• Returväg saknas.
• SD-WAN eller statisk routing skickar svarstrafik via en annan väg.
• VPN trafik saknar en matchande IPsec rutt eller returrutt.

Asymmetrisk routing ger ofta fel som är svåra att förstå eftersom brandväggen inte tydligt kan tilldela anslutningsstatus. Paket kan då visas som att de inte tillhör anslutningen.

Paketet tillhör inte en känd anslutning

Meddelanden som Could not associate packet to any connection eller liknande conntrack-meddelanden innebär ofta att brandväggen inte kan hitta ett lämpligt anslutningskontextobjekt.

Möjliga orsaker:

• Returtrafik tar en annan väg.
• Anslutning upprättades på en annan HA-nod.
• Sessionen har redan löpt ut.
• TCP-flaggor matchar inte den förväntade anslutningen.
• En enhet skickar svar utan föregående begäran.
• Stateful inspektion ser bara en del av dataflödet.

Här är Packet Capture viktigare än en enda loggpost. Du måste se om båda riktningarna går igenom samma brandvägg och samma zon.

Webbfilter, TLS Inspection, Application Control eller IPS blockerade

Inte varje droppe kommer från själva brandväggsregeln. Trafik är ofta tillåten men blockeras då av en säkerhetsmodul.

Typiska exempel:

• Webbpolicy blockerar en kategori eller URL-grupp.
• TLS Inspection avbryts på grund av certifikat, SNI, chiffer eller undantag.
• Application Control upptäcker ett oönskat program.
• IPS blockerar ett mönster.
• Active Threat Response stöter på en IoC.
• Zero-Day Protection håller tillbaka eller blockerar en nedladdning.

För IPS-träffar bör signaturen, policyn och regelkontexten kontrolleras innan ett brett undantag anges. Lämplig procedur finns i Sophos Firewall Konfigurera IPS och testa det säkert.

För webb- och TLS-fall bör även QUIC kontrolleras. När webbläsare använder UDP 443 matchar webbfiltrering och TLS-förväntningar inte alltid. Mer om detta: Sophos Firewall blockera QUIC och HTTP/3 korrekt.

MTU, MSS eller fragmentering

Med VPN, PPPoE, SD-WAN, cellulära eller kapslade tunnlar kan ett paket vara för stort för sökvägen. Då ser man inte alltid ett tydligt brandväggsfall, utan snarare anslutningsavbrott, långsamma applikationer eller enskilda tjänster som hänger sig.

För sådana fall är Sophos Firewall Kontrollera MTU och MSS för VPN-problem lämplig.

Strukturerad process

I praktiken fungerar denna ordning bra:

1. Observera testfall: Källa, destination, port, protokoll, tid.
2. Log Viewer kontroll: Filtrera brandväggsmodul och lämpliga säkerhetsmoduler.
3. Rule ID och NAT ID sökning: Kontrollera vilken regel som faktiskt uppfylldes.
4. Starta Packet Capture: Ställ in ett smalt filter och återskapa testet.
5. Kontrollera status: Utvärdera Incoming, Forwarded, Consumed, Generated eller Violation.
6. Kontrollera omvänd riktning: Kommer svaret tillbaka och går samma väg?
7. Kontrollera säkerhetsmoduler: Webb, TLS, Application Control, IPS, ATR, WAF.
8. Kontrollera serviceloggar: Om det finns serviceproblem, kontrollera lämplig loggfil under /log.
9. Kontrollera centrala loggar: Inkludera Central Reporting eller SIEM om lokala loggar inte räcker.

Lämpliga tjänst- och loggfiler sammanfattas i Sophos Firewall Felsökning: tjänster och loggar.

Om ingenting visas i Log Viewer

Ingen loggpost betyder inte automatiskt att brandväggen inte är inblandad.

Möjliga orsaker:

• Loggning är inte aktiverad i brandväggsregeln.
• Den relevanta loggtypen är inte aktiv under System services > Log settings.
• Anslutningen avslutades inte rent och loggades därför inte.
• Trafiken når inte brandväggen alls.
• Trafiken hanteras av en lokal tjänst.
• Filtret i Log Viewer är för smalt.
• Loggminnet är begränsat eller gamla poster har redan skrivits över.

I sådana fall, använd Packet Capture först. Om Packet Capture inte heller visar någon inmatning ligger fokus mer på klient, switch, VLAN, routing framför brandväggen eller felaktigt testmål.

När tcpdump eller loggarkiv behövs

WebAdmin Packet Capture är bra för snabb analys. För längre inspelningar, PCAP-filer, mycket exakta filter eller supportfall är tcpdump ofta bättre lämpad för SSH. Detta gäller särskilt om ett problem bara uppstår sporadiskt eller om inspelningen behöver utvärderas senare i Wireshark eller av Sophos Support.

I sådana fall bör följande klargöras före inspelningen:

• Vilken käll-IP, destinations-IP och portar måste inkluderas i filtret?
• Hur länge kan inspelningen pågå?
• Var lagras filen PCAP?
• Vem kan se filen?
• När kommer filen att raderas igen efter analys?

Den praktiska proceduren finns i Sophos Firewall tcpdump: Spela in paket via CLI. Om tjänstloggar krävs utöver paket, hjälper Sophos Firewall Spara loggar för support och analys.

Ange endast undantag specifikt

Med droppar är frestelsen att snabbt skapa ett undantag. Detta kan hjälpa på kort sikt, men försämrar ofta säkerheten eller döljer orsaken.

Undantag bör endast göras om det är tydligt:

• vilken modul som blockerar
• vilken värd, domän eller applikation som berörs
• varför trafiken är legitim
• hur snävt undantaget kan vara
• när undantaget kommer att kontrolleras eller tas bort

Breda undantag för hela nätverk, Any regler eller globala TLS undantag bör undvikas. Ett litet, dokumenterat undantag med ett granskningsdatum är bättre.

Dokumentera resultat

Ett bra droppresultat måste dokumenteras på ett sådant sätt att en annan person kan förstå testet. Detta är viktigt för interna granskningar, ändringsdokumentation och supportärenden.

Behåll åtminstone:

• Datum, tid och tidszon för testet.
• Källa IP, Destination IP, Port, Protocol och User.
• Förväntad brandväggsregel och faktisk synlig Rule ID.
• Förväntad NAT-regel och faktisk synlig NAT ID.
• Paketinsamlingsstatus: Allowed, Incoming, Forwarded, Consumed, Generated eller Violation.
• Relevant orsak eller modulmeddelande.
• Förändring gjord eller medvetet ingen förändring.
• Om ett undantag gjordes: ägare, syfte, giltighet och granskningsdatum.

Denna dokumentation förhindrar att ett kortsiktigt felsökningssteg blir en permanent, oklar säkerhetsrisk.

Checklista

• Källa IP, destinations-IP, port och protokoll känt.
• Tidpunkt för test dokumenterad.
• Log Viewer kontrollerad med korrekt modul och tidsfilter.
• Rule ID och NAT ID utvärderade.
• Om det inte finns någon släpppost, kontrollera om Firewall ID 0 eller standardregeln påverkas.
• Brandväggsregel och regelordning kontrolleras.
• NAT regel och returrutt kontrollerade.
• Packet Capture utförs med ett smalt filter.
• Status och orsak utvärderades i Packet Capture.
• Kollade fram och tillbaka.
• Webbfilter, TLS Inspection, Application Control, IPS och Active Threat Response markerade.
• Vid VPN MTU kontrolleras MSS och rutt.
• För DNAT eller WAF målvärd, värdadress och backend kontrolleras.
• Centrala loggar eller syslog kontrolleras om lokala loggar inte räcker.
• Om support krävs förbereds tcpdump eller loggarkiv specifikt.
• Undantag är endast snäva och dokumenterade.
• Fynd dokumenterade med Rule ID, NAT ID, status, orsak och förändring.

Vanliga frågor