Testa Sophos Firewall-regel korrekt

En brandväggsregel bör inte bara sparas utan också testas noggrant. Speciellt med webbfiltret, TLS Inspection, NAT, IPS eller användarmatchning kan en regel se korrekt ut men ändå inte fungera som förväntat.

Flera verktyg är lämpliga för testet:

• Log viewer för verkliga händelser och regelbeslut
• Policy tester för webb-, brandväggs- och SSL/TLS-policylogik
• Packet capture för den faktiska paketflödet
• tcpdump för längre inspelningar, PCAP-filer och supportärenden

Det är viktigt med rätt ordning: Först kontrolleras att testet är tydligt definierat och att regeln genererar loggning. Därefter visar Log Viewer vilket beslut brandväggen faktiskt loggar. Policy tester hjälper med den förväntade policylogiken men bevisar inte ett verkligt paketflöde. Packet Capture är det bästa beviset när routing, NAT, VLAN, VPN, leverantör eller ett målssystem kan vara inblandade. Om testet måste köras längre, en PCAP-fil behövs eller Sophos Support ska utvärdera inspelningen, är tcpdump på Sophos Firewall det bättre verktyget.

Ett bra regeltest besvarar därför inte bara frågan om en regel “fungerar”. Det visar vilken Rule ID som faktiskt matchade, vilken NAT ID som var inblandad, om Security Features ingrep och om riktning ut och returväg tar den förväntade vägen.

Vilken artikel passar?

Denna artikel är rätt startpunkt om ett specifikt anslutningsförsök med Source IP, Destination, Service och tidpunkt ska testas. Vid relaterade felbilder är en mer specifik artikel ofta snabbare:

• En regel matchar inte alls eller en annan regel vinner: Sophos Firewall-regel matchar inte: Kontrollera orsaker.
• DNAT, SNAT, MASQ eller NAT-ordning är inblandad: Förstå NAT på Sophos Firewall.
• En intern server publiceras från internet: Publicera server via DNAT.
• Packet Capture visar Drops, Violation eller oväntade drop-anledningar: Analysera bortkastade paket på Sophos Firewall.
• SSL VPN är ansluten men interna mål fungerar inte: Ställ in SSL VPN Remote Access på Sophos Firewall.
• Site-to-Site-IPsec eller Remote-Access-IPsec har problem: Felsökning av IPsec VPN på Sophos Firewall.
• WebAdmin-verktyg räcker inte och lokala loggar behövs: Sophos Firewall Troubleshooting: Services och Logs.
• Ett supportärende behöver loggarkiv, IPsec-data eller PCAP-filer: Säkra loggar för support och analys på Sophos Firewall.

Denna avgränsning förhindrar att man med ett allmänt regeltest undersöker ett specifikt NAT-, VPN-, routing- eller tjänsteproblem för brett.

Rätt användning av verktygen

• Log viewer: Visar Rule ID, NAT ID, Action, User och Security-Feature-beslut. Det bevisar däremot inga paket som inte når brandväggen alls.
• Policy tester: Visar förväntad Firewall-, Web- och SSL/TLS-Policy för definierade indata. Det bevisar ingen verklig returväg, inget SD-WAN-beteende, ingen paketförlust och inget providerproblem.
• Packet capture: Visar om paket anländer, vidarebefordras och om svar kommer tillbaka. Det förklarar däremot inte automatiskt den tekniska avsikten bakom en regel eller Web Policy.
• tcpdump: Passar för längre inspelningar, mycket exakta BPF-filter, PCAP-filer och Wireshark-analys. Rule ID, NAT ID eller Web-Policy-beslut syns inte direkt i WebAdmin.
• Central Reporting eller Syslog: Hjälper för historik, rapporter, SIEM-korrelation och senare analys. För live-paketflöde och lokala tjänstedetaljer är lokala verktyg oftast snabbare.

Om en regel påstås “inte matcha” bör man därför inte omedelbart ändra själva regeln. Ofta ligger orsaken i NAT, routing, en överordnad regel, bristande loggning eller en säkerhetsfunktion. För systematisk felsökning passar dessutom Sophos Firewall-regel matchar inte: Kontrollera orsaker.

För Live Troubleshooting är den lokala Log Viewer oftast snabbare än Central Reporting eller ett SIEM. Centrala loggar är viktiga när händelser ska följas upp, korreleras eller sparas över längre tid. För installation passar Central Firewall Reporting och Skicka Syslog till SIEM.

Kort genomgång för regeltest

För de flesta supportärenden räcker en tydlig procedur:

1. Definiera testfall med Source IP, Destination, Service, användare och tidpunkt.
2. Aktivera Log firewall traffic i den berörda regeln.
3. Kontrollera regelposition och användningsräknare.
4. Reproducera testet exakt en gång.
5. Filtrera Log Viewer efter Source IP, Destination IP och Service.
6. Notera Rule ID och NAT ID från den verkliga loggposten.
7. Använd Policy tester endast för policylogik.
8. Starta Packet Capture om Log Viewer och Policy tester inte stämmer överens.
9. Dokumentera resultatet innan en regel flyttas eller ändras.

Viktigt är att bara ändra ett testfall per körning. Om regelposition, NAT, DNS, routing och klient ändras samtidigt går det senare inte längre att koppla framgången till rätt ändring.

Denna procedur förhindrar att man bygger om en fungerande regel i onödan, även om det egentliga problemet ligger i NAT, routing, DNS, TLS Inspection eller ett målssystem.

Innan testet

Först bör man noggrant notera vad som ska testas:

• Source IP: 172.16.10.25
• Användare: user@domain.local
• Source zone: LAN
• Destination: https://www.example.com
• Service: HTTPS
• Förväntad regel: LAN_to_WAN_Clients
• Förväntad åtgärd: tillåten, blockerad, decrypted, inte decrypted

Därefter aktiverar man Log firewall traffic i den berörda brandväggsregeln. Utan loggning är Log Viewer endast begränsat användbar.

Steg 1: Kontrollera regelposition

Öppna Rules and policies > Firewall rules och kontrollera:

• Står regeln ovanför mer generella regler?
• Är den aktiv?
• Är rätt IPv4- eller IPv6-vy vald?
• Är den i en meningsfull Rule group?
• Finns det undantag?
• Finns det en automatiskt skapad regel ovanför?

Om man testar en ny regel bör man återställa regelns användningsräknare. Därefter är det lättare att se om regeln verkligen träffades under testet.

Steg 2: Öppna Log Viewer

Öppna Log viewer uppe till höger i WebAdmin-konsolen.

Användbara filter:

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

För webbtrafik, kontrollera dessutom:

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

Log Viewer uppdateras automatiskt. För lugn analys kan man pausa live-vyn, filtrera och sedan fortsätta.

Steg 3: Reproducera testet

Testet bör utföras från en definierad klient:

• Öppna webbplats
• Skicka ping
• Testa port
• Starta applikation
• Upprätta VPN-anslutning
• Ladda ner fil

Om möjligt bör endast ett test köras åt gången. Annars blandas loggar och regelräknare.

Kontrollera därefter:

• Ökar regelräknaren?
• Syns en logg i Log Viewer?
• Vilken Rule ID visas?
• Vilken NAT Rule ID visas?
• Tillåts eller blockeras trafiken?
• Aktiveras en säkerhetsfunktion?

Om Log Viewer förblir tom är det ännu inget bevis mot regeln. Kontrollera först logging, tidsfilter, modulfilter och verkligt paketflöde. Ofta når trafiken inte brandväggen alls, regeln loggar inte, fel loggtyp är avaktiverad eller testet använder en annan mål-IP än väntat.

Steg 4: Använd Policy tester

Policy tester är användbar när man vill kontrollera vilken brandväggsregel, SSL/TLS inspection rule eller webbpolicy som teoretiskt skulle gälla för webbtrafik.

Menypath:

Diagnostics > Tools > Policy tester

Typiska indata:

• URL
• Användare
• Tid och dag
• Source IP
• Source zone
• Testmetod

Som testmetod väljer man till exempel Firewall, SSL/TLS, and web, om kombinationen av brandväggsregel, SSL/TLS inspection rule och webbpolicy ska kontrolleras.

Policy tester visar inte bara Accepted eller Blocked, utan även den matchade brandväggsregeln, den erkända destinationen, Source zone och beroende på testmetod ytterligare webb- eller SSL/TLS-information. Därmed ser man snabbt om trafiken i grunden landar i den förväntade regeln.

Viktigt:

⚠️ Policy tester ersätter inte ett verkligt paketflödestest. Policy-testresultat avbildar inte SD-WAN-rutter tillförlitligt. Det faktiska beteendet kan därför avvika om SD-WAN, routing eller gateways är inblandade.

SFOS 22: Policy tester kan visa felaktiga resultat

Vid SFOS 22.0 GA och SFOS 22.0 MR1 bör man bedöma policy-testresultat särskilt försiktigt. Policy Test och Policy Route Test kan visa trafik som blockerad eller tilldela den till en felaktig regel i vissa fall, även om produktiv trafik korrekt passerar genom brandväggen.

För administratörer är konsekvensen viktig: Om Policy tester visar ett oväntat resultat, men Log Viewer, regelräknare och Packet Capture bekräftar det verkliga paketflödet, bör man inte omedelbart bygga om brandväggsregler eller NAT-regler. Först kontrolleras om det bara gäller diagnostikvisningen.

Praktisk procedur vid motstridiga resultat:

1. Dokumentera testet noggrant med Source IP, Destination, Service och användare.
2. Filtrera Log Viewer efter Source IP, Destination IP och Service.
3. Kontrollera Rule ID och NAT Rule ID från den verkliga loggposten.
4. Starta Packet Capture med snäv filter.
5. Jämför inkommande, vidarebefordrade och returtrafik.
6. Behandla policy-tester-resultatet endast som en indikation, inte som ett ensamt bevis.
7. Kontrollera firmwareversion och Sophos kända problem innan produktiva regler ändras.

Denna försiktighet gäller särskilt i underhållsfönster. Ett felaktigt diagnosresultat bör inte leda till att fungerande produktiva regler sorteras om eller att NAT-regler ändras utan bevis.

Policy tester är särskilt bra för:

• Webbpolicy
• URL-kategorisering
• Användarkontext
• Schema
• SSL/TLS inspection rule
• Brandväggsregelmatchning för webbtrafik

Den är mindre bra för:

• verkliga routingbeslut
• NAT-returväg
• paketförluster
• leverantörs- eller switchproblem
• applikationer med flera anslutningar och portar

Steg 5: Använd Packet Capture

Om Log Viewer och Policy tester inte räcker, använd Diagnostics > Packet capture.

Filtret bör sättas snävt, till exempel:

• Source IP för klienten
• Destination IP för servern
• Destination port
• Protokoll

Sedan:

1. Starta Packet Capture.
2. Reproducera testet.
3. Stoppa Packet Capture.
4. Jämför inkommande och vidarebefordrade händelser.
5. Jämför Rule ID och NAT ID med Log Viewer.

Tolkning:

• Inget paket anländer: Kontrollera klient, VLAN, switch, gateway, provider eller Cloud Security Group.
• Paket kommer in men går inte ut: Kontrollera brandväggsregel, NAT, routing eller Security Feature.
• Paket går ut men svar saknas: Kontrollera returväg, målssystem, NAT eller extern brandvägg.
• Paket har status Violation: Kontrollera Policy, IPS, webbfilter eller Application Control.
• NAT ID är oväntad: Kontrollera NAT-ordning och generiska NAT-regler.

Mer om detta: Använd Packet Capture Tool i WebAdmin. Om paket slängs är dessutom Analysera bortkastade paket på Sophos Firewall användbar.

Läs Log Viewer och Packet Capture tillsammans

Log Viewer visar beslutet, Packet Capture visar paketflödet. I praktiken behövs ofta båda vyerna.

• Log Viewer visar förväntad Rule ID, Packet Capture visar Forwarded: Regeltestet är plausibelt för firewallen. Returväg och målssystem måste fortfarande kontrolleras separat.
• Log Viewer visar förväntad Rule ID, Packet Capture visar inget svar: Kontrollera målssystem, returväg, NAT eller extern brandvägg.
• Packet Capture visar Incoming, men ingen passande logg: Kontrollera logging, modulfilter, default-regel, Device Access eller drop-analys.
• Packet Capture visar Consumed: Trafiken slutar på själva firewallen. Kontrollera Device Access och Local Service ACL.
• Packet Capture visar Violation: Stäm av Reason, Rule ID, NAT ID och Security-modul med Log Viewer.

Om båda verktygen verkar säga emot varandra bör testfallet först göras snävare. En enskild klient, ett mål, en port och en kort testtidpunkt är bättre än en bred inspelning med mycket bakgrundstrafik.

Använd snäva Packet-Capture-filter

Packet Capture är endast användbart om filtret är tillräckligt snävt. En för bred inspelning visar snabbt för mycket bakgrundstrafik, särskilt på produktiva brandväggar med webb, DNS, VPN eller servertrafik. Filtret bör därför härledas från det definierade testfallet.

Praktiska BPF-exempel:

• Enskild klient till ett mål: host 172.16.10.25 and host 203.0.113.10, när Source och Destination är kända.
• Klient till HTTPS-mål: host 172.16.10.25 and port 443, när målet kan ändras via DNS eller CDN.
• Endast utgående trafik från en klient: src host 172.16.10.25, när det först kontrolleras om klienten överhuvudtaget skickar.
• Endast svarstrafik till klienten: dst host 172.16.10.25, när returväg eller svarspaket saknas.
• DNS-test: host 172.16.10.25 and port 53, när namnupplösning och regeltest ska kontrolleras separat.
• ICMP-test: icmp and host 172.16.10.25, när en ping används som enkel tillgänglighetstest.

Vid DNAT- eller VPN-tester bör man särskilt uppmärksamma riktningen. Ett filter på den interna server-IP:n visar inte nödvändigtvis den ursprungliga åtkomsten till den offentliga IP:n. Omvänt visar ett filter på den offentliga IP:n inte automatiskt om trafiken efter NAT når den interna servern. I sådana fall är ofta två korta inspelningar renare: först på den offentliga sidan, sedan på det interna målet.

Efter testet bör man omedelbart stoppa inspelningen. Långa inspelningar ökar risken för att onödiga användardata, interna värdnamn eller främmande anslutningar spelas in.

När man ska byta till tcpdump

WebAdmin Packet Capture är idealiskt för snabba tester. Det räcker dock inte för alla fall. Man bör byta till tcpdump om något av dessa punkter gäller:

• Inspelningen ska utvärderas som PCAP-fil i Wireshark eller av support.
• Testet pågår längre än en kort manuell reproduktionstest.
• Det behövs mycket exakta BPF-filter, till exempel för VoIP, VPN, DNS eller flera värdar.
• WebAdmin-bufferten fylls eller visar bara ett utdrag.
• Den relevanta trafiken måste observeras på ett visst gränssnitt under längre tid.

Även med tcpdump gäller: Sätt filter snävt, notera testtid, håll inspelningen kort och ta bort filen efter överföring. Den praktiska CLI-guiden finns i Sophos Firewall tcpdump: Fånga paket via CLI.

Steg 6: Validera säkerhetsfunktioner individuellt

Om rätt regel matchar men trafiken inte fungerar bör de aktiverade funktionerna kontrolleras individuellt.

• Web policy: Kontrollera kategori, användare, Schedule och Policy-ordning.
• Scan HTTP and decrypted HTTPS: HTTPS skannas endast om det redan är decrypted.
• SSL/TLS inspection: Kontrollera passande regel, Decryption Profile och CA-certifikat på klienter.
• IPS: Kontrollera signatur, Policy och möjliga False Positives.
• Application Control: Kontrollera identifierad applikation, kategori och Cloud-App-identifiering.
• Security Heartbeat: Kontrollera om Endpoint skickar Heartbeat och om status är grön, gul eller röd.
• Traffic Shaping: Kontrollera om policyn är aktiv och matchar rätt applikation eller regel.
• NAT: Kontrollera korrekt SNAT-, DNAT- eller PAT-regel och regelordning.

För HTTPS gäller: En brandväggsregel med webbfiltrering räcker inte för att kontrollera HTTPS-innehåll. Det behövs dessutom en lämplig SSL/TLS inspection rule med dekryptering och distribuerat CA-certifikat.

Mer om detta: Rulla ut TLS Inspection på Sophos Firewall steg för steg. För NAT-fel passar Förstå NAT på Sophos Firewall, eftersom en NAT-regel inte tillåter trafik utan bara översätter adresser eller portar.

Steg 7: Kontrollera loggfiler

Om WebAdmin-verktyg inte räcker bör de relevanta loggfilerna kontrolleras.

Typiska filer:

• Brandväggsregel: firewall_rule.log
• NAT: nat_rule.log
• Brandväggsanslutningar: fwlog.log
• IPS och DPI: ips.log
• Web Proxy: awarrenhttp.log
• IPsec: strongswan.log, charon.log
• SSL VPN: sslvpn.log
• DNS: dnsd.log, dnsgrabber.log
• DHCP: dhcpd.log

Vilken loggfil som hör till vilket modul sammanfattas i Sophos Firewall Troubleshooting: Services och Logs.

Vid supportfall är ett loggarkiv eller CTR bara riktigt hjälpsamt om testtidpunkten och förväntade IDs är dokumenterade. Ett stort loggpaket utan Source, Destination, Port, User, Rule ID och NAT ID leder ofta bara till längre följdfrågor.

Exempel: Testa LAN till WAN webbregel

1. Skapa brandväggsregel LAN_to_WAN_Clients.
2. Aktivera loggning.
3. Ställ in tjänster på HTTP och HTTPS.
4. Välj webbpolicy.
5. Låt Block QUIC protocol vara aktiverat.
6. Aktivera Scan HTTP and decrypted HTTPS.
7. Skapa SSL/TLS inspection rule för testgruppen.
8. Installera CA-certifikat på testklienten.
9. Återställ regelräknaren.
10. Öppna webbplats.
11. Filtrera Log Viewer efter Source IP.
12. Kör Policy tester för samma URL.
13. Starta Packet Capture vid avvikelse.

Så ser man om regeln matchar, om HTTPS verkligen dekrypteras och om webbfilter, IPS eller Application Control ingriper.

Dokumentera testresultat

Efter ett regeltest bör resultatet dokumenteras kort. Detta är särskilt viktigt om ett supportärende, ett underhållsfönster eller en senare regelrensning uppstår.

Det är meningsfullt att inkludera:

• Datum och tid för testet
• Source IP, användare, Destination, Service och testad URL eller applikation
• förväntad och faktiskt matchad brandväggsregel-ID
• NAT Rule ID, om NAT är inblandad
• Åtgärd i Log Viewer
• Skärmdump eller export från Packet Capture, om paketflödet var relevant
• ändrad regel, webbpolicy, SSL/TLS inspection rule eller NAT-regel
• öppen punkt, om beteendet ännu inte är helt förklarat

Vid produktiva ändringar bör man dessutom notera om regeln endast är avsedd för en pilot, permanent eller som en tillfällig lösning. Tillfälliga testregler bör ha ett utgångsdatum eller en tydlig ägare, så att de inte blir kvar som gammalt skräp i regelverket.

Om regeltestet leder till ett supportfall bör dessutom loggarkiv, Packet Capture eller tcpdump-PCAP, berörd tidsperiod och redan uteslutna orsaker dokumenteras. För den delen passar Säkra loggar för support och analys på Sophos Firewall.

FAQ