Usare correttamente FQDN host e wildcard FQDN su Sophos Firewall

Gli host FQDN sono utili quando una destinazione non può essere descritta in modo affidabile con un indirizzo IP fisso. Esempi tipici sono i servizi cloud, i server di aggiornamento, gli endpoint di autenticazione o i servizi dei fornitori i cui indirizzi IP possono cambiare.

Un host FQDN non sostituisce una policy web, né il controllo completo degli URL, né una garanzia che ogni applicazione corrisponda in modo corretto. La questione importante è come Sophos Firewall risolve il nome o, nel caso dei caratteri jolly, lo apprende dal traffico DNS.

Quando gli host FQDN hanno senso

Gli host FQDN si adattano alle regole in cui una destinazione tecnica è meglio descritta da un nome DNS piuttosto che da singoli indirizzi IP. Ciò è particolarmente utile per il traffico in uscita.

Esempi utili:

Un server interno può connettersi solo a updates.vendor.example .
Un’applicazione deve accedere ad alcuni FQDN di fornitori noti.
È necessario utilizzare un endpoint cloud specifico in una regola firewall, una regola NAT, un percorso SD-WAN o una configurazione VPN.
Un caso di risoluzione dei problemi deve mostrare se una regola corrisponde al nome previsto o a un indirizzo IP imprevisto.

Gli host FQDN sono meno adatti per un ampio accesso al Web come “tutto in un unico servizio SaaS” quando l’applicazione utilizza molti domini, CDN, API, telemetria ed endpoint di accesso. Per il traffico web, le policy web, i gruppi URL, la protezione DNS, il controllo delle applicazioni o l’ispezione TLS rappresentano spesso il livello di controllo migliore.

Sophos Firewall può usare host FQDN non solo nelle regole firewall, ma anche in impostazioni come SD-WAN policy routes, VPN settings e oggetti tecnici per server mail, proxy, DNS, autenticazione, remote access, web o syslog. Tuttavia, per ogni utilizzo va verificato se un nome DNS è davvero più stabile di un oggetto IP o di un livello di policy dedicato.

Per la regola firewall stessa, iniziare con capire e configurare in modo sicuro le regole Sophos Firewall. Se una regola non corrisponde, utilizzare regola Sophos Firewall che non corrisponde: verificare le cause.

Host FQDN normale o FQDN con caratteri jolly

Sophos Firewall gestisce gli host FQDN normali e gli FQDN con caratteri jolly in modo diverso. Questo è il dettaglio operativo più importante.

Host FQDN normale

Per un normale host FQDN, come updates.vendor.example , il firewall risolve il nome tramite DNS. Gli indirizzi IP restituiti vengono utilizzati per l’oggetto. Se il record DNS ha un TTL, il firewall aggiorna la risoluzione dopo la scadenza del TTL.

Per SFOS 22 vale un importante limite IPv6: gli oggetti host FQDN non risolvono indirizzi IPv6. Ciò non impedisce a DNS Lookup o ai normali client di ricevere risposte AAAA, ma l’oggetto stesso non mantiene queste destinazioni IPv6. Supporto IPv6 e limiti in Sophos Firewall con SFOS 22 distingue questo limite dalle altre funzioni supportate e non supportate.

Funziona bene quando:

l’FQDN punta direttamente agli indirizzi IP richiesti,
l’applicazione utilizza esattamente quel nome,
le risposte DNS non cambiano costantemente tra molti target CDN,
il test utilizza la stessa risoluzione dei nomi rilevata dal firewall.

FQDN con caratteri jolly

Per un FQDN con caratteri jolly, come *.example.com , il firewall non risolve semplicemente “tutti i possibili sottodomini”. Il DNS non fornisce un elenco completo di tutti i sottodomini.

Invece, il firewall apprende gli indirizzi IP corrispondenti dalle risposte DNS. A questo scopo deve vedere le risposte corrispondenti; per il DNS in transito deve inoltre essere abilitato learn-subdomains. Il traffico DNS visibile da solo non garantisce che l’apprendimento riesca. I percorsi di apprendimento documentati sono:

Sophos Firewall è il server DNS per i client.
Oppure il traffico DNS passa attraverso il firewall e viene rilevato da DPI.
Secondo Sophos, questo apprendimento si applica al traffico DNS UDP sulla porta 53 verso server DNS esterni.

Se i client utilizzano DNS-over-HTTPS, DNS-over-TLS, un altro percorso DNS o un risolutore locale, il firewall potrebbe non vedere le risposte DNS pertinenti. Un FQDN con caratteri jolly può quindi rimanere vuoto o incompleto anche se il dominio funziona nel browser.

Crea un host FQDN

Il percorso del menu è:

Hosts and services > FQDN host > Add

Solo pochi campi contano per un oggetto pulito:

Name: descrittivo e tecnicamente stabile, ad esempio fqdn_vendor_updates o wfqdn_example_subdomains .
FQDN: il nome completo, ad esempio updates.vendor.example o *.example.com .
FQDN host group: opzionalmente selezionare un gruppo esistente o crearne uno nuovo. Un host FQDN può appartenere a più FQDN host groups.
Scrittura: scrive gli FQDN in minuscolo. Sophos afferma che le lettere maiuscole negli host FQDN non sono supportate.

Dopo aver inserito i campi, salvare l’oggetto con Save.

Dopo il salvataggio, non inserire immediatamente l’oggetto alla cieca nelle regole di produzione. Eseguire prima un breve test: il firewall risolve il nome, il visualizzatore log mostra successivamente l’IP di destinazione previsto e questo IP corrisponde alla risposta DNS del client?

Raggruppare più host FQDN

Un FQDN host group riunisce diversi host FQDN esistenti in un unico oggetto riutilizzabile. I gruppi possono essere selezionati, tra l’altro, nelle regole firewall e nelle SD-WAN policy routes.

Aprire Hosts and services > FQDN host group > Add. Inserire una denominazione univoca in Name, selezionare gli host necessari e fare clic su Save. Per un’applicazione con endpoint separati, il gruppo grp_vendor_service potrebbe contenere login.vendor.example, api.vendor.example e updates.vendor.example. Un host può appartenere a più gruppi. Includere solo i nomi necessari, perché ogni host aggiuntivo amplia tutte le regole che usano il gruppo.

Negli elenchi FQDN host e FQDN host group è possibile cercare in base a qualsiasi attributo visualizzato. Prima di modificare o eliminare un oggetto, verificare separatamente quali regole firewall, SD-WAN policy routes o altre configurazioni lo utilizzano. La modifica di un gruppo condiviso interessa tutti questi utilizzi.

Utilizzo nelle regole del firewall

Nella maggior parte dei progetti, un host FQDN appartiene alle regole in uscita in Destination networks . La regola descrive quindi quali origini interne possono connettersi a quale destinazione dinamica.

Flusso tipico:

Creare l’oggetto FQDN in Hosts and services > FQDN host .
Aprire o creare la regola di corrispondenza in Rules and policies > Firewall rules .
Definire Source zones e Source networks and devices in modo restrittivo.
Scegli deliberatamente Destination zones, solitamente WAN .
Selezionare l’oggetto FQDN in Destination networks .
Consentire solo le porte richieste in Services , ad esempio HTTPS .
Abilita la registrazione.
Eseguire un test reale e controllare Rule ID, IP di destinazione, Rule ID NAT e servizio in Log Viewer.

Un host FQDN non rende sicura una regola da solo. Se Source è Any , Service è Any e Destination è un oggetto jolly ampio, il risultato può diventare rapidamente molto aperto. È meglio una piccola regola con fonte chiara, servizio chiaro, registrazione attiva e scopo documentato.

Caso speciale: gruppi preconfigurati per le regole Web Proxy

I gruppi preconfigurati SafeSearch enforcement, YouTube restrictions enforcement e Google app enforcement sono destinati esclusivamente alle regole che applicano SafeSearch, le restrizioni di YouTube o gli accessi a Google Workspace tramite Web Proxy. Non sostituiscono un elenco personalizzato di destinazioni SaaS generiche.

Prima di attivare una regola di questo tipo, assicurarsi che i dispositivi del gruppo pilota considerino attendibile la CA, definire le opportune esclusioni dalla decifratura e preparare test di accettazione specifici per HTTP e HTTPS. La procedura è descritta in introdurre gradualmente la TLS Inspection su Sophos Firewall.

Nella regola firewall dedicata, impostare Action su Allow e Destination zones su WAN. Selezionare i gruppi preconfigurati necessari in Destination networks e HTTP e HTTPS in Services. Attivare inoltre Scan HTTP and decrypted HTTPS, Block QUIC protocol, Use web proxy instead of DPI engine e Decrypt HTTPS during web proxy filtering. Posizionare la regola sopra quelle che elaborano lo stesso traffico con il motore DPI.

Dopo il test, usare il Log Viewer e un browser per confermare che solo il gruppo pilota previsto utilizzi questa regola e che la restrizione desiderata funzioni. Per il rollback, disattivare la nuova regola proxy e verificare che il traffico venga nuovamente elaborato dalla regola DPI sottostante. Eliminare la regola proxy solo dopo questa conferma.

Limiti e insidie

Molti problemi FQDN non derivano dall’elenco delle regole, ma dal comportamento DNS dei client o delle applicazioni.

Il firewall vede diverse risposte DNS

Se client e firewall utilizzano risolutori DNS diversi, possono ricevere indirizzi IP diversi per lo stesso nome. Questo è normale con i CDN. Una regola può quindi corrispondere a un IP mentre il client ne utilizza un altro.

Durante la risoluzione dei problemi, confrontare:

Quale IP restituisce nslookup o dig sul client?
Quale IP di destinazione appare nel Log Viewer?
Quali server DNS utilizzano il client e il firewall?
Il DNS utilizza la porta 53, DNS-over-HTTPS o DNS-over-TLS?

L’FQDN con caratteri jolly non apprende nulla

Un FQDN con caratteri jolly funziona solo se il firewall vede le risposte DNS corrispondenti. Se un client utilizza DoH nel browser o un percorso DNS che non passa attraverso il firewall, il firewall non può apprendere i sottodomini. Per il traffico DNS che si limita ad attraversare il firewall, verificare inoltre se learn-subdomains è abilitato. È un ulteriore requisito, non una garanzia di successo.

In questi casi, lo spostamento della regola del firewall non è la soluzione. Decidi invece la struttura del DNS: utilizza il firewall come forwarder DNS, instrada il traffico DNS attraverso il firewall in modo controllato o utilizza un altro livello di controllo per il traffico web.

L’FQDN è troppo ampio

Un carattere jolly come *.example.com può includere molto più del previsto. I moderni servizi SaaS utilizzano domini di accesso, domini API, CDN multimediali, telemetria, servizi di supporto e terze parti. A volte un singolo oggetto jolly è troppo grossolano.

Se l’accesso deve essere ampio in base alla progettazione, una policy Web, un gruppo URL o un controllo delle applicazioni è spesso più facile da comprendere e rivedere rispetto a una regola firewall FQDN molto grande.

Più domini puntano allo stesso IP

Sophos documenta esplicitamente che gli host FQDN non supportano più domini che si risolvono nello stesso indirizzo IP. Un oggetto FQDN utilizza gli indirizzi IP risolti e non può distinguere tali domini a livello IP. Non ci si deve quindi aspettare una separazione affidabile dei domini tramite questo oggetto.

Per le decisioni web basate sul dominio il livello web è quindi più adatto di una pura regola firewall basata su IP con un oggetto FQDN.

Risoluzione dei problemi

Se una regola FQDN non si comporta come previsto, controlla innanzitutto la connessione reale. Il nome nell’oggetto non è determinante; l’indirizzo IP utilizzato al momento del test è.

La regola non corrisponde

Controllo:

La zona di origine corrisponde?
L’IP di origine o la rete di origine corrispondono?
Il servizio corrisponde, ad esempio, a TCP 443 anziché solo a HTTP ?
Il Log Viewer mostra un altro Rule ID?
Il Log Viewer mostra un IP di destinazione che non corrisponde alla risposta DNS corrente?
È attiva una regola più generale al di sopra della regola FQDN?

Se il Log Viewer mostra un’altra regola, l’ordine delle regole è più importante dell’oggetto FQDN. Se il Log Viewer non mostra nulla, l’assenza di traffico sul firewall o la registrazione non attiva sono possibili cause, ma non le uniche. Verificare anche il modulo selezionato e i filtri di tempo, campo e ricerca. Le sessioni delle regole firewall vengono registrate solo alla chiusura della connessione, quando viene ricevuto un evento Destroy; se la connessione si chiude senza questo evento, il log della sessione può mancare. Occorre quindi considerare anche la possibilità che la connessione sia ancora aperta. Verificare con un Packet Capture mirato se i pacchetti di test raggiungono il firewall; un Log Viewer vuoto da solo non dimostra il contrario.

L’FQDN con caratteri jolly rimane vuoto

Controllo:

Il client utilizza il firewall come server DNS?
Il DNS è visibile attraverso il firewall?
Il cliente utilizza DoH o DoT?
Viene utilizzato UDP 53?
Per il DNS in transito è abilitato learn-subdomains? Le risposte DNS visibili da sole non garantiscono che venga appreso un binding.
Esiste un percorso di richiesta DNS o un risolutore interno che nasconde la risposta prima che il firewall la veda?

Se il DNS viene instradato intenzionalmente internamente, configurare DNS request routes su Sophos Firewall aiuta con la progettazione del DNS.

DNS cambiato, la regola reagisce più tardi

Gli oggetti FQDN funzionano con le risposte e le cache DNS. Se la destinazione di un fornitore cambia, può verificarsi un ritardo finché il firewall non utilizza il nuovo stato. Per i normali host FQDN è determinante il TTL del record DNS.

Nella Device Console, Sophos mette a disposizione la famiglia di comandi di sistema set fqdn-host, che non modifica soltanto un singolo oggetto host selezionato. cache-ttl usa per impostazione predefinita dns-reply-ttl oppure può essere impostato da 60 a 86400 secondi. idle-timeout rimuove i binding inutilizzati dopo 60–86400 secondi; il valore predefinito è 3600 secondi. eviction controlla se e dopo quale intervallo vengono rimossi gli indirizzi IP appresi per i sottodomini wildcard; l’intervallo va da 60 a 86400 secondi. learn-subdomains attiva o disattiva l’apprendimento di questi indirizzi dal traffico di transito che attraversa il firewall senza avere origine o destinazione nel firewall stesso. Se si modifica cache-ttl, il nuovo valore si applica solo alle voci risolte successivamente; quelle già nella cache mantengono il valore precedente fino alla scadenza.

Non modificare questi valori come prima misura. Verificare innanzitutto che il design DNS, il percorso del resolver e la base delle regole siano corretti. Prima di una modifica, annotare tutti i valori correnti, cambiare un solo parametro alla volta e verificarne l’effetto con nuove risoluzioni. Per il rollback ripristinare il valore iniziale annotato; per il TTL predefinito è dns-reply-ttl. Il tuning deve rientrare in una procedura operativa o di supporto documentata.

Raccomandazione operativa

Gli host FQDN rimangono gestibili quando vengono trattati come dipendenze tecniche e non come eccezioni spontanee.

Buona pratica:

Documentare uno scopo chiaro per ciascun oggetto FQDN.
Usa i caratteri jolly con parsimonia.
Combina oggetti FQDN con definizioni di origine e servizio ristrette.
Abilita la registrazione di regole nuove o critiche.
Testare le modifiche con Log Viewer e ricerca DNS.
Non nascondere un ampio accesso al Web in una regola FQDN di grandi dimensioni.
Per i servizi SaaS o cloud, controlla regolarmente se il fornitore richiede domini aggiuntivi.

La documentazione CLI indica fino a 16.000 host FQDN. Per SFOS 22, tuttavia, Sophos documenta un limite massimo condiviso di 16.000 host complessivi tra tutti i tipi di host; da questo non si può dedurre una capacità FQDN aggiuntiva e indipendente né una riserva libera. Questo limite massimo non è un invito alla crescita incontrollata. Molte vecchie eccezioni FQDN rendono più difficili review, troubleshooting e manutenzione delle regole. È preferibile una lista di oggetti più piccola e documentata con owner, scopo e data di revisione.

Se un oggetto è stato creato solo perché “altrimenti un’applicazione non funziona”, rivederlo in seguito. Questi oggetti di emergenza spesso diventano eccezioni permanenti difficili da spiegare.

Domande frequenti

Qual è la differenza tra un host FQDN e un host IP?

Un host IP descrive un indirizzo o una rete fissa. Un host FQDN descrive un nome DNS i cui indirizzi IP correnti possono essere utilizzati dal firewall. Ciò è utile con le destinazioni dinamiche, ma dipende dalla risoluzione DNS e dal comportamento della cache.

`*.example.com` funziona automaticamente per tutti i sottodomini?

Non come un elenco completo di domini. Il firewall deve vedere le risposte DNS corrispondenti e apprenderne gli indirizzi IP. Se il DNS non è visibile attraverso il firewall, un FQDN con caratteri jolly può rimanere incompleto.

Perché la mia regola FQDN non corrisponde?

Di solito il contesto della regola, l’ordine o l’IP di destinazione effettivamente utilizzato non corrispondono. Nel Log Viewer, controllare quali Rule ID, IP di destinazione, porta di destinazione e Rule ID NAT compaiono durante il test reale.

Gli host FQDN funzionano con DNS-over-HTTPS o DNS-over-TLS?

Gli FQDN con caratteri jolly sono problematici quando i client utilizzano DoH o DoT e il firewall non riesce a visualizzare le risposte DNS. Il firewall quindi non può apprendere in modo affidabile i sottodomini richiesti.

È opportuno utilizzare gli host FQDN per il filtraggio Web?

Solo selettivamente. Per un vero controllo web, le policy web, i gruppi URL, la protezione DNS, il controllo delle applicazioni o l’ispezione TLS sono generalmente più adatti. Gli host FQDN sono utili per le destinazioni tecniche nelle regole di rete, ma non costituiscono una policy URL completa.