Skapa och använd URL Groups säkert på Sophos Firewall

En URL Group samlar konkreta domäner så att de kan användas tillsammans i en Web Policy eller en SSL/TLS inspection rule. Det låter enkelt, men har en viktig följd: varje ändring i gruppen påverkar alla regler och policies som refererar till objektet.

Det säkra arbetssättet börjar därför inte med en så stor leverantörslista som möjligt. Först fastställs de domäner som faktiskt används utifrån en begäran, logg eller leverantörsdokumentation. Därefter skapas en liten grupp med tydligt syfte, ägare och testplan.

URL Group i sju steg

1. Dokumentera berörd klient, de faktiska målhostarna och önskat beslut: tillåt, blockera eller dekryptera inte.
2. Kontrollera att en URL Group verkligen passar. Den hanterar domäner, men inte URL-sökvägar, frågesträngar eller reguljära uttryck.
3. Ange ett tydligt namn under Web > URL groups > Add och lägg till varje giltigt domännamn med Add.
4. Välj gruppen antingen som Activity i en Web Policy eller under Categories and websites i en SSL/TLS inspection rule.
5. Kontrollera regelordning, status, källomfång och loggning. En grupp i sig tillåter eller blockerar ännu ingenting.
6. Använd en ny anslutning för att testa en förväntad träff och en medvetet liknande icke-träff.
7. Dokumentera domänlista, användande objekt, ägare, anledning, testdatum och rollback.

⚠️ Flera domäner i en URL Group utvärderas med OR. En enda träff räcker. För TLS-undantag omfattar en domänpost dessutom dess underdomäner. En för bred rotdomän eller en högt placerad Allow-regel kan därför omfatta betydligt mer trafik än planerat.

Vad en URL Group styr och inte styr

En URL Group är ett återanvändbart domänobjekt. Den beskriver vilka domäner som hör ihop. Regeln som använder objektet avgör sedan vad som händer med träffen.

Typiska användningsområden:

• en liten företagsrelaterad allowlist i en Web Policy
• en uttrycklig blocklist för kända domäner
• en domänlista i en Don't decrypt-regel
• den lokala TLS-undantagslistan för bekräftade dekrypteringsproblem

En URL Group är däremot inte rätt verktyg för varje webbfall:

• Web category: bred innehållsklassificering eller en egen kategori med URL-sökvägar eller nyckelord
• Web Exception: regex-baserad matchning och riktat undantag från webb-, skannings- eller certifikatkontroller
• FQDN Host: DNS-baserat nätverksobjekt för brandväggs-, NAT- eller routningsregler
• Threat Feed: dynamiskt underhållna IOC- eller domänlistor

Konfigurera Web Protection med Web Policies förklarar hela policylogiken. Valet mellan en egen kategori och en domänlista behandlas i Använd web categories och Instant Alerts. För dynamiska säkerhetslistor passar Sophos Firewall Threat Feeds.

Domän i stället för fullständig URL

Under Search/Add förväntar sig SFOS ett giltigt domännamn. Protokoll, sökväg och query hör inte hemma i fältet.

Giltiga exempelvärden:

updates.vendor.example
cdn.vendor.example

Olämpliga värden:

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

Ändelsen .example är reserverad för dokumentation. I den verkliga konfigurationen ersätts exemplen med domäner som har bekräftats i loggen, begäran eller leverantörsdokumentationen.

Om en viss URL-sökväg, en frågeparameter eller ett reguljärt uttryck krävs passar beroende på syftet en egen web category eller en säkert avgränsad Web Exception. Domänlistan utökas inte med ett till synes praktiskt wildcardmönster.

Planera domänomfånget

Exemplet använder gruppen Vendor update domains med två separata hostar:

• updates.vendor.example för uppdateringshämtningen
• cdn.vendor.example för tillhörande innehållsendpoint

Rotdomänen vendor.example används medvetet inte som förkortning. Sophos dokumenterar uttryckligen att underdomäner inkluderas när URL Groups matchas i TLS-undantag. En post vendor.example skulle därför även omfatta login.vendor.example, telemetry.vendor.example och andra underdomäner i detta flöde.

Även en snävare post kan omfatta underdomäner. updates.vendor.example kan därför också träffa api.updates.vendor.example vid TLS-matchning. Om endast en specifik host förväntas testas alltid en medvetet liknande host som negativt mål utöver det positiva målet.

Flera poster i samma grupp är inte en obligatorisk lista. På grund av OR-logiken räcker en domänträff. Om en tjänst bara fungerar när två hostar är nåbara samtidigt måste varje host testas separat. URL Group bevisar inte något funktionellt beroende mellan dem.

Skapa en URL Group

1. Öppna Web > URL groups.
2. Välj Add.
3. Ange ett namn, till exempel Vendor update domains.
4. Ange updates.vendor.example under Search/Add.
5. Välj Add och kontrollera att värdet visas i listan.
6. Lägg till cdn.vendor.example på samma sätt.
7. Välj Save.
8. Öppna den sparade gruppen igen och kontrollera namnet och båda domänerna.

Att välja Add är ett eget steg. Ett domännamn som bara finns kvar i inmatningsfältet ingår ännu inte i gruppen.

Den aktuella SFOS 22-hjälpen anger inget fast maximalt antal domäner per URL Group. Det är inget löfte om en obegränsad lista. Om hundratals poster, frekventa leverantörsändringar eller ständigt föränderliga IOC:er förväntas är en manuellt underhållen URL Group oftast fel driftsmodell.

Använd en URL Group i en Web Policy

En URL Group får effekt som Allow, Warn, Block eller Quota först genom en Web Policy-regel.

1. Öppna Web > Policies.
2. Redigera berörd policy eller skapa en ny.
3. Välj Add rule.
4. Ange avsett användar- eller gruppomfång under Users.
5. Avmarkera det allmänna valet All web traffic under Activities och välj URL Group Vendor update domains.
6. Ange önskad åtgärd för HTTP och HTTPS, till exempel Allow eller Block.
7. Kontrollera regelpositionen, slå på dess status och spara policyn.
8. Kontrollera under Rules and policies > Firewall rules att denna Web Policy är vald under Web filtering i den brandväggsregel som faktiskt matchar.
9. Aktivera Log firewall traffic för verifieringen.

Web Policy-regler utvärderas uppifrån och ned. En allmän Allow-regel ovanför den nya URL Group-regeln kan dölja träffen. Omvänt kan en specifik Allow-regel som ligger för högt göra senare Block-regler verkningslösa. Positionen är därför en del av säkerhetsbeslutet och inte bara en visningsfråga.

En URL Group i en Web Policy ersätter inte en brandväggsregel. Brandväggsregeln tillåter först dataflödet mellan zonerna, därefter bedömer tilldelad Web Policy webbåtkomsten. Testa regler med Log Viewer, Policy Tester och Packet Capture visar vilken regel och vilken policy som faktiskt används.

Använd en URL Group som TLS-undantag

Vid bekräftade problem med Certificate Pinning eller annan dekryptering kan samma objekttyp användas i en SSL/TLS inspection rule med Action: Don’t decrypt. SFOS jämför då domänen effektivt som text via Server Name Indication, eller SNI.

Det finns två tydliga alternativ.

Komplettera Local TLS exclusion list

Local TLS exclusion list är en inbyggd URL Group och är tom som standard. Den hör till den permanenta standardundantagsregeln högst upp i SSL/TLS-regeltabellen.

Den manuella sökvägen är:

Web > URL groups > Local TLS exclusion list

Detta alternativ passar för ett lokalt bekräftat domänundantag som ska gälla oberoende av en snävare egen käll- eller användarregel. Domäner kan också läggas till i listan via felsökningsfunktionerna i Control Center eller Log Viewer. Varje ny domän dokumenteras och testas därför som ett produktionsundantag för säkerheten.

Managed TLS exclusion list har en annan uppgift. Sophos underhåller kända inkompatibla domäner i listan och kan uppdatera den med firmwareuppdateringar. Egna driftsdomäner ersätter inte en medvetet planerad lokal regel i detta leverantörshanterade objekt.

Skapa en egen Don’t decrypt-regel

Om undantaget ska begränsas till vissa källor, användare, tjänster eller målzoner är en egen regel lättare att kontrollera:

1. Öppna Rules and policies > SSL/TLS inspection rules.
2. Välj Add.
3. Ange ett namn, till exempel Vendor updates no decrypt.
4. Välj Action: Don’t decrypt.
5. Aktivera Log connections.
6. Begränsa Source zones, Source networks, Users, Destination zones och Services till nödvändigt omfång.
7. Välj URL Group Vendor update domains under Categories and websites.
8. Placera regeln direkt under standardundantagen och ovanför allmänna Decrypt-regler.
9. Spara och testa med en ny anslutning.

SSL/TLS inspection rules fungerar oberoende av brandväggsregler. En brandväggsregel som matchar korrekt bevisar därför inte att önskad TLS-regel används. Omvänt undantar Don’t decrypt endast dekrypteringen från detta flöde. Det är inget allmänt tillstånd för godtycklig nätverkstrafik.

URL Groups är effektivare för denna SNI-matchning än många FQDN Host Objects i källan eller destinationen för en TLS-regel. FQDN Host Objects slås upp via DNS och fyller en annan funktion. Skapa och använd FQDN Hosts säkert förklarar skillnaderna.

Om TLS-anslutningen inte innehåller användbar SNI kan domänen inte identifieras på detta sätt. Gruppen utökas då inte med en rotdomän. Kontrollera först mål-IP, certifikat, Packet Capture och det faktiska programflödet.

Verifiera matchningen med positiva och negativa tester

En lyckad sidladdning bevisar bara att tjänsten är nåbar. Den bevisar varken rätt Web Policy-regel eller avsett TLS-undantag.

Web Policy-test

1. Notera pilotklient, användare, tid och förväntad åtgärd.
2. Stäng webbläsar- eller programsessionen helt och starta den på nytt.
3. Öppna updates.vendor.example eller den verkliga positiva domänen.
4. Kontrollera Source, User, Domain, Firewall Rule ID, Web Policy och Action i Log Viewer.
5. Testa login.vendor.example eller en verklig host som medvetet inte har lagts till.
6. Bekräfta att den negativa hosten fortfarande bedöms av den normala efterföljande policyregeln.
7. Om två gruppvärden krävs, testa varje host separat.

Om webbläsaren använder QUIC eller HTTP/3 kan den förväntade TCP-webbvägen se annorlunda ut. Avgränsa först testet mot QUIC och HTTP/3.

TLS-undantagstest

1. Upprätta en ny TLS-anslutning till den positiva hosten.
2. Kontrollera matchande regel och status utan dekryptering i SSL/TLS-loggen.
3. Jämför certifikatet som klienten ser med tillståndet under den normala dekrypteringsregeln.
4. Öppna en liknande negativ host som inte finns i gruppen.
5. Bekräfta att denna host fortfarande hanteras av förväntad Decrypt-regel.
6. Dokumentera källomfång, SNI och regelposition.

För ett medvetet rollbacktest återställs den användande webb- eller TLS-regeln till det dokumenterade tidigare tillståndet under ett underhållsfönster. Den positiva hosten måste då åter visa tidigare beteende. Först denna motkontroll gör en fungerande workaround till ett reproducerbart acceptanstest.

Avgränsa fel systematiskt

URL Group används inte i Web Policy

• Domänvärdet har angetts men inte lagts till med Add.
• URL Group är inte vald under Activities i den aktiva policyregeln.
• All web traffic eller en annan tidigare regel matchar först.
• Policyregeln är avstängd.
• Web Policy är inte vald i den brandväggsregel som faktiskt matchar.
• Den verkliga begäran använder en odokumenterad redirect-, login-, API- eller CDN-host.
• En befintlig webbläsar- eller QUIC-anslutning har inte byggts upp på nytt.

TLS-undantaget används inte

• URL Group är inte vald under Categories and websites i den förväntade regeln.
• Don't decrypt-regeln ligger under en Decrypt-regel som redan matchar.
• Source, User, Zone, Service eller något annat regelkriterium stämmer inte.
• Anslutningen skickar ingen användbar SNI.
• Den verkliga TLS-hosten skiljer sig från URL:en som visas i webbläsaren.
• Den befintliga TLS-sessionen har fortsatt användas efter ändringen.

URL Group används för brett

• En rotdomän har angetts i stället för de hostar som faktiskt behövs.
• En post omfattar ytterligare underdomäner vid TLS-matchning.
• Gruppen används av flera policies eller TLS-regler.
• En Allow-regel ligger för högt eller gäller för många användare.
• Local TLS exclusion list har bredare effekt än en egen källbegränsad regel.

Lägg då inte till ytterligare en domän. Kontrollera först alla användningar av gruppen, den faktiska regelordningen och det negativa testet.

Hantera ändringar och rollback säkert

Före varje ändring av en URL Group i produktion dokumenteras:

• tidigare domänlista
• refererande Web Policies och SSL/TLS inspection rules
• ägare och teknisk motivering
• berörda användare, källor och tjänster
• positiva och negativa testfall
• gransknings- eller utgångsdatum

En delad grupp utökas inte obemärkt för ett enskilt incidentfall. Om en web allowlist och ett TLS-undantag har olika ägare eller livscykler är separata URL Groups tydligare, även om vissa domäner är identiska.

Vid rollback återställs först tillståndet i regeln eller policyn som använder gruppen, eller så tas endast den nyligen tillagda domänen bort. Hela gruppen tas bort först när ingen annan policy eller regel längre är beroende av den. Därefter kontrolleras nya anslutningar för den positiva och negativa hosten samt loggarna på nytt.

Checklista för drift

• URL Group bekräftad som rätt verktyg.
• Endast giltiga domäner tillagda, utan protokoll, sökvägar, wildcards eller regex.
• Rotdomänens och underdomänernas effekt medvetet begränsad.
• OR-logik mellan flera domäner beaktad.
• Gruppnamn, ägare, syfte och granskningsdatum dokumenterade.
• Användande Web Policy eller SSL/TLS inspection rule tydligt identifierad.
• Regelstatus, position, källomfång och loggning kontrollerade.
• Web Policy vald i rätt brandväggsregel.
• För ett TLS-undantag har SNI och Don't decrypt-regel bekräftats.
• Positiva och negativa tester med nya anslutningar genomförda.
• Referenser och tidigare tillstånd sparade för rollback.

Vanliga frågor