URL Groups op Sophos Firewall maken en veilig gebruiken

Een URL Group bundelt concrete domeinen zodat ze samen in een Web Policy of een SSL/TLS inspection rule kunnen worden gebruikt. Dat klinkt eenvoudig, maar heeft een belangrijk gevolg: elke wijziging aan de groep beïnvloedt alle regels en policies die naar dit object verwijzen.

De veilige werkwijze begint daarom niet met een zo groot mogelijke leverancierslijst. Eerst worden de daadwerkelijk gebruikte domeinen uit een request, log of leveranciersdocumentatie vastgelegd. Daarna ontstaat een kleine groep met een duidelijk doel, een eigenaar en een testplan.

URL Group in zeven stappen

1. De betrokken client, de werkelijke doelhosts en de gewenste beslissing documenteren: toestaan, blokkeren of niet ontsleutelen.
2. Controleren of een URL Group echt past. Deze verwerkt domeinen, maar geen URL-paden, querystrings of reguliere expressies.
3. Onder Web > URL groups > Add een duidelijke naam instellen en elke geldige domeinnaam met Add overnemen.
4. De groep als Activity in een Web Policy of onder Categories and websites in een SSL/TLS inspection rule selecteren.
5. Regelvolgorde, status, bronbereik en logging controleren. Een groep alleen staat nog niets toe en blokkeert nog niets.
6. Met een nieuwe verbinding een verwachte match en een bewust vergelijkbare niet-match testen.
7. Domeinlijst, gebruikers van het object, eigenaar, reden, testdatum en rollback documenteren.

⚠️ Meerdere domeinen binnen een URL Group worden met OR geëvalueerd. Eén match is voldoende. Bij TLS-uitsluitingen omvat een domeinvermelding bovendien de subdomeinen. Een te breed hoofddomein of een hoog geplaatste Allow-regel kan daardoor aanzienlijk meer verkeer omvatten dan gepland.

Wat een URL Group aanstuurt en wat niet

Een URL Group is een herbruikbaar domeinobject. Deze beschrijft welke domeinen bij elkaar horen. De regel die het object gebruikt, bepaalt vervolgens wat er met de match gebeurt.

Typische toepassingen:

• een kleine zakelijke allowlist in een Web Policy
• een expliciete blocklist voor bekende domeinen
• een domeinlijst in een Don't decrypt-regel
• de lokale TLS-uitsluitingslijst voor bevestigde ontsleutelingsproblemen

Een URL Group is echter niet voor elke webtaak het juiste hulpmiddel:

• Web category: brede inhoudelijke classificatie of een eigen categorie met URL-paden of trefwoorden
• Web Exception: regex-gebaseerde match en gericht overslaan van web-, scan- of certificaatcontroles
• FQDN Host: DNS-gebaseerd netwerkobject voor firewall-, NAT- of routeringsregels
• Threat Feed: dynamisch onderhouden IOC- of domeinlijsten

Web Protection met Web Policies configureren legt de volledige policylogica uit. De keuze tussen een eigen categorie en een domeinlijst staat in Web categories en Instant Alerts gebruiken. Voor dynamische beveiligingslijsten zijn Sophos Firewall Threat Feeds bedoeld.

Domein in plaats van volledige URL

Onder Search/Add verwacht SFOS een geldige domeinnaam. Protocol, pad en query horen niet in dit veld.

Geldige voorbeeldwaarden:

updates.vendor.example
cdn.vendor.example

Ongeschikte waarden:

https://updates.vendor.example/download/file.bin
*.vendor.example
^updates\.vendor\.example/

De uitgang .example is gereserveerd voor documentatie. In de echte configuratie worden de voorbeelden vervangen door de domeinen die in het log, request of de leveranciersdocumentatie zijn bevestigd.

Als een specifiek URL-pad, een queryparameter of een reguliere expressie nodig is, past afhankelijk van het doel een eigen web category of een veilig begrensde Web Exception. De domeinlijst wordt niet uitgebreid met een schijnbaar handig wildcardpatroon.

Domeinbereik plannen

Het voorbeeld gebruikt de groep Vendor update domains met twee afzonderlijke hosts:

• updates.vendor.example voor de updatedownload
• cdn.vendor.example voor het bijbehorende contentendpoint

Het hoofddomein vendor.example wordt bewust niet als afkorting gebruikt. Sophos documenteert voor URL Group-matching in TLS-uitsluitingen uitdrukkelijk dat subdomeinen worden meegenomen. Een vermelding vendor.example zou in dit pad daarom ook login.vendor.example, telemetry.vendor.example en andere subdomeinen omvatten.

Ook een beperktere vermelding kan subdomeinen omvatten. updates.vendor.example kan in de TLS-match dus ook api.updates.vendor.example omvatten. Als slechts één concrete host wordt verwacht, wordt naast het positieve doel altijd een bewust vergelijkbare host als negatief doel getest.

Meerdere vermeldingen in dezelfde groep zijn geen verplichte lijst. Door de OR-logica is één domeinmatch voldoende. Als een dienst alleen werkt wanneer twee hosts samen bereikbaar zijn, moet elke host afzonderlijk worden getest. De URL Group bewijst geen functionele afhankelijkheid tussen beide.

URL Group maken

1. Web > URL groups openen.
2. Add selecteren.
3. Een naam zoals Vendor update domains instellen.
4. Onder Search/Add updates.vendor.example invoeren.
5. Add selecteren en controleren of de waarde in de lijst verschijnt.
6. cdn.vendor.example op dezelfde manier toevoegen.
7. Save selecteren.
8. De opgeslagen groep opnieuw openen en de naam en beide domeinen controleren.

Het selecteren van Add is een aparte stap. Een domeinnaam die alleen in het invoerveld staat, maakt nog geen deel uit van de groep.

De actuele SFOS 22-help vermeldt geen vast maximumaantal domeinen per URL Group. Dat is geen belofte van een onbeperkte lijst. Als honderden vermeldingen, frequente leverancierswijzigingen of voortdurend veranderende IOC’s worden verwacht, is een handmatig onderhouden URL Group meestal het verkeerde beheermodel.

URL Group in een Web Policy gebruiken

Een URL Group krijgt pas via een Web Policy-regel een Allow-, Warn-, Block- of Quota-effect.

1. Web > Policies openen.
2. De betrokken policy bewerken of een nieuwe policy maken.
3. Add rule selecteren.
4. Onder Users het bedoelde gebruikers- of groepsbereik instellen.
5. Onder Activities de algemene selectie All web traffic uitschakelen en de URL Group Vendor update domains selecteren.
6. De gewenste actie voor HTTP en HTTPS instellen, bijvoorbeeld Allow of Block.
7. De regelpositie controleren, de status inschakelen en de policy opslaan.
8. Onder Rules and policies > Firewall rules controleren of deze Web Policy onder Web filtering is geselecteerd in de firewallregel die daadwerkelijk matcht.
9. Log firewall traffic voor de acceptatietest inschakelen.

Web Policy-regels worden van boven naar beneden geëvalueerd. Een algemene Allow-regel boven de nieuwe URL Group-regel kan de match verhullen. Omgekeerd kan een specifieke Allow-regel die te hoog staat latere Block-regels onwerkzaam maken. De positie maakt daarom deel uit van de beveiligingsbeslissing en is niet alleen een weergavekwestie.

Een URL Group in een Web Policy vervangt geen firewallregel. De firewallregel staat eerst de gegevensstroom tussen de zones toe, daarna beoordeelt de gekoppelde Web Policy de webtoegang. Regels testen met Log Viewer, Policy Tester en Packet Capture laat zien welke regel en welke policy daadwerkelijk gelden.

URL Group als TLS-uitsluiting gebruiken

Voor bevestigde problemen met Certificate Pinning of andere ontsleutelingsproblemen kan hetzelfde objecttype in een SSL/TLS inspection rule met Action: Don’t decrypt worden gebruikt. SFOS vergelijkt het domein daarbij efficiënt als tekst via Server Name Indication, kortweg SNI.

Er zijn twee heldere varianten.

Local TLS exclusion list aanvullen

De Local TLS exclusion list is een ingebouwde URL Group en is standaard leeg. Deze hoort bij de permanente standaarduitsluitingsregel bovenaan de SSL/TLS-regeltabel.

Het handmatige pad is:

Web > URL groups > Local TLS exclusion list

Deze variant past voor een lokaal bevestigde domeinuitsluiting die onafhankelijk van een beperktere eigen bron- of gebruikersregel moet gelden. Domeinen kunnen ook via de troubleshootingfuncties in Control Center of Log Viewer aan deze lijst worden toegevoegd. Elk nieuw domein wordt daarom als productieve beveiligingsuitzondering gedocumenteerd en getest.

De Managed TLS exclusion list heeft een andere taak. Sophos onderhoudt hierin bekende incompatibele domeinen en kan de lijst via firmware-updates bijwerken. Eigen operationele domeinen zijn geen vervanging voor een bewust gekozen lokale regel in dit door de leverancier beheerde object.

Eigen Don’t decrypt-regel maken

Als de uitsluiting tot bepaalde bronnen, gebruikers, services of doelzones moet worden beperkt, is een eigen regel beter controleerbaar:

1. Rules and policies > SSL/TLS inspection rules openen.
2. Add selecteren.
3. Een naam zoals Vendor updates no decrypt instellen.
4. Action: Don’t decrypt selecteren.
5. Log connections inschakelen.
6. Source zones, Source networks, Users, Destination zones en Services tot het benodigde bereik beperken.
7. Onder Categories and websites de URL Group Vendor update domains selecteren.
8. De regel direct onder de standaarduitsluitingen en boven algemene Decrypt-regels plaatsen.
9. Opslaan en met een nieuwe verbinding testen.

SSL/TLS inspection rules werken onafhankelijk van firewallregels. Een correct matchende firewallregel bewijst daarom niet dat de gewenste TLS-regel geldt. Omgekeerd haalt Don’t decrypt alleen de ontsleuteling uit dit pad. Het is geen algemene toestemming voor willekeurig netwerkverkeer.

URL Groups zijn voor deze SNI-match efficiënter dan veel FQDN Host Objects in de bron of bestemming van een TLS-regel. FQDN Host Objects worden via DNS omgezet en hebben een andere functie. FQDN Hosts maken en veilig gebruiken legt de verschillen uit.

Als de TLS-verbinding geen bruikbare SNI bevat, kan het domein op deze manier niet worden herkend. De groep wordt dan niet met een hoofddomein verbreed. Eerst worden doel-IP, certificaat, Packet Capture en de werkelijke applicatiestroom gecontroleerd.

Match met positieve en negatieve test controleren

Een geslaagde paginalading bewijst alleen dat de dienst bereikbaar is. Ze bewijst niet dat de juiste Web Policy-regel of de bedoelde TLS-uitsluiting geldt.

Web Policy-test

1. Pilotclient, gebruiker, tijd en verwachte actie noteren.
2. De browser- of applicatiesessie volledig sluiten en opnieuw starten.
3. updates.vendor.example of het echte positieve domein openen.
4. In Log Viewer Source, User, Domain, Firewall Rule ID, Web Policy en Action controleren.
5. login.vendor.example of een echte, bewust niet opgenomen host testen.
6. Bevestigen dat de negatieve host nog steeds door de normale volgende policyregel wordt beoordeeld.
7. Als twee groepswaarden vereist zijn, elke host afzonderlijk testen.

Als de browser QUIC of HTTP/3 gebruikt, kan het verwachte TCP-webpad er anders uitzien. De test wordt eerst van QUIC en HTTP/3 onderscheiden.

TLS-uitsluitingstest

1. Een nieuwe TLS-verbinding met de positieve host opbouwen.
2. In het SSL/TLS-log de matchende regel en de status zonder ontsleuteling controleren.
3. Het voor de client zichtbare certificaat vergelijken met de toestand onder de normale ontsleutelingsregel.
4. Een vergelijkbare negatieve host openen die niet in de groep staat.
5. Bevestigen dat deze host nog steeds door de verwachte Decrypt-regel wordt verwerkt.
6. Bronbereik, SNI en regelpositie documenteren.

Voor een bewuste rollbacktest wordt de gebruikte web- of TLS-regel tijdens een onderhoudsvenster naar de gedocumenteerde vorige toestand teruggezet. De positieve host moet daarna opnieuw het eerdere gedrag vertonen. Alleen deze tegenproef maakt van een werkende workaround een reproduceerbare acceptatietest.

Fouten systematisch afbakenen

URL Group geldt niet in de Web Policy

• De domeinwaarde is ingevoerd, maar niet met Add overgenomen.
• De URL Group is niet onder Activities van de actieve policyregel geselecteerd.
• All web traffic of een andere eerdere regel matcht eerst.
• De policyregel is uitgeschakeld.
• De Web Policy is niet in de daadwerkelijk matchende firewallregel geselecteerd.
• Het echte request gebruikt een niet-gedocumenteerde redirect-, login-, API- of CDN-host.
• Een bestaande browser- of QUIC-verbinding is niet opnieuw opgebouwd.

TLS-uitsluiting geldt niet

• De URL Group is niet onder Categories and websites van de verwachte regel geselecteerd.
• De Don't decrypt-regel staat onder een Decrypt-regel die al matcht.
• Source, User, Zone, Service of een ander regelcriterium past niet.
• De verbinding stuurt geen bruikbare SNI.
• De werkelijke TLS-host verschilt van de URL die in de browser zichtbaar is.
• De bestaande TLS-sessie is na de wijziging verder gebruikt.

URL Group geldt te breed

• Een hoofddomein is ingevoerd in plaats van de werkelijk benodigde hosts.
• Een vermelding omvat in de TLS-match extra subdomeinen.
• De groep wordt door meerdere policies of TLS-regels gebruikt.
• Een Allow-regel staat te hoog of geldt voor te veel gebruikers.
• De Local TLS exclusion list werkt breder dan een eigen, op bron beperkte regel.

Voeg dan geen nieuw domein toe. Controleer eerst alle toepassingen van de groep, de werkelijke regelvolgorde en de negatieve test.

Wijzigingen en rollback veilig beheren

Leg vóór elke wijziging aan een productieve URL Group vast:

• de vorige domeinlijst
• verwijzende Web Policies en SSL/TLS inspection rules
• eigenaar en zakelijke reden
• betrokken gebruikers, bronnen en services
• positieve en negatieve testgevallen
• review- of vervaldatum

Een gedeelde groep wordt niet stilzwijgend voor één incident uitgebreid. Als een weballowlist en een TLS-uitsluiting verschillende eigenaren of levenscycli hebben, zijn afzonderlijke URL Groups duidelijker, ook wanneer enkele domeinen identiek zijn.

Voor rollback wordt eerst de gebruikte regel- of policytoestand hersteld of alleen het nieuw toegevoegde domein verwijderd. Verwijder de hele groep pas als geen andere policy of regel ervan afhankelijk is. Controleer daarna opnieuw nieuwe verbindingen voor de positieve en negatieve host en bekijk de logs nogmaals.

Operationele checklist

• Bevestigd dat een URL Group het juiste hulpmiddel is.
• Alleen geldige domeinen toegevoegd, zonder protocollen, paden, wildcards of regex.
• Effect van hoofddomein en subdomeinen bewust begrensd.
• Rekening gehouden met OR-logica tussen meerdere domeinen.
• Groepsnaam, eigenaar, doel en reviewdatum gedocumenteerd.
• De gebruikte Web Policy of SSL/TLS inspection rule duidelijk vastgesteld.
• Regelstatus, positie, bronbereik en logging gecontroleerd.
• Web Policy in de juiste firewallregel geselecteerd.
• Voor een TLS-uitsluiting SNI en Don't decrypt-regel bevestigd.
• Positieve en negatieve tests met nieuwe verbindingen uitgevoerd.
• Verwijzingen en vorige toestand voor rollback vastgelegd.

Veelgestelde vragen