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 include i sottodomini nella corrispondenza delle esclusioni TLS. api.updates.vendor.example è un sottodominio di updates.vendor.example e costituisce quindi una corrispondenza attesa, non una destinazione negativa. Nell’esempio, login.vendor.example è adatto come destinazione negativa, purché né vendor.example né questo host siano presenti nel gruppo e nessun’altra eccezione lo includa. Sostituire le destinazioni con host di test reali e controllati. Se è consentito escludere esclusivamente un singolo host, una voce di dominio non può garantire questo requisito come corrispondenza esatta dell’host; prima dell’uso in produzione, valutare i sottodomini inclusi e chiarire l’ambito consentito.

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

Verificare prima licenze, utilizzi e modalità operativa

Secondo la guida SFOS 22, una Base License è sufficiente per applicare gli URL Groups come criteri in una SSL/TLS inspection rule. Le Web Categories nella stessa regola richiedono invece una licenza Web Protection. Prima dell’uso in una Web Policy, verificare inoltre in Administration > Licensing che Web Protection sia attivo.

La pagina Object usage documenta un contatore di utilizzo per oggetti di rete, routing, host e servizi, ma non per gli URL Groups. Prima di modificare un gruppo esistente, controllarne quindi i possibili utilizzatori direttamente in Web > Policies e Rules and policies > SSL/TLS inspection rules. Una sola modifica a un gruppo condiviso può infatti cambiare più decisioni di sicurezza.

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.

Aprire un gruppo esistente in Web > URL groups selezionando Edit per il gruppo interessato. Prima di salvare, documentare l’elenco dei domini precedente e tutti gli utilizzi noti. Quindi selezionare Save, riaprire il gruppo tramite Edit e verificare con nuove connessioni sia l’elenco salvato sia l’effetto sulle policy e sulle regole TLS interessate. In caso di effetti inattesi, ripristinare l’elenco dei domini precedente documentato; non eliminare semplicemente un gruppo condiviso.

Le pagine della guida sugli URL Groups e sulla loro creazione per SFOS 22 e 23 non indicano un numero massimo fisso di domini per gruppo. 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. Negli Advanced settings della Web Policy attivare Enable logging and reporting e nella regola firewall 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.

Questo percorso vale per la modalità DPI e per connessioni SSL/TLS rilevate su TCP; le SSL/TLS inspection rules non vengono applicate a UDP. In una regola personalizzata, in Source zones si possono scegliere solo zone interne. La regola firewall viene valutata prima e poi viene applicata la SSL/TLS inspection rule. Una regola firewall o Web Policy corrispondente non dimostra quindi una corrispondenza TLS.

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. Selezionare un Decryption profile adatto. Le restrizioni del profilo possono essere applicate anche con Don’t decrypt; il profilo non è quindi privo di effetto. Occorre tenere conto delle seguenti limitazioni di TLS 1.3.
7. Limitare Source zones, Source networks, Users, Destination zones e Services all’ambito necessario.
8. In Categories and websites, selezionare l’URL Group Vendor update domains.
9. Posizionare la regola direttamente sotto le esclusioni predefinite e sopra le regole Decrypt generali.
10. Salvare e testare con una nuova connessione.

Don’t decrypt non comporta gli stessi controlli sui certificati di Decrypt. Per TLS 1.3, il blocco degli errori dei certificati e l’applicazione della lunghezza minima della chiave RSA nel Decryption Profile richiedono l’azione Decrypt. Anche Downgrade to TLS 1.2 and decrypt si applica solo con questa azione. Con Don’t decrypt o Deny, Reject and notify viene applicato come Reject. Prima di configurare un’eccezione, verificare quindi la versione TLS negoziata, i controlli sui certificati necessari e il profilo. Durante la fase pilota, controllare nel log la regola, l’azione e la versione TLS effettive, nonché il certificato visibile al client. Se mancano controlli necessari, non approvare l’eccezione oppure ripristinare la regola precedente documentata.

Le SSL/TLS inspection rules usano criteri propri dopo la regola 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.

È necessaria cautela quando si combinano esclusioni per sorgente e destinazione: la descrizione della regola TLS indica una corrispondenza con tutti i criteri configurati; al tempo stesso, la guida alle esclusioni per siti web segnala che le esclusioni per sorgente e destinazione non possono essere combinate. L’ambito esatto di questa indicazione rimane poco chiaro. Questo esempio non garantisce quindi il funzionamento di ogni combinazione e non costituisce una guida per le connessioni in ingresso; utilizza zone interne in Source zones. Prima dell’approvazione per l’uso in produzione, verificare con nuove connessioni la sorgente consentita verso l’host escluso, la stessa sorgente verso un host non escluso e un’altra sorgente verso l’host escluso. Solo la combinazione prevista deve corrispondere alla regola Don’t decrypt personalizzata. Se l’effetto è diverso da quello previsto, ripristinare la regola precedente documentata e chiarire l’ambito, anziché ampliare l’esclusione.

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.

Usare Diagnostics > Tools > Policy tester per verificare innanzitutto quale azione di Web Policy è prevista per URL, utente e ora. Non sostituisce il test con un client reale e i log, ma distingue un errore di policy da una regola firewall associata in modo errato. Se il percorso dei dati non è chiaro, Diagnostics > Packet capture mostra tra l’altro Firewall Rule ID e Web Filter ID. Attivare la cattura solo per il client pilota e l’host di destinazione interessati, quindi disattivarla.

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.
• Verificati licenze, modalità DPI/TCP e Decryption profile.
• Eseguiti test positivi e negativi con nuove connessioni.
• Salvati riferimenti e stato precedente per il rollback.

Domande frequenti