Naar de inhoud
Avanet

Sophos Firewall Webbescherming instellen met Web Policies

Sophos Firewall

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.

  • Web Policy: Regels voor toegestane, gewaarschuwde, geblokkeerde of quota-gebaseerde webtoegang.
  • Webcategorieën: Sophos-categorieën en eigen categorieën voor websites.
  • URL-groepen: Eigen domeinlijsten voor gerichte toestaan- of blokkeerregels.
  • Bestandstypen: Beheer van bepaalde download- of bestandstypen.
  • Inhoudsfilters: Termen of patronen voor inhoudscontrole.
  • Uitzonderingen: Gerichte uitzonderingen op web-, TLS- of scan-gedrag.
  • Algemene instellingen: SafeSearch, YouTube-beperkingen, Google Apps en Microsoft Entra ID Tenant-beperkingen.
  • Logging en rapportage: Traceerbaarheid in Log Viewer, rapportage, Central of SIEM.

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.

Als Web Policies op gebruikers of groepen moeten reageren, moet gebruikersherkenning werken. AD SSO, Captive Portal, STAS, SATC of andere methoden mogen niet pas tijdens de Web Policy-uitrol worden ontdekt. In de Log Viewer moet zichtbaar zijn of een request als bekende gebruiker, als groep of als Anybody of onbekende gebruiker is beoordeeld.

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:

  • Bekende risicocategorieën blokkeren: Webcategorie.
  • Bepaalde SaaS-domeinen toestaan: URL-groep.
  • Enkel verkeerd gecategoriseerd domein behandelen: URL-groep of eigen categorie.
  • Streaming tijdsgebonden beperken: Web Policy met schema of quota.
  • Waarschuwingspagina in plaats van harde blokkering: Web Policy met waarschuwingsactie.

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.

Voor zuivere domeinmatches zijn URL-groepen meestal beter dan eigen Web Categories. Sophos wijst erop dat URL-groepen performanter zijn en minder false positives kunnen opleveren. Eigen categorieën zijn nuttig wanneer een domein naast de standaard Sophos-categorie ook in een eigen policylogica moet verschijnen.

Gebruik keywords in eigen categorieën zeer voorzichtig. Keywords worden tegen de volledige URL inclusief pad en query gecontroleerd. Een allow op basis van een keyword kan daardoor onbedoeld matchen als het woord in een queryparameter op een ander domein voorkomt. Voor allow-beslissingen zijn concrete domeinen of URL-groepen meestal schoner; keywordregels passen eerder bij smalle blokkeercases.

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. Controleer search engine enforcement, bijvoorbeeld SafeSearch of YouTube restrictions.
  5. Stel policy quota status in als Quota-acties worden gebruikt.
  6. Controleer Advanced settings, vooral logging, reporting, grote downloads, Google Apps en Microsoft Entra ID Tenant Restrictions.
  7. Sla de policy op.

Een regel binnen de Web Policy wordt met Add rule aangemaakt. De firewall maakt eerst een uitgeschakelde standaardregel aan die HTTP voor Anybody blokkeert. Daarna worden de velden gericht aangepast:

  1. Open Users en stel bewust Anybody, concrete gebruikers of groepen in.
  2. Open Activities en selecteer All web traffic, User activities, Categories, URL Groups, File types of Content filters.
  3. Voeg indien nodig Content filters toe. Voor Content filters gebruikt de firewall voor HTTPS dezelfde actie als voor HTTP.
  4. Stel Action voor HTTP in: Allow, Warn, Block of Quota.
  5. Controleer de HTTPS-actie: Use action, Allow HTTPS, Warn HTTPS, Block HTTPS of Quota HTTPS.
  6. Stel Constraints in als de regel alleen volgens een schema moet gelden.
  7. Controleer de regelpositie binnen de policy.
  8. Schakel de regelstatus in.
  9. 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.

Regels in een Web Policy worden van boven naar beneden geëvalueerd. Een Allow-regel voor All web traffic boven een Block-regel maakt de blokkeerregel praktisch onwerkzaam. Daarom moet na elke wijziging niet alleen de inhoud van de regel worden gecontroleerd, maar ook de volgorde en de statusschakelaar.

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.
  • Scan HTTP and decrypted HTTPS is geactiveerd als web-malware- of inhoudsscanning moet werken.
  • Use Zero-day protection is alleen zinvol als bestanden via HTTP of ontsleutelde HTTPS worden gescand.
  • Block QUIC protocol is bewust ingesteld.
  • Use web proxy instead of DPI engine is bewust ingeschakeld of bewust uitgeschakeld.
  • TLS-inspectie wordt apart gepland en niet verward met Web Policy.

Sophos Firewall zet Block QUIC protocol standaard aan wanneer in de regel een Web Policy is geselecteerd of Scan HTTP and decrypted HTTPS is ingeschakeld. Dat is vaak zinvol, omdat QUIC niet zoals klassiek HTTPS-verkeer kan worden gescand. Toch moet men dit vinkje niet zomaar accepteren, maar bewust testen: browsers, Google-diensten, collaboration-tools en individuele SaaS-applicaties kunnen ander gedrag vertonen als QUIC wordt geblokkeerd.

Als in dezelfde firewallregel ook Application Control wordt gebruikt, is er een belangrijke overlap: sommige Micro Apps, bijvoorbeeld uploads of downloads binnen Dropbox of Gmail, worden via URL-details herkend. In DPI-omgevingen vereist deze herkenning een passende SSL/TLS Inspection-regel met decryption. Application Control kan zulke Micro Apps dan ook evalueren als de Web Policy zelf niet het eigenlijke beslispunt is.

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.

  • DPI-modus: Moderne standaard voor veel client-internetregels. TLS-inspectie loopt via SSL/TLS-inspectieregels, Quota wordt niet ondersteund.
  • Web Proxy-modus: Omgevingen met expliciet proxygedrag of policy-quota. Proxygedrag, browser-/clientcompatibiliteit en proxylogs bewust controleren.

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.

De Web Proxy filtert in de firewallregel alleen de klassieke poorten 80 en 443. De DPI Engine kan HTTP- en SSL/TLS-verkeer ook op andere poorten inspecteren, mits de regel en SSL/TLS Inspection-regels passen. Bij direct-proxyontwerpen moet bovendien duidelijk zijn of clients de proxy expliciet gebruiken of dat normaal transparant clientverkeer door de regel loopt. Anders test men snel het verkeerde pad.

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.

Bij Bing en Yahoo kan SafeSearch op HTTPS-verbindingen alleen worden afgedwongen als HTTPS scanning in de betrokken firewallregel actief is. Google Apps-loginbeperkingen gelden alleen voor door Google gehoste domeinen. Microsoft Entra ID Tenant Restrictions hebben schone tenantwaarden nodig en moeten met echte Microsoft-cloudaanmeldingen worden getest, niet alleen met een voorbeeld-URL.

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.

De allowed time quota wordt op Web Policy-niveau ingesteld en geldt voor alle regels in deze policy die een Quota-actie gebruiken. Als twee categorieën verschillende tijdsquota nodig hebben, zijn gescheiden Web Policies schoner dan één policy met gemengde quotaverwachtingen. Quota’s worden lokaal om middernacht gereset en kunnen niet op nul worden gezet.

Policy Overrides zijn een ander hulpmiddel dan quota’s. Hiermee kunnen geautoriseerde gebruikers in de User Portal tijdelijke toegang tot normaal geblokkeerde websites aanmaken. Dat kan nuttig zijn voor scholen of supportscenario’s, maar vereist duidelijke grenzen: niet-overschrijfbare categorieën, bevoegde personen, tijdvensters en review van overrides.

Web Exceptions en TLS-uitzonderingen

Web Exceptions zijn krachtig en daarom gevaarlijk als snelle reparatie. Een exception onder Web > Exceptions kan beschermingscontroles voor passend verkeer overslaan, onafhankelijk van welke Web Policy op dat moment geldt. Afhankelijk van de selectie worden HTTPS decryption, HTTPS certificate validation, Malware and content scanning, Zero-day protection of Policy checks overgeslagen.

Voor DPI-omgevingen geldt een belangrijke beperking: Web Exceptions werken alleen als een Web Policy is ingesteld, Malware and content scanning actief is of ATP actief is. SSL/TLS Exclusion Rules zijn daarentegen de juiste plaats als het alleen gaat om bepaalde TLS-verbindingen niet te ontsleutelen. Het operationele verschil is belangrijk:

  • SSL/TLS Exclusion Rule: neemt TLS-verbindingen gericht uit de ontsleuteling, meestal vanwege Certificate Pinning of incompatibiliteit.
  • Web Exception: kan Web Policy-controles, malware-scanning, Zero-Day-analyse of certificaatvalidatie overslaan.
  • URL Group in Web Policy: stuurt Allow, Warn, Block of Quota binnen de normale policylogica.

Voor exceptions moeten rootdomeinen en te brede URL-regex-patronen worden vermeden. Een patroon zoals example.com kan ook in paden of queryparameters van andere domeinen voorkomen. Beter zijn concrete hostnames, passende URL-groepen en een duidelijke scope op bron, doel, categorie of gebruikersgroep.

Exceptions combineren hun verschillende criteria met AND. Binnen één criteriumtype, bijvoorbeeld meerdere URL Patterns, geldt daarentegen OR. Dat is handig maar foutgevoelig: een exception met URL Pattern en Source IP werkt alleen als beide passen. Een exception met zeer veel URL Patterns kan daarentegen veel breder werken dan bedoeld.

Wees bijzonder voorzichtig met Policy checks. Als een Web Exception Policy checks overslaat, kan dat ook andere regelbeslissingen indirect verzwakken. In combinatie met Synchronized Security Heartbeat kan zo’n uitzondering ertoe leiden dat webrequests niet zoals verwacht worden geblokkeerd, hoewel Heartbeat-controles in de firewallregel zijn ingesteld.

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
  • Of een Web Exception of TLS Exclusion heeft gegolden
  • Of een download door grootte, malware-scanfout of Zero-Day-analyse anders werd behandeld

Bij Syslog of SIEM zijn URL en action niet genoeg. Voor een betrouwbare analyse zijn ook Firewall Rule ID, gebruiker, categorie, Web Policy, HTTP-methode, status, scanresultaat, exception-indicatie en SSL/TLS-relatie nodig. Als deze velden in het SIEM ontbreken of verkeerd worden genormaliseerd, lijkt Web Protection in rapportage snel onduidelijker dan het op de firewall werkelijk is.

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:

  • Snelle e-mail bij enkele gevoelige webcategorieën: Directe waarschuwingen.
  • Terugkerende rapporten, trends en gebruikers- of categorie-evaluaties: Central Firewall Reporting.
  • Langere bewaring, correlatie met andere systemen of SOC-processen: Syslog of SIEM.

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:

  • Wie heeft toegang nodig? Voorkomt globale uitzonderingen voor enkele gebruikers.
  • Welk domein, categorie of bestandstype is betrokken? Scheidt URL-groep, webcategorie en bestandstype duidelijk.
  • Is het een tijdelijke of permanente uitzondering? Dwingt beoordeling af in plaats van permanente schaduwtoestemmingen.
  • Welke firewallregel en Web Policy zijn betrokken? Voorkomt wijzigingen in de verkeerde regel.
  • Hoe wordt getest? Maakt het succes in de Log Viewer aantoonbaar.

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.

Als de verbinding niet wordt ontsleuteld, kan de firewall toch SNI- of domeininformatie voor policybeslissingen gebruiken. Voor blokpagina’s, waarschuwingspagina’s, bestandstypen, Content Filters, malware-scanning en Zero-Day-analyse is echter meer zichtbaarheid nodig. Controleer daarom in Log Viewer niet alleen de Web Policy-actie, maar ook de SSL/TLS Inspection-status.

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.

Vooral Web Exceptions die Policy checks of Malware and content scanning overslaan zijn riskant. Als alleen HTTPS decryption stoort, is een SSL/TLS Exclusion meestal nauwer en beter te begrijpen.

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, Web Policy-logging en Reporting actief.
  • Web Policy-regels zijn ingeschakeld en staan in de juiste volgorde.
  • TLS-inspectie en CA-certificaat voor pilotgroep gecontroleerd.
  • QUIC-strategie gedefinieerd.
  • Web Exceptions en TLS Exclusions afzonderlijk gedocumenteerd.
  • 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

Waarom is mijn Sophos Firewall Web Policy niet van toepassing?

Vaak is de Web Policy niet in de juiste firewallregel geselecteerd, wordt de firewallregel niet geraakt of staat een andere regel hoger. In de Log Viewer moet eerst regel-ID, gebruiker, zone en webcategorie worden gecontroleerd.

Is Webbescherming voldoende zonder TLS-inspectie?

Voor eenvoudige domein- of categoriebeslissingen kan Webbescherming ook zonder volledige ontsleuteling nuttig zijn. Voor inhoudscontrole, downloads, bestandstypen en betrouwbaardere HTTPS-controle is TLS-inspectie in veel omgevingen nodig.

Moet men QUIC op Sophos Firewall blokkeren?

In veel bedrijfsomgevingen wel, als webfilter, TLS-inspectie en scanning consistent moeten werken. Dan vallen browsers normaal terug op HTTPS via TCP. De beslissing moet worden getest en gedocumenteerd.

Wat is het verschil tussen Web Policy en firewallregel?

De firewallregel staat verkeer tussen zones en netwerken toe. De Web Policy beheert daarna webcategorieën, URL-groepen, waarschuwingen, blokkeringen, quota’s of andere webcontroles binnen deze regel.

Waar kan men Webbeschermingsbeslissingen zien?

Eerst in de Log Viewer met web- en firewallfilters. Voor langere evaluatie helpen Central Firewall Reporting of Syslog/SIEM. Bij technische detailproblemen kunnen Webproxy-, awarrenhttp-, nSXLd- en IPS-logs relevant zijn.

Hoe moet men Web Policy-uitzonderingen documenteren?

Minimaal met reden, betrokken domein of categorie, gebruikersgroep, firewallregel, Web Policy, eigenaar en beoordelingsdatum. Tijdelijke uitzonderingen moeten een vervaldatum in de naam of in de documentatie hebben.