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.

Welk artikel over webbescherming past bij uw situatie?

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

• Webbescherming en Web Policies inrichten: Dit artikel.
• Single of Dual Engine, scanfouten, groottelimieten en een echte malwaretest begrijpen: Sophos Firewall Malware-Scanning configureren en testen.
• Webcategorieën, URL-groepen en directe waarschuwingen evalueren: Sophos Firewall Webcategorieën en directe waarschuwingen gebruiken.
• HTTPS-verkeer ontsleutelen en controleren: Sophos Firewall TLS-inspectie correct invoeren.
• CA-certificaat voor beheerde clients distribueren: Sophos Firewall CA-certificaat voor TLS-inspectie distribueren.
• QUIC en HTTP/3 bij webfilterproblemen indelen: Sophos Firewall QUIC en HTTP/3 correct blokkeren.
• Uitzoeken welke firewallregel en policy echt van toepassing zijn: Sophos Firewall regel testen met Log Viewer, Policy tester en Packet Capture.
• Web- en beveiligingsevenementen langer evalueren: Central Firewall Reporting of Syslog naar SIEM sturen.

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 scangedrag.
• Search engine enforcement: SafeSearch en YouTube-beperkingen.
• Advanced settings: Google Apps-inlogdomeinen en Microsoft Entra ID Tenant Restrictions.
• 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.

Gebruikerscriteria in de overeenkomende firewallregel gaan vóór Users in de Web Policy; de policy kan die scope beperken, maar geen uitgesloten gebruiker toevoegen.

Minimaal uitvoerbaar pad

Maak onder Web > Policies een policy en activeer daarin minstens één gerichte Allow/Block-beslissing.

Bewerk vervolgens onder Rules and policies > Firewall rules een echte regel met Action: Accept, passende Source Zone en Source Network, Destination Zone en Destination Network en de benodigde Services. Activeer Log firewall traffic en wijs de Web Policy toe onder Web filtering. Controleer alleen of het bestaande NAT bij het huidige internetpad past; introduceer niet uitsluitend voor deze policy nieuw NAT-gedrag. Leg vóór de wijziging de Rule ID en de resultaten van dezelfde bewust toegestane en geblokkeerde requests vast en herhaal ze erna vanuit de echte bron- en gebruikerscontext. Accepteer de wijziging pas als Log Viewer de verwachte Rule ID, policy en echte Allow- en Block-resultaten toont.

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

De categorie highly objectionable criminal activity wordt altijd geblokkeerd. Noch beleidsregels, noch uitzonderingen kunnen deze categorie toestaan; bovendien verbergt SFOS het domein in logs en rapporten.

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.

URL Groups maken en veilig gebruiken legt uit hoe geldige domeinwaarden, OR-logica, gebruik in een Web Policy en TLS-uitsluitingen samenhangen.

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 of File types.
3. Kies voor inhoud de aparte tab Content filters, selecteer het filter, activeer and with content en laat HTTPS op Use action.
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.

Contentfilterlijsten correct importeren

Content filters worden beheerd onder Web > Content filters en daarna onder Activities in de webpolicyregel geselecteerd. Voor grotere lijsten met termen ondersteunt Sophos een eenvoudig .txt-bestand. Het bestand mag maximaal 2,000 regels bevatten en elke invoer mag inclusief spaties en leestekens maximaal 80 tekens lang zijn.

Het importbestand bevat exact één term per regel en elke regel wordt als exact match beoordeeld. Koppen, opmerkingen, metadata of extra kolommen horen niet in het bestand. Sla niet-ASCII-inhoud op als UTF-8.

Veilige werkwijze:

1. Maak de termen schoon in een teksteditor en plaats exact één invoer per regel.
2. Sla het bestand als .txt met UTF-8-codering op.
3. Importeer de lijst onder Web > Content filters en geef deze een duidelijke naam.
4. Open in Activities de tab Content filters, selecteer het filter, activeer and with content en behoud Use action.
5. Test met een pilotclient één toegestane term en één bewust overeenkomende term en controleer de actie in Log Viewer.

Als een import wordt geweigerd of afzonderlijke termen niet worden toegepast, controleer dan eerst het aantal regels, de tekenlengte, de codering en onzichtbare extra tekens. Een brede Allow-regel boven de Content filter-regel mag de lijst niet omzeilen.

Aangepaste webbestandstypen maken

Sophos Firewall herkent File types aan de bestandsextensie of MIME-header. De ingebouwde typen kunnen niet worden bewerkt. Maak een aangepast type onder Web > File types > Add op basis van een geschikte sjabloon en voeg de benodigde extensies zonder voorafgaande punt of MIME-headers toe. Hetzelfde object kan daarna in web- en e-mailbeveiligingspolicies worden gebruikt.

Voer in het dialoogvenster Add een naam in. Template is optioneel en neemt de gebruikelijke extensies en MIME-headers van een categorie over; voor het aangepaste type kunnen waarden worden toegevoegd. Sla daarna op met Save. Zet geen punt voor een extensie: pdf is correct en .pdf niet. Ingebouwde typen dienen als sjabloon en kunnen niet worden bewerkt; maak voor wijzigingen een aangepast type.

SFOS bevat de ingebouwde categorieën 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 en Web files. De detailweergave onder Web > File types is de operationele bron voor de extensies en MIME-headers die momenteel zijn vastgelegd. Compressed files bevat bijvoorbeeld onder meer 7z, gz, rar, tar.gz en zip, terwijl Document files onder meer docx, xlsx, pptx, odt, rtf en pdf bevat. Open vóór het toestaan van een categorie daarom het concrete ingebouwde type in de eigen SFOS-versie en vergelijk dit met de werkelijke toepassing; vertrouw niet alleen op de categorienaam.

Het nieuwe bestandstype heeft op zichzelf nog geen effect. Selecteer het onder Activities > File types in de betreffende webpolicyregel. Controleer daarna de actie, status en volgorde van de regel en of de webpolicy nog is toegewezen aan de firewallregel die het verkeer daadwerkelijk verwerkt.

Valideer dit met een representatieve download en een bewust vergelijkbaar bestand dat niet mag matchen. Controleer in Log Viewer de webpolicy en de actie. Een match op extensie of MIME-header is een policyclassificatie, geen bewijs van malware of van een uitgevoerde Zero-Day-analyse. Voor HTTPS hangt de benodigde zichtbaarheid ook af van het TLS Inspection-pad. Als het type niet matcht, vergelijk dan eerst de regelstatus en -volgorde, het werkelijk geselecteerde File Type, het Content-Type-antwoord van de server, de zichtbare bestandsextensie en de TLS Inspection-status. Een onjuist of algemeen MIME-type van de server kan ertoe leiden dat de test anders uitvalt dan de bestandsnaam doet vermoeden.

User Activities duidelijk bundelen

Onder Web > User activities > Add combineert een User activity Web Categories, File types en URL Groups tot een herbruikbare activiteit. Deze elementen worden met OR geëvalueerd; één match is voldoende. De naam verwijst dus niet naar een aangemelde gebruiker, maar naar een verzameling webcriteria.

Selecteer de User Activity daarna onder Activities in de webpolicyregel. Dit past wanneer dezelfde combinatie in meerdere policies wordt gebruikt. Test voor de validatie minstens één match per opgenomen objecttype en één vergelijkbaar geval dat niet mag matchen.

Regelvolgorde en gemigreerde policies controleren

Webpolicyregels worden van boven naar beneden geëvalueerd. Staat bijvoorbeeld een Allow-regel voor het bestandstype .mdb boven een categorieblokkeerregel, dan blijven .mdb-downloads uit die categorie toegestaan. In DPI-modus kan de eerste verbinding met de categorie worden toegestaan totdat het bestandstype bekend is; past het bestand daarna niet, dan verbreekt de firewall de verbinding zonder een blokkeerpagina te tonen. Als de categorie altijd moet worden geblokkeerd, hoort de categorieregel boven de Allow-regel voor het bestandstype.

Voor gemigreerde oude policies geldt bovendien een harde limiet van 128 regels per policy. Bevat de bron meer regels, dan gebruikt SFOS alleen de eerste 128. Aangrenzende regels voor User Activities, Categories, URL Groups, File types en Dynamic Categories worden daarom vóór of na de migratie bewust samengevoegd tot gecombineerde Activities. Regelaantal, volgorde en echte Allow- en Block-tests horen bij de migratievalidatie.

Terugkerende tijdvensters worden als afzonderlijk schema gemaakt. De werkwijze en de afbakening van een tijdgestuurde firewallregel staan in Tijdschema’s voor regels en policies instellen op Sophos Firewall.

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.
• 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.
• Op het transparante firewallregelpad is Use web proxy instead of DPI engine ingeschakeld voor SafeSearch, YouTube Restrictions en Google Apps-inlogbeperkingen; voor andere functies en bij Direct Proxy wordt de modus bewust naar behoefte gekozen.
• 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.

In een transparante firewallregel verwerkt de Transparent Web Proxy alleen verkeer op de klassieke poorten 80 en 443. Op andere poorten kan de DPI Engine HTTP- en SSL/TLS-verkeer inspecteren, mits zowel de firewallregel als de SSL/TLS Inspection-regels passen. Direct Proxy is daarentegen een afzonderlijk, expliciet door de client gekozen pad en vereist Use web proxy instead of DPI engine niet noodzakelijk. Leg daarom bij elke test vast of de client het transparante pad of zijn expliciete proxyconfiguratie gebruikt.

De volledige functiekeuze, pilotmigratie en modusspecifieke controles staan in DPI Engine en Web Proxy correct vergelijken.

Direct Web Proxy met een PAC-bestand instellen legt uit hoe listener, PAC-bestand, Device Access en een werkende proxyregel samenhangen.

IPv6-only-clients die IPv4-only-webdoelen openen, gebruiken een apart pad met twee regels. NAT64 met Direct Web Proxy scheidt de Web Policy in de IPv6-regel van Application Control en IPS in de IPv4-egress.

Als Sophos Firewall zijn Web Requests naar een parent proxy moet doorsturen, leidt een upstream proxy in WAN of LAN/DMZ configureren door het juiste regel- en NAT-pad voor elke topologie.

Als meerdere RDS-gebruikers hetzelfde server-IP delen, kan Per-Connection AD SSO voor multi-userhosts de afzonderlijke HTTP- en HTTPS-proxyverbindingen onderscheiden. De methode geldt niet voor non-proxyverkeer en moet daarom bewust worden afgebakend ten opzichte van SATC.

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

SafeSearch en YouTube staan onder Search engine enforcement; Google Apps en Entra onder Advanced settings.

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.

Op het transparante firewallregelpad vereisen SafeSearch, YouTube Restrictions en Google Apps Use web proxy instead of DPI engine; een expliciete Direct Proxy kan deze proxyfuncties zonder die firewallregeloptie leveren. Bing en Yahoo via HTTPS vereisen bovendien HTTPS scanning. Behandel Entra Tenant Restrictions apart, test echte Microsoft-aanmeldingen en behoud de governance van identiteiten en cloudapps in Microsoft 365 of Google Workspace.

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 Quota geldt niet voor Content filters of Dynamic Categories en wordt niet ondersteund in de DPI-modus. Een quotawijziging wordt bovendien niet toegepast als de policy ongeldig is, er geen tijd resteert of er al een Quota-sessie actief is.

Deze Policy Quota geldt voor webcategorieën en is niet de gebruikersgebaseerde Surfing Quota. Het maken, toewijzen en controleren van het verbruik van Surfing Quota en Network Traffic Quota volgt een afzonderlijk proces.

Policy Quota tijdens gebruik controleren

Onder Web > Policy quota status toont SFOS per gebruiker de resterende tijd in de betreffende Web Policies binnen een periode van 24 uur. De geselecteerde gebruiker kan daar met Reset worden teruggezet. Dit is een bewuste statuswijziging en geen diagnoseknop: documenteer eerst gebruiker, policy, resterende tijd, reden en tijdstip.

Deze reset betreft de tijdgebaseerde Policy Quota van een webcategorie. Dit is niet hetzelfde als Reset user accounting voor Surfing Quota of Network Traffic Quota. Een reset corrigeert geen verkeerde regelvolgorde en ook geen ontbrekende gebruikersidentificatie.

Waarschuwings- en blokkeerpagina’s aanpassen

Onder Web > User notifications kunnen eigen afbeeldingen en blokkeer-, override-, quota- en waarschuwingsteksten worden ingesteld. De placeholders {category}, {user} en {url} voegen de webcategorie, gebruikersnaam en geblokkeerde URL in. De preview controleert weergave en tekst, maar niet of de juiste Web Policy en firewallregel de productieaanvraag matchen.

De melding moet kort uitleggen waarom de toegang is geblokkeerd of gewaarschuwd en waar een legitieme zakelijke behoefte kan worden gemeld. Gebruikersnamen en URL’s kunnen gevoelige informatie bevatten; de pagina bevat daarom geen interne geheimen, wachtwoorden of onnodige contactgegevens.

Policy Overrides veilig beperken

Policy Overrides zijn een ander hulpmiddel dan quota’s. Met Enable policy override kunnen geautoriseerde gebruikers in de User Portal tijdelijke toegang tot normaal geblokkeerde websites aanmaken. Authorized users and groups beperkt wie dit mag doen en Blocked websites and categories bepaalt welke doelen nooit mogen worden overschreven. Allow manual access code entry wordt alleen ingeschakeld als door gebruikers aangemaakte codes in het goedkeuringsproces passen.

Documenteer onder Web > General settings > Policy overrides eerst de vorige toestand en de bevoegde gebruikers. De bevoegde gebruiker stelt in de User Portal websites of categorieën, een beperkte periode en een toegangscode voor de override in. Bij een verzoek naar een passend geblokkeerd doel bevat de blokkeerpagina een extra veld voor die code. Als Allow manual access code entry aan staat, mogen de aangewezen gebruikers eigen codes aanmaken; staat de optie uit, dan moeten zij gegenereerde codes gebruiken. Verwar deze keuze niet met het invoeren van een reeds geldige code op de blokkeerpagina.

Met View overrides kunnen bestaande overrides worden weergegeven, ingeschakeld, uitgeschakeld en verwijderd. Gebruik voor de acceptatie een bevoegde testgebruiker om binnen de periode met een geldige code een passend doel te openen; zonder code, buiten de periode en voor een doel dat nooit mag worden vrijgegeven via een override moet de normale blokkade blijven gelden. Vergelijk gebruiker, Rule ID, webpolicy, actie en tijd in Log Viewer. Bij HTTPS moet de blokkeerpagina daadwerkelijk kunnen worden weergegeven; alleen een verbroken verbinding biedt geen invoerveld.

Schakel voor rollback de pilotoverride uit via View overrides en controleer met een nieuw verzoek de oorspronkelijke blokkade. Verwijder pas daarna een niet meer benodigde override en herstel uitsluitend de tijdens de pilot gewijzigde globale waarden naar hun gedocumenteerde vorige toestand. Verwijder bestaande overrides van andere gebruikers niet zonder onderscheid.

Voor AD-gebruikers geldt My policy overrides alleen voor de hoofdgroep en individuele gebruikers, niet voor andere groepslidmaatschappen. Een matchende SSL/TLS Inspection-regel met Action > Deny houdt voorrang. Als een goedgekeurde override in die situatie moet werken, wordt een nauw begrensde Web Exception gepland die HTTPS-decryptie overslaat en afzonderlijk met een negatieve test wordt gecontroleerd; de TLS-regel wordt niet breed afgezwakt.

Web Exceptions en TLS-uitzonderingen

Het overslaan van HTTPS decryption verwijdert afhankelijke controles en staat ongeldige servercertificaten toe; Malware and content scanning slaat automatisch Zero-day protection over. Een concreet hostnamepatroon kan al in de TLS-context overeenkomen, terwijl een zuiver URL-pad alleen zichtbaar is bij HTTP of reeds ontsleuteld HTTPS. Een URL Group is geen Web Exception-criterium.

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.

Vermijd voor exceptions rootdomeinen en te brede regex-patronen. Gebruik concrete hostnames en een duidelijke scope op bron, doel, categorie of gebruikersgroep; URL-groepen horen in de normale Web Policy-logica.

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

Het exacte pad is Diagnostics > Tools > Pop-out tools > Policy tester. Firewall, SSL/TLS, and web test het gecombineerde transparante pad, terwijl Web policy only de beslissing van de Web Policy isoleert. De webtest vertegenwoordigt uitsluitend transparante webtoegang, houdt geen rekening met SD-WAN-routes en accepteert geen Source Networks met MAC-adressen. Zonder opgegeven protocol gebruikt de tester HTTP; zonder opgegeven poort gebruikt hij de standaardpoort van het gekozen protocol.

Voer vóór de wijziging beide relevante modi als baseline uit en leg het resultaat en de verwachte Rule ID vast; herhaal daarna exact dezelfde tests. De Policy Tester blijft een voorcontrole en vervangt geen echte Allow- en Block-test vanaf een pilotclient, omdat NAT, TLS-inspectie, QUIC, routing of een expliciet Direct Proxy-pad de werkelijke pakketstroom anders kunnen verwerken.

2. Echte test met een 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