Analysera kasserade paket i Sophos Firewall

Ett kasserat paket innebär inte automatiskt ett fel. Brandväggen kan blockera trafiken som avsett, oväntat kassera legitim trafik eller inte se dataflödet alls. Med följande arbetsgång går det snabbt att avgöra om orsaken är en regel, NAT, returvägen, en säkerhetsmodul eller ett system framför brandväggen.

Avgränsa kasserade paket på några minuter

1. Dokumentera testfallet: notera käll-IP, destinations-IP, port, protokoll, klockslag och förväntad riktning. Vid sporadiska fel bör även användare, applikation och den senaste konfigurationsändringen antecknas.
2. Filtrera i Log Viewer: sök i modulen Firewall efter IP-adress, port och klockslag. Öppna vid behov även Web, SSL/TLS inspection, Application filter, IPS, Active threat response, Web server protection eller VPN.
3. Starta Packet Capture: ställ in ett snävt filter under Diagnostics > Packet capture, aktivera inspelningen och genomför exakt ett reproducerbart test.
4. Läs paketstatusen: Incoming, Forwarded, Consumed, Generated eller Violation visar om paketet tas emot, vidarebefordras, behandlas lokalt, genereras av brandväggen eller kasseras.
5. Koppla beslutet till rätt regel: jämför Rule ID, NAT ID och Reason med den förväntade brandväggs- och NAT-regeln. Kontrollera även respektive policy-ID vid träffar i Web, IPS eller Application.
6. Fånga returtrafiken: om trafiken vidarebefordras men inget svar syns bör returväg, målsystem, NAT, SD-WAN och asymmetrisk routing kontrolleras.
7. Ändra först därefter: skapa inte en bred Allow-regel eller ett globalt undantag innan ansvarig modul och faktisk orsak har identifierats.

En fördjupad beskrivning av regelmatchning och Policy Tester finns i Testa Sophos Firewall-regler med Log Viewer och Packet Capture.

Läs Log Viewer och Packet Capture tillsammans

Log Viewer och Invalid traffic

Log Viewer öppnas uppe till höger i WebAdmin. Den visar inte bara brandväggsbeslut utan även händelser från de berörda säkerhetsmodulerna. För trafik via webbproxyn kan modulen Firewall exempelvis visa Allowed samtidigt som modulen Web visar Blocked: brandväggsregeln tillåter anslutningen till proxyn, medan Web Policy blockerar innehållet. Därför ska modulerna alltid jämföras för samma testtidpunkt. Filter, Detailed view, sessionstidpunkt och Log occurrence beskrivs i Använd Sophos Firewall Log Viewer på rätt sätt.

För brandväggstrafik måste två förutsättningar kontrolleras separat:

• Log firewall traffic är aktiverat i den aktuella regeln. SSL/TLS-regler har det separata alternativet Log connections.
• Under System services > Log settings är nödvändigt utdatamål för Log Viewer aktiverat under Local reporting, Sophos Central eller Syslog.

Brandväggssessioner visas vanligtvis när brandväggen tar emot en Destroy-händelse när anslutningen stängs. Om en anslutning avbryts utan denna händelse kan den förväntade posten saknas. För längre lagring kan Central Firewall Reporting eller Syslog till ett SIEM användas.

Invalid traffic betyder att Conntrack inte kan koppla ett paket till en aktuell anslutning. En utgången session eller ytterligare TCP-paket med RST och FIN kan orsaka sådana händelser och innebär inte automatiskt ett fel. Om anslutningsproblem uppstår samtidigt bör båda riktningarna fångas och möjliga orsaker som saknad returrutt, asymmetrisk väg eller ett rollbyte i HA kontrolleras. En längre Conntrack-tid kan i vissa fall bara minska antalet loggposter; den åtgärdar inte orsaken.

Om den specifika orsaken till blockeringen är Invalid TCP reserved bit kan Accurate ECN, snarare än en brandväggsregel, vara orsaken. Lös Invalid TCP reserved bit som orsakas av Accurate ECN förklarar hur detta bekräftas och vilken säkerhetspåverkan den globala CLI-lösningen har.

Status, Rule ID, NAT ID och Reason

Packet Capture visar paket som passerar ett gränssnitt och kompletterar detta med bearbetningen i brandvägg, NAT och säkerhetsmoduler. Den aktuella hjälpen för SFOS 22 definierar följande statusvärden:

• Incoming: paketet anländer till ett gränssnitt. Det bevisar ännu inte att paketet vidarebefordras.
• Forwarded: brandväggen vidarebefordrar paketet till ett utgående gränssnitt. Om svaret saknas ska målsystemet och returvägen undersökas härnäst.
• Consumed: paketet är avsett för själva brandväggen, exempelvis WebAdmin, SSH, DNS eller en VPN-portal.
• Generated: brandväggen skapar paketet, till exempel som svar eller systemtrafik.
• Violation: en policyöverträdelse gör att paketet kasseras. Rule ID, Reason och ansvarig modul visar vad som ska kontrolleras härnäst.

Även Rule ID, NAT ID, Reason, Connection ID, Web filter ID, Application ID, IPS policy ID och Username är viktiga. Ett oväntat värde kan betyda att en mer generell regel högre upp matchar, att NAT ändrar de synliga adresserna eller att användaren inte har identifierats.

Reason ger vägledning men är ingen fullständig grundorsaksanalys. Värden som Firewall, LOCAL_ACL, INVALID_TRAFFIC, APPLICATION_FILTER, IPS, USER_IDENTITY, IP_SPOOF, SSL_VPN_ACL_VIOLATION eller VIRTUAL_HOST kan beroende på version leda till ansvarig modul. Läs först status och ID:n och öppna därefter rätt område i Log Viewer. Användning och filtrering beskrivs i Sophos Firewall Packet Capture.

Firewall ID 0 och saknade loggar för kasserade paket

Om ingen explicit brandväggsregel matchar används sist i regelbasen den inbyggda regeln Drop all med Policy ID eller Firewall ID 0. Den skapar ingen vanlig loggpost för brandväggstrafik. Om dessa kasserade paket ska kunna spåras i Log Viewer, Central Reporting eller Syslog skapar man en egen regel med Action: Drop och aktiverat Log firewall traffic sist i regelbasen.

Välj nödvändiga Source- och Destination-zoner individuellt och använd inte generellt Any för zonerna. Då förblir lokala tjänster korrekt tillgängliga. Om slutregeln registrerar mycket legitim trafik saknas sannolikt en lämplig Allow-regel högre upp, eller så har ett nätverk klassificerats fel.

För SFOS 22.0.1 MR1 Build 490 dokumenterar Sophos dessutom Known Issue NC-178387: Default Drops med ID 0 saknas i Dropped Packet Capture och i drppkt; i vanlig Packet Capture kan endast Incoming visas utan motsvarande Violation Firewall-post. Trafiken kasseras ändå. Sophos anger ingen entydigt bekräftad korrigeringsversion i listan över Known Issues, därför får beteendet inte förutsättas i andra versioner än den angivna builden.

Vid en misstänkt Default Drop:

1. Kontrollera regelordningen och Policy Test.
2. Jämför resultatet med en faktisk Packet Capture.
3. Skapa vid behov av loggning en slutregel med specifika zoner och eget Rule ID.
4. Upprepa testet och bekräfta det nya Rule ID:t i loggen eller inspelningen.

Policy Tester under Diagnostics > Tools tar inte hänsyn till SD-WAN-rutter och är därför aldrig ett tillräckligt bevis i sig. På SFOS 22.0 GA kunde dessutom NC-177587 visa felaktiga regelresultat; produktionsloggar och Packet Capture är fortfarande avgörande.

Avgränsa orsaken utifrån resultatet

Regel, NAT och returväg

Om Rule ID inte motsvarar den förväntade regeln ska Source- och Destination-zon, nätverksobjekt, tjänst, protokoll, användare, schema och regelordning kontrolleras. Vid DNAT är det avgörande om testet görs mot den publika adressen och vilket NAT ID som faktiskt används. Grunderna beskrivs i Förstå brandväggsregler och Publicera en server via DNAT.

Om Packet Capture visar Forwarded men inget svar är en ytterligare Allow-regel sällan lösningen. Vanliga orsaker är att SNAT/MASQ eller en returrutt saknas, att en länkad NAT-regel är inaktiverad, att målsystemet blockerar lokalt eller att SD-WAN skickar svaret via en annan väg. Trafiken i båda riktningarna måste passera samma stateful-brandvägg.

Session, asymmetrisk routing och HA

Meddelanden som Could not associate packet to any connection betyder att ingen matchande Conntrack-post hittades. Möjliga orsaker är en utgången session, oväntade TCP-flaggor, en asymmetrisk returväg eller ett dataflöde som brandväggen bara ser i en riktning. Efter ett rollbyte i HA kan det även vara relevant på vilken nod anslutningen upprättades.

En enstaka RST- eller FIN-händelse utan ett användarproblem kräver inte en omedelbar ändring. Reproducerbara avbrott kontrolleras däremot med samma filter i båda riktningarna; därefter granskas routing, SD-WAN, VPN-vägar och HA-status.

Consumed och lokala brandväggstjänster

Consumed är inte en normal kassering av vidarebefordrad trafik. Målet är själva brandväggen, exempelvis WebAdmin, User Portal, VPN Portal, SSH, DNS, DHCP, IPsec, SSL VPN eller SNMP. För dessa anslutningar är det vanligtvis Administration > Device access och Local service ACL som gäller, inte en vanlig brandväggsregel. Den säkra konfigurationen beskrivs i Säkra Device Access på Sophos Firewall.

Säkerhetsmoduler, VPN och MTU

En brandväggsregel kan tillåta trafik innan en efterföljande modul blockerar den. Kontrollera därför även Web Policy, SSL/TLS inspection, Application Control, IPS, Active Threat Response och WAF när relevanta ID:n eller Reasons visas. Vid en IPS-träff ska signaturen och regelkontexten bedömas innan ett undantag skapas; processen beskrivs i Testa Sophos Firewall IPS på ett säkert sätt.

Vid webb- och TLS-problem kan QUIC över UDP 443 förändra den förväntade behandlingen. Artikeln Blockera QUIC och HTTP/3 visar rätt kontroll.

I VPN, PPPoE, SD-WAN eller kapslade tunnlar orsakar MTU, MSS och fragmentering oftare stopp eller delvisa avbrott än en tydlig kassering. Se guiderna om MTU och MSS och felsökning av IPsec VPN.

När standardkontrollen inte räcker

Ingen post i Log Viewer eller Packet Capture

Om en loggpost saknas ska först regelloggning, Log settings, tidsfilter och ansvarig modul kontrolleras. Om inte heller Packet Capture visar några paket bör följande verifieras innan nätverket felsöks:

• Packet Capture är verkligen aktivt och testet genomfördes först därefter.
• Filtret innehåller rätt adresser, portar, riktning och gränssnitt; vid behov kan det tillfälligt breddas något.
• Bufferten på 2048 KB är inte full. När bufferten är full stoppas inspelningen automatiskt och måste startas om efter Clear.
• Packet capture and Live connections körs under System services > Services; vid startproblem ska tjänsten startas om kontrollerat.

Först när ett reproducerbart test med fungerande inspelning inte visar någon inkommande trafik ska fokus flyttas till systemen framför brandväggen: klient, VLAN, switch, gateway, överordnad router eller felaktigt testmål.

tcpdump, Drop Capture och loggarkiv

För längre inspelningar, PCAP-filer eller exakta BPF-filter loggar man in via SSH och väljer Option 4: Device Console. Ett snävt exempel för två värdar och HTTPS är:

tcpdump 'host 192.0.2.10 and host 198.51.100.20 and port 443'

För paket som kasseras av brandväggsregler kan samma filter användas med drop-packet-capture:

drop-packet-capture 'host 192.0.2.10 and host 198.51.100.20 and port 443'

drop-packet-capture hjälper inte vid problem på applikationslagret. För en PCAP-fil stöder tcpdump alternativet filedump; filen lagras tillfälligt under /tmp. Håll inspelningen så kort och begränsad som möjligt eftersom paketen kan innehålla känslig information, och radera filen efter analysen. Fler exempel finns i tcpdump på Sophos Firewall.

Om supporten även behöver tjänsteloggar ska först rätt logg identifieras och endast den nödvändiga tidsperioden sparas. Se Sophos Firewall-tjänster och loggar samt Spara loggar för support och analys.

Åtgärda och dokumentera säkert

Ett undantag är meningsfullt först när modulen, det legitima syftet och det minsta nödvändiga tillämpningsområdet har fastställts. Skapa inte ett globalt TLS-undantag, en Allow-regel med Any eller åtkomst för hela nätverk bara för att tjänsten då fungerar. Konkreta värdar, tjänster och användare samt ett datum för granskning eller upphörande är bättre.

Dokumentera följande innan ärendet avslutas:

• Source, Destination, port, protokoll, klockslag och användare.
• Förväntat och faktiskt Rule ID samt NAT ID.
• Status, Reason och berörd säkerhetsmodul.
• Fram- och returriktning eller punkten där flödet slutar.
• Ändring, owner, ticket och granskningsdatum; dokumentera även om ingen ändring avsiktligt gjordes.

Upprepa därefter samma test. Den tillåtna anslutningen ska fungera och en otillåten jämförelsekälla ska fortfarande blockeras. Då blir en snabb felavhjälpning inte en permanent säkerhetslucka.

Vanliga frågor