Konfigurera Sophos Firewall Web Protection med webbpolicyer

Sophos Firewall Web Protection styr vilka webbplatser, kategorier och webbinnehåll användare får åtkomst till. I praktiken är Web Protection dock inte bara en enkel kryssruta. En webbpolicy måste planeras noggrant, aktiveras i en lämplig brandväggsregel och sedan testas med verklig trafik.

Många fel uppstår eftersom en webbpolicy finns men inte tillämpas på någon aktiv brandväggsregel. Andra problem är relaterade till HTTPS, TLS-inspektion, QUIC, användarigenkänning, regelordning eller för grova undantag. Den meningsfulla processen är därför: planera policy, bygga regel, aktivera, testa och övervaka i drift.

Vilken artikel om Web Protection passar?

Web Protection överlappar med brandväggsregler, TLS-inspektion, QUIC, rapportering och undantag. Beroende på uppgift kan en mer specifik artikel passa bättre:

• Grundläggande inställning av Web Protection och webbpolicyer: Denna artikel.
• Utvärdera webbkategorier, URL-grupper och omedelbara varningar: Använd Sophos Firewall webbkategorier och omedelbara varningar.
• Dekryptera och kontrollera HTTPS-trafik: Införa Sophos Firewall TLS-inspektion korrekt.
• Distribuera CA-certifikat för hanterade klienter: Distribuera Sophos Firewall CA-certifikat för TLS-inspektion.
• Klassificera QUIC och HTTP/3 vid webbfiltreringsproblem: Blockera Sophos Firewall QUIC och HTTP/3 korrekt.
• Ta reda på vilken brandväggsregel och policy som verkligen gäller: Testa Sophos Firewall-regel med Log Viewer, Policy tester och Packet Capture.
• Utvärdera webb- och säkerhetshändelser under längre tid: Central Firewall Reporting eller Skicka syslog till SIEM.

Så förblir analysen ren: Först måste det vara klart om brandväggsregeln matchar. Därefter kontrollerar man webbpolicy, kategori, användarkontext, QUIC, TLS-inspektion och loggning.

Vad Web Protection kontrollerar

Web Protection består av flera komponenter. Inte varje komponent behöver användas i varje miljö, men sambanden bör vara tydliga.

• Webbpolicy: Regler för tillåtna, varnade, blockerade eller kvotbaserade webbåtkomster.
• Webbkategorier: Sophos-kategorier och egna kategorier för webbplatser.
• URL-grupper: Egna domänlistor för riktade tillåt- eller blockregler.
• Filtyper: Kontroll av specifika nedladdnings- eller filtyper.
• Innehållsfilter: Termer eller mönster för innehållskontroll.
• Undantag: Riktade undantag från webb-, TLS- eller skanningsbeteende.
• Allmänna inställningar: SafeSearch, YouTube-begränsningar, Google Apps och Microsoft Entra ID Tenant Restrictions.
• Loggning och rapportering: Spårbarhet i Log Viewer, rapportering, Central eller SIEM.

Web Protection ersätter inte en ren brandväggsregelbas. Brandväggsregeln avgör först vilken trafik från vilken zon till vilken målzon som är tillåten. Webbpolicyn kompletterar denna regel med webbkontroll. Grunderna för regelordning, källa, destination, tjänster och säkerhetsprofiler finns i Förstå och bygga upp Sophos Firewall-regler korrekt.

Förutsättningar

Innan utrullning bör dessa punkter klargöras:

• Web Protection är licensierad eller ingår i det använda paketet.
• De berörda klientnäten har egna brandväggsregler.
• Loggning är aktiv i de relevanta reglerna.
• DNS och tid på brandväggen fungerar korrekt.
• Användarigenkänning är klar, om policyer ska gälla per användare eller grupp.
• TLS-inspektion är planerad om HTTPS-innehåll ska granskas noggrannare.
• QUIC/HTTP/3 tillåts eller blockeras medvetet.
• Det finns en pilotgrupp och en återfallsplan för affärskritiska sidor.

Särskilt viktigt är separationen efter målgrupper. En webbpolicy för vanliga klienter, servrar, gäster, VPN-användare och hanteringssystem bör inte vara densamma. Servrar behöver ofta mindre webbläsarkontroll men strängare mål- och uppdateringslistor. Gäster behöver ofta kategorier och bandbreddsbegränsning men ingen åtkomst till interna resurser.

Om webbpolicyer ska reagera på användare eller grupper måste användarigenkänningen fungera. AD SSO, Captive Portal, STAS, SATC eller andra metoder bör inte upptäckas först under webbpolicyutrullningen. I Log Viewer måste det synas om en request bedömdes som känd användare, som grupp eller som Anybody respektive okänd användare.

Planera webbpolicy

En bra webbpolicy börjar inte i gränssnittet utan med några tekniska beslut.

Definiera målgrupper

Först fastställs för vem policyn gäller:

• Standardklienter i LAN
• Hanterade bärbara datorer via VPN
• Gäst-WLAN
• Utbildningsrum eller skolmiljöer
• Servrar med utgående HTTP/HTTPS-åtkomst
• Privilegierade administratörsarbetsplatser

Om samma brandväggsregel innehåller flera mycket olika grupper blir Web Protection svår att förstå. Bättre är separata regler och policyer, till exempel LAN_USERS_WEB, GUEST_WEB eller SERVER_UPDATES_WEB.

Fastställ kategorier och URL-grupper

Sophos-webbkategorier är bra för bred styrning: Malware, Phishing, Adult Content, Anonymizer, Streaming, Social Media eller Games. URL-grupper är bättre när enskilda domäner ska tillåtas eller blockeras specifikt.

Typisk användning:

• Blockera kända riskkategorier: Webbkategori.
• Tillåta specifika SaaS-domäner: URL-grupp.
• Hantera enskild felkategoriserad domän: URL-grupp eller egen kategori.
• Begränsa streaming tidsmässigt: Webbpolicy med schema eller kvot.
• Varningssida istället för hård blockering: Webbpolicy med varningsåtgärd.

URL-grupper bör inte bli en osorterad samlingslista. Om många domäner läggs till behöver listan en ägare, ett syfte och ett granskningsdatum. För mycket stora eller dynamiska listor är Sophos Firewall Threat Feeds eller andra arkitekturkomponenter ofta mer lämpliga.

För rena domänmatchningar är URL-grupper oftast bättre än egna Web Categories. Sophos påpekar att URL-grupper är mer performanta och kan ge färre false positives. Egna kategorier är användbara när en domän dessutom ska ingå i en egen policylogik utöver sin standardkategori från Sophos.

Keywords i egna kategorier bör användas mycket försiktigt. Keywords kontrolleras mot hela URL:en inklusive path och query. Ett allow baserat på ett keyword kan därför träffa oavsiktligt om ordet finns i en queryparameter på en annan domän. För allow-beslut är konkreta domäner eller URL-grupper oftast renare; keyword-regler passar bättre för smala blockeringsfall.

Sätt tillåt-regler försiktigt

Tillåt-regler i webbpolicyer bör vara snäva. En tillåt-regel högt upp kan göra senare blockregler ineffektiva eftersom Sophos webbpolicy-regler utvärderas uppifrån och ner. Detta är särskilt relevant om en URL-grupp, en filtypsregel eller ett kategoriundantag står ovanför andra regler.

Praktiskt beprövat:

1. Specifika tillåtna affärsundantag högst upp.
2. Kritiska blockkategorier därefter.
3. Varnings- eller kvotregler för gråzoner.
4. Allmänt tillåten webtrafik först i slutet.

Skapa webbpolicy

Webbpolicyn skapas under följande meny:

Web > Policies

Grundläggande steg:

1. Välj Add policy.
2. Ge ett beskrivande namn, till exempel LAN_USERS_STANDARD_WEB.
3. Lägg till regler.
4. Kontrollera search engine enforcement, till exempel SafeSearch eller YouTube restrictions.
5. Sätt policy quota status om Quota-åtgärder används.
6. Kontrollera Advanced settings, särskilt logging, reporting, stora nedladdningar, Google Apps och Microsoft Entra ID Tenant Restrictions.
7. Spara policyn.

En regel i webbpolicyn skapas med Add rule. Brandväggen skapar först en inaktiverad standardregel som blockerar HTTP för Anybody. Därefter justeras fälten medvetet:

1. Öppna Users och sätt medvetet Anybody, konkreta användare eller grupper.
2. Öppna Activities och välj All web traffic, User activities, Categories, URL Groups, File types eller Content filters.
3. Lägg till Content filters vid behov. För Content filters använder brandväggen samma åtgärd för HTTPS som för HTTP.
4. Sätt Action för HTTP: Allow, Warn, Block eller Quota.
5. Kontrollera HTTPS-åtgärden: Use action, Allow HTTPS, Warn HTTPS, Block HTTPS eller Quota HTTPS.
6. Sätt Constraints om regeln bara ska gälla enligt ett schema.
7. Kontrollera regelpositionen inom policyn.
8. Aktivera regelns status.
9. Spara policyn.

En webbpolicy i sig har ingen effekt. Policyn måste sedan användas i en brandväggsregel. Detta är ett av de vanligaste konfigurationsfelen.

Regler i en webbpolicy utvärderas uppifrån och ned. En Allow-regel för All web traffic ovanför en Block-regel gör blockregeln praktiskt taget verkningslös. Därför bör man efter varje ändring kontrollera inte bara regelns innehåll, utan också ordningen och statusbrytaren.

Aktivera webbpolicy i brandväggsregel

Brandväggsregeln finns under:

Rules and policies > Firewall rules

För normal klient-internettrafik ansvarar oftast en regel från LAN eller en klientzon till WAN. Där väljs den lämpliga webbpolicyn i avsnittet Web filtering.

Kontrollpunkter i brandväggsregeln:

• Källzon och källnätverk matchar klientnätet.
• Destinationszon är vanligtvis WAN.
• Tjänster innehåller HTTP/HTTPS eller de önskade webbtjänsterna.
• Log firewall traffic är aktiv.
• I avsnittet Web filtering är rätt webbpolicy inställd.
• Scan HTTP and decrypted HTTPS är aktiverad när web-malware- eller innehållsskanning ska fungera.
• Use Zero-day protection är bara meningsfull om filer skannas via HTTP eller dekrypterad HTTPS.
• Block QUIC protocol är medvetet inställd.
• Use web proxy instead of DPI engine är medvetet aktiverad eller medvetet inaktiverad.
• TLS-inspektion planeras separat och förväxlas inte med webbpolicy.

Sophos Firewall aktiverar Block QUIC protocol som standard när en webbpolicy väljs i regeln eller Scan HTTP and decrypted HTTPS aktiveras. Det är ofta vettigt eftersom QUIC inte kan skannas som klassisk HTTPS-trafik. Ändå bör kryssrutan testas medvetet: webbläsare, Google-tjänster, samarbetsverktyg och enskilda SaaS-applikationer kan ändra beteende när QUIC blockeras.

Om Application Control också används i samma brandväggsregel finns en viktig överlappning: vissa Micro Apps, till exempel uppladdningar eller nedladdningar i Dropbox eller Gmail, identifieras via URL-detaljer. I DPI-miljöer kräver denna identifiering en lämplig SSL/TLS Inspection-regel med dekryptering. Application Control kan då utvärdera sådana Micro Apps även om webbpolicyn inte är den egentliga beslutspunkten.

Om en mer allmän regel ovanför den önskade webbregeln matchar, når trafiken inte webbpolicyn. I sådana fall hjälper Testa Sophos Firewall-regel med Log Viewer och Packet Capture.

HTTPS, TLS-inspektion och QUIC klassificera

En stor del av webtrafiken är HTTPS. Utan TLS-inspektion ser brandväggen mindre innehåll. Kategorier, SNI, certifikat, mål-IP, domäninformation och metadata hjälper, men ersätter inte en fullständig innehållsgranskning.

DPI eller Web Proxy?

Vid Web Protection måste man tidigt bestämma om den berörda brandväggsregeln använder DPI Engine eller Web Proxy. Detta beslut påverkar vilka funktioner som gäller och vilka loggar som senare är relevanta.

• DPI-läge: Modern standard för många klient-internetregler. TLS-inspektion sker via SSL/TLS-inspektionsregler, kvot stöds inte.
• Web Proxy-läge: Miljöer med explicit proxy-beteende eller policykvot. Proxy-beteende, webbläsar-/klientkompatibilitet och proxy-loggar medvetet kontrollera.

I många installationer är DPI-läge den bättre startpunkten. Men om tidskontingenter behövs via Quota räcker inte en ren DPI-regel. Då måste Web Proxy-läge planeras och testas medvetet. Detta beslut bör fattas före utrullning eftersom en senare förändring kan skapa andra felbilder, loggar och användarupplevelser.

Web Proxy filtrerar i brandväggsregeln bara de klassiska portarna 80 och 443. DPI Engine kan inspektera HTTP- och SSL/TLS-trafik även på andra portar, om regeln och SSL/TLS Inspection-reglerna passar. Vid direct proxy-design måste det dessutom vara klart om klienterna använder proxyn explicit eller om normal transparent klienttrafik går genom regeln. Annars testar man lätt fel väg.

TLS-inspektion

Om nedladdningar, malware-skanning, vissa webbkategorier eller innehållskontroller ska granskas pålitligt måste TLS-inspektion planeras. För detta behövs ett betrott CA-certifikat på klienterna, lämpliga TLS-regler, undantag och en ren pilot.

Utrullningen finns i Rulla ut TLS-inspektion på Sophos Firewall steg för steg. För distribution och validering av CA-certifikatet passar Installera Sophos Firewall CA-certifikat för HTTPS-skanning.

QUIC och HTTP/3

Moderna webbläsare använder ofta QUIC respektive HTTP/3 över UDP 443. Detta kan störa webbfilter-, TLS-inspektions- och skanningsförväntningar om man egentligen vill kontrollera klassisk HTTPS-trafik över TCP.

I många företagsmiljöer är det vettigt att blockera QUIC i klient-internetregler så att webbläsare faller tillbaka på HTTPS över TCP. Detaljerna finns i Blockera Sophos Firewall QUIC och HTTP/3 korrekt.

SafeSearch, YouTube och Tenant Restrictions

Sophos Firewall kan i webbpolicyer sätta ytterligare sök- och molnkontroller.

Typiska alternativ:

• Enforce SafeSearch för Google, Yahoo och Bing.
• Enforce YouTube restrictions för begränsat YouTube-innehåll.
• Restrict login domains for Google Apps för tillåtna Google-domäner.
• Apply Microsoft Entra ID tenant restrictions för Microsoft-moln-tenant-styrning.

Dessa funktioner är hjälpsamma men inte magiska. Vid HTTPS beror effektiviteten delvis på HTTPS-skanning respektive TLS-inspektion. Dessutom ersätter de inte identitets- och molnappstyrning i Microsoft 365 eller Google Workspace. För produktiva miljöer bör man testa effekten med verkliga testanvändare och de berörda webbläsarna.

För Bing och Yahoo kan SafeSearch bara tvingas på HTTPS-anslutningar om HTTPS scanning är aktiv i den berörda brandväggsregeln. Google Apps-inloggningsbegränsningar gäller endast Google-hostade domäner. Microsoft Entra ID Tenant Restrictions behöver rena tenant-värden och bör testas med verkliga Microsoft-molninloggningar, inte bara med en exempel-URL.

Kvot och varningssidor

Webbpolicyer kan inte bara blockera eller tillåta. Med varnings- eller kvotåtgärder kan man medvetet informera användare eller tillåta tidsbegränsad åtkomst.

Meningsfulla exempel:

• Användare får medvetet bekräfta en varning för vissa gråzoner.
• Streaming eller shopping är endast tillåtet tidsbegränsat.
• Skol- eller laboratoriemiljöer tillåter vissa kategorier endast under definierade tider.

Viktigt: Policykvot stöds inte i DPI-läge. Om tidskontingenter behövs måste Web Proxy-läge användas. Detta bör beslutas tidigt eftersom DPI och Web Proxy har olika egenskaper och begränsningar.

Allowed time quota sätts på webbpolicynivå och gäller för alla regler i denna policy som använder en Quota-åtgärd. Om två kategorier behöver olika tidskvoter är separata webbpolicyer renare än en enda policy med blandade kvotförväntningar. Kvoter återställs lokalt vid midnatt och kan inte sättas till noll.

Policy Overrides är ett annat verktyg än kvoter. De gör det möjligt för auktoriserade användare i User Portal att skapa tillfällig åtkomst till normalt blockerade webbplatser. Det kan vara användbart för skolor eller supportscenarier, men kräver tydliga gränser: kategorier som inte kan åsidosättas, behöriga personer, tidsfönster och granskning av overrides.

Web Exceptions och TLS-undantag

Web Exceptions är kraftfulla och därför farliga om de används som snabb reparation. Ett undantag under Web > Exceptions kan hoppa över skyddskontroller för matchande trafik, oberoende av vilken webbpolicy som gäller. Beroende på val hoppas HTTPS decryption, HTTPS certificate validation, Malware and content scanning, Zero-day protection eller Policy checks över.

För DPI-miljöer gäller en viktig begränsning: Web Exceptions träder bara i kraft om en webbpolicy är satt, Malware and content scanning är aktiv eller ATP är aktiv. SSL/TLS Exclusion Rules är däremot rätt plats om det bara handlar om att inte dekryptera vissa TLS-anslutningar. Den operativa skillnaden är viktig:

• SSL/TLS Exclusion Rule: undantar TLS-anslutningar riktat från dekryptering, typiskt på grund av Certificate Pinning eller inkompatibilitet.
• Web Exception: kan hoppa över webbpolicykontroller, malware-skanning, Zero-Day-analys eller certifikatvalidering.
• URL Group in Web Policy: styr Allow, Warn, Block eller Quota inom den normala policylogiken.

För undantag bör man undvika rotdomäner och för breda URL-regex-mönster. Ett mönster som example.com kan också förekomma i paths eller queryparametrar på andra domäner. Bättre är konkreta hostnames, passande URL-grupper och tydlig scope efter källa, destination, kategori eller användargrupp.

Undantag kombinerar sina olika kriterier med AND. Inom en kriterietyp, till exempel flera URL Patterns, gäller däremot OR. Det är praktiskt men felkänsligt: ett undantag med URL Pattern och Source IP gäller bara om båda matchar. Ett undantag med mycket många URL Patterns kan däremot verka mycket bredare än tänkt.

Var särskilt försiktig med Policy checks. Om en Web Exception hoppar över Policy checks kan det indirekt försvaga andra regelbeslut. I kombination med Synchronized Security Heartbeat kan ett sådant undantag leda till att web requests inte blockeras som förväntat, trots att Heartbeat-kontroller är satta i brandväggsregeln.

Testa Web Protection

Efter att ha sparat bör man inte bara kontrollera om policyn finns. Avgörande är om den gäller för verklig trafik.

1. Använd Policy Tester

Under Web > Policies finns Policy tester tillgänglig. Med den kan man kontrollera vilken policybeslut som förväntas för användare, URL och kontext.

Policy Testern är en bra förkontroll men ersätter inte ett verkligt paketflöde. En brandväggsregel, NAT, TLS-inspektion, QUIC eller routing kan ändå förhindra att den förväntade policyn gäller för verklig trafik.

2. Verklighetstest med pilotklient

Med en pilotklient kontrollera:

• tillåten affärssida
• blockerad kategori
• varningskategori
• URL-grupp Tillåt
• URL-grupp Blockera
• HTTPS-sida med och utan TLS-inspektion
• Nedladdning av en ofarlig testfiltyp
• Beteende med QUIC aktiv eller blockerad

3. Kontrollera Log Viewer

I Log Viewer bör det synas:

• vilken brandväggsregel som träffades
• vilken användare som identifierades, om relevant
• vilken webbkategori eller URL-grupp som var inblandad
• om HTTPS, TLS-inspektion eller malware-skanning var inblandade
• om åtgärden tillät, varnade eller blockerade
• om en Web Exception eller TLS Exclusion tillämpades
• om en nedladdning hanterades annorlunda på grund av storlek, malware-skanningsfel eller Zero-Day-analys

För Syslog eller SIEM räcker inte URL och action. För en robust analys behövs även Firewall Rule ID, användare, kategori, webbpolicy, HTTP-metod, status, skanningsresultat, undantagsindikering och SSL/TLS-relation. Om dessa fält saknas i SIEM eller normaliseras fel ser Web Protection snabbt otydligare ut i rapporteringen än den faktiskt är på brandväggen.

För djupare felsökning är även loggfiler relevanta. Tilldelningen finns i Sophos Firewall Troubleshooting: Services och Logs.

Omedelbara varningar och rapportering

Om vissa kategorier inte bara ska blockeras utan aktivt rapporteras kan omedelbara varningar vara användbara. Detta är särskilt användbart i skolor, strikt reglerade miljöer eller områden med tydlig internetanvändningspolicy.

De tre utvärderingsvägarna besvarar olika frågor:

• Snabbt e-postmeddelande vid få känsliga webbkategorier: Omedelbara varningar.
• Återkommande rapporter, trender och användar- eller kategoriutvärderingar: Central Firewall Reporting.
• Längre lagring, korrelation med andra system eller SOC-processer: Syslog eller SIEM.

Innan omedelbara varningar bör det vara klart vem som får meddelandet, vilka kategorier som verkligen utlöser en reaktion, hur falska positiva hanteras och när kategoriurvalet granskas. En bred varningslista utan ägare skapar snabbt e-postbrus men ingen bättre säkerhet.

För teknisk aktivering och triage finns Använd Sophos Firewall webbkategorier och omedelbara varningar. För långsiktiga utvärderingar bör Central Firewall Reporting eller Skicka Sophos Firewall syslog till SIEM övervägas.

Hantera ändringar och undantag i drift

Web Protection förändras ständigt i drift. Nya SaaS-tjänster tillkommer, enskilda domäner kategoriseras felaktigt, avdelningar behöver tillfälligt åtkomst och webbläsarbeteende förändras. Utan en tydlig process uppstår snabbt breda undantag som senare ingen kan förklara.

För varje ändring bör man minst dokumentera:

• Vem behöver åtkomst? förhindrar globala undantag för få användare.
• Vilken domän, kategori eller filtyp är berörd? separerar URL-grupp, webbkategori och filtyp tydligt.
• Är det ett tillfälligt eller permanent undantag? tvingar till granskning istället för permanenta skuggfrisläppanden.
• Vilken brandväggsregel och webbpolicy är berörda? förhindrar ändringar i fel regel.
• Hur testas det? gör framgången i Log Viewer spårbar.

En liten förändringsprocess har visat sig vara effektiv:

1. Registrera förfrågan med användare, URL, tidpunkt, affärsskäl och skärmdump eller felmeddelande.
2. Kontrollera i Log Viewer vilken brandväggsregel, webbpolicy, kategori och åtgärd som gällde.
3. Besluta om kategorin är grundläggande felaktig, om endast en enskild domän ska tillåtas eller om förfrågan avslås.
4. Om ett undantag behövs, arbeta så snävt som möjligt: enskild URL-grupp istället för hela kategori, enskild användargrupp istället för hela LAN.
5. Testa ändringen i en testrule eller pilotgrupp.
6. Efter att ha sparat, genomför ett verklighetstest och dokumentera Log Viewer, kategori, Rule ID och användarkontext.
7. Sätt ett granskningsdatum, särskilt för tillfälliga affärsundantag.

Tillfälliga undantag bör namnges tydligt, till exempel TMP_ALLOW_vendor-portal_until_2026-07-31. Permanenta affärsundantag behöver också en ägare. Om ingen är ansvarig för ett undantag bör det inte förbli permanent i policyn.

Om många enskilda domäner för samma tjänst uppstår är ofta inte webbpolicyn problemet, utan tjänstens arkitektur. Då bör man överväga om en egen brandväggsregel, en egen webbpolicy, en väl underhållen URL-grupp eller en annan kontrollpunkt passar bättre. För dynamiska IOC- eller blocklistor är webbpolicyundantag oftast fel plats; för detta passar snarare Sophos Firewall Threat Feeds.

Återställning och nödfrihet

En ändring i webbpolicy kan omedelbart påverka produktivt arbete. Därför bör man före större ändringar fastställa hur det gamla tillståndet återställs.

Praktiska återställningsalternativ:

• Duplicera eller dokumentera den berörda webbpolicyn före ändringen
• Testa ändringen först i en pilotregel eller liten användargrupp
• Ta inte bort den gamla brandväggsregeln eller den gamla webbpolicyn omedelbart
• Definiera tidsfönster, testanvändare och återfallskriterium
• Efter att ha sparat, kontrollera Log Viewer, Rule ID och kategori beslut

För akuta blockeringar bör man inte reflexmässigt införa en bred tillåt-regel högst upp. Bättre är ett snävt, tidsbegränsat undantag med tydlig URL-grupp, användargrupp och granskningsdatum. Om trycket är högt kan ett tillfälligt undantag stabilisera driften, men det måste sedan utvärderas igen.

Typiska fel

Webbpolicy gäller inte

Oftast är policyn inte aktiverad i rätt brandväggsregel, regeln träffas inte, en regel högre upp tillåter trafiken eller användarkontexten passar inte. Kontrollera först Log Viewer och Rule ID.

HTTPS blockeras inte som förväntat

Utan TLS-inspektion ser brandväggen färre detaljer. Beroende på mål kan ett domän- eller kategori beslut fungera, medan innehållsgranskning, filtyper eller vissa sökfunktioner är begränsade.

Om anslutningen inte dekrypteras kan brandväggen ändå använda SNI- eller domäninformation för policybeslut. Blockeringssidor, varningssidor, filtyper, Content Filters, malware-skanning och Zero-Day-analys behöver däremot mer synlighet. Därför bör man i Log Viewer inte bara kontrollera webbpolicyåtgärden, utan också SSL/TLS Inspection-status.

QUIC kringgår förväntningen

Om webbläsare använder UDP 443 kan trafiken behandlas annorlunda än klassisk HTTPS över TCP. I klientregler bör man medvetet besluta om QUIC blockeras.

Tillåt-regel är för högt upp

En bred tillåt-regel i början av webbpolicyn kan upphäva senare blockregler. Regelordning inom webbpolicyn är lika viktig som regelordning i brandväggsregellistan.

För många undantag

Undantag löser snabbt ett enskilt problem men kan minska skyddseffekten. Varje undantag behöver syfte, ägare och granskningsdatum. Om många undantag uppstår är ofta policystrukturen fel eller en affärsapplikation behöver en egen regel.

Särskilt riskabla är Web Exceptions som hoppar över Policy checks eller Malware and content scanning. Om det bara är HTTPS decryption som stör är en SSL/TLS Exclusion oftast smalare och lättare att förstå.

Rapportering visar inget

Då bör loggning, rapportering, brandväggsregel, policyval eller loggöverföring kontrolleras. En policy utan loggning är svår att utvärdera i drift.

Driftchecklista

• Web Protection licensstatus kontrollerad.
• Klient-, server-, gäst- och VPN-trafik utvärderad separat.
• Webbpolicy med beskrivande namn skapad.
• Kritiska kategorier och URL-grupper planerade medvetet.
• Regelordning inom webbpolicyn kontrollerad.
• Webbpolicy aktiverad i lämplig brandväggsregel.
• Log firewall traffic, webbpolicyloggning och Reporting aktiv.
• Webbpolicyregler är aktiverade och i rätt ordning.
• TLS-inspektion och CA-certifikat för pilotgrupp kontrollerad.
• QUIC-strategi definierad.
• Web Exceptions och TLS Exclusions dokumenterade separat.
• Policy Tester och verklighetstester genomförda.
• Log Viewer och rapportering kontrollerad.
• Ändringsprocess för webbpolicyundantag definierad.
• Tillfälliga undantag med utgångsdatum försedda.
• Undantag dokumenterade med ägare och granskningsdatum.

FAQ