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.

SFOS 22 présente une limite IPv6 importante : les objets hôte FQDN ne résolvent aucune adresse IPv6. Cela n’empêche pas DNS Lookup ni les clients ordinaires de recevoir des réponses AAAA, mais l’objet lui-même ne maintient pas ces destinations IPv6. Prise en charge et limites d’IPv6 sur Sophos Firewall avec SFOS 22 distingue cette limite des autres fonctions prises en charge ou non.

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. Pour cela, il doit voir les réponses correspondantes ; pour le DNS en transit, learn-subdomains doit également être activé. Le trafic DNS visible ne garantit pas à lui seul un apprentissage réussi. Les méthodes d’apprentissage documentées sont les suivantes :

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 ?

Regrouper plusieurs hôtes FQDN

Un FQDN host group rassemble plusieurs hôtes FQDN existants dans un objet réutilisable. Ces groupes peuvent notamment être sélectionnés dans les règles de pare-feu et les SD-WAN policy routes.

Accédez à Hosts and services > FQDN host group > Add. Saisissez un libellé unique sous Name, sélectionnez les hôtes nécessaires, puis cliquez sur Save. Pour une application disposant de plusieurs points de terminaison, le groupe grp_vendor_service pourrait contenir login.vendor.example, api.vendor.example et updates.vendor.example. Un hôte peut appartenir à plusieurs groupes. N’ajoutez que les noms nécessaires, car tout hôte supplémentaire élargit chaque règle qui utilise le groupe.

Les listes FQDN host et FQDN host group permettent d’effectuer une recherche selon n’importe quel attribut affiché. Avant de modifier ou de supprimer un objet, vérifiez séparément quelles règles de pare-feu, SD-WAN policy routes ou autres configurations l’utilisent. La modification d’un groupe partagé affecte toutes ces utilisations.

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.

Cas particulier : groupes prédéfinis pour les règles Web Proxy

Les groupes prédéfinis SafeSearch enforcement, YouTube restrictions enforcement et Google app enforcement sont exclusivement destinés aux règles qui imposent SafeSearch, les restrictions YouTube ou les connexions Google Workspace via le Web Proxy. Ils ne remplacent pas une liste personnalisée de destinations SaaS générales.

Avant d’activer une telle règle, veillez à ce que les appareils du groupe pilote approuvent la CA, définissez les exclusions de déchiffrement appropriées et préparez des tests de validation HTTP et HTTPS précis. La procédure est décrite dans déployer progressivement l’inspection TLS sur Sophos Firewall.

Dans la règle de pare-feu dédiée, réglez Action sur Allow et Destination zones sur WAN. Sous Destination networks, sélectionnez les groupes prédéfinis nécessaires et, sous Services, HTTP et HTTPS. Activez aussi Scan HTTP and decrypted HTTPS, Block QUIC protocol, Use web proxy instead of DPI engine et Decrypt HTTPS during web proxy filtering. Placez la règle au-dessus de celles qui traitent le même trafic avec le moteur DPI.

Après le test, vérifiez dans le Log Viewer et dans un navigateur que seul le groupe pilote prévu utilise cette règle et que la restriction attendue fonctionne. Pour revenir en arrière, désactivez la nouvelle règle proxy et vérifiez que le trafic est de nouveau traité par la règle DPI placée en dessous. Ne supprimez la règle proxy qu’après cette confirmation.

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. Pour le trafic DNS qui ne fait que traverser le pare-feu, vérifiez également si learn-subdomains est activé. C’est une condition préalable supplémentaire, pas une garantie de réussite.

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 indique explicitement que les hôtes FQDN ne prennent pas en charge plusieurs domaines qui se résolvent vers la même adresse IP. Un objet FQDN utilise les adresses IP résolues et ne peut pas distinguer ces domaines au niveau IP. Il ne faut donc pas en attendre une séparation fiable des domaines.

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, l’absence de trafic au niveau du pare-feu ou une journalisation inactive sont des causes possibles, mais ce ne sont pas les seules. Vérifiez également le module sélectionné ainsi que les filtres de temps, de champs et de recherche. Les sessions des règles de pare-feu ne sont journalisées qu’à la fermeture de la connexion, lorsqu’un événement Destroy est reçu ; si la connexion se ferme sans cet événement, le journal de session peut manquer. Il faut donc également tenir compte d’une connexion encore ouverte. Utilisez un Packet Capture ciblé pour vérifier si les paquets de test atteignent le pare-feu ; un Log Viewer vide ne prouve pas à lui seul le contraire.

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é ?
Pour le DNS en transit, learn-subdomains est-il activé ? Des réponses DNS visibles ne garantissent pas à elles seules qu’une association a été apprise.
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.

Dans la Device Console, Sophos fournit la famille de commandes système set fqdn-host ; elle ne modifie pas uniquement un objet hôte sélectionné. cache-ttl utilise dns-reply-ttl par défaut ou peut être réglé de 60 à 86400 secondes. idle-timeout supprime les bindings inutilisés après un intervalle configurable de 60 à 86400 secondes ; sa valeur par défaut est de 3600 secondes. eviction détermine si et après quel intervalle les adresses IP apprises pour les sous-domaines wildcard sont supprimées ; cet intervalle va de 60 à 86400 secondes. learn-subdomains active ou désactive l’apprentissage de ces adresses dans le trafic de transit qui traverse le pare-feu sans provenir de celui-ci ni lui être destiné. 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.

Ne modifiez pas ces valeurs en première intention. Vérifiez d’abord la conception DNS, le chemin du résolveur et la base de règles. Avant toute modification, consignez toutes les valeurs actuelles, ne changez qu’un paramètre à la fois et testez son effet avec des entrées nouvellement résolues. Pour revenir en arrière, restaurez la valeur initiale consignée ; pour le TTL par défaut, il s’agit de dns-reply-ttl. Le réglage doit faire partie d’une procédure d’exploitation ou de support documentée.

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.

La documentation CLI indique jusqu’à 16 000 hôtes FQDN. Pour SFOS 22, Sophos documente toutefois une limite commune de 16 000 hôtes, tous types d’hôtes confondus ; il ne faut pas en déduire une capacité FQDN supplémentaire et indépendante ni une réserve disponible. Cette limite 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.