Sophos Firewall URL Groups erstellen und sicher verwenden

Eine URL Group bündelt konkrete Domains, damit sie in einer Web Policy oder einer SSL/TLS Inspection Rule gemeinsam verwendet werden können. Das klingt einfach, hat aber eine wichtige Konsequenz: Jede Änderung an der Gruppe wirkt auf alle Regeln und Policies, die dieses Objekt referenzieren.

Der sichere Ablauf beginnt deshalb nicht mit einer möglichst grossen Herstellerliste. Zuerst werden die tatsächlich verwendeten Domains aus Request, Log oder Herstellerdokumentation erfasst. Danach entsteht eine kleine Gruppe mit klarem Zweck, Owner und Testplan.

URL Group in sieben Schritten

1. Den betroffenen Client, die echten Zielhosts und den gewünschten Entscheid dokumentieren: erlauben, blockieren oder nicht entschlüsseln.
2. Prüfen, ob eine URL Group wirklich passt. Sie verarbeitet Domains, aber keine URL-Pfade, Query-Strings oder regulären Ausdrücke.
3. Unter Web > URL groups > Add einen sprechenden Namen setzen und jeden gültigen Domainnamen mit Add übernehmen.
4. Die Gruppe entweder als Activity in einer Web Policy oder unter Categories and websites in einer SSL/TLS Inspection Rule auswählen.
5. Regelreihenfolge, Status, Quellbereich und Logging kontrollieren. Eine Gruppe allein erlaubt oder blockiert noch nichts.
6. Mit einer neuen Verbindung einen erwarteten Treffer und einen bewusst ähnlichen Nicht-Treffer testen.
7. Domainliste, Verbraucher, Owner, Begründung, Testdatum und Rollback dokumentieren.

⚠️ Mehrere Domains innerhalb einer URL Group werden mit OR ausgewertet. Ein einzelner Treffer genügt. Bei TLS-Ausnahmen schliesst ein Domain-Eintrag ausserdem seine Subdomains ein. Eine zu breite Root-Domain oder eine hoch platzierte Allow-Regel kann deshalb deutlich mehr Traffic erfassen als geplant.

Was eine URL Group steuert und was nicht

Eine URL Group ist ein wiederverwendbares Domainobjekt. Sie beschreibt, welche Domains zusammengehören. Die konsumierende Regel entscheidet danach, was mit dem Match geschieht.

Typische Verwendungen:

• eine kleine Business-Allowlist in einer Web Policy
• eine explizite Blocklist für bekannte Domains
• eine Domainliste in einer Don't decrypt-Regel
• die lokale TLS-Ausnahmeliste für bestätigte Decryption-Probleme

Eine URL Group ist dagegen nicht das richtige Werkzeug für jeden Webfall:

• Web category: breite inhaltliche Klassifizierung oder eigene Kategorie mit URL-Pfaden beziehungsweise Keywords
• Web Exception: Regex-basierter Match und gezieltes Überspringen von Web-, Scan- oder Zertifikatsprüfungen
• FQDN Host: DNS-basiertes Netzwerkobjekt für Firewall-, NAT- oder Routingregeln
• Threat Feed: dynamisch gepflegte IOC- oder Domainlisten

Die vollständige Policy-Logik erklärt Web Protection mit Web Policies einrichten. Die Wahl zwischen eigener Kategorie und Domainliste steht unter Web-Kategorien und Instant Alerts nutzen. Für dynamische Sicherheitslisten passt Sophos Firewall Threat Feeds.

Domain statt vollständiger URL

Unter Search/Add erwartet SFOS einen gültigen Domainnamen. Protokoll, Pfad und Query gehören nicht in das Feld.

Gültige Beispielwerte:

updates.vendor.example
cdn.vendor.example

Ungeeignete Werte:

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

Die Endung .example ist für Dokumentation reserviert. In der realen Konfiguration werden die Beispiele durch die im Log, Request oder Herstellerdokument bestätigten Domains ersetzt.

Wenn ein bestimmter URL-Pfad, ein Query-Parameter oder ein regulärer Ausdruck erforderlich ist, passt je nach Ziel eine eigene Web Category oder eine sicher begrenzte Web Exception. Die Domainliste wird nicht durch ein scheinbar praktisches Wildcard-Muster erweitert.

Domain-Scope planen

Das Beispiel verwendet die Gruppe Vendor update domains mit zwei getrennten Hosts:

• updates.vendor.example für den Update-Download
• cdn.vendor.example für den zugehörigen Content-Endpunkt

Die Root-Domain vendor.example wird bewusst nicht als Abkürzung verwendet. Sophos dokumentiert für den URL-Group-Match in TLS-Ausnahmen ausdrücklich, dass Subdomains eingeschlossen sind. Ein Eintrag vendor.example würde in diesem Pfad deshalb auch login.vendor.example, telemetry.vendor.example und weitere Subdomains umfassen.

Auch ein engerer Eintrag kann Subdomains einschliessen. updates.vendor.example kann im TLS-Match somit auch api.updates.vendor.example erfassen. Wer nur einen konkreten Host erwartet, prüft deshalb neben dem Positivziel immer einen absichtlich ähnlichen Host als Negativziel.

Mehrere Einträge in derselben Gruppe sind keine Pflichtliste. Wegen der OR-Logik reicht ein Domainmatch. Wenn ein Dienst nur funktioniert, wenn zwei Hosts gemeinsam erreichbar sind, muss jeder Host separat getestet werden. Die URL Group beweist keine funktionale Abhängigkeit zwischen ihnen.

URL Group erstellen

1. Web > URL groups öffnen.
2. Add auswählen.
3. Als Namen zum Beispiel Vendor update domains setzen.
4. Unter Search/Add updates.vendor.example eingeben.
5. Add wählen und kontrollieren, dass der Wert in der Liste erscheint.
6. cdn.vendor.example auf dieselbe Weise hinzufügen.
7. Save wählen.
8. Die gespeicherte Gruppe nochmals öffnen und Namen sowie beide Domains prüfen.

Das Drücken von Add ist ein eigener Schritt. Ein Domainname, der nur im Eingabefeld steht, ist noch nicht Teil der Gruppe.

Die aktuelle SFOS-22-Hilfe nennt keine feste maximale Anzahl Domains pro URL Group. Das ist keine Zusage für eine unbegrenzte Liste. Wenn hunderte Einträge, häufige Herstelleränderungen oder laufend wechselnde IOCs erwartet werden, ist eine manuell gepflegte URL Group meistens das falsche Betriebsmodell.

URL Group in einer Web Policy verwenden

Eine URL Group erhält ihre Allow-, Warn-, Block- oder Quota-Wirkung erst durch eine Web-Policy-Regel.

1. Web > Policies öffnen.
2. Die betroffene Policy bearbeiten oder eine neue Policy anlegen.
3. Add rule wählen.
4. Unter Users den vorgesehenen Benutzer- oder Gruppenscope setzen.
5. Unter Activities die allgemeine Auswahl All web traffic entfernen und die URL Group Vendor update domains auswählen.
6. Die gewünschte Aktion für HTTP und HTTPS setzen, zum Beispiel Allow oder Block.
7. Regelposition kontrollieren, Status einschalten und Policy speichern.
8. Unter Rules and policies > Firewall rules prüfen, dass diese Web Policy in der tatsächlich matchenden Firewall-Regel unter Web filtering ausgewählt ist.
9. Log firewall traffic für die Abnahme aktivieren.

Web-Policy-Regeln werden von oben nach unten ausgewertet. Eine allgemeine Allow-Regel oberhalb der neuen URL-Group-Regel kann den Match verdecken. Umgekehrt kann eine spezifische Allow-Regel zu weit oben spätere Blockregeln unwirksam machen. Die Position ist deshalb Teil des Sicherheitsentscheids und nicht nur eine Darstellungsfrage.

Eine URL Group in einer Web Policy ersetzt keine Firewall-Regel. Die Firewall-Regel erlaubt zuerst den Datenfluss zwischen den Zonen, danach bewertet die zugeordnete Web Policy den Webzugriff. Welche Regel und Policy wirklich greifen, zeigt Regel testen mit Log Viewer, Policy Tester und Packet Capture.

URL Group als TLS-Ausnahme verwenden

Für bestätigte Certificate-Pinning- oder andere Decryption-Probleme kann dieselbe Objektart in einer SSL/TLS Inspection Rule mit Action: Don’t decrypt verwendet werden. SFOS gleicht die Domain dabei effizient als Text über den Server Name Indication, kurz SNI, ab.

Es gibt zwei saubere Varianten.

Local TLS exclusion list ergänzen

Die Local TLS exclusion list ist eine eingebaute URL Group und standardmässig leer. Sie gehört zur permanenten Standard-Ausnahmeregel ganz oben in der SSL/TLS-Regeltabelle.

Der manuelle Pfad lautet:

Web > URL groups > Local TLS exclusion list

Diese Variante passt für eine lokal bestätigte Domainausnahme, die unabhängig von einer engeren eigenen Quell- oder Benutzerregel gelten soll. Domains können auch über die Troubleshooting-Funktionen im Control Center oder Log Viewer in diese Liste gelangen. Jede neue Domain wird deshalb wie eine produktive Sicherheitsausnahme dokumentiert und getestet.

Die Managed TLS exclusion list löst eine andere Aufgabe. Sophos pflegt darin bekannte inkompatible Domains und kann die Liste mit Firmware-Updates aktualisieren. Eigene betriebliche Domains gehören nicht als Ersatz für eine bewusste lokale Regel in dieses Herstellerobjekt.

Eigene Don’t-decrypt-Regel erstellen

Wenn die Ausnahme auf bestimmte Quellen, Benutzer, Services oder Zielzonen begrenzt werden soll, ist eine eigene Regel besser nachvollziehbar:

1. Rules and policies > SSL/TLS inspection rules öffnen.
2. Add auswählen.
3. Einen Namen wie Vendor updates no decrypt setzen.
4. Action: Don’t decrypt wählen.
5. Log connections aktivieren.
6. Source zones, Source networks, Users, Destination zones und Services auf den benötigten Scope begrenzen.
7. Unter Categories and websites die URL Group Vendor update domains auswählen.
8. Die Regel direkt unter den Standard-Ausnahmen und oberhalb allgemeiner Decrypt-Regeln positionieren.
9. Speichern und mit einer neuen Verbindung testen.

SSL/TLS Inspection Rules arbeiten unabhängig von Firewall-Regeln. Eine korrekt matchende Firewall-Regel beweist daher nicht, dass die gewünschte TLS-Regel greift. Umgekehrt nimmt Don’t decrypt nur die Entschlüsselung aus diesem Pfad. Es ist keine pauschale Freigabe für beliebigen Netzwerktraffic.

URL Groups sind für diesen SNI-Match effizienter als viele FQDN Host Objects in Source oder Destination einer TLS-Regel. FQDN Host Objects lösen DNS-basiert auf und erfüllen eine andere Aufgabe. Die Unterschiede erklärt FQDN Hosts erstellen und sicher verwenden.

Fehlt SNI in der TLS-Verbindung, kann die Domain auf diesem Weg nicht erkannt werden. Dann wird die Gruppe nicht mit einer Root-Domain verbreitert. Zuerst werden Ziel-IP, Zertifikat, Packet Capture und der tatsächliche Anwendungsflow geprüft.

Match mit Positiv- und Negativtest prüfen

Ein erfolgreicher Seitenaufruf beweist nur, dass der Dienst erreichbar ist. Er beweist weder die richtige Web-Policy-Regel noch die gewünschte TLS-Ausnahme.

Web-Policy-Test

1. Pilotclient, Benutzer, Uhrzeit und erwartete Aktion notieren.
2. Browser- oder Anwendungssession vollständig schliessen und neu starten.
3. updates.vendor.example beziehungsweise die reale Positivdomain aufrufen.
4. Im Log Viewer Source, User, Domain, Firewall Rule ID, Web Policy und Action prüfen.
5. login.vendor.example beziehungsweise einen realen, bewusst nicht aufgenommenen Host testen.
6. Bestätigen, dass der Negativhost weiterhin von der normalen späteren Policy-Regel bewertet wird.
7. Bei zwei erforderlichen Gruppenwerten jeden Host einzeln testen.

Wenn der Browser QUIC beziehungsweise HTTP/3 verwendet, kann der erwartete TCP-Webpfad anders aussehen. Der Test wird dann zuerst gegen QUIC und HTTP/3 abgegrenzt.

TLS-Ausnahmetest

1. Neue TLS-Verbindung zum Positivhost aufbauen.
2. Im SSL/TLS-Log die matchende Regel und den Nicht-Entschlüsselungsstatus prüfen.
3. Das vom Client sichtbare Zertifikat mit dem Zustand der normalen Decryption-Regel vergleichen.
4. Einen ähnlichen Negativhost aufrufen, der nicht in der Gruppe steht.
5. Bestätigen, dass dieser Host weiterhin von der erwarteten Decrypt-Regel erfasst wird.
6. Source Scope, SNI und Regelposition dokumentieren.

Für einen bewussten Rollback-Test wird die konsumierende Web- oder TLS-Regel im Wartungsfenster auf den dokumentierten Vorzustand zurückgesetzt. Danach muss der Positivhost wieder das frühere Verhalten zeigen. Erst diese Gegenprobe macht aus einem funktionierenden Workaround eine nachvollziehbare Abnahme.

Fehler systematisch eingrenzen

URL Group greift in der Web Policy nicht

• Der Domainwert wurde eingegeben, aber nicht mit Add übernommen.
• Die URL Group ist nicht unter Activities der aktiven Policy-Regel ausgewählt.
• All web traffic oder eine andere frühere Regel matcht zuerst.
• Die Policy-Regel ist ausgeschaltet.
• Die Web Policy ist nicht in der tatsächlich matchenden Firewall-Regel ausgewählt.
• Der echte Request verwendet einen Redirect-, Login-, API- oder CDN-Host, der nicht dokumentiert wurde.
• Eine bestehende Browser- oder QUIC-Verbindung wurde nicht neu aufgebaut.

TLS-Ausnahme greift nicht

• Die URL Group ist nicht unter Categories and websites der erwarteten Regel ausgewählt.
• Die Don't decrypt-Regel steht unter einer bereits matchenden Decrypt-Regel.
• Source, User, Zone, Service oder ein anderes Regelkriterium passt nicht.
• Die Verbindung sendet kein auswertbares SNI.
• Der reale TLS-Host unterscheidet sich von der sichtbaren Browser-URL.
• Die bestehende TLS-Session wurde nach der Änderung weiterverwendet.

URL Group greift zu breit

• Eine Root-Domain wurde statt der tatsächlich benötigten Hosts eingetragen.
• Ein Eintrag umfasst im TLS-Match weitere Subdomains.
• Die Gruppe wird von mehreren Policies oder TLS-Regeln verwendet.
• Eine Allow-Regel steht zu weit oben oder gilt für zu viele Benutzer.
• Die Local TLS exclusion list wirkt breiter als eine eigene, quellenbegrenzte Regel.

Dann wird nicht noch eine weitere Domain ergänzt. Zuerst werden alle Verwendungen der Gruppe, die echte Regelreihenfolge und der Negativtest geprüft.

Änderungen und Rollback sicher betreiben

Vor jeder Änderung an einer produktiven URL Group werden festgehalten:

• bisherige Domainliste
• referenzierende Web Policies und SSL/TLS Inspection Rules
• Owner und fachliche Begründung
• betroffene Benutzer, Quellen und Services
• positiver und negativer Testfall
• Review- oder Ablaufdatum

Eine gemeinsam verwendete Gruppe wird nicht für einen einzelnen Störungsfall stillschweigend erweitert. Wenn Web-Allowlist und TLS-Ausnahme unterschiedliche Owner oder Lebenszyklen haben, sind getrennte URL Groups sauberer, auch wenn einzelne Domains identisch sind.

Für den Rollback wird zuerst der konsumierende Regel- oder Policyzustand wiederhergestellt oder nur der neu hinzugefügte Domainwert entfernt. Die ganze Gruppe wird erst gelöscht, wenn keine andere Policy oder Regel mehr davon abhängt. Danach werden neue Verbindungen für Positiv- und Negativhost sowie die Logs erneut geprüft.

Betriebscheckliste

• URL Group als passendes Werkzeug bestätigt.
• Nur gültige Domains, keine Protokolle, Pfade, Wildcards oder Regex eingetragen.
• Root-Domain und Subdomain-Wirkung bewusst begrenzt.
• OR-Logik zwischen mehreren Domains berücksichtigt.
• Gruppenname, Owner, Zweck und Review-Datum dokumentiert.
• Web Policy oder SSL/TLS Inspection Rule als Verbraucher eindeutig bestimmt.
• Regelstatus, Position, Source Scope und Logging geprüft.
• Web Policy in der richtigen Firewall-Regel ausgewählt.
• Bei TLS-Ausnahme SNI und Don't decrypt-Regel bestätigt.
• Positiv- und Negativtest mit neuen Verbindungen durchgeführt.
• Referenzen und Vorzustand für den Rollback gesichert.

Häufige Fragen