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.
• Förstå Single eller Dual Engine, skanningsfel, storleksgränser och ett verkligt malware-test: Konfigurera och testa malware-skanning i Sophos Firewall.
• 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.
• Search engine enforcement: SafeSearch och YouTube-begränsningar.
• Advanced settings: begränsningar för Google Apps-inloggningsdomäner 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.

Användarkriterierna i den matchande brandväggsregeln har företräde framför Users i webbpolicyn; policyn kan begränsa omfattningen men inte lägga till en användare som regeln utesluter.

Minsta fungerande konfiguration

Skapa policyn under Web > Policies och aktivera minst ett avgränsat Allow/Block-beslut i den.

Redigera därefter en verklig regel under Rules and policies > Firewall rules med Action: Accept, rätt Source Zone och Source Network, Destination Zone och Destination Network samt nödvändiga Services. Aktivera Log firewall traffic och tilldela webbpolicyn under Web filtering. Kontrollera bara att befintlig NAT stämmer med den nuvarande internetvägen; inför inte ett nytt NAT-beteende enbart för policyn. Dokumentera Rule ID och resultatet för samma avsiktligt tillåtna och blockerade requests före och efter ändringen från verklig käll- och användarkontext. Godkänn först när Log Viewer visar förväntad Rule ID, policy och verkliga Allow- och Block-resultat.

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

Kategorin highly objectionable criminal activity blockeras alltid. Varken policyregler eller undantag kan tillåta kategorin; SFOS döljer dessutom domänen i loggar och rapporter.

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.

Skapa och använd URL Groups säkert förklarar hur giltiga domänvärden, OR-logik, användning i Web Policy och TLS-undantag hänger ihop.

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 eller File types.
3. För innehåll, välj den separata fliken Content filters, välj filtret, aktivera and with content och behåll HTTPS som Use action.
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.

Importera innehållsfilterlistor korrekt

Content filters hanteras under Web > Content filters och väljs sedan under Activities i webbpolicyregeln. För större termlistor stöder Sophos en enkel .txt-fil. Filen får innehålla högst 2,000 rader och varje post får vara högst 80 tecken lång, inklusive blanksteg och skiljetecken.

Importfilen innehåller en term per rad och varje rad utvärderas som exact match. Rubriker, kommentarer, metadata eller extra kolumner ska inte finnas; använd UTF-8.

Säker arbetsgång:

1. Rensa termerna i en textredigerare och placera exakt en post per rad.
2. Spara filen som .txt med UTF-8-kodning.
3. Importera listan under Web > Content filters och ge den ett tydligt namn.
4. Öppna Content filters i Activities, välj filtret, aktivera and with content och behåll Use action.
5. Testa med en pilotklient en tillåten term och en term som avsiktligt matchar, och kontrollera åtgärden i Log Viewer.

Om en import avvisas eller enskilda termer inte tillämpas ska man först kontrollera antalet rader, teckenlängden, kodningen och osynliga extratecken. En bred Allow-regel ovanför Content filter-regeln får inte kringgå listan.

Skapa anpassade filtyper för webben

Sophos Firewall identifierar File types utifrån filändelsen eller MIME-headern. De inbyggda typerna kan inte redigeras. Skapa en anpassad typ under Web > File types > Add från en lämplig mall och lägg till de nödvändiga filändelserna utan inledande punkt eller MIME-headrar. Samma objekt kan sedan användas i policyer för webb- och e-postskydd.

Ange ett namn i dialogrutan Add. Template är valfritt och fyller i de vanliga filändelserna och MIME-headrarna för en kategori; du kan lägga till värden för den anpassade typen. Spara sedan med Save. Skriv inte en punkt före filändelsen: pdf är rätt och .pdf är fel. Inbyggda typer fungerar som mallar och kan inte redigeras; skapa en anpassad typ när något behöver ändras.

SFOS har de inbyggda kategorierna All executable files, Audio files, Backup files, Compressed files, Configuration files, Database files, Developer files, Disk image files, Document files, Dynamic files, Encoded files, Executable files, Image files, Page layout files, Plugin files, System files, Video files och Web files. Detaljvyn under Web > File types är den operativa källan för de filändelser och MIME-headrar som är konfigurerade för tillfället. Compressed files innehåller till exempel bland annat 7z, gz, rar, tar.gz och zip, medan Document files bland annat innehåller docx, xlsx, pptx, odt, rtf och pdf. Öppna därför den konkreta inbyggda typen i den egna SFOS-versionen och jämför den med det verkliga användningsfallet innan kategorin tillåts, i stället för att enbart utgå från namnet.

Den nya filtypen har ingen effekt i sig. Den måste väljas under Activities > File types i den berörda webbpolicyregeln. Kontrollera därefter åtgärden, regelns status och ordning samt att webbpolicyn fortfarande är tilldelad den brandväggsregel som faktiskt hanterar trafiken.

Validera med en representativ nedladdning och en avsiktligt liknande fil som inte ska matcha. Kontrollera webbpolicy och åtgärd i Log Viewer. En matchning på filändelse eller MIME-header är en policyklassificering, inte ett bevis på malware eller en genomförd Zero-Day-analys. För HTTPS beror den nödvändiga insynen också på TLS Inspection-sökvägen. Om typen inte matchar ska du först jämföra regelns status och ordning, den File Type som faktiskt valts, serverns Content-Type-svar, den synliga filändelsen och TLS Inspection-statusen. En felaktig eller generell MIME-typ från servern kan göra att testet ger ett annat resultat än filnamnet antyder.

Samla User Activities tydligt

Under Web > User activities > Add samlar en User activity Web Categories, File types och URL Groups i en återanvändbar aktivitet. Dessa element utvärderas med OR; en enda matchning räcker. Namnet syftar alltså inte på en inloggad användare utan på en samling webbkriterier.

Välj sedan User Activity under Activities i webbpolicyregeln. Det passar när samma kombination används i flera policyer. Validera med minst en matchning för varje ingående objekttyp och ett liknande fall som inte ska matcha.

Kontrollera regelordning och migrerade policyer

Webbpolicyregler utvärderas uppifrån och ned. Om exempelvis en Allow-regel för filtypen .mdb ligger ovanför en regel som blockerar en kategori, förblir .mdb-nedladdningar från den kategorin tillåtna. I DPI-läge kan den första anslutningen till kategorin tillåtas tills filtypen är känd; om filen därefter inte matchar avbryter brandväggen anslutningen utan att visa en blockeringssida. Om kategorin alltid ska blockeras måste dess regel ligga ovanför filtypens Allow-regel.

För migrerade äldre policyer gäller dessutom en hård gräns på 128 regler per policy. Om källan innehåller fler regler använder SFOS endast de första 128. Intilliggande regler för User Activities, Categories, URL Groups, File types och Dynamic Categories bör därför medvetet slås samman till kombinerade Activities före eller efter migreringen. Regelantal, ordning och verkliga Allow- och Block-tester ingår i migreringsvalideringen.

Återkommande tidsfönster skapas som ett separat schema. Förfarandet och avgränsningen mot en tidsstyrd brandväggsregel beskrivs i Konfigurera scheman för regler och policyer i Sophos Firewall.

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

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.
• På brandväggsregelns transparenta väg är Use web proxy instead of DPI engine aktiverad för SafeSearch, YouTube Restrictions och Google Apps-begränsningar; för andra funktioner och Direct Proxy väljs läget medvetet efter behov.
• 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.

Bedöma HTTPS, TLS-inspektion och QUIC

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: Passar miljöer med explicit proxybeteende eller policykvot; proxybeteende, webbläsar- och klientkompatibilitet samt proxyloggar måste kontrolleras medvetet.

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.

I en transparent brandväggsregel hanterar Transparent Web Proxy bara de klassiska portarna 80 och 443. På andra portar kan DPI Engine inspektera HTTP- och SSL/TLS-trafik om både brandväggsregeln och SSL/TLS Inspection-reglerna passar. Direct Proxy är däremot en separat, explicit väg som klienten väljer och kräver inte nödvändigtvis Use web proxy instead of DPI engine. Dokumentera därför vid varje test om klienten använder den transparenta vägen eller sin explicita proxykonfiguration.

Det fullständiga funktionsvalet, pilotmigreringen och de lägesspecifika kontrollerna finns i Jämför DPI Engine och Web Proxy korrekt.

Konfigurera Direct Web Proxy med en PAC-fil förklarar hur listener, PAC-fil, Device Access och en fungerande proxyregel hör ihop.

IPv6-only-klienter som når IPv4-only-webbmål använder en separat väg med två regler. NAT64 med Direct Web Proxy skiljer Web Policy i IPv6-regeln från Application Control och IPS i IPv4-egress.

Om Sophos Firewall ska vidarebefordra sina Web Requests till en parent proxy leder konfigurera en upstream proxy i WAN eller LAN/DMZ genom rätt regel- och NAT-väg för varje topologi.

När flera RDS-användare delar samma server-IP kan Per-Connection AD SSO för fleranvändarvärdar skilja de enskilda HTTP- och HTTPS-proxyanslutningarna åt. Metoden gäller inte trafik utanför proxyn och måste därför medvetet avgränsas mot SATC.

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

SafeSearch och YouTube finns i Search engine enforcement; Google Apps och Entra i Advanced settings.

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.

På brandväggsregelns transparenta väg kräver SafeSearch, YouTube Restrictions och Google Apps Use web proxy instead of DPI engine; en explicit Direct Proxy kan tillhandahålla dessa proxyfunktioner utan det alternativet i brandväggsregeln. Bing och Yahoo via HTTPS kräver dessutom HTTPS scanning. Hantera Entra Tenant Restrictions separat, testa verkliga Microsoft-inloggningar och behåll styrningen av identiteter och molnappar i Microsoft 365 eller Google Workspace.

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 Quota gäller inte Content filters eller Dynamic Categories och stöds inte av DPI. Ändringar fungerar inte med ogiltig policy, utan återstående tid eller när en Quota-session redan är aktiv.

Denna Policy Quota gäller för webbkategorier och är inte den användarbaserade Surfing Quota. Att skapa, tilldela och kontrollera förbrukningen för Surfing Quota och Network Traffic Quota följer ett separat arbetsflöde.

Kontrollera Policy Quota i drift

Under Web > Policy quota status visar SFOS den återstående tiden för enskilda användare i berörda Web Policies inom en 24-timmarsperiod. Den valda användaren kan återställas där med Reset. Detta är en medveten statusändring och ingen diagnosknapp: dokumentera först användare, policy, återstående tid, orsak och tidpunkt.

Denna reset gäller den tidsbaserade Policy Quota för en webbkategori. Den är inte samma sak som Reset user accounting för Surfing Quota eller Network Traffic Quota. En reset korrigerar varken fel regelordning eller saknad användaridentifiering.

Anpassa varnings- och blockeringssidor

Under Web > User notifications kan egna bilder och blockerings-, override-, quota- och varningsmeddelanden konfigureras. Platshållarna {category}, {user} och {url} infogar webbkategori, användarnamn och blockerad URL. Preview kontrollerar presentation och text, men inte om rätt Web Policy och brandväggsregel matchar produktionsanropet.

Meddelandet ska kort förklara varför åtkomsten blockerades eller varnades och var ett legitimt verksamhetsbehov kan rapporteras. Användarnamn och URL:er kan innehålla känslig information; sidan ska därför inte innehålla interna hemligheter, lösenord eller onödiga kontaktuppgifter.

Begränsa Policy Overrides säkert

Policy Overrides är ett annat verktyg än kvoter. Med Enable policy override kan auktoriserade användare skapa tillfällig åtkomst till normalt blockerade webbplatser i User Portal. Authorized users and groups begränsar vilka som får göra det och Blocked websites and categories anger mål som aldrig får åsidosättas. Allow manual access code entry aktiveras bara om användarskapade koder passar godkännandeprocessen.

Dokumentera först det tidigare läget och behöriga användare under Web > General settings > Policy overrides. Den behöriga användaren anger webbplatser eller kategorier, ett begränsat tidsintervall och en åtkomstkod för overriden i User Portal. När ett matchande blockerat mål begärs innehåller blockeringssidan ett extra fält för den koden. Om Allow manual access code entry är aktiverat får de angivna användarna skapa egna koder; om alternativet är avaktiverat måste de använda genererade koder. Detta val ska inte förväxlas med att ange en redan giltig kod på blockeringssidan.

Med View overrides kan befintliga overrides visas, aktiveras, avaktiveras och tas bort. Vid acceptanstestet ska en behörig testanvändare öppna ett matchande mål inom tidsintervallet med en giltig kod; utan kod, utanför tidsintervallet och för ett mål som aldrig får tillåtas genom en override ska den normala blockeringen fortfarande gälla. Jämför användare, Rule ID, webbpolicy, åtgärd och tid i Log Viewer. För HTTPS måste blockeringssidan kunna visas; enbart ett anslutningsavbrott ger inget inmatningsfält.

Vid återställning avaktiveras pilotoverriden via View overrides, och den ursprungliga blockeringen kontrolleras med en ny begäran. Först därefter tas en override som inte längre behövs bort, och endast de globala värden som ändrades under piloten återställs till sitt dokumenterade tidigare läge. Ta inte urskillningslöst bort andra användares befintliga overrides.

För AD-användare gäller My policy overrides bara huvudgruppen och enskilda användare, inte andra gruppmedlemskap. En matchande SSL/TLS-inspektionsregel med Action > Deny har fortfarande företräde. Om en godkänd override måste fungera i det läget planeras en snävt begränsad Web Exception som hoppar över HTTPS-dekryptering och testas separat med ett negativt fall; TLS-regeln försvagas inte generellt.

Web Exceptions och TLS-undantag

Att hoppa över HTTPS decryption tar bort beroende kontroller och tillåter ogiltiga servercertifikat; Malware and content scanning hoppar automatiskt över Zero-day protection. Hostnamnsmönster kan matcha i TLS, rena URL-sökvägar endast i HTTP eller redan dekrypterad HTTPS. URL Group är inget Web Exception-kriterium.

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 ska rotdomäner och för breda regex-mönster undvikas. Använd konkreta hostnames och tydlig scope efter källa, destination, kategori eller användargrupp; URL-grupper hör till webbpolicyns normala logik.

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

Den exakta sökvägen är Diagnostics > Tools > Pop-out tools > Policy tester. Firewall, SSL/TLS, and web testar den kombinerade transparenta vägen, medan Web policy only isolerar webbpolicybeslutet. Webbtestet representerar endast transparent webbåtkomst, tar inte hänsyn till SD-WAN-rutter och accepterar inte Source Networks med MAC-adresser. Om protokoll saknas används HTTP; om port saknas används standardporten för det valda protokollet.

Kör båda relevanta lägena som referens före ändringen och dokumentera resultatet och förväntad Rule ID; upprepa därefter exakt samma tester. Policy Tester är fortfarande en förkontroll och ersätter inte verkliga Allow- och Block-test från en pilotklient, eftersom NAT, TLS-inspektion, QUIC, routing eller en explicit Direct Proxy-väg kan hantera det verkliga flödet annorlunda.

2. Praktiskt test med en pilotklient

Kontrollera följande med en pilotklient:

• 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-status. 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 fram granskning i stället för permanenta, odokumenterade undantag.
• 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 testregel 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 tillfällig nödåtkomst

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 kategoribeslut

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 kategoribeslut 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