Skapa och testa Sophos Firewall Web Exceptions säkert

En Web Exception går snabbt att skapa, men effekten kan bli betydligt större än förväntat. Beroende på valet hoppar Sophos Firewall inte bara över HTTPS-dekryptering utan även certifikatvalidering, skanning efter skadlig kod och innehåll, Zero-Day-analys eller fullständiga Web Policy-kontroller.

Den säkra ordningen är därför att först identifiera det berörda flödet och den kontroll som faktiskt orsakar problemet, därefter begränsa matchningen och först sedan aktivera minsta nödvändiga undantag. Ett positivt test räcker inte. I det negativa testet ska ett liknande mål som inte har undantagits fortfarande kontrolleras normalt.

Web Exception i sju steg

1. Dokumentera berörd klient, målhost, URL-sökväg, protokoll och tidpunkt.
2. Kontrollera om DPI Mode eller Web Proxy Mode används och vilken brandväggsregel och Web Policy som faktiskt gäller.
3. Avgör om bara TLS-dekryptering eller en specifik Web Protection-kontroll orsakar problemet.
4. Definiera snäva URL-, kategori-, käll- eller målkriterier under Web > Exceptions > Add an exception.
5. Välj bara minsta nödvändiga alternativ under Skip the selected checks or actions.
6. Aktivera undantaget och testa samma flöde igen med en ny webbläsar- eller programprocess.
7. Utför ett negativt test mot ett liknande mål som inte har undantagits och dokumentera matchning, effekt, ansvarig och granskningsdatum.

⚠️ HTTPS decryption är inte ett harmlöst kompatibilitetsalternativ. För matchande trafik försvinner även beroende kontroller och brandväggen tillåter då ogiltiga servercertifikat. Malware and content scanning hoppar automatiskt även över Zero-Day-analysen. Ett brett undantag får därför inte vara det första felsökningssteget.

Välj Web Exception eller TLS Exclusion

Båda verktygen kan förhindra att HTTPS-trafik dekrypteras, men de löser inte samma uppgift.

En SSL/TLS inspection rule med Action: Don’t decrypt passar när endast dekryptering ska undantas för tydligt angivna mål i DPI Mode. En URL Group i Local TLS exclusion list är särskilt effektiv eftersom brandväggen jämför Server Name Indication, eller SNI, som text.

Skapa och använd URL Groups säkert visar hur en sådan domänlista skapas, kopplas till en Don't decrypt-regel och testas med ett negativt mål.

En Web Exception passar när en Web Protection-kontroll dessutom eller i stället ska hoppas över:

• HTTPS decryption
• HTTPS certificate validation
• Malware and content scanning
• Zero-day protection
• Policy checks

I DPI Mode gäller en Web Exception bara om minst en Web Policy, Malware and content scanning eller ATP är aktiv för flödet. I Web Proxy Mode hör Web Exception direkt till den proxybaserade Web Protection-sökvägen.

Den planerade uppbyggnaden av DPI eller Web Proxy, Decryption Rules och CA-distribution beskrivs i Inför TLS Inspection korrekt. Själva filtreringslogiken förklaras i Konfigurera Web Protection med Web Policies.

Planera en snäv och spårbar matchning

Ett undantag ska inte börja med en godtycklig leverantörsdomän. Först registreras den konkreta begäran i webbläsaren, Log Viewer eller programloggarna. Därefter avgörs om hostname, sökväg, kategori, käll-IP eller mål-IP är det stabilaste kriteriet.

AND mellan typer, OR inom en typ

Sophos Firewall kopplar samman olika kriterietyper med AND. Om exempelvis URL-mönster och Source IP addresses anges måste båda typerna matcha.

Flera värden inom samma typ utvärderas med OR. Två URL-mönster innebär alltså att något av dem kan räcka. Två Source IP addresses innebär att någon av de båda källorna kan räcka.

Den här logiken är viktig vid felsökning. Ett undantag kan se korrekt ut men ändå inte gälla eftersom en extra kriterietyp inte matchar det verkliga flödet.

Förankra det reguljära uttrycket säkert

Reguljära uttryck är tillåtna under URL pattern matches. Ett fristående mönster som vendor.example är olämpligt. Texten kan också matcha på en oväntad plats i URL:en och undanta onödigt många begäranden.

För den reserverade exempeldomänen updates.vendor.example kan ett medvetet förankrat hostmönster se ut så här:

^([A-Za-z0-9.-]*\.)?updates\.vendor\.example/

Värdet är bara ett exempel. vendor.example är en reserverad dokumentationsdomän och ersätts med den verkliga målhost som har bekräftats i loggen eller begäran. Det valfria prefixet tillåter subdomäner. Om exakt en host ska undantas används inget onödigt jokertecken för subdomäner.

Tecken utanför ASCII anges som Punycode i mönstret. Efter varje regexändring ska testet innehålla en förväntad matchning och minst en avsiktligt liknande icke-matchning.

Skilj på hostname och URL-sökväg

Undantag för HTTPS decryption och HTTPS certificate validation kan utvärdera hostname från TLS-kontexten. Ett mönster som enbart riktas mot en URL-sökväg fungerar däremot för HTTPS först när anslutningen redan dekrypteras.

Detta skapar en viktig gräns: ett undantag kan inte stänga av dekryptering och därefter på ett tillförlitligt sätt använda en del som bara syns i den krypterade HTTP-sökvägen som urvalskriterium. Det kräver en hostbaserad omfattning eller en annan design.

Skapa Web Exception

Exemplet undantar en enskild pilotklient från HTTPS-dekryptering för en bekräftad leverantörshost. Det är inte en universell undantagsregel.

1. Öppna Web > Exceptions.
2. Välj Add an exception.
3. Ange ett tydligt namn, till exempel Vendor API no decrypt.
4. Aktivera URL pattern matches.
5. Ange det testade och förankrade mönstret under Search/Add och lägg till det med Add.
6. Aktivera även Source IP addresses för piloten och ange klientens konkreta IP-adress.
7. Välj enbart HTTPS decryption under Skip the selected checks or actions.
8. Välj Save.
9. Aktivera reglaget för det nya undantaget i listan.
10. Kontrollera namn, Matching URLs, källor och den överhoppade kontrollen igen.

Käll-IP-adressen är medvetet inställd i exemplet. Utan den skulle undantaget omedelbart gälla alla klienter vars begäran matchar URL-mönstret. Efter en lyckad pilot kan omfattningen kontrollerat utökas till de källor som verkligen behöver undantaget.

För en ren TLS Exclusion över många mål är en URL Group i en Don't decrypt-regel vanligtvis enklare att underhålla och effektivare. Många FQDN Host Objects i källan eller destinationen för en SSL/TLS inspection rule är olämpliga eftersom de kan orsaka många DNS-uppslag för nya TLS-anslutningar.

Förstå effekten av alternativen som hoppas över

Innan konfigurationen sparas måste det vara tydligt vilket skydd som försvinner.

HTTPS decryption

Brandväggen dekrypterar inte matchande HTTPS-trafik. Därmed kan den inte heller utföra kontroller som kräver dekrypterat innehåll. Sophos dokumenterar dessutom att trafik med ett ogiltigt servercertifikat tillåts för denna matchning.

Om endast ett certifikatproblem orsakar störningen är alternativet ofta för brett. Först kontrolleras om HTTPS certificate validation är det mer precisa undantaget.

HTTPS certificate validation

Brandväggen hoppar över giltighetskontrollen av servercertifikatet. Konfigurerad dekryptering kan fortsätta. Undantaget passar bara för ett känt mål med ett medvetet accepterat certifikatproblem och kräver ett nära granskningsdatum.

Ett utgånget, felaktigt namngett eller ej betrott certifikat ska om möjligt repareras på målsystemet. Distributionen av rätt Inspection CA löser ett annat problem och beskrivs i Distribuera CA-certifikatet för TLS Inspection.

Malware and content scanning

Brandväggen hoppar över skanning efter skadlig kod och innehåll för matchningen. Då hoppas även Zero-day protection automatiskt över. Ett enda val tar alltså bort två skyddslager från datasökvägen.

Före detta undantag kontrolleras filtyp, skanningsgräns, kryptering, felåtgärd och den nedladdning som faktiskt matchar. Hela testflödet finns i Konfigurera och testa skanning efter skadlig kod.

Zero-day protection

Zero-Day-analysen hoppas över. Inga analysrapporter skapas för matchande filer, även om den klassiska skanningen efter skadlig kod rapporterar ett fynd. Alternativet är snävare än att helt hoppa över Malware and content scanning.

Policy checks

Web Policy-kontroller hoppas över för den matchande begäran. Ett sådant undantag kan göra kategorier, användar- eller grupplogik och andra policybeslut verkningslösa. Det ska bara användas för ett tydligt verifierat policyproblem, inte som allmän lösning för en blockerad webbplats.

Verifiera effekten med positiva och negativa tester

Att en sida laddas framgångsrikt bevisar bara att något har ändrats. Det bevisar ännu inte att undantaget är precist.

1. Registrera tidpunkt, pilotklient, målhost och förväntad effekt.
2. Stäng den befintliga webbläsar- eller programsessionen och skapa en ny anslutning.
3. Upprepa den berörda begäran.
4. Jämför käll-IP, målhost, Web Policy, Firewall Rule ID och Action i Log Viewer.
5. Jämför servercertifikatet som klienten ser med tillståndet före ändringen för ett dekrypteringsundantag.
6. Öppna ett liknande mål som inte har undantagits.
7. Kontrollera att målet fortfarande omfattas av normal Web Policy, Decryption Rule och skanningskedja.
8. Inaktivera undantaget kort och återskapa det ursprungliga felet om det är säkert under underhållsfönstret.
9. Aktivera undantaget igen och bekräfta resultatet på nytt.

Om QUIC eller HTTP/3 kringgår den förväntade TCP-TLS-sökvägen kan testet bli missvisande. Avgränsningen finns i Blockera QUIC och HTTP/3 korrekt. Log Viewer, Policy Tester och Packet Capture visar vilken regel och policy som faktiskt matchar.

Avgränsa fel systematiskt

Undantaget gäller inte

• Reglaget under Web > Exceptions är inte aktivt.
• En extra kriterietyp matchar inte på grund av AND-logiken.
• Regexen är inte förankrad i början eller motsvarar inte verklig hostname.
• Trafiken dekrypteras inte för ett HTTPS-sökvägsundantag, så sökvägen syns inte.
• I DPI Mode är varken en Web Policy, Malware and content scanning eller ATP aktiv för flödet.
• En annan brandväggsregel, Web Policy eller driftform gäller än förväntat.
• En befintlig webbläsar- eller programsession har inte skapats på nytt.

Undantaget gäller för brett

• Mönstret innehåller ett okontrollerat jokertecken eller bara en fristående rot-domänsträng.
• Source IP addresses eller annan pilotomfattning saknas.
• Flera URL-mönster inom samma typ verkar bredare än förväntat på grund av OR.
• En hel Web category har undantagits i stället för den specifika hosten.
• Flera alternativ har aktiverats trots att bara en kontroll orsakar problemet.

Webbplatsen fungerar, men skyddseffekten är oklar

Undantaget utökas då inte. Först kontrolleras webbläsarcertifikat, Web- och SSL/TLS Inspection-loggar, Firewall Rule ID, Web Policy och en kontrollerad nedladdning tillsammans. Utan detta underlag är undantaget bara en funktionell workaround, ännu inte ett accepterat säkerhetsbeslut.

Granskning och rollback

Varje Web Exception i produktion innehåller minst:

• teknisk motivering och ärende
• ansvarig för program och brandvägg
• berörda hostar, sökvägar, källor och användargrupper
• exakt vilka kontroller som hoppas över
• datum för positiva och negativa tester
• gransknings- eller utgångsdatum
• dokumenterat tidigare tillstånd

Vid rollback inaktiveras undantaget först i stället för att raderas direkt. Därefter testas ursprungligt fel, normal skyddssökväg och opåverkade mål igen. Undantaget tas bort först när inget beroende finns kvar.

Standard- och leverantörsundantag ändras inte utan kontroll. För ett eget undantag ska det framgå varför det finns och vem som senare ska ompröva det.

Driftchecklista

• DPI Mode eller Web Proxy Mode fastställt.
• Brandväggsregel och Web Policy som faktiskt matchar bekräftade.
• Hostname och vid behov URL-sökväg registrerade från verklig trafik.
• Regex förankrad i början och testad mot icke-matchningar.
• AND mellan kriterietyper och OR inom en typ beaktade.
• Endast minsta nödvändiga alternativ valt.
• Automatisk Zero-Day-bypass vid Malware and content scanning beaktad.
• Pilotkälla begränsad.
• Positiva och negativa tester genomförda.
• Log Viewer, certifikat och skyddseffekt kontrollerade tillsammans.
• Ansvarig, ärende, granskningsdatum och rollback dokumenterade.

Vanliga frågor