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.

Den här guiden gäller SFOS 22.0. WebAdmin-etiketterna lämnas avsiktligt på engelska så att de kan hittas direkt i gränssnittet.

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.

Kontrollera produktkraven innan ett undantag väljs

För vissa hanterade produkter är port- och domäntillåtelser en förutsättning för den aktuella funktionen. Fastställ därför produktens funktion, version och faktiska anslutningsväg tillsammans med produktansvarig innan en brandväggsregel, TLS Exclusion eller Web Exception väljs. Dokumentera nödvändiga destinationer, portar, protokoll, riktningar och uttryckligen krävda inspektionsundantag i ändringsärendet i stället för att ge alla Sophos-produkter generell åtkomst.

• Wireless: Förkontrollen för Wireless skiljer hanteringsnät, DNS, tidstjänst och regionala destinationer från den senare wifi-konfigurationen.
• ZTNA: Identifiera först lokal driftsättning eller molndrift i ZTNA-gatewayguiden; deras anslutningsriktningar och inspektionskrav är inte utbytbara.
• Switchregistrering: Guiden för switchregistrering behandlar DNS, registreringsdestinationer och kontroller av proxy-/TLS-vägen.
• Endpoint, XDR och MDR: Nätverks- och proxykraven skiljer mellan plattformar, licensierade funktioner och installationsspecifika destinationer. En lista över tillåtna domäner är inte en generell lista över dekrypteringsundantag.
• NDR och integrationsappliances: Applianceplaneringen behandlar utgående port- och domänkrav; driftguiden hjälper till att kontrollera de NDR- och Log Collector-funktioner som faktiskt körs på enheten var för sig.

Den interna guiden är en utgångspunkt; produktansvarig måste bekräfta de bindande kraven för den specifika driftsättningen före ändringen. Nätverksåtkomst och att hoppa över inspektion är fortfarande separata beslut. Om verifierade krav saknas eller källorna motsäger varandra ska undantaget inte utökas på chans: spara underlaget och klargör frågan med produkt- och brandväggsansvariga. Därefter gäller fortfarande pilot, positiva och negativa tester, granskning och rollback enligt den här guiden.

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.

SSL/TLS exclusion list använder domännamn i klartext och omfattar deras subdomäner, inte reguljära uttryck. SSL/TLS-undantag kan förutom dekryptering även undanta krav på certifikat och protokoll. De motsvarar därför inte en Web Exception som enbart gäller HTTPS certificate validation. Bekräftade domäner kan läggas till i Local TLS exclusion list via Control Center eller Log Viewer; alternativt redigeras URL Group under Web > URL groups eller SSL/TLS inspection rule. Även webbkategorier kan vara kriterier i en SSL/TLS inspection rule.

Även den trafik som omfattas skiljer sig: i DPI Mode gäller Web Exceptions för SSL/TLS-anslutningar på valfri port, medan de i Web Proxy Mode gäller SSL/TLS på port 443. SSL/TLS Exclusion Rules gäller bara i DPI Mode, men är också portoberoende. Utöver URL Groups kan de använda zoner, nätverk, IP-adresser, tjänster, användare och grupper som kriterier. Web Exceptions erbjuder URL-mönster, Web categories samt IP-adresser eller intervall för källa och mål.

En aktiv Web Exception kan hoppa över de valda skyddskontrollerna för matchande webbflöden; det är ingen garanti för att varje systemblockering kan hävas. Omfattningen kan därför inte begränsas genom att placera en Web Policy-regel senare i ordningen. Undantagets egna kriterier är avgörande; kontrollera ändå ordningen för brandväggs-, Web- och SSL/TLS-regler separat, eftersom den avgör vilken skyddssökväg som först behandlar flödet.

Dokumenterad gräns och olöst motsägelse: Sophos beskriver generellt undantag som oberoende av policyer och regler. Kategoriguiden för SFOS 22.0 och 23.0 anger dock uttryckligen att highly objectionable criminal activity alltid blockeras: ingen policy eller något undantag får tillåta dessa sidor, och domännamn döljs avsiktligt i loggar och rapporter. Dessa olika påståenden bevisar inte att ett kringgående fungerar. Det säkra tillvägagångssättet är fortfarande att inte kringgå blockeringen och vid behov klargöra motsägelsen med Sophos Support. Använd endast ofarliga, godkända destinationer för tester, aldrig förbjudet innehåll.

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.

Kontrollera punkter, värdgräns och oönskade matchningar i sökvägen

I ett reguljärt uttryck står en punkt utan escape för vilket tecken som helst. Punkterna i ett fast värdnamn skrivs därför som \.. Tecknet ^ förankrar matchningen i början; det avslutande / avgränsar värden mot namn med liknande början, som updates.vendor.example.attacker.example. Sophos Firewall accepterar / och \/. För exakt en värd är det snävare mönstret:

^updates\.vendor\.example/

Exemplen avser den värd-/URL-representation som dessa Sophos-mönster tillämpas på, utan inledande https://. Testverktyget måste använda samma representation. Vid andra portar eller en annan representation ska man inte lägga till .* på chans, utan klargöra det faktiskt utvärderade värdet och skyddssökvägen. HTTPS-begränsningen i nästa avsnitt gäller fortfarande.

För mönstret med exakt värd förväntas följande resultat. Med det befintliga mönstret med valfri subdomän är även cdn.updates.vendor.example/file en avsedd matchning; övriga negativa fall förblir icke-matchningar.

De två sista fallen är särskilt viktiga: jämförelsen kan omfatta hela URL:en, inklusive sökväg och frågeparametrar. En oförankrad domäntext kan därför utlösa undantaget på en annan värd. Testet kontrollerar bara matchningen; om skyddskontroller faktiskt hoppas över verifieras senare med en ny begäran och loggar.

Testa långa icke-matchningar lokalt

Många oförankrade mönster kan kräva ytterligare sökarbete, särskilt när HTTPS-dekryptering gör hela URL-texten tillgänglig. Det ger inte stöd för ett generellt antal steg eller en alltid konstant, linjär eller exponentiell körtid för alla mönster. Förankring ersätter inte heller granskning av komplexa kvantifierare. Använd inte ett generellt jokertecken .* för värdnamn.

Ett test med 1000 tecken kompletterar de korta fallen. På en lokal administratörsdator med Python 3 skapar detta exempel en helt fiktiv URL-text med en lång sökväg och måldomänen enbart i frågeparametrarna. Det testar båda mönstren som visas här utan att kontakta en brandvägg:

import re
from time import perf_counter

prefix = "other.example/"
suffix = "?next=updates.vendor.example/file"
value = prefix + "a" * (1000 - len(prefix) - len(suffix)) + suffix
assert len(value) == 1000
patterns = [
    r"^updates\.vendor\.example/",
    r"^([A-Za-z0-9.-]*\.)?updates\.vendor\.example/",
]
for pattern in patterns:
    regex = re.compile(pattern)
    start = perf_counter()
    for _ in range(100):
        assert regex.search(value) is None
    print(pattern, "Nicht-Treffer, Sekunden:", perf_counter() - start)

Två icke-matchningar förväntas. Ytterligare syntetiska fall bör omfatta långa, nästan matchande värdnamn och långa sökvägar; jämför mönstren före och efter med samma indata. För misstänkta komplexa mönster används ett lokalt verktyg med tidsgräns, och ett test som hänger avbryts. Python-tider och stegräknare från andra regexmotorer är inte SFOS-mätningar eller prestandalöften. Kopiera inte produktions-URL:er, token, användarnamn eller kunddata till externa regexwebbplatser; fiktiva data räcker för dessa tester.

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. Med okrypterad HTTP är URL-sökvägen synlig utan TLS-dekryptering.

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, ange klientens konkreta IP-adress och bekräfta med Add.
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örbered ett nytt värdundantag i Config Studio

Config Studio kan skapa en ny Web Exception från ett domännamn utan att först importera ett befintligt undantag. Det är ett separat arbetsflöde; Bad regex och Apply Fix används däremot för att reparera befintliga poster enligt beskrivningen längre ned. Det nya undantaget förbereds först bara lokalt och tillämpas på brandväggen först genom TAR-importen.

Spara först en fullständig säkerhetskopia av brandväggen och en oförändrad selektiv export av WebFilterException från samma brandvägg på en skyddad plats. Avsnittet Exportera WebFilterException och kontrollera med Config Studio beskriver exporten av Entities.xml, filhanteringen och den senare nedladdningen. Dokumentera ett ännu oanvänt namn, den bekräftade målvärden, det nödvändiga alternativet för överhoppade kontroller och den avsedda klientomfattningen i ändringsärendet. Ett befintligt namn är inget säkert sätt att lägga till en extra post: importen uppdaterar matchande befintliga undantag. Ett ändrat namn skapar däremot en ny post utan att ta bort den gamla.

1. Öppna Config Studio via åtkomstlänken längre ned, välj Configuration editor och gå till Rules > Web exceptions.
2. Välj Add och ange det nya, unika namnet, till exempel Vendor API exact host no decrypt.
3. Aktivera endast det alternativ som behövs i det aktuella fallet under Skip these checks. För dekrypteringsexemplet är det Skip HTTPS decryption. Övriga alternativ heter Skip policy check, Skip cert validation, Skip malware scan och Skip zero-day protection. De ovan beskrivna följderna för skyddet gäller även när en post skapas i editorn; välj inte flera alternativ för säkerhets skull.
4. Välj omfattning under Match by URL/Domain: Exact host only för enbart den bekräftade värden eller Domain + all subdomains om samtliga subdomäner uttryckligen behövs och har godkänts. För updates.vendor.example behåller exemplet Exact host only; cdn.updates.vendor.example ska inte omfattas.
5. Ange det bekräftade domännamnet i textfältet utan URL-sökväg, till exempel updates.vendor.example. Ersätt detta dokumentationsvärde med den verkliga målvärden. Den genererade regexen och förhandsvisningen visas automatiskt; kontrollera båda mot den planerade omfattningen och de positiva och negativa fallen ovan.
6. Välj Add to URL Regex list. Mönstret måste därefter finnas under URL Regex Patterns. Ett synligt värde i förhandsvisningen är ännu inte en post som har lagts till i listan.
7. Valfritt kan man under URL Regex Patterns använda + Add URL regex för att lägga till ett eget, redan kontrollerat mönster direkt. Detta behövs inte när man skapar från ett domännamn; ytterligare mönster utökar den möjliga matchningen på grund av OR.
8. Välj slutligen Add längst ned i sidoformuläret. Först då skapas det nya undantaget i editorn.

Jämför före nedladdningen import-XML:en under Preview med det sparade tidigare tillståndet och ändringsärendet. Endast det godkända nya undantaget får läggas till; befintliga namn, kriterier, aktiveringsstatusar och alternativ för överhoppade kontroller får inte ändras oavsiktligt. Även klientomfattningen måste stämma: Exact host only begränsar målet, inte källorna. Om en nödvändig pilotkälla inte bevisligen ingår i den genererade konfigurationen ska den inte importeras; använd i stället WebAdmin-flödet ovan med Source IP addresses. Lägg inte till overifierade extra fält i XML:en.

Välj sedan Download > Download TAR och spara arkivet på en skyddad plats. Avsnittet Importera, kontrollera effekten och återställ omfattar importmeddelanden, jämförelse före/efter under Web > Exceptions, aktiveringskontroll samt nya anslutningar med positiva och negativa tester. XML-förhandsvisningen eller en lyckad import ersätter inte detta test av skyddseffekten. Vid ett oväntat resultat ska den nya posten inaktiveras kontrollerat och den normala skyddssökvägen kontrolleras igen. En återimport av den ursprungliga selektiva exporten tar inte automatiskt bort det nyskapade undantaget; ta bort det riktat först när beroendena har klarlagts. Låt befintliga undantag vara orörda.

Undanta en kategori i stället för en enskild domän

Om konfidentiella finansiella uppgifter inte ska dekrypteras kan kategorin Financial services vara rätt kriterium. Ett kategoriundantag omfattar dock fler destinationer än en enskild host; klassificeringen måste passa den avsedda omfattningen.

1. Ange ett namn som Financial services no decrypt under Web > Exceptions > Add an exception.
2. Aktivera Web site categories, välj Add new item och sedan Financial services.
3. Bekräfta med Apply selected items. Ange även Source IP addresses med klientens IP-adress och Add för piloten.
4. Välj endast HTTPS decryption, välj Save och aktivera reglaget i listan.
5. Testa en godkänd finansiell tjänst och en ofarlig destination utanför kategorin med nya anslutningar. Både pilotkällan och kategorin måste matcha på grund av AND.

Matchande HTTPS-anslutningar förlorar dekryptering och de innehållskontroller som är beroende av den; även den ovan beskrivna följden för certifikat gäller. Detta är inte ett generellt tillstånd för kategorin eller ett påstående om att alla andra skyddsfunktioner stängs av.

Malware-undantag för en bekräftad nedladdningshost

En leverantör som bedöms ha låg risk är inte i sig ett skäl att stänga av skanning. Om ett motiverat undantag behövs används proceduren ovan med ett eget namn som Vendor download scan exception, det bekräftade hostmönstret och pilotkällan. Välj Malware and content scanning i stället för HTTPS decryption. Zero-day protection väljs automatiskt; även äldre undantag som hoppar över skanning efter skadlig kod hoppar över Zero-Day-analys. Välj sedan Save och aktivera reglaget. Matchande nedladdningar får ingen skanning efter skadlig kod och innehåll eller Zero-Day-analys, inklusive dess analysrapporter. Välj inte dessutom bort de andra kontrollerna. Kontrollera den avsedda skyddssökvägen med en ofarlig, kontrollerad nedladdning från den godkända hosten och en jämförelsedestination som inte har undantagits; en lyckad nedladdning räcker inte.

Ange andra kriterier och hantera befintliga undantag

Ange webbplatsens bekräftade IP-adress under Destination IP addresses och välj Add, inte klientens IP-adress. Vid tillåtna kombinationer av målkriteriet med URL eller kategori måste alla valda typer matcha. URL-mönster använder ASCII-tecken; internationaliserade domännamn anges som Punycode. Matching URLs i standardundantaget Apple Update kan användas som syntaxexempel, inte som en overifierad mall för tillåtelser.

TLS-undantag: motstridiga uppgifter om omfattningen. Sidorna Add an exception för SFOS 22.0 och 23.0 beskriver den allmänna AND-logiken mellan kriterietyper, men Exclude a website from TLS inspection säger uttryckligen att käll- och målundantag inte kan kombineras. Begränsningens exakta omfattning är oklar; den allmänna matchningslogiken visar inte att kombinationen är tillåten. Att kombinera Source IP addresses och Destination IP addresses är därför inte ett verifierat tillåtet förfarande. Bekräfta den faktiska SFOS-versionen inklusive build, DPI-/proxyvägen, den nödvändiga kontroll som ska undantas och den snäva värd-/kategoriomfattningen innan ett TLS-undantag aktiveras. Behåll tillvägagångssättet ovan med pilotkällan och bekräftat värdnamn eller bekräftad kategori, utan att lägga till ett kriterium för mål-IP. Mål plus bekräftat värdnamn/kategori är ett separat alternativ endast om klientomfattningen är oberoende begränsad och godkänd. Ersätt inte den avsedda begränsningen med ett undantag enbart för källan och ta inte bara bort ett kriterium för att få en matchning: det utökar undantaget från säkerhetskontrollerna. Om både käll- och mål-IP måste begränsas, stoppa utan att aktivera eller utöka undantaget och begär tillsammans med den brandväggsansvarige ett buildspecifikt klargörande från Sophos Support.

Standardundantag stöder programuppdateringar och andra viktiga webbplatsfunktioner. Under Web > Exceptions öppnar Edit ett befintligt undantag och Clone skapar en kopia. Kontrollera alla ärvda kriterier och alternativ innan kopian aktiveras. Web > General settings styr den allmänna valideringen av HTTPS-certifikat; ett enskilt certifikatundantag ersätter inte den grundinställningen.

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.

Detta ger inte tillåtelse att använda Policy checks för att häva den ovan beskrivna, dokumenterade absoluta blockeringen av highly objectionable criminal activity.

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.

Öppna Policy tester under Diagnostics > Tools, i avsnittet Pop-out tools. Testmetoden Firewall, SSL/TLS, and web hjälper till att identifiera förväntad brandväggsregel, SSL/TLS inspection rule och Web Policy. Verktyget testar dock endast webbtrafik i Transparent Mode och återger därför inte ett uttryckligt direct web proxy-flöde. Bekräfta alltid med en ny begäran och verkliga loggar att Web Exception faktiskt gäller.

För loggbevis måste Log firewall traffic vara aktiverat i brandväggsregeln; aktivera även Log connections i SSL/TLS inspection rule. Under System services > Log settings måste relevanta loggtyper vara aktiva för Local reporting. Begränsa därefter Log Viewer till testtiden och käll-IP-adressen och jämför modulerna Web filter och SSL/TLS inspection med Firewall Rule ID, policy och Action. Använd Sophos Firewall Log Viewer korrekt förklarar kontrollerna. Om hela vyn förblir tom följer du Log Viewer uppdateras inte i stället för att bredda undantaget på grundval av en misstanke.

Avgränsa fel systematiskt

Undantaget gäller inte

• Den dokumenterade absoluta kategoriblockeringen är inget matchningsfel. Ett avsiktligt dolt domännamn är här inget loggningsfel. Webbkategorier och Web Policies förklarar gränsen; försök inte med ett bredare undantag eller tester mot detta innehåll.
• 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.

Om WebAdmin-verktygen inte isolerar orsaken kopplar Tilldela Sophos Firewall-serviceloggar korrekt DPI-, proxy-, malware- och Zero-Day-loggar till den berörda skyddssökvägen. Debug aktiveras inte som första steg.

Hög CPU-belastning och långsam webbåtkomst efter regexändringar

Jämför först tidpunkter och belastningsförlopp under Diagnostics > System graphs med långsamma begäranden och de senaste ändringarna av undantag. Kontrollera i Web > Exceptions de Selection criteria eller Matching URLs som gäller för alla aktiva undantag: saknas ^, escape för punkterna i värdnamnet eller en tydlig värdgräns? Finns breda jokertecken eller många oförankrade domäntexter?

Med behörig konsolåtkomst körs följande skrivskyddade kommando under Device Management > Advanced Shell. Det visar aktuell processbelastning men ändrar ingen konfiguration; avsluta visningen med q.

top

Om awarrenhttp eller snort ligger högst i CPU-användning kan Web Exception-regex bidra till belastningen. Det är en indikation, inte ett bevis på den enda orsaken: båda processerna utför andra kontroller. Undersök därför belastning, begäranden och mönster tillsammans, gör endast en begränsad ändring och mät igen vid jämförbar trafikbelastning. Om CPU-belastningen förblir hög, fortsätt att avgränsa övriga orsaker i den berörda skyddssökvägen; stäng inte generellt av inspektion eller alla undantag som jämförelsetest.

Reparera befintliga regex selektivt

För ett fåtal undantag är Web > Exceptions > Edit den tydligaste vägen. Spara först namn, aktiveringsstatus, kriterier och alternativ för överhoppade kontroller; korrigera sedan endast det testade URL-mönstret. För många poster kan modulen WebFilterException i stället exporteras. Exporten omfattar de valda Web Exception-konfigurationerna, inte automatiskt bara det felaktiga undantaget. Även oförändrade poster måste bevaras i jämförelsen före och efter.

Spara en aktuell säkerhetskopia av brandväggen och en oförändrad selektiv export på ett säkert ställe före båda importvarianterna. Klargör återställningsväg, underhållsfönster och administratörsåtkomst före importen. En selektiv export ersätter inte en fullständig säkerhetskopia. Förvara originalfil, arbetskopia och godkänt resultat separat; konfigurationer och genererade rapporter innehåller interna uppgifter och hör endast hemma på en godkänd administratörsdator med skyddad åtkomst.

Exportera WebFilterException och kontrollera med Config Studio

1. Öppna Backup & firmware > Import export på samma brandvägg och välj Export selective configuration.
2. Sök efter WebFilterException via Add new item och bekräfta med Apply selected items. Välj inte Include dependent entity: andra konfigurationsområden ska inte redigeras samtidigt.
3. Spara arkivet API-[timestamp].tar med Export eller Download. Packa upp en arbetskopia; där finns Entities.xml.
4. Öppna Sophos Firewall Config Studio. Välj Configuration editor och Rules > Web exceptions och läs sedan in den selektiva Entities.xml via Import.
5. Leta i Config Analysis efter Bad regex. Öppna den berörda posten med Edit, granska förslaget via Apply Fix och bekräfta med Update. Ändra inte namn; ett ändrat namn gör att brandväggsimporten skapar ett nytt undantag i stället för att uppdatera det befintliga.
6. Kontrollera förslaget med positiva och negativa fall samt långa icke-matchningar. För nya värdmönster skiljer Exact host only och Domain + all subdomains mellan avsedda omfattningar; reparationen får inte oavsiktligt tillåta subdomäner. En automatisk korrigering ersätter varken detta beslut eller testet av skyddseffekten.
7. Kontrollera importkonfigurationen under Preview och jämför med originalet: endast godkända regex ska ändras, inte namn, källor, målkriterier, aktivering eller alternativ för överhoppade kontroller. Spara det godkända arkivet via Download > Download TAR.

Config Studio behandlar konfigurationsdata i webbläsaren på enheten; parsning, analys och rapportgenerering laddar inte upp dessa data externt. Lokala filer, nedladdningar och HTML-rapporter förblir ändå konfidentiella. Överför inte konfigurationer till andra analysverktyg online. Att redigera eller ladda ned i Config Studio ändrar ännu inget på brandväggen.

Alternativ: redigera Entities.xml kontrollerat

Utan Config Studio redigeras samma selektivt exporterade arbetskopia i en textredigerare. Ändra endast de berörda URL-mönstren; ersätt inte generellt alla punkter i XML-filen. XML-struktur, objektnamn och övriga fält förblir oförändrade. Kontrollera före paketeringen att XML:en är välformad och granska hela diffen. Importera inte vid oklar syntax eller oväntade extrafiler.

Behåll filnamnet exakt Entities.xml och paketera filerna i ett nytt TAR-arkiv med samma struktur som originalet, inte i ZIP eller under en extra katalog. Om originalet innehåller fler filer får dessa inte tyst utelämnas. Den enkla Web Exception-proceduren får inte tillämpas på andra moduler eller känsliga, ömsesidigt beroende objekt.

Importera, kontrollera effekten och återställ

Importen skriver över matchande befintliga inställningar. Ett arkiv som laddats upp utan fel bevisar varken en snäv matchning eller oförändrat skydd. Godkänn först diffen och importera sedan under det överenskomna underhållsfönstret.

Under Backup & firmware > Import export > Import väljer man med Browse den kontrollerade .tar och kör Import. Kontrollera importmeddelandena efter fel; jämför därefter namn och antal poster, aktiveringsstatus, Matching URLs, kriterier och alternativ för överhoppade kontroller med det önskade tillståndet under Web > Exceptions. Inställningar utan matchande importpost ligger kvar; importen tar inte automatiskt bort oönskade extra undantag.

Skapa sedan nya anslutningar, upprepa de befintliga positiva och negativa testerna med loggar och jämför CPU-förlopp och processbelastning med baslinjen vid en prestandareparation. Stoppa utrullningen vid fel och inaktivera det berörda undantaget kontrollerat om följderna för programmet är acceptabla. För riktad återställning kan den oförändrade selektiva exporten från samma brandvägg importeras; uteslut först mellanliggande ändringar, eftersom även dessa annars skulle skrivas över. Återaktivera inte ett bevisligen för brett tidigare tillstånd utan granskning. Återställning av en fullständig säkerhetskopia förblir den separat planerade nödvägen, inte det första återställningssteget för en enskild regex. Kontrollera konfigurationen och skyddssökvägen igen efter varje återställning.

Planera WebFilterException via XML API

Den selektiva importen av Entities.xml ovan är inte en generell instruktion för XML API. Objektreferenserna för SFOS 22.0 och 23.0 beskriver Add Web Filter Exception / Update Web Filter Exception med objektet WebFilterException. Följande mappningar hjälper till att granska en planerad automation; de utgör inte en fullständig begäran som är färdig att skicka. Åtkomst, skyddade inloggningsuppgifter, explicit operation, versionsanpassad struktur för begäran och säker tolkning av svar ingår i det centrala arbetsflödet Använd XML API säkert. Inga skrivningar görs utan syntax som har bekräftats för den aktuella builden.

Skilj på aktivering, skip-flaggor och DomainList

Enabled aktiverar undantaget och tillåter on eller off. De fem skip-flaggorna tillåter också on eller off, men anger att en kontroll ska hoppas över, inte aktiveras: HttpsDecrypt för HTTPS-dekryptering, VirusScan för skanning efter skadlig kod, PolicyCheck för Web Policy-kontroller, ZeroDayProtection för Zero-Day-skydd och CertValidation för validering av HTTPS-certifikat. on för en skip-flagga innebär alltså att skydd kringgås. De ovan beskrivna följderna för skyddet gäller fortfarande, särskilt att Zero-Day automatiskt hoppas över när skanning efter skadlig kod hoppas över. Dra inte slutsatsen att en post redan är aktiv eller matchar utifrån en satt skip-flagga.

Referensen visar upprepningsbara kriterier under DomainList och separata reglage på objektet:

• EnableSrcIP med SrcIp: kontroll av käll-IP; klienten hör hemma här.
• EnableDstIP med DstIp: kontroll av mål-IP; webbplatsens adress hör hemma här.
• EnableURLRegex med URLRegex: kontroll av URL-mönster, inte en domänlista som automatiskt omfattar subdomäner.
• EnableWebCat med WebCategory: kontroll av webbkategori.

De fyra reglagen är skalära yes/no-värden, inte on/off. De fyra kriterierna är strängarrayer som tillåter flera värden; för varje post i SrcIp och DstIp anger referensen högst 43 tecken. En ifylld array ersätter inte ett bekräftat aktiveringsreglage. Enligt matchningslogiken måste olika aktiverade kriterietyper matcha med AND, medan värden inom en typ matchar med OR. Ytterligare URL-mönster kan därför bredda matchningen. Den ovan dokumenterade, ännu oklara TLS-begränsningen för kombinerade käll- och mål-IP-undantag kvarstår: att båda API-fälten finns bevisar inte att kombinationen är tillåten. Skapa inte ett bredare undantag från skyddskontrollerna genom att utelämna ett kriterium.

För URLRegex krävs fortfarande förankring i början, escape för punkterna i värdnamnet, en tydlig värdgräns, ASCII/Punycode samt positiva och negativa tester och tester med långa icke-matchningar. Mönstret i API-referensen är inte en godkänd tillåtelselista och ersätter varken dessa tester eller begränsningen för HTTPS-sökvägar. Enbart kontroll av XML-syntaxen bevisar inte att matchningen är säker.

Name är den enda parameter som är markerad som obligatorisk: en skalär sträng med högst 60 tecken; ^, ;, ', " och \ är inte tillåtna. Den valfria parametern NewName används för namnbyte och har samma begränsningar. Den ska inte likställas med att skapa en ny post genom ett ändrat namn vid selektiv import. Desc är en valfri skalär sträng med högst 250 tecken; IsDefault markerar ett standardundantag med skalärt yes/no och ger inte behörighet att ändra standardobjekt. Övriga parametrar är valfria och deras defaultkolumner är tomma. Detta innebär varken ett bestämt standardvärde eller ett löfte om att utelämnade värden bevaras vid en uppdatering. Spara först det lagrade tillståndet och definiera en fullständig jämförelse mellan önskat och faktiskt tillstånd.

Klassificera svar efter operation, kod och symbol

Båda objektreferenserna innehåller exakt dessa mappningar. Operationsbeteckningarna och symbolerna lämnas avsiktligt oförändrade:

Dessa XML-koder är inte HTTP-statuskoder. Message.* förblir en oupplöst dokumentationssymbol, inte ett verifierat meddelande vid körning eller en entydig felorsak. Framför allt får inget numeriskt maximum härledas från Message.WebExceptionsLimit. Add och Update har olika symboler för lyckat resultat respektive fel; mappningarna för 502 och 522 vid Add överförs inte till Update.

Spara det faktiska svaret med operation och XML-kod på ett skyddat sätt, även vid timeout eller oklart resultat. Före varje nytt skrivförsök ska den faktiskt lagrade posten kontrolleras via en läsande fråga som har bekräftats för den aktuella builden eller under Web > Exceptions: gammalt och eventuellt nytt namn, antal, aktivering, samtliga kriterier och skip-flaggor. Inte heller ett rapporterat lyckat resultat ersätter denna jämförelse. Om en post redan finns ska den inte blint skapas på nytt, döpas om eller skrivas över, och kriterier ska inte tas bort på chans. Stoppa vid oklart eller delvis ändrat tillstånd och klargör situationen med den brandväggsansvarige utifrån svaret, det tidigare tillståndet och det önskade tillståndet. Efter en bekräftad ändring ska nya anslutningar upprättas och de befintliga positiva och negativa testerna genomföras; först dessa kontrollerar skyddseffekten. Den centrala API-guiden förklarar även varningar, delvis lyckade operationer och ett säkert tillvägagångssätt utan blinda återförsök.

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