Utiliser correctement les FQDN hosts et wildcard FQDNs sur Sophos Firewall

Les hôtes FQDN sont utiles lorsqu’une destination ne peut pas être décrite de manière fiable avec une adresse IP fixe. Des exemples typiques sont les services cloud, les serveurs de mise à jour, les points de terminaison d’authentification ou les services de fournisseurs dont les adresses IP peuvent changer.

Un hôte FQDN ne remplace pas une politique Web, ni un contrôle complet des URL et ne garantit pas que chaque application correspondra correctement. La question importante est de savoir comment Sophos Firewall résout le nom ou, pour les caractères génériques, l’apprend à partir du trafic DNS.

Quand les hôtes FQDN ont du sens

Les hôtes FQDN correspondent à des règles selon lesquelles une destination technique est mieux décrite par un nom DNS que par des adresses IP individuelles. Ceci est particulièrement utile pour le trafic sortant.

Exemples utiles :

Un serveur interne ne peut se connecter qu’à updates.vendor.example .
Une application doit accéder à quelques FQDN de fournisseurs connus.
Un point de terminaison cloud spécifique doit être utilisé dans une règle de pare-feu, une règle NAT, une route SD-WAN ou une configuration VPN.
Un cas de dépannage doit montrer si une règle correspond au nom attendu ou à une adresse IP inattendue.

Les hôtes FQDN sont moins adaptés à un accès Web étendu tel que « tout sous un seul service SaaS » lorsque l’application utilise de nombreux domaines, CDN, API, télémétrie et points de terminaison de connexion. Pour le trafic Web, les politiques Web, les groupes d’URL, la protection DNS, le contrôle des applications ou l’inspection TLS constituent souvent la meilleure couche de contrôle.

Sophos Firewall peut utiliser des hôtes FQDN non seulement dans les règles de pare-feu, mais aussi dans des paramètres comme les SD-WAN policy routes, les VPN settings et les objets techniques pour serveurs mail, proxy, DNS, authentification, remote access, web ou syslog. Il faut tout de même vérifier pour chaque cas si un nom DNS est réellement plus stable qu’un objet IP ou qu’une couche de politique dédiée.

Pour la règle de pare-feu elle-même, commencez par comprendre et configurer les règles Sophos Firewall de manière sûre. Si une règle ne correspond pas, utilisez règle Sophos Firewall qui ne correspond pas: vérifier les causes.

Hôte FQDN normal ou FQDN générique

Sophos Firewall gère différemment les hôtes FQDN normaux et les FQDN génériques. C’est le détail opérationnel le plus important.

Hôte FQDN normal

Pour un hôte FQDN normal, tel que updates.vendor.example , le pare-feu résout le nom via DNS. Les adresses IP renvoyées sont utilisées pour l’objet. Si l’enregistrement DNS a une durée de vie, le pare-feu actualise la résolution après l’expiration de cette durée de vie.

Cela fonctionne bien lorsque :

le FQDN pointe directement vers les adresses IP requises,
l’application utilise exactement ce nom,
les réponses DNS ne basculent pas constamment entre de nombreuses cibles CDN,
le test utilise la même résolution de nom que celle vue par le pare-feu.

Nom de domaine complet générique

Pour un FQDN générique, tel que *.example.com , le pare-feu ne résout pas simplement « tous les sous-domaines possibles ». DNS ne fournit pas une liste complète de tous les sous-domaines.

Au lieu de cela, le pare-feu apprend les adresses IP correspondantes à partir des réponses DNS. Cela fonctionne de manière fiable lorsque le pare-feu peut voir le trafic DNS :

Sophos Firewall est le serveur DNS des clients.
Ou bien le trafic DNS traverse le pare-feu et est détecté par DPI.
Selon Sophos, cet apprentissage s’applique au trafic DNS UDP sur le port 53 vers les serveurs DNS externes.

Si les clients utilisent DNS sur HTTPS, DNS sur TLS, un autre chemin DNS ou un résolveur local, le pare-feu peut ne pas voir les réponses DNS pertinentes. Un FQDN générique peut alors rester vide ou incomplet même si le domaine fonctionne dans le navigateur.

Créer un hôte FQDN

Le chemin du menu est :

Hosts and services > FQDN host > Add

Seuls quelques champs comptent pour un objet propre :

Name: descriptif et techniquement stable, par exemple fqdn_vendor_updates ou wfqdn_example_subdomains .
FQDN: le nom complet, par exemple updates.vendor.example ou *.example.com .
FQDN host group: sélectionner éventuellement un groupe existant ou créer un nouveau groupe. Un hôte FQDN peut appartenir à plusieurs FQDN host groups.
Écriture: écrit les noms de domaine complets en minuscules. Sophos indique que les lettres majuscules dans les hôtes FQDN ne sont pas prises en charge.

Après avoir renseigné les champs, enregistrer l’objet avec Save.

Après la sauvegarde, ne placez pas immédiatement l’objet aveuglément dans les règles de production. Exécutez d’abord un court test : le pare-feu résout-il le nom, le Log Viewer affiche-t-il ultérieurement l’adresse IP de destination attendue et cette adresse IP correspond-elle à la réponse DNS du client ?

Utilisation dans les règles de pare-feu

Dans la plupart des conceptions, un hôte FQDN appartient aux règles sortantes sous Destination networks . La règle décrit ensuite quelles sources internes peuvent se connecter à quelle destination dynamique.

Flux typique :

Créez l’objet FQDN sous Hosts and services > FQDN host .
Ouvrez ou créez la règle de correspondance sous Rules and policies > Firewall rules .
Définissez Source zones et Source networks and devices de manière étroite.
Choisissez Destination zones délibérément, généralement WAN .
Sélectionnez l’objet FQDN sous Destination networks .
Autorisez uniquement les ports requis sous Services , par exemple HTTPS .
Activer la journalisation.
Exécutez un test réel et vérifiez l’ID de règle, l’adresse IP de destination, l’ID de règle NAT et le service dans le Log Viewer.

Un hôte FQDN ne sécurise pas à lui seul une règle. Si Source est Any , Service est Any et Destination est un objet générique large, le résultat peut rapidement devenir très ouvert. Une petite règle avec une source claire, un service clair, une journalisation active et un objectif documenté est préférable.

Limites et pièges

De nombreux problèmes de FQDN ne proviennent pas de la liste de règles, mais du comportement DNS des clients ou des applications.

Le pare-feu voit différentes réponses DNS

Si le client et le pare-feu utilisent des résolveurs DNS différents, ils peuvent recevoir des adresses IP différentes pour le même nom. C’est normal avec les CDN. Une règle peut alors correspondre à une adresse IP tandis que le client en utilise une autre.

Lors du dépannage, comparez :

Quelle adresse IP nslookup ou dig renvoie-t-elle au client ?
Quelle adresse IP de destination apparaît dans le Log Viewer ?
Quels serveurs DNS le client et le pare-feu utilisent-ils ?
Le DNS utilise-t-il le port 53 , DNS-over-HTTPS ou DNS-over-TLS ?

Le FQDN générique n’apprend rien

Un FQDN générique ne fonctionne que si le pare-feu voit les réponses DNS correspondantes. Si un client utilise DoH dans le navigateur ou un chemin DNS qui ne traverse pas le pare-feu, le pare-feu ne peut pas apprendre les sous-domaines.

Dans ces cas-là, déplacer la règle de pare-feu n’est pas la solution. Décidez plutôt de la conception DNS : utilisez le pare-feu comme redirecteur DNS, acheminez le trafic DNS à travers le pare-feu de manière contrôlée ou utilisez une autre couche de contrôle pour le trafic Web.

Le FQDN est trop large

Un caractère générique tel que *.example.com peut inclure bien plus que prévu. Les services SaaS modernes utilisent des domaines de connexion, des domaines API, des CDN multimédia, la télémétrie, des services d’assistance et des tiers. Parfois, un seul objet générique est trop grossier.

Si l’accès doit être large de par sa conception, une politique Web, un groupe d’URL ou un contrôle des applications est souvent plus facile à comprendre et à examiner qu’une très grande règle de pare-feu FQDN.

Plusieurs domaines pointent vers la même IP

Sophos souligne que les hôtes FQDN ne sont pas destinés à distinguer clairement plusieurs domaines lorsqu’ils correspondent à la même adresse IP. Sur la couche IP, le pare-feu ne peut pas toujours savoir quel domaine une application utilise ultérieurement.

Pour les décisions Web basées sur un domaine, la couche Web est donc plus adaptée qu’une règle de pare-feu purement basée sur IP avec un objet FQDN.

Dépannage

Si une règle FQDN ne se comporte pas comme prévu, vérifiez d’abord la connexion réelle. Le nom dans l’objet n’est pas déterminant ; l’adresse IP utilisée au moment du test est.

La règle ne correspond pas

Vérifier:

La zone source correspond-elle ?
L’adresse IP source ou le réseau source correspondent-ils ?
Le service correspond-il, par exemple TCP 443 au lieu de seulement HTTP ?
Le Log Viewer affiche-t-il un autre ID de règle ?
Le Log Viewer affiche-t-il une adresse IP de destination qui ne correspond pas à la réponse DNS actuelle ?
Une règle plus générale est-elle active au-dessus de la règle FQDN ?

Si le Log Viewer affiche une autre règle, l’ordre des règles est plus important que l’objet FQDN. Si le Log Viewer n’affiche rien, le trafic n’atteint pas le pare-feu ou la journalisation n’est pas active.

Le FQDN générique reste vide

Vérifier:

Le client utilise-t-il le pare-feu comme serveur DNS ?
Le DNS est-il visible à travers le pare-feu ?
Le client utilise-t-il DoH ou DoT ?
UDP 53 est-il utilisé ?
Existe-t-il une route de requête DNS ou un résolveur interne masquant la réponse avant que le pare-feu ne la voie ?

Si le DNS est intentionnellement acheminé en interne, configurer les DNS request routes sur Sophos Firewall aide à la conception du DNS.

DNS modifié, la règle réagit plus tard

Les objets FQDN fonctionnent avec les réponses DNS et les caches. Si la destination d’un fournisseur change, il peut y avoir un délai jusqu’à ce que le pare-feu utilise le nouvel état. Pour les hôtes FQDN normaux, la durée de vie de l’enregistrement DNS est déterminante.

Sophos propose des options CLI pour les hôtes FQDN, notamment cache-ttl, idle-timeout, eviction et learn-subdomains. cache-ttl peut utiliser le TTL de la réponse DNS ou une valeur entre 60 et 86400 secondes. idle-timeout supprime par défaut les bindings inutilisés après 3600 secondes. eviction contrôle quand les adresses IP apprises à partir de sous-domaines wildcard sont supprimées. Si cache-ttl est modifié, la nouvelle valeur ne s’applique qu’aux nouvelles résolutions ; les entrées déjà en cache conservent leur valeur précédente jusqu’à expiration.

Ces valeurs ne doivent pas être modifiées comme première réaction. Il faut d’abord vérifier si la conception DNS, le chemin du résolveur et la base de règles sont corrects. Le réglage fait partie d’une procédure documentée d’exploitation ou de support.

Recommandation opérationnelle

Les hôtes FQDN restent gérables lorsqu’ils sont traités comme des dépendances techniques et non comme des exceptions spontanées.

Bonne pratique :

Documentez un objectif clair pour chaque objet FQDN.
Utilisez les caractères génériques avec parcimonie.
Combinez des objets FQDN avec des définitions étroites de source et de service.
Activez la journalisation des règles nouvelles ou critiques.
Testez les modifications avec Log Viewer et la recherche DNS.
Ne cachez pas l’accès large au Web dans une règle FQDN volumineuse.
Pour les services SaaS ou cloud, vérifiez régulièrement si le fournisseur nécessite des domaines supplémentaires.

Sophos indique une limite allant jusqu’à 16 000 hôtes FQDN, mais ce n’est pas une invitation à une croissance incontrôlée. De nombreuses anciennes exceptions FQDN compliquent les revues, le troubleshooting et la maintenance des règles. Une liste d’objets plus petite et documentée avec propriétaire, objectif et date de revue est préférable.

Si un objet a été créé uniquement parce que « une application ne fonctionne pas autrement », examinez-le ultérieurement. Ces objets d’urgence deviennent souvent des exceptions permanentes et difficiles à expliquer.

FAQ

Quelle est la différence entre un hôte FQDN et un hôte IP ?

Un hôte IP décrit une adresse ou un réseau fixe. Un hôte FQDN décrit un nom DNS dont les adresses IP actuelles sont utilisées par le pare-feu. Cela facilite les destinations dynamiques, mais dépend de la résolution DNS et du comportement du cache.

`*.example.com` fonctionne-t-il automatiquement pour tous les sous-domaines ?

Pas comme une liste complète de domaines. Le pare-feu doit voir les réponses DNS correspondantes et en tirer des adresses IP. Si le DNS n’est pas visible via le pare-feu, un FQDN générique peut rester incomplet.

Pourquoi ma règle FQDN ne correspond-elle pas ?

Habituellement, le contexte de la règle, l’ordre ou l’adresse IP de destination réellement utilisée ne correspondent pas. Dans le Log Viewer, vérifiez quel ID de règle, IP de destination, port de destination et ID de règle NAT apparaissent pendant le test réel.

Les hôtes FQDN fonctionnent-ils avec DNS-over-HTTPS ou DNS-over-TLS ?

Les FQDN génériques sont problématiques lorsque les clients utilisent DoH ou DoT et que le pare-feu ne peut pas voir les réponses DNS. Le pare-feu ne peut alors pas apprendre de manière fiable les sous-domaines requis.

Les hôtes FQDN doivent-ils être utilisés pour le filtrage Web ?

Seulement de manière sélective. Pour un véritable contrôle Web, les politiques Web, les groupes d’URL, la protection DNS, le contrôle des applications ou l’inspection TLS sont généralement plus adaptés. Les hôtes FQDN sont utiles pour les destinations techniques dans les règles réseau, mais ils ne constituent pas une stratégie d’URL complète.