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:

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.

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.

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:

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.

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. Välj användare, grupper eller Anybody medvetet.
5. Välj aktiviteter, kategorier, URL-grupper, filtyper eller innehållsfilter.
6. Ange åtgärd för HTTP och HTTPS: Allow, Warn, Block eller Quota.
7. Sätt schema om regeln bara ska gälla vid vissa tider.
8. Aktivera regeln.
9. Kontrollera regelposition inom policyn.
10. Aktivera loggning och rapportering.
11. 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.

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.
• Malware Scan är lämpligt aktiverad.
• Block QUIC protocol är medvetet inställd.
• TLS-inspektion planeras separat och förväxlas inte med webbpolicy.

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.

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.

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.

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.

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

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:

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:

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.

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.

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 och webb-loggning aktiv.
• TLS-inspektion och CA-certifikat för pilotgrupp kontrollerad.
• QUIC-strategi definierad.
• 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