Sophos Firewall-regel schoon testen

Een firewall-regel moet niet alleen worden opgeslagen, maar ook gericht worden getest. Vooral bij webfilter, TLS Inspection, NAT, IPS of User Matching kan een regel er visueel correct uitzien, maar toch niet werken zoals verwacht.

Voor de test zijn verschillende tools geschikt:

• Log viewer voor echte gebeurtenissen en regelbeslissingen
• Policy tester voor web-, firewall- en SSL/TLS-policy-logica
• Packet capture voor de daadwerkelijke pakketstroom
• tcpdump voor langere opnames, PCAP-bestanden en supportgevallen

Belangrijk is de juiste volgorde: Eerst wordt gecontroleerd of de test correct is gedefinieerd en de regel logging genereert. Daarna toont de Log Viewer welke beslissing de firewall daadwerkelijk registreert. De Policy tester helpt bij de verwachte policy-logica, maar bewijst geen echte pakketstroom. Packet Capture is het beste bewijs wanneer routing, NAT, VLAN, VPN, provider of een doelsysteem betrokken kunnen zijn. Als de test langer moet duren, een PCAP-bestand nodig is of Sophos Support de opname moet evalueren, is tcpdump op de Sophos Firewall het betere hulpmiddel.

Een goede regeltest beantwoordt daarom niet alleen de vraag of een regel “werkt”. Hij toont welke Rule ID werkelijk heeft gematcht, welke NAT ID betrokken was, of Security Features hebben ingegrepen en of heen- en terugrichting hetzelfde verwachte pad nemen.

Welk artikel past?

Dit artikel is de juiste start als een specifieke verbindingspoging met Source IP, Destination, Service en tijd moet worden getest. Bij gerelateerde foutbeelden is een specifieker artikel vaak sneller:

• Een regel matcht helemaal niet of een andere regel wint: Sophos Firewall-regel matcht niet: Oorzaken controleren.
• DNAT, SNAT, MASQ of NAT-volgorde is betrokken: NAT op Sophos Firewall begrijpen.
• Een interne server wordt vanuit het internet gepubliceerd: Server publiceren via DNAT.
• Packet Capture toont drops, Violation of onverwachte drop-redenen: Sophos Firewall verworpen pakketten analyseren.
• SSL VPN is verbonden, maar interne doelen werken niet: Sophos Firewall SSL VPN Remote Access instellen.
• Site-to-Site-IPsec of Remote-Access-IPsec veroorzaakt problemen: Sophos Firewall IPsec VPN Troubleshooting.
• WebAdmin-tools zijn niet voldoende en lokale logs zijn nodig: Sophos Firewall Troubleshooting: Services en Logs.
• Een supportgeval heeft logarchief, IPsec-gegevens of PCAP-bestanden nodig: Sophos Firewall Logs voor Support en Analyse opslaan.

Deze afbakening voorkomt dat men met een algemene regeltest een specifiek NAT-, VPN-, routing- of dienstprobleem te breed onderzoekt.

De tools correct plaatsen

• Log viewer: toont Rule ID, NAT ID, Action, gebruiker en Security-Feature-beslissingen. Hij bewijst echter geen pakketten die de firewall helemaal niet bereiken.
• Policy tester: toont de verwachte firewall-, web- en SSL/TLS-policy voor gedefinieerde invoer. Hij bewijst geen echte retourweg, geen SD-WAN-gedrag, geen pakketverlies en geen providerprobleem.
• Packet capture: toont of pakketten aankomen, worden doorgestuurd en of antwoorden terugkomen. Hij verklaart niet automatisch de inhoudelijke bedoeling achter een regel of webpolicy.
• tcpdump: geschikt voor langere opnames, zeer nauwkeurige BPF-filters, PCAP-bestanden en Wireshark-analyse. Rule ID, NAT ID of webpolicy-beslissingen ziet men daarmee niet direct in WebAdmin.
• Central Reporting of Syslog: helpt voor verloop, rapporten, SIEM-correlatie en latere analyse. Voor live-pakketstroom en lokale dienstdetails blijven lokale tools meestal sneller.

Als een regel zogenaamd “niet werkt”, moet men daarom niet meteen de regel zelf wijzigen. Vaak ligt de oorzaak in NAT, routing, een overkoepelende regel, ontbrekende logging of een security feature. Voor systematisch foutzoeken past daarnaast Sophos Firewall-regel matcht niet: Oorzaken controleren.

Voor live-troubleshooting blijft de lokale Log Viewer meestal sneller dan Central Reporting of een SIEM. Centrale logs zijn belangrijk wanneer events later moeten worden nagegaan, gecorreleerd of over langere tijd bewaard. Voor de inrichting passen Central Firewall Reporting en Syslog naar SIEM sturen.

Korte procedure voor de regeltest

Voor de meeste supportgevallen volstaat een duidelijke procedure:

1. Testgeval met Source IP, Destination, Service, gebruiker en tijdstip vaststellen.
2. Log firewall traffic in de betreffende regel activeren.
3. Regelpositie en Usage Counter controleren.
4. Test precies één keer reproduceren.
5. Log Viewer filteren op Source IP, Destination IP en Service.
6. Rule ID en NAT ID uit de echte logvermelding noteren.
7. Policy tester alleen voor policy-logica gebruiken.
8. Packet Capture starten als Log Viewer en Policy tester niet overeenkomen.
9. Resultaat documenteren voordat een regel wordt verplaatst of gewijzigd.

Belangrijk is om per run maar één testcase te wijzigen. Als regelpositie, NAT, DNS, routing en client tegelijk worden aangepast, kan het latere succes niet meer netjes worden toegewezen.

Deze procedure voorkomt dat men een werkende regel onnodig aanpast, terwijl het eigenlijke probleem bij NAT, routing, DNS, TLS Inspection of een doelsysteem ligt.

Voor de test

Eerst moet men precies noteren wat getest moet worden:

• Source IP: 172.16.10.25
• Gebruiker: user@domain.local
• Source zone: LAN
• Destination: https://www.example.com
• Service: HTTPS
• Verwachte regel: LAN_to_WAN_Clients
• Verwachte actie: toegestaan, geblokkeerd, decrypted, niet decrypted

Daarna in de betreffende firewall-regel Log firewall traffic activeren. Zonder logging is de Log Viewer slechts beperkt nuttig.

Stap 1: Regelpositie controleren

Men opent Rules and policies > Firewall rules en controleert:

• Staat de regel boven algemenere regels?
• Is deze actief?
• Is de juiste IPv4- of IPv6-weergave geselecteerd?
• Is deze in een zinvolle Rule group?
• Zijn er uitsluitingen?
• Is er een automatisch gegenereerde regel erboven?

Als men een nieuwe regel test, moet men de Usage Counter van de regel resetten. Daarna is beter te zien of de regel bij de test echt is geraakt.

Stap 2: Log Viewer openen

Men opent rechtsboven in de WebAdmin-console de Log viewer.

Nuttige filters:

• Module: Firewall
• Source IP
• Destination IP
• Destination port
• Rule ID
• Rule name
• Action
• User

Voor webverkeer extra controleren:

• Web filter
• SSL/TLS inspection
• Application filter
• IPS

De Log Viewer wordt automatisch bijgewerkt. Voor rustige analyse kan men de live-weergave pauzeren, filteren en daarna weer hervatten.

Stap 3: Test reproduceren

De test moet worden uitgevoerd vanaf een gedefinieerde client:

• Website openen
• Ping verzenden
• Poort testen
• Applicatie starten
• VPN-verbinding opbouwen
• Bestand downloaden

Indien mogelijk, moet altijd slechts één test tegelijk worden uitgevoerd. Anders vermengen logs en regelcounters zich.

Daarna controleren:

• Stijgt de regelcounter?
• Ziet men een log in de Log Viewer?
• Welke Rule ID wordt weergegeven?
• Welke NAT Rule ID wordt weergegeven?
• Wordt het verkeer toegestaan of geblokkeerd?
• Grijpt een security feature in?

Als de Log Viewer leeg blijft, is dat nog geen bewijs tegen de regel. Controleer dan eerst logging, tijdfilter, modulefilter en echte pakketstroom. Vaak bereikt het verkeer de firewall helemaal niet, logt de regel niet, is het verkeerde logtype gedeactiveerd of gebruikt de test een andere doel-IP dan verwacht.

Stap 4: Policy tester gebruiken

De Policy tester is nuttig als men wil controleren welke firewall-regel, SSL/TLS inspection rule of webpolicy voor webverkeer theoretisch zou gelden.

Menupad:

Diagnostics > Tools > Policy tester

Typische invoer:

• URL
• Gebruiker
• Tijd en dag
• Source IP
• Source zone
• Test method

Als testmethode kiest men bijvoorbeeld Firewall, SSL/TLS, and web, als de combinatie van firewall-regel, SSL/TLS inspection rule en webpolicy moet worden gecontroleerd.

De Policy tester toont niet alleen Accepted of Blocked, maar ook de gematchte firewall-regel, de herkende bestemming, de Source zone en afhankelijk van de testmethode verdere web- of SSL/TLS-informatie. Hierdoor ziet men snel of het verkeer in de verwachte regel terechtkomt.

Belangrijk:

⚠️ De Policy tester vervangt geen echte pakketstroomtest. Policy-testresultaten geven SD-WAN routes niet betrouwbaar weer. Het daadwerkelijke gedrag kan daarom afwijken als SD-WAN, routing of gateways betrokken zijn.

SFOS 22: Policy tester kan onjuiste resultaten tonen

Bij SFOS 22.0 GA en SFOS 22.0 MR1 moet men Policy-testresultaten bijzonder voorzichtig beoordelen. Policy Test en Policy Route Test kunnen verkeer in bepaalde gevallen als geblokkeerd weergeven of aan een verkeerde regel toewijzen, hoewel productief verkeer correct door de firewall loopt.

Voor beheerders is de consequentie belangrijk: Als de Policy tester een onverwacht resultaat toont, maar Log Viewer, regelcounters en Packet Capture de echte pakketstroom bevestigen, moet men niet meteen firewall-regels of NAT-regels aanpassen. Eerst wordt gecontroleerd of het alleen de diagnoseweergave betreft.

Praktische procedure bij tegenstrijdige resultaten:

1. Test met Source IP, Destination, Service en gebruiker goed documenteren.
2. Log Viewer filteren op Source IP, Destination IP en Service.
3. Rule ID en NAT Rule ID uit de echte logvermelding controleren.
4. Packet Capture met nauwe filter starten.
5. Inkomend, doorgestuurd en retourverkeer vergelijken.
6. Policy-tester-resultaat alleen als aanwijzing behandelen, niet als enig bewijs.
7. Firmwareversie en Sophos Known Issues controleren voordat productieve regels worden gewijzigd.

Deze voorzichtigheid geldt vooral in onderhoudsvensters. Een fout diagnose-resultaat mag er niet toe leiden dat werkende productieve regels opnieuw worden gesorteerd of NAT-regels zonder bewijs worden aangepast.

De Policy tester is bijzonder goed voor:

• Webpolicy
• URL-categorisering
• Gebruikerscontext
• Schema
• SSL/TLS inspection rule
• Firewall-regel-matching voor webverkeer

Hij is minder goed voor:

• echte routingbeslissingen
• NAT-retourweg
• pakketverlies
• provider- of switchproblemen
• applicaties met meerdere verbindingen en poorten

Stap 5: Packet Capture inzetten

Als Log Viewer en Policy tester niet voldoende zijn, gebruikt men Diagnostics > Packet capture.

De filter moet nauw worden ingesteld, bijvoorbeeld:

• Source IP van de client
• Destination IP van de server
• Destination port
• Protocol

Dan:

1. Packet Capture starten.
2. Test reproduceren.
3. Packet Capture stoppen.
4. Inkomende en doorgestuurde gebeurtenissen vergelijken.
5. Rule ID en NAT ID met Log Viewer vergelijken.

Interpretatie:

• Geen pakket komt aan: client, VLAN, switch, gateway, provider of Cloud Security Group controleren.
• Pakket komt binnen, maar gaat niet uit: firewallregel, NAT, routing of Security Feature controleren.
• Pakket gaat uit, antwoord ontbreekt: retourroute, doelsysteem, NAT of externe firewall controleren.
• Pakket heeft status Violation: policy, IPS, webfilter of Application Control controleren.
• NAT ID is onverwacht: NAT-volgorde en generieke NAT-regels controleren.

Meer hierover: Packet Capture Tool in WebAdmin gebruiken. Als pakketten worden verworpen, is daarnaast Sophos Firewall verworpen pakketten analyseren nuttig.

Log Viewer en Packet Capture samen lezen

De Log Viewer toont de beslissing, Packet Capture toont de pakketstroom. In de praktijk zijn vaak beide perspectieven nodig.

• Log Viewer toont verwachte Rule ID, Packet Capture toont Forwarded: de regeltest is voor de firewall plausibel. Retourweg en doelsysteem moeten apart worden gecontroleerd.
• Log Viewer toont verwachte Rule ID, Packet Capture toont geen antwoord: doelsysteem, retourroute, NAT of externe firewall controleren.
• Packet Capture toont Incoming, maar geen passend log: logging, modulefilter, default-regel, Device Access of drop-analyse controleren.
• Packet Capture toont Consumed: traffic eindigt op de firewall zelf. Device Access en Local Service ACL controleren.
• Packet Capture toont Violation: Reason, Rule ID, NAT ID en securitymodule met Log Viewer vergelijken.

Als beide tools tegenstrijdig lijken, moet de testcase eerst nauwer worden gemaakt. Eén client, één doel, één poort en een kort testmoment zijn beter dan een brede opname met veel achtergrondtraffic.

Nauwkeurige Packet-Capture-filters gebruiken

Packet Capture is alleen nuttig als de filter nauw genoeg is. Een te brede opname toont snel te veel achtergrondverkeer, vooral op productieve firewalls met web, DNS, VPN of serververkeer. De filter moet daarom worden afgeleid van het gedefinieerde testgeval.

Praktische BPF-voorbeelden:

• Enkele client naar een doel: host 172.16.10.25 and host 203.0.113.10, als Source en Destination bekend zijn.
• Client naar HTTPS-doel: host 172.16.10.25 and port 443, als het doel via DNS of CDN kan wisselen.
• Alleen uitgaand verkeer van een client: src host 172.16.10.25, als eerst wordt gecontroleerd of de client werkelijk verzendt.
• Alleen antwoordverkeer naar de client: dst host 172.16.10.25, als retourweg of antwoordpakketten ontbreken.
• DNS-test: host 172.16.10.25 and port 53, als naamresolutie en regeltest apart moeten worden gecontroleerd.
• ICMP-test: icmp and host 172.16.10.25, als een ping als eenvoudige bereikbaarheidstest dient.

Bij DNAT- of VPN-tests moet men vooral op de kijkrichting letten. Een filter op de interne server-IP toont niet noodzakelijk de oorspronkelijke toegang tot de openbare IP. Omgekeerd toont een filter op de openbare IP niet automatisch of het verkeer na NAT bij de interne server aankomt. In dergelijke gevallen zijn vaak twee korte opnames schoner: eerst aan de openbare kant, daarna aan het interne doel.

Na de test moet men de capture onmiddellijk stoppen. Lange opnames verhogen het risico om onnodige gebruikersgegevens, interne hostnamen of vreemde verbindingen op te nemen.

Wanneer men naar tcpdump overschakelt

De WebAdmin Packet Capture is ideaal voor snelle tests. Het is echter niet voldoende voor elk geval. Men moet naar tcpdump overschakelen als een van deze punten van toepassing is:

• De opname moet als PCAP-bestand in Wireshark of door support worden geëvalueerd.
• De test duurt langer dan een korte handmatige reproductietest.
• Er zijn zeer nauwkeurige BPF-filters nodig, bijvoorbeeld voor VoIP, VPN, DNS of meerdere hosts.
• De WebAdmin-buffer loopt vol of toont slechts een uitsnede.
• Het relevante verkeer moet op een bepaald interface gedurende langere tijd worden geobserveerd.

Ook bij tcpdump geldt: Filter nauw instellen, testtijd noteren, opname kort houden en het bestand na de overdracht weer verwijderen. De praktische CLI-handleiding staat in Sophos Firewall tcpdump: Paketten per CLI opnemen.

Stap 6: Security Features afzonderlijk valideren

Als de juiste regel matcht, maar het verkeer niet werkt, moeten de geactiveerde features afzonderlijk worden gecontroleerd.

• Webpolicy: categorie, gebruiker, schema en policy-volgorde controleren.
• Scan HTTP and decrypted HTTPS: HTTPS wordt alleen gescand als het al decrypted is.
• SSL/TLS inspection: passende regel, Decryption Profile en CA-certificaat op clients controleren.
• IPS: signatuur, policy en mogelijke false positives controleren.
• Application Control: herkende applicatie, categorie en Cloud-App-herkenning controleren.
• Security Heartbeat: controleren of de Endpoint Heartbeat verzendt en of de status groen, geel of rood is.
• Traffic Shaping: controleren of de policy actief is en bij de juiste applicatie of regel past.
• NAT: correcte SNAT-, DNAT- of PAT-regel en regelvolgorde controleren.

Voor HTTPS geldt: Een firewall-regel met webfiltering is niet voldoende om HTTPS-inhoud te controleren. Er is daarnaast een passende SSL/TLS inspection rule met decryptie en verspreid CA-certificaat nodig.

Meer hierover: TLS Inspection op Sophos Firewall stapsgewijs uitrollen. Voor NAT-fouten past NAT op Sophos Firewall begrijpen, omdat een NAT-regel geen verkeer toestaat, maar alleen adressen of poorten vertaalt.

Stap 7: Logbestanden controleren

Als WebAdmin-tools niet voldoende zijn, moeten de passende logbestanden worden gecontroleerd.

Typische bestanden:

• Firewall-regel: firewall_rule.log
• NAT: nat_rule.log
• Firewall-verbindingen: fwlog.log
• IPS en DPI: ips.log
• Web Proxy: awarrenhttp.log
• IPsec: strongswan.log, charon.log
• SSL VPN: sslvpn.log
• DNS: dnsd.log, dnsgrabber.log
• DHCP: dhcpd.log

Welke logbestand bij welk module hoort, is samengevat in Sophos Firewall Troubleshooting: Services en Logs.

Bij supportcases is een logarchief of CTR alleen echt nuttig als testtijdstip en verwachte ID’s gedocumenteerd zijn. Een groot logpakket zonder Source, Destination, poort, gebruiker, Rule ID en NAT ID leidt vaak alleen tot extra terugvragen.

Voorbeeld: LAN naar WAN webregel testen

1. Firewall-regel LAN_to_WAN_Clients aanmaken.
2. Logging activeren.
3. Services instellen op HTTP en HTTPS.
4. Webpolicy selecteren.
5. Block QUIC protocol geactiveerd laten.
6. Scan HTTP and decrypted HTTPS activeren.
7. SSL/TLS inspection rule voor de testgroep aanmaken.
8. CA-certificaat op de testclient installeren.
9. Regelcounter resetten.
10. Website openen.
11. Log Viewer filteren op Source IP.
12. Policy tester voor dezelfde URL uitvoeren.
13. Bij afwijking Packet Capture starten.

Zo ziet men of de regel matcht, of HTTPS echt wordt gedecodeerd en of webfilter, IPS of Application Control ingrijpen.

Testresultaat documenteren

Na een regeltest moet het resultaat kort worden gedocumenteerd. Dit is vooral belangrijk als er een supportgeval, een onderhoudsvenster of een latere regelopruiming uit voortkomt.

Zinvol zijn:

• Datum en tijd van de test
• Source IP, gebruiker, bestemming, service en geteste URL of applicatie
• verwachte en daadwerkelijk gematchte Firewall Rule ID
• NAT Rule ID, als NAT betrokken is
• Actie in de Log Viewer
• Screenshot of export uit Packet Capture, als de pakketstroom relevant was
• gewijzigde regel, webpolicy, SSL/TLS inspection rule of NAT-regel
• open punt, als het gedrag nog niet volledig is verklaard

Bij productieve wijzigingen moet men bovendien noteren of de regel alleen voor een pilot, permanent of als tijdelijke workaround is bedoeld. Tijdelijke testregels moeten een vervaldatum of een duidelijke eigenaar hebben, zodat ze niet als oude last in het regelwerk blijven.

Als uit de regeltest een supportcase ontstaat, moeten aanvullend logarchief, Packet Capture of tcpdump-PCAP, getroffen tijdvenster en al uitgesloten oorzaken worden gedocumenteerd. Voor dit deel past Sophos Firewall Logs voor Support en Analyse opslaan.

FAQ