Verworpen pakketten op Sophos Firewall analyseren

Een verworpen pakket is niet automatisch een fout. De firewall kan verkeer volgens plan blokkeren, legitiem verkeer onverwacht verwerpen of de datastroom helemaal niet zien. Met de volgende procedure is snel te bepalen of een regel, NAT, het retourpad, een securitymodule of een systeem vóór de firewall verantwoordelijk is.

Drops binnen enkele minuten afbakenen

1. Testscenario noteren: Leg Source IP, Destination IP, poort, protocol, tijdstip en verwachte richting vast. Noteer bij sporadische fouten ook gebruiker, applicatie en laatste configuratiewijziging.
2. Log Viewer filteren: Zoek in de Firewall-module op IP-adres, poort en tijdstip. Open afhankelijk van het geval ook Web, SSL/TLS inspection, Application filter, IPS, Active threat response, Web server protection of VPN.
3. Packet Capture starten: Stel onder Diagnostics > Packet capture een nauw filter in, activeer de capture en voer precies één reproduceerbare test uit.
4. Pakketstatus lezen: Incoming, Forwarded, Consumed, Generated en Violation laten zien of het pakket aankomt, wordt doorgestuurd, lokaal wordt verwerkt, door de firewall wordt gegenereerd of wordt verworpen.
5. Beslissing koppelen: Vergelijk Rule ID, NAT ID en Reason met de verwachte firewall- en NAT-regel. Controleer bij Web-, IPS- of Application-hits ook de betreffende Policy ID.
6. Retourrichting vastleggen: Als het heenverkeer wordt doorgestuurd maar geen antwoord zichtbaar is, controleer dan retourroute, doelsysteem, NAT, SD-WAN en asymmetrische routing.
7. Pas daarna wijzigen: Maak geen brede Allow-regel of globale uitzondering voordat de verantwoordelijke module en de werkelijke oorzaak vaststaan.

Voor algemene rule matching en de Policy Tester is er de uitgebreide handleiding Sophos Firewall-regels testen met Log Viewer en Packet Capture.

Log Viewer en Packet Capture samen lezen

Log Viewer en Invalid traffic

De Log Viewer opent rechtsboven in WebAdmin. Deze toont niet alleen firewallbeslissingen, maar ook gebeurtenissen van de betrokken securitymodules. Bij Web Proxy-verkeer kan de Firewall-module bijvoorbeeld Allowed melden terwijl de Web-module tegelijk Blocked toont: de firewallregel staat de verbinding met de proxy toe, terwijl de Web Policy de inhoud blokkeert. Vergelijk daarom altijd de modules van hetzelfde testmoment. Filters, Detailed view, het sessiemoment en Log occurrence worden uitgelegd in Sophos Firewall Log Viewer correct gebruiken.

Voor firewallverkeer moeten twee voorwaarden afzonderlijk worden gecontroleerd:

• In de betreffende regel is Log firewall traffic ingeschakeld. SSL/TLS-regels hebben hiervoor de aparte optie Log connections.
• Onder System services > Log settings is het benodigde uitvoerdoel voor Log Viewer onder Local reporting, Sophos Fusion (voorheen Sophos Central) of Syslog ingeschakeld.

Firewallsessies verschijnen doorgaans wanneer de firewall bij het sluiten een Destroy-event ontvangt. Als een verbinding zonder dit event wordt afgebroken, kan de verwachte vermelding ontbreken. Voor langere bewaartermijnen zijn Central Firewall Reporting en Syslog naar een SIEM geschikt.

Invalid traffic betekent dat Conntrack een pakket niet aan een actieve verbinding kan koppelen. Een verlopen sessie of extra TCP-RST- en FIN-pakketten kunnen zulke gebeurtenissen veroorzaken en zijn niet automatisch een fout. Treden tegelijkertijd verbindingsproblemen op, leg dan beide richtingen vast en controleer mogelijke oorzaken zoals een ontbrekende retourroute, een asymmetrisch pad of een HA-rolwissel. Een langere Conntrack-tijd vermindert mogelijk alleen het aantal logmeldingen; de oorzaak wordt er niet door verholpen.

Als de specifieke dropreden Invalid TCP reserved bit luidt, kan Accurate ECN in plaats van een firewallregel de oorzaak zijn. Invalid TCP reserved bit door Accurate ECN oplossen legt uit hoe dit wordt aangetoond en welke beveiligingsimpact de globale CLI-workaround heeft.

Status, Rule ID, NAT ID en Reason

Packet Capture toont pakketten die een interface passeren en voegt informatie toe over de verwerking door firewall, NAT en securitymodules. De huidige SFOS 22-documentatie definieert de volgende statussen:

• Incoming: Het pakket komt op een interface aan. Dit bewijst nog niet dat het wordt doorgestuurd.
• Forwarded: De firewall stuurt het pakket naar een uitgaande interface. Als het antwoord ontbreekt, ligt de volgende focus op het doelsysteem en het retourpad.
• Consumed: Het pakket is bestemd voor de firewall zelf, bijvoorbeeld voor WebAdmin, SSH, DNS of een VPN Portal.
• Generated: De firewall genereert het pakket zelf, bijvoorbeeld als antwoord of systeemverkeer.
• Violation: Een Policy-overtreding leidt tot de drop. Rule ID, Reason en de verantwoordelijke module bepalen het volgende controlepunt.

Daarnaast zijn Rule ID, NAT ID, Reason, Connection ID, Web filter ID, Application ID, IPS policy ID en Username belangrijk. Een onverwachte waarde kan betekenen dat een algemenere regel hoger in de lijst wordt toegepast, NAT de zichtbare adressen wijzigt of de gebruiker niet wordt herkend.

Reason is een aanwijzing, geen volledig Root Cause-rapport. Waarden zoals Firewall, LOCAL_ACL, INVALID_TRAFFIC, APPLICATION_FILTER, IPS, USER_IDENTITY, IP_SPOOF, SSL_VPN_ACL_VIOLATION en VIRTUAL_HOST kunnen afhankelijk van de versie naar de verantwoordelijke module leiden. Lees eerst status en ID’s en open daarna het passende onderdeel van Log Viewer. De bediening en filtering worden uitgelegd in Sophos Firewall Packet Capture.

Een gericht capturefilter instellen

Onder Diagnostics > Packet capture > Configure beperkt Enter BPF string de opname en bepaalt Number of bytes to capture (per packet) de pakketlengte. Wrap capture buffer once full overschrijft oude gegevens in plaats van te stoppen. Na Save filtert Display filter op Interface name, Ethernet type, Packet type, Source IP/port, Destination IP/port, Reason, Status, Rule ID, User of Connection ID. Een nauw BPF-filter spaart de buffer van 2048 KB en verzamelt minder gevoelige gegevens.

Firewall ID 0 en ontbrekende drop-logs

Als geen expliciete regel overeenkomt, gebruikt de firewall Drop all met Policy of Firewall ID 0, zonder normale trafficlog. Maak voor traceerbare drops onder Rules and policies > Firewall rules > Add firewall rule > New firewall rule als laatste een regel met Rule name, Action: Drop, Source zones and networks, Destination zones and networks, Services en Log firewall traffic. Beperk de waarden voor één test. Om de ingebouwde slotregel volledig na te bootsen adviseert Sophos een any-any-Drop-regel; controleer vooraf logvolume en bestaande slotregels.

Op SFOS 22.0.1 MR1 Build 490 zorgt NC-178387 ervoor dat ID 0 ontbreekt in Dropped Packet Capture en drppkt; Packet Capture toont alleen Incoming zonder Violation Firewall. Het verkeer wordt toch verworpen. Voor NC-178387 is momenteel geen fixversie bevestigd; MR2 alleen bewijst dus geen fix. Neem deze controle vóór de keuze van een andere build op in het firmware-updateplan.

1. Controleer regelvolgorde en Policy Test.
2. Vergelijk met Packet Capture.
3. Maak zo nodig de gelogde slotregel en bevestig de Rule ID.
4. Schakel een tijdelijke regel uit of verwijder die en controleer dat ID 0 blijft droppen; alleen de extra log verdwijnt.

De Policy tester onder Diagnostics > Tools, bij Pop-out tools, verwerkt geen SD-WAN-routes. NC-177587 trof SFOS 22.0 GA Build 411 en is opgelost in MR1 Build 490; controleer voor andere builds de actuele status van NC-177587 als onderdeel van het firmware-updateplan. Echte logs en Packet Capture blijven leidend.

Oorzaak op basis van de bevinding afbakenen

Regel, NAT en retourpad

Als de Rule ID niet bij de verwachte regel past, controleer dan Source- en Destination-zone, netwerkobjecten, service, protocol, gebruiker, tijdschema en regelvolgorde. Bij DNAT is bepalend of de test op het publieke adres wordt uitgevoerd en welke NAT ID werkelijk wordt toegepast. De basis staat in Firewall-regels begrijpen en Een server publiceren via DNAT.

Als Packet Capture Forwarded toont maar geen antwoord, is een extra Allow-regel zelden de oplossing. Vaak ontbreken SNAT/MASQ of een retourroute, is een gekoppelde NAT-regel uitgeschakeld, blokkeert het doelsysteem lokaal of stuurt SD-WAN het antwoord via een ander pad. Heen- en retourverkeer moeten dezelfde stateful firewall passeren.

Sessie, asymmetrische routing en HA

Meldingen zoals Could not associate packet to any connection betekenen dat geen passende Conntrack-vermelding is gevonden. Mogelijke oorzaken zijn een verlopen sessie, onverwachte TCP-flags, een asymmetrisch retourpad of een datastroom die de firewall slechts in één richting ziet. Na een HA-rolwissel kan bovendien relevant zijn op welk knooppunt de verbinding is opgebouwd.

Eén RST- of FIN-event zonder gebruikersprobleem vereist niet direct een wijziging. Reproduceerbare onderbrekingen worden daarentegen met hetzelfde filter in beide richtingen gecontroleerd; daarna volgen routing, SD-WAN, VPN-paden en HA-status.

Consumed en lokale firewallservices

Consumed is geen normale transitdrop. De bestemming is de firewall zelf, bijvoorbeeld WebAdmin, User Portal, VPN Portal, SSH, DNS, DHCP, IPsec, SSL VPN of SNMP. Voor deze verbindingen zijn meestal Administration > Device access en Local service ACL verantwoordelijk, niet een normale firewallregel. De veilige configuratie wordt beschreven in Sophos Firewall Device Access beveiligen.

Securitymodules, VPN en MTU

Een firewallregel kan verkeer toestaan voordat een volgende module het blokkeert. Controleer daarom bij passende ID’s of Reasons ook Web Policy, SSL/TLS inspection, Application Control, IPS, Active Threat Response en WAF. Beoordeel bij een IPS-hit de signature en regelcontext voordat een uitzondering wordt gemaakt; de procedure staat in Sophos Firewall IPS veilig testen.

Bij Web- en TLS-problemen kan QUIC via UDP 443 de verwachte verwerking veranderen. Het artikel QUIC en HTTP/3 blokkeren toont de juiste controle.

Bij VPN, PPPoE, SD-WAN of geneste tunnels veroorzaken MTU, MSS en fragmentatie eerder vastlopers of gedeeltelijke onderbrekingen dan een duidelijke drop. Raadpleeg hiervoor de handleidingen over MTU en MSS en IPsec VPN Troubleshooting.

Connection List gebruiken voor actieve sessies

Onder Diagnostics > Connection list toont de lijst actieve verbindingen. Display filter beperkt deze op In interface, Out interface, User, Network protocol, Source IP, Destination IP, Packet type, Source port, Destination port en Rule ID. Kolommen zoals NAT ID, Protocol, Application name, Connection status, Connection ID, Gateway ID en policy-ID’s helpen de flow te koppelen. Connection ID toont waar aanwezig gerelateerde proxy-, FTP-, SIP- en vergelijkbare sessies.

Een actieve sessie met verwachte Rule ID en NAT ID bevestigt de waarden van de huidige flow. Afwezigheid bewijst geen drop: de lijst is een momentopname en verworpen of gesloten verbindingen kunnen ontbreken. Controleer tijdens de test en correleer met Log Viewer en Packet Capture.

Als de standaardcontrole niet volstaat

Geen vermelding in Log Viewer of Packet Capture

Als een logvermelding ontbreekt, controleer dan eerst rule logging, Log settings, tijdfilter en de verantwoordelijke module. Als ook Packet Capture geen enkel pakket toont, controleer dan vóór verdere netwerkdiagnose het volgende:

• Packet Capture is werkelijk actief en de test is pas daarna uitgevoerd.
• Het filter bevat de juiste adressen, poorten, richting en interface; maak het bij wijze van test iets ruimer.
• De buffer van 2048 KB is niet vol. Zonder Wrap capture buffer once full stopt de opname wanneer de buffer vol is en moet deze na Clear opnieuw worden gestart; met de optie ingeschakeld worden de oudste gegevens overschreven.
• Onder System services > Services draait Packet capture and Live connections; start deze service gecontroleerd opnieuw als er een startprobleem is.

Pas als een reproduceerbare test met een werkende capture geen inkomend pakket toont, verschuift de focus naar een punt vóór de firewall: client, VLAN, switch, gateway, upstream router of een onjuist testdoel.

tcpdump, Drop Capture en logarchieven

Meld voor langere captures, PCAP-bestanden of nauwkeurige BPF-filters aan via SSH en kies Option 4: Device Console. Een beperkt voorbeeld voor twee hosts en HTTPS is:

tcpdump 'host 192.0.2.10 and host 198.51.100.20 and port 443'

Voor pakketten die door firewallregels worden verworpen, kan hetzelfde filter met drop-packet-capture worden gebruikt:

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

drop-packet-capture helpt niet bij problemen op de Application Layer. De voorbeelden volgen de gedocumenteerde Device Console-syntaxis van SFOS 22; ze zijn voor dit artikel niet op een firewall uitgevoerd. Voor een PCAP-bestand ondersteunt tcpdump de optie filedump; het bestand staat tijdelijk onder /tmp. Houd de capture zo kort en beperkt mogelijk, omdat pakketten gevoelige inhoud kunnen bevatten, en verwijder het bestand na de analyse. Meer voorbeelden staan in tcpdump op Sophos Firewall.

Als support daarnaast servicelogs nodig heeft, bepaal dan eerst de betreffende log en stel alleen de benodigde periode veilig. Gebruik hiervoor Sophos Firewall services en logs en Logs voor support en analyse opslaan.

Veilig oplossen en documenteren

Een uitzondering is pas zinvol als module, legitiem doel en kleinst mogelijke scope vaststaan. Maak geen globale TLS-uitzondering, Any-Allow-regel of vrijstelling voor complete netwerken alleen omdat de service daarna werkt. Concrete hosts, services en gebruikers met een review- of vervaldatum zijn beter.

Documenteer voor de afronding:

• Source, Destination, poort, protocol, tijdstip en gebruiker.
• Verwachte en werkelijk zichtbare Rule ID en NAT ID.
• Status, Reason en betrokken securitymodule.
• Heen- en retourrichting of het punt waar de flow eindigt.
• Wijziging, Owner, Ticket en reviewdatum; leg ook vast als bewust niets is gewijzigd.

Herhaal daarna dezelfde test. De toegestane verbinding moet werken en een niet-toegestane vergelijkingsbron moet geblokkeerd blijven. Zo ontstaat uit een snelle oplossing geen permanent beveiligingslek.

Veelgestelde vragen