Sophos Firewall Webbescherming instellen met Web Policies

Sophos Firewall Webbescherming bepaalt welke websites, categorieën en webinhoud gebruikers mogen bereiken. In de praktijk is webbescherming echter niet eenvoudigweg een enkele instelling. Een Web Policy moet zorgvuldig worden gepland, geactiveerd in een passende firewallregel en vervolgens getest met echt verkeer.

Veel fouten ontstaan omdat een Web Policy wel bestaat, maar niet wordt toegepast op een actieve firewallregel. Andere problemen houden verband met HTTPS, TLS-inspectie, QUIC, gebruikersherkenning, regelvolgorde of te ruime uitzonderingen. De logische volgorde is daarom: policy plannen, regel bouwen, activeren, testen en in gebruik monitoren.

Welke Webbeschermingsartikel past?

Webbescherming overlapt met firewallregels, TLS-inspectie, QUIC, rapportage en uitzonderingen. Afhankelijk van de taak past een specifieker artikel beter:

Zo blijft de analyse helder: eerst moet duidelijk zijn of de firewallregel overeenkomt. Daarna controleert men Web Policy, categorie, gebruikerscontext, QUIC, TLS-inspectie en logging.

Wat Webbescherming controleert

Webbescherming bestaat uit meerdere componenten. Niet elke component hoeft in elke omgeving te worden gebruikt, maar de samenhang moet duidelijk zijn.

Webbescherming vervangt geen solide basis van firewallregels. De firewallregel bepaalt eerst welk verkeer van welke zone naar welke doelzone is toegestaan. De Web Policy voegt webcontrole toe aan deze regel. De basisprincipes van regelvolgorde, bron, bestemming, services en beveiligingsprofielen staan in Sophos Firewall regels begrijpen en correct opbouwen.

Vereisten

Voor de uitrol moeten deze punten duidelijk zijn:

• Webbescherming is gelicentieerd of opgenomen in het gebruikte pakket.
• De betrokken clientnetwerken hebben eigen firewallregels.
• Logging is actief in de relevante regels.
• DNS en tijd van de firewall werken correct.
• Gebruikersherkenning is duidelijk, als policies per gebruiker of groep moeten gelden.
• TLS-inspectie is gepland als HTTPS-inhoud nauwkeuriger moet worden gecontroleerd.
• QUIC/HTTP/3 wordt bewust toegestaan of geblokkeerd.
• Er is een pilotgroep en een terugvaloptie voor bedrijfskritische sites.

Bijzonder belangrijk is de scheiding naar doelgroepen. Een Web Policy voor normale clients, servers, gasten, VPN-gebruikers en beheersystemen moet niet dezelfde zijn. Servers hebben vaak minder browsecontrole nodig, maar strengere doel- en updatelijsten. Gasten hebben vaak categorieën en bandbreedtebeperking nodig, maar geen toegang tot interne bronnen.

Web Policy plannen

Een goede Web Policy begint niet in de interface, maar met enkele zakelijke beslissingen.

Doelgroepen definiëren

Eerst wordt bepaald voor wie de policy geldt:

• Standaardclients in het LAN
• Beheerde laptops via VPN
• Gast-WLAN
• Leslokalen of schoolomgevingen
• Servers met uitgaande HTTP/HTTPS-toegang
• Geprivilegieerde beheerderswerkplekken

Als dezelfde firewallregel meerdere zeer verschillende groepen bevat, wordt webbescherming moeilijk te begrijpen. Beter zijn gescheiden regels en policies, bijvoorbeeld LAN_USERS_WEB, GUEST_WEB of SERVER_UPDATES_WEB.

Categorieën en URL-groepen vaststellen

Sophos-webcategorieën zijn goed voor brede controle: malware, phishing, volwassen inhoud, anonymizers, streaming, sociale media of games. URL-groepen zijn beter als specifieke domeinen gericht moeten worden toegestaan of geblokkeerd.

Typisch gebruik:

URL-groepen moeten geen ongeordende verzamelingslijst worden. Als veel domeinen worden toegevoegd, heeft de lijst een eigenaar, een doel en een beoordelingsdatum nodig. Voor zeer grote of dynamische lijsten zijn Sophos Firewall Threat Feeds of andere architectuurcomponenten vaak zinvoller.

Toestaan-regels voorzichtig instellen

Toestaan-regels in Web Policies moeten nauwkeurig zijn. Een toestaan-regel hoog in de lijst kan latere blokkeerregels onwerkzaam maken, omdat Sophos Web Policy-regels van boven naar beneden worden geëvalueerd. Dit is vooral relevant als een URL-groep, een bestandstype-regel of een categorie-uitzondering boven andere regels staat.

Praktisch bewezen:

1. Specifieke toegestane zakelijke uitzonderingen bovenaan.
2. Kritische blokcategorieën daarna.
3. Waarschuwings- of quotaregels voor grijze gebieden.
4. Algemeen toegestaan webverkeer pas aan het einde.

Web Policy aanmaken

De Web Policy wordt aangemaakt onder het volgende menu:

Web > Policies

Basisstappen:

1. Kies Add policy.
2. Geef een duidelijke naam, bijvoorbeeld LAN_USERS_STANDARD_WEB.
3. Voeg regels toe.
4. Kies bewust gebruikers, groepen of Anybody.
5. Selecteer activiteiten, categorieën, URL-groepen, bestandstypen of inhoudsfilters.
6. Stel actie voor HTTP en HTTPS in: Allow, Warn, Block of Quota.
7. Stel schema in als de regel alleen op bepaalde tijden moet gelden.
8. Activeer de regel.
9. Controleer de regelpositie binnen de policy.
10. Activeer logging en rapportage.
11. Sla de policy op.

Een Web Policy alleen heeft nog geen effect. De policy moet daarna in een firewallregel worden gebruikt. Dit is een van de meest voorkomende configuratiefouten.

Web Policy in firewallregel activeren

De firewallregel bevindt zich onder:

Rules and policies > Firewall rules

Voor normaal client-internetverkeer is meestal een regel van LAN of een clientzone naar WAN verantwoordelijk. Daar wordt in het gedeelte Web filtering de passende Web Policy geselecteerd.

Controlepunten in de firewallregel:

• Bronzone en bronnetwerken passen bij het clientnetwerk.
• Doelzone is meestal WAN.
• Services bevatten HTTP/HTTPS of de gewenste webdiensten.
• Log firewall traffic is actief.
• In het gedeelte Web filtering is de juiste Web Policy ingesteld.
• Malware Scan is passend geactiveerd.
• Block QUIC protocol is bewust ingesteld.
• TLS-inspectie wordt apart gepland en niet verward met Web Policy.

Als een algemenere regel boven de gewenste webregel overeenkomt, bereikt het verkeer de Web Policy niet. In dergelijke gevallen helpt Sophos Firewall regel testen met Log Viewer en Packet Capture.

HTTPS, TLS-inspectie en QUIC indelen

Een groot deel van het webverkeer is HTTPS. Zonder TLS-inspectie ziet de firewall minder inhoud. Categorieën, SNI, certificaten, doel-IP, domeininformatie en metadata helpen, maar vervangen geen volledige inhoudscontrole.

DPI of Web Proxy?

Bij webbescherming moet men vroeg beslissen of de betrokken firewallregel de DPI Engine of de Web Proxy gebruikt. Deze beslissing beïnvloedt welke functies hoe werken en welke logs later relevant zijn.

In veel installaties is de DPI-modus het betere startpunt. Als echter tijdsquota via Quota nodig zijn, is een pure DPI-regel niet voldoende. Dan moet Web Proxy-modus bewust worden gepland en getest. Deze beslissing moet voor de uitrol worden genomen, omdat een latere wijziging andere foutbeelden, logs en gebruikerservaringen kan veroorzaken.

TLS-inspectie

Als downloads, malware-scanning, bepaalde webcategorieën of inhoudscontroles betrouwbaar moeten worden gecontroleerd, moet TLS-inspectie worden gepland. Hiervoor is een vertrouwd CA-certificaat op de clients nodig, passende TLS-regels, uitzonderingen en een schone pilot.

De uitrol staat in TLS-inspectie op Sophos Firewall stapsgewijs uitrollen. Voor het distribueren en valideren van het CA-certificaat past Sophos Firewall CA-certificaat voor HTTPS-scanning installeren.

QUIC en HTTP/3

Moderne browsers gebruiken vaak QUIC of HTTP/3 via UDP 443. Dit kan webfilter-, TLS-inspectie- en scanverwachtingen verstoren als men eigenlijk klassiek HTTPS-verkeer via TCP wil controleren.

In veel bedrijfsomgevingen is het zinvol om QUIC in client-internetregels te blokkeren, zodat browsers terugvallen op HTTPS via TCP. De details staan in Sophos Firewall QUIC en HTTP/3 correct blokkeren.

SafeSearch, YouTube en Tenant-beperkingen

Sophos Firewall kan in Web Policies extra zoek- en cloudcontroles instellen.

Typische opties:

• Enforce SafeSearch voor Google, Yahoo en Bing.
• Enforce YouTube restrictions voor beperkte YouTube-inhoud.
• Restrict login domains for Google Apps voor toegestane Google-domeinen.
• Apply Microsoft Entra ID tenant restrictions voor Microsoft-cloudtenantbeheer.

Deze functies zijn nuttig, maar niet magisch. Bij HTTPS hangt de effectiviteit deels af van HTTPS-scanning of TLS-inspectie. Bovendien vervangen ze geen identiteits- en cloud-appbeheer in Microsoft 365 of Google Workspace. Voor productieve omgevingen moet men de werking testen met echte testgebruikers en de betrokken browsers.

Quota en waarschuwingspagina’s

Web Policies kunnen niet alleen blokkeren of toestaan. Met waarschuwings- of quota-acties kan men gebruikers bewust informeren of tijdelijk beperkte toegang toestaan.

Zinvolle voorbeelden:

• Gebruikers mogen een waarschuwing voor bepaalde grijze gebieden bewust bevestigen.
• Streaming of winkelen is alleen tijdelijk toegestaan.
• School- of laboratoriumomgevingen staan bepaalde categorieën alleen tijdens gedefinieerde tijden toe.

Belangrijk: Policy-quota wordt in de DPI-modus niet ondersteund. Als tijdsquota nodig zijn, moet Web Proxy-modus worden gebruikt. Dit moet vroeg worden besloten, omdat DPI en Web Proxy verschillende eigenschappen en grenzen hebben.

Webbescherming testen

Na het opslaan moet men niet alleen controleren of de policy bestaat. Doorslaggevend is of deze voor echt verkeer van toepassing is.

1. Policy Tester gebruiken

Onder Web > Policies is de Policy tester beschikbaar. Hiermee kan men controleren welke policybeslissing voor gebruiker, URL en context wordt verwacht.

De Policy Tester is een goede voorcontrole, maar vervangt geen echte pakketstroom. Een firewallregel, NAT, TLS-inspectie, QUIC of routing kan nog steeds voorkomen dat de verwachte policy in echt verkeer van toepassing is.

2. Echt test met pilotclient

Met een pilotclient controleren:

• Toegestane zakelijke site
• Geblokkeerde categorie
• Waarschuwende categorie
• URL-groep toestaan
• URL-groep blokkeren
• HTTPS-site met en zonder TLS-inspectie
• Download van een onschadelijk testbestandstype
• Gedrag met QUIC actief of geblokkeerd

3. Log Viewer controleren

In de Log Viewer moet zichtbaar zijn:

• Welke firewallregel is geraakt
• Welke gebruiker is herkend, indien relevant
• Welke webcategorie of URL-groep betrokken was
• Of HTTPS, TLS-inspectie of malware-scan betrokken waren
• Of de actie was toegestaan, gewaarschuwd of geblokkeerd

Voor diepere probleemoplossing zijn ook logbestanden relevant. De toewijzing staat in Sophos Firewall Troubleshooting: Services en Logs.

Directe waarschuwingen en rapportage

Als bepaalde categorieën niet alleen moeten worden geblokkeerd, maar ook actief moeten worden gemeld, kunnen directe waarschuwingen nuttig zijn. Dit is vooral handig in scholen, streng gereguleerde omgevingen of gebieden met een duidelijke internetgebruiksrichtlijn.

De drie evaluatieroutes beantwoorden verschillende vragen:

Voor directe waarschuwingen moet duidelijk zijn wie de melding ontvangt, welke categorieën echt een reactie uitlokken, hoe valse positieven worden behandeld en wanneer de categoriekeuze wordt herzien. Een brede waarschuwingslijst zonder eigenaar genereert snel e-mailruis, maar geen betere beveiliging.

Voor de technische activering en triage staat Sophos Firewall Webcategorieën en directe waarschuwingen gebruiken. Voor langdurige evaluaties moeten Central Firewall Reporting of Sophos Firewall Syslog naar SIEM sturen worden overwogen.

Wijzigingen en uitzonderingen in gebruik beheren

Webbescherming verandert voortdurend in gebruik. Nieuwe SaaS-diensten komen erbij, afzonderlijke domeinen worden verkeerd gecategoriseerd, afdelingen hebben tijdelijk toegang nodig en browsergedrag verandert. Zonder duidelijke procedure ontstaan snel brede uitzonderingen die later niemand meer kan verklaren.

Voor elke wijziging moet men ten minste vastleggen:

Een kleine wijzigingsprocedure heeft zich bewezen:

1. Verzoek vastleggen met gebruiker, URL, tijdstip, zakelijke reden en screenshot of foutmelding.
2. In de Log Viewer controleren welke firewallregel, Web Policy, categorie en actie van toepassing waren.
3. Beslissen of de categorie fundamenteel verkeerd is, of alleen een enkel domein moet worden vrijgegeven of dat het verzoek wordt afgewezen.
4. Als een uitzondering nodig is, zo nauw mogelijk werken: enkele URL-groep in plaats van hele categorie, enkele gebruikersgroep in plaats van heel LAN.
5. Wijziging in een testregel of pilotgroep controleren.
6. Na het opslaan een echte test uitvoeren en Log Viewer, categorie, regel-ID en gebruikerscontext documenteren.
7. Beoordelingsdatum instellen, vooral bij tijdelijke zakelijke uitzonderingen.

Tijdelijke uitzonderingen moeten duidelijk worden benoemd, bijvoorbeeld TMP_ALLOW_vendor-portal_until_2026-07-31. Permanente zakelijke uitzonderingen hebben ook een eigenaar nodig. Als niemand verantwoordelijk is voor een uitzondering, moet deze niet permanent in de policy blijven.

Als veel afzonderlijke domeinen voor dezelfde dienst ontstaan, is vaak niet de Web Policy het probleem, maar de architectuur van de dienst. Dan moet men controleren of een eigen firewallregel, een eigen Web Policy, een goed onderhouden URL-groep of een ander controlepunt beter past. Voor dynamische IOC- of blokkeerlijsten zijn Web Policy-uitzonderingen meestal de verkeerde plek; daarvoor passen eerder Sophos Firewall Threat Feeds.

Rollback en noodtoestemming

Een wijziging in de Web Policy kan direct invloed hebben op productief werk. Daarom moet men voor grotere wijzigingen vaststellen hoe de oude situatie kan worden hersteld.

Praktische rollback-opties:

• Betrokken Web Policy voor de wijziging dupliceren of documenteren
• Wijziging eerst in een pilotregel of kleine gebruikersgroep testen
• Oude firewallregel of oude Web Policy niet direct verwijderen
• Tijdvenster, testgebruikers en terugvalcriterium definiëren
• Na het opslaan Log Viewer, regel-ID en categoriebeslissing controleren

Voor acute blokkeringen moet niet reflexmatig een brede toestaan-regel bovenaan worden ingevoegd. Beter is een nauwe, tijdelijk beperkte uitzondering met duidelijke URL-groep, gebruikersgroep en beoordelingsdatum. Als de druk hoog is, kan een tijdelijke uitzondering de werking stabiliseren, maar deze moet daarna opnieuw worden beoordeeld.

Typische fouten

Web Policy is niet van toepassing

Meestal is de policy niet in de juiste firewallregel geactiveerd, wordt de regel niet geraakt, staat een regel hoger die het verkeer toestaat of past de gebruikerscontext niet. Eerst Log Viewer en regel-ID controleren.

HTTPS wordt niet zoals verwacht geblokkeerd

Zonder TLS-inspectie ziet de firewall minder details. Afhankelijk van het doel kan een domein- of categoriebeslissing werken, terwijl inhoudscontrole, bestandstypen of bepaalde zoekfuncties beperkt blijven.

QUIC omzeilt de verwachting

Als browsers UDP 443 gebruiken, kan verkeer anders worden verwerkt dan klassiek HTTPS via TCP. In clientregels moet bewust worden besloten of QUIC wordt geblokkeerd.

Toestaan-regel staat te hoog

Een brede toestaan-regel aan het begin van de Web Policy kan latere blokkeerregels uitschakelen. Regelvolgorde binnen de Web Policy is net zo belangrijk als regelvolgorde in de firewallregellijst.

Te veel uitzonderingen

Uitzonderingen lossen snel een enkel probleem op, maar kunnen de beschermende werking verminderen. Elke uitzondering heeft een doel, eigenaar en beoordelingsdatum nodig. Als veel uitzonderingen ontstaan, is vaak de policystructuur verkeerd of heeft een zakelijke toepassing een eigen regel nodig.

Rapportage toont niets

Dan moeten logging, rapportage, firewallregel, policyselectie of logdoorsturing worden gecontroleerd. Een policy zonder logging is in gebruik moeilijk te evalueren.

Bedrijfschecklist

• Webbeschermingslicentiestatus gecontroleerd.
• Client-, server-, gasten- en VPN-verkeer afzonderlijk geëvalueerd.
• Web Policy met duidelijke naam aangemaakt.
• Kritische categorieën en URL-groepen bewust gepland.
• Regelvolgorde binnen de Web Policy gecontroleerd.
• Web Policy in de juiste firewallregel geactiveerd.
• Log firewall traffic en web-logging actief.
• TLS-inspectie en CA-certificaat voor pilotgroep gecontroleerd.
• QUIC-strategie gedefinieerd.
• Policy Tester en echte tests uitgevoerd.
• Log Viewer en rapportage gecontroleerd.
• Wijzigingsproces voor Web Policy-uitzonderingen gedefinieerd.
• Tijdelijke uitzonderingen met vervaldatum voorzien.
• Uitzonderingen met eigenaar en beoordelingsdatum gedocumenteerd.

FAQ