Creare e usare in sicurezza gli URL Groups su Sophos Firewall

Un URL Group raggruppa domini specifici per utilizzarli insieme in una Web Policy o in una SSL/TLS inspection rule. Può sembrare semplice, ma comporta una conseguenza importante: ogni modifica al gruppo interessa tutte le regole e le policy che fanno riferimento a questo oggetto.

Il processo sicuro non inizia quindi con l’elenco più ampio possibile fornito dal produttore. Prima si individuano i domini effettivamente utilizzati tramite una richiesta, un log o la documentazione del produttore. Poi si crea un gruppo piccolo con scopo, responsabile e piano di test chiari.

URL Group in sette passaggi

1. Documentare il client interessato, gli host di destinazione reali e la decisione desiderata: consentire, bloccare o non decrittografare.
2. Verificare che un URL Group sia davvero adatto. Elabora domini, ma non percorsi URL, stringhe di query o espressioni regolari.
3. In Web > URL groups > Add, impostare un nome significativo e acquisire ogni nome di dominio valido con Add.
4. Selezionare il gruppo come Activity in una Web Policy oppure in Categories and websites in una SSL/TLS inspection rule.
5. Controllare ordine delle regole, stato, ambito sorgente e logging. Un gruppo da solo non consente né blocca ancora nulla.
6. Con una nuova connessione, testare una corrispondenza attesa e una mancata corrispondenza volutamente simile.
7. Documentare elenco dei domini, utilizzatori, responsabile, motivazione, data del test e rollback.

⚠️ Più domini nello stesso URL Group vengono valutati con OR. È sufficiente una sola corrispondenza. Nelle esclusioni TLS, inoltre, una voce di dominio include i relativi sottodomini. Un dominio radice troppo ampio o una regola Allow collocata molto in alto possono quindi intercettare molto più traffico del previsto.

Cosa controlla un URL Group e cosa non controlla

Un URL Group è un oggetto di dominio riutilizzabile. Descrive quali domini appartengono allo stesso insieme. La regola che lo utilizza decide poi cosa accade alla corrispondenza.

Utilizzi tipici:

• una piccola allowlist aziendale in una Web Policy
• una blocklist esplicita per domini noti
• un elenco di domini in una regola Don't decrypt
• la lista locale di esclusioni TLS per problemi di decrittografia confermati

Un URL Group non è però lo strumento corretto per ogni caso web:

• Web category: classificazione ampia dei contenuti o categoria personalizzata con percorsi URL o parole chiave
• Web Exception: corrispondenza basata su regex ed esclusione mirata dei controlli web, di scansione o dei certificati
• FQDN Host: oggetto di rete basato su DNS per regole firewall, NAT o di routing
• Threat Feed: elenchi di IOC o domini aggiornati dinamicamente

Configurare Web Protection con Web Policies spiega la logica completa delle policy. La scelta tra una categoria personalizzata e un elenco di domini è descritta in Usare le web categories e gli Instant Alerts. Per gli elenchi di sicurezza dinamici sono indicati i Threat Feeds di Sophos Firewall.

Dominio invece dell’URL completo

In Search/Add, SFOS richiede un nome di dominio valido. Protocollo, percorso e query non devono essere inseriti nel campo.

Valori di esempio validi:

updates.vendor.example
cdn.vendor.example

Valori non adatti:

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

L’estensione .example è riservata alla documentazione. Nella configurazione reale, gli esempi vengono sostituiti con i domini confermati nel log, nella richiesta o nella documentazione del produttore.

Se occorre un percorso URL specifico, un parametro di query o un’espressione regolare, a seconda dell’obiettivo è adatta una web category personalizzata o una Web Exception delimitata in sicurezza. L’elenco dei domini non viene ampliato con un pattern wildcard apparentemente pratico.

Pianificare l’ambito dei domini

L’esempio usa il gruppo Vendor update domains con due host distinti:

• updates.vendor.example per il download degli aggiornamenti
• cdn.vendor.example per il relativo endpoint dei contenuti

Il dominio radice vendor.example non viene volutamente utilizzato come scorciatoia. Sophos documenta espressamente che i sottodomini sono inclusi nella corrispondenza degli URL Groups nelle esclusioni TLS. In questo percorso, una voce vendor.example includerebbe quindi anche login.vendor.example, telemetry.vendor.example e altri sottodomini.

Anche una voce più ristretta può includere sottodomini. Nella corrispondenza TLS, updates.vendor.example può quindi intercettare anche api.updates.vendor.example. Se è previsto un solo host specifico, oltre alla destinazione positiva viene sempre testato come destinazione negativa un host volutamente simile.

Più voci nello stesso gruppo non costituiscono un elenco obbligatorio. A causa della logica OR, basta la corrispondenza di un dominio. Se un servizio funziona solo quando due host sono raggiungibili insieme, ogni host deve essere testato separatamente. L’URL Group non dimostra una dipendenza funzionale tra di essi.

Creare un URL Group

1. Aprire Web > URL groups.
2. Selezionare Add.
3. Impostare un nome come Vendor update domains.
4. Inserire updates.vendor.example in Search/Add.
5. Selezionare Add e controllare che il valore compaia nell’elenco.
6. Aggiungere cdn.vendor.example nello stesso modo.
7. Selezionare Save.
8. Riaprire il gruppo salvato e controllare il nome e i due domini.

La selezione di Add è un passaggio separato. Un nome di dominio presente solo nel campo di immissione non fa ancora parte del gruppo.

La guida attuale di SFOS 22 non indica un numero massimo fisso di domini per URL Group. Questo non garantisce un elenco illimitato. Se sono previste centinaia di voci, frequenti modifiche del produttore o IOC in continuo cambiamento, un URL Group gestito manualmente è in genere il modello operativo sbagliato.

Usare un URL Group in una Web Policy

Un URL Group acquisisce un effetto Allow, Warn, Block o Quota solo tramite una regola di Web Policy.

1. Aprire Web > Policies.
2. Modificare la policy interessata o crearne una nuova.
3. Selezionare Add rule.
4. In Users, impostare l’ambito previsto di utenti o gruppi.
5. In Activities, deselezionare la scelta generale All web traffic e selezionare l’URL Group Vendor update domains.
6. Impostare l’azione desiderata per HTTP e HTTPS, per esempio Allow o Block.
7. Controllare la posizione della regola, attivarne lo stato e salvare la policy.
8. In Rules and policies > Firewall rules, verificare che questa Web Policy sia selezionata in Web filtering nella regola firewall che corrisponde effettivamente.
9. Attivare Log firewall traffic per il collaudo.

Le regole di una Web Policy vengono valutate dall’alto verso il basso. Una regola Allow generale sopra la nuova regola dell’URL Group può nascondere la corrispondenza. Viceversa, una regola Allow specifica collocata troppo in alto può rendere inefficaci le regole Block successive. La posizione fa quindi parte della decisione di sicurezza e non è solo una questione di visualizzazione.

Un URL Group in una Web Policy non sostituisce una regola firewall. La regola firewall consente prima il flusso di dati tra le zone, poi la Web Policy associata valuta l’accesso web. Testare le regole con Log Viewer, Policy Tester e Packet Capture mostra quale regola e quale policy vengono effettivamente applicate.

Usare un URL Group come esclusione TLS

Per problemi confermati di Certificate Pinning o altri problemi di decrittografia, lo stesso tipo di oggetto può essere usato in una SSL/TLS inspection rule con Action: Don’t decrypt. SFOS confronta in modo efficiente il dominio come testo tramite Server Name Indication, o SNI.

Sono disponibili due varianti chiare.

Integrare la Local TLS exclusion list

La Local TLS exclusion list è un URL Group integrato e vuoto per impostazione predefinita. Appartiene alla regola di esclusione predefinita permanente in cima alla tabella delle regole SSL/TLS.

Il percorso manuale è:

Web > URL groups > Local TLS exclusion list

Questa variante è adatta a un’esclusione di dominio confermata localmente che deve essere applicata indipendentemente da una regola personalizzata più ristretta per sorgente o utente. I domini possono essere aggiunti a questo elenco anche tramite le funzioni di risoluzione dei problemi nel Control Center o nel Log Viewer. Ogni nuovo dominio viene quindi documentato e testato come eccezione di sicurezza in produzione.

La Managed TLS exclusion list svolge un’altra funzione. Sophos mantiene in questo elenco i domini noti come incompatibili e può aggiornarlo tramite gli aggiornamenti firmware. I domini operativi propri non sostituiscono una regola locale consapevole in questo oggetto gestito dal produttore.

Creare una regola Don’t decrypt personalizzata

Se l’esclusione deve essere limitata a sorgenti, utenti, servizi o zone di destinazione specifici, una regola personalizzata è più facile da verificare:

1. Aprire Rules and policies > SSL/TLS inspection rules.
2. Selezionare Add.
3. Impostare un nome come Vendor updates no decrypt.
4. Selezionare Action: Don’t decrypt.
5. Attivare Log connections.
6. Limitare Source zones, Source networks, Users, Destination zones e Services all’ambito necessario.
7. In Categories and websites, selezionare l’URL Group Vendor update domains.
8. Posizionare la regola direttamente sotto le esclusioni predefinite e sopra le regole Decrypt generali.
9. Salvare e testare con una nuova connessione.

Le SSL/TLS inspection rules funzionano indipendentemente dalle regole firewall. Una regola firewall che corrisponde correttamente non dimostra quindi che venga applicata la regola TLS desiderata. Viceversa, Don’t decrypt esclude solo la decrittografia da questo percorso. Non è un’autorizzazione generale per traffico di rete arbitrario.

Gli URL Groups sono più efficienti per questa corrispondenza SNI rispetto a molti FQDN Host Objects nella sorgente o nella destinazione di una regola TLS. Gli FQDN Host Objects eseguono una risoluzione DNS e svolgono una funzione diversa. Creare e usare in sicurezza gli FQDN Hosts spiega le differenze.

Se la connessione TLS non contiene un SNI utilizzabile, il dominio non può essere riconosciuto in questo modo. Il gruppo non viene quindi ampliato con un dominio radice. Prima si controllano l’IP di destinazione, il certificato, Packet Capture e il flusso effettivo dell’applicazione.

Verificare la corrispondenza con test positivi e negativi

Il caricamento riuscito di una pagina dimostra solo che il servizio è raggiungibile. Non dimostra né la regola di Web Policy corretta né l’esclusione TLS desiderata.

Test della Web Policy

1. Annotare il client pilota, l’utente, l’ora e l’azione prevista.
2. Chiudere completamente la sessione del browser o dell’applicazione e riavviarla.
3. Aprire updates.vendor.example oppure il dominio positivo reale.
4. Nel Log Viewer, controllare Source, User, Domain, Firewall Rule ID, Web Policy e Action.
5. Testare login.vendor.example oppure un host reale volutamente non aggiunto.
6. Confermare che l’host negativo continui a essere valutato dalla normale regola di policy successiva.
7. Se sono necessari due valori del gruppo, testare ogni host singolarmente.

Se il browser utilizza QUIC o HTTP/3, il percorso web TCP previsto può risultare diverso. Prima si distingue il test da QUIC e HTTP/3.

Test dell’esclusione TLS

1. Stabilire una nuova connessione TLS verso l’host positivo.
2. Nel log SSL/TLS, controllare la regola corrispondente e lo stato di mancata decrittografia.
3. Confrontare il certificato visibile al client con lo stato della normale regola di decrittografia.
4. Aprire un host negativo simile che non è nel gruppo.
5. Confermare che questo host continui a essere gestito dalla regola Decrypt prevista.
6. Documentare l’ambito sorgente, l’SNI e la posizione della regola.

Per un test di rollback consapevole, durante una finestra di manutenzione si ripristina lo stato precedente documentato della regola web o TLS che utilizza il gruppo. L’host positivo deve quindi mostrare nuovamente il comportamento precedente. Solo questa controprova trasforma un workaround funzionante in un collaudo riproducibile.

Delimitare sistematicamente gli errori

L’URL Group non viene applicato nella Web Policy

• Il dominio è stato inserito, ma non acquisito con Add.
• L’URL Group non è selezionato in Activities nella regola di policy attiva.
• All web traffic o un’altra regola precedente corrisponde per prima.
• La regola di policy è disattivata.
• La Web Policy non è selezionata nella regola firewall che corrisponde effettivamente.
• La richiesta reale usa un host di reindirizzamento, login, API o CDN non documentato.
• Una connessione del browser o QUIC esistente non è stata ricreata.

L’esclusione TLS non viene applicata

• L’URL Group non è selezionato in Categories and websites nella regola prevista.
• La regola Don't decrypt si trova sotto una regola Decrypt che corrisponde già.
• Source, User, Zone, Service o un altro criterio della regola non corrisponde.
• La connessione non invia un SNI utilizzabile.
• L’host TLS reale è diverso dall’URL visibile nel browser.
• La sessione TLS esistente è rimasta in uso dopo la modifica.

L’URL Group viene applicato troppo ampiamente

• È stato inserito un dominio radice invece degli host effettivamente necessari.
• Una voce include ulteriori sottodomini nella corrispondenza TLS.
• Il gruppo è utilizzato da più policy o regole TLS.
• Una regola Allow è collocata troppo in alto o si applica a troppi utenti.
• La Local TLS exclusion list ha un effetto più ampio rispetto a una regola personalizzata limitata per sorgente.

In questo caso non si aggiunge un altro dominio. Prima si controllano tutti gli utilizzi del gruppo, l’effettivo ordine delle regole e il test negativo.

Gestire in sicurezza modifiche e rollback

Prima di ogni modifica a un URL Group in produzione si registrano:

• l’elenco dei domini precedente
• le Web Policies e SSL/TLS inspection rules che fanno riferimento al gruppo
• il responsabile e la motivazione tecnica
• gli utenti, le sorgenti e i servizi interessati
• i casi di test positivi e negativi
• la data di revisione o scadenza

Un gruppo condiviso non viene ampliato in modo silenzioso per un singolo incidente. Se una web allowlist e un’esclusione TLS hanno responsabili o cicli di vita diversi, è più chiaro usare URL Groups separati, anche se alcuni domini sono identici.

Per il rollback, si ripristina prima lo stato della regola o della policy che utilizza il gruppo, oppure si rimuove solo il dominio appena aggiunto. L’intero gruppo viene eliminato solo quando nessun’altra policy o regola ne dipende. Successivamente si ricontrollano le nuove connessioni per gli host positivo e negativo e si esaminano di nuovo i log.

Checklist operativa

• URL Group confermato come strumento adatto.
• Aggiunti solo domini validi, senza protocolli, percorsi, wildcard o regex.
• Effetto del dominio radice e dei sottodomini limitato consapevolmente.
• Considerata la logica OR tra più domini.
• Documentati nome del gruppo, responsabile, scopo e data di revisione.
• Identificata chiaramente la Web Policy o SSL/TLS inspection rule utilizzatrice.
• Verificati stato, posizione, ambito sorgente e logging della regola.
• Web Policy selezionata nella regola firewall corretta.
• Per un’esclusione TLS, confermati SNI e regola Don't decrypt.
• Eseguiti test positivi e negativi con nuove connessioni.
• Salvati riferimenti e stato precedente per il rollback.

Domande frequenti