Qu'est-ce qu'un « sinkhole DNS » et comment fonctionne-t-il ?

Toute connexion réseau moderne commence par une recherche. Chaque fois qu'un appareil ouvre une page Web, télécharge une mise à jour ou contacte un serveur externe, il demande à un résolveur de traduire un nom de domaine lisible par l'utilisateur en une adresse IP. Comme cette recherche a lieu avant que les paquets de données ne soient échangés entre les hôtes, elle constitue l'un des points de contrôle les plus efficaces dans la défense du réseau.

Les acteurs malveillants exploitent constamment cette étape. Certaines variantes de logiciels malveillants interrogent des hôtes distants pour recevoir des commandes ou exfiltrer des données, tandis que les leurres de hameçonnage incitent les utilisateurs à accéder à des portails Web frauduleux. La compréhension de la grande diversité des types d’attaques DNS souligne pourquoi il est essentiel de contrôler le comportement des requêtes. Le « sinkholing » DNS offre aux équipes de sécurité un mécanisme actif permettant d’intercepter ces requêtes à un stade précoce, mettant ainsi fin aux communications malveillantes avant qu’une machine infectée ne puisse établir une connexion.

Qu'est-ce qu'un « sinkhole » DNS ?

Un « sinkhole DNS » est un mécanisme de sécurité qui intercepte les requêtes DNS destinées à des domaines malveillants connus et renvoie une fausse adresse IP contrôlée à la place de la destination légitime. Cette redirection empêche les appareils clients d'accéder à l'infrastructure malveillante, neutralisant ainsi efficacement les rappels de logiciels malveillants, les campagnes de hameçonnage et les canaux de commande des botnets dès la phase de résolution.

Dans le cadre d'un fonctionnement réseau standard, un résolveur récursif interroge les serveurs de noms faisant autorité et fournit au client l'adresse externe réelle du nom d'hôte demandé. Dans une configuration de type « sinkhole », le résolveur vérifie si le domaine demandé figure sur une liste noire préétablie. Si le domaine demandé apparaît sur cette liste, le résolveur ne renvoie pas la réponse réelle. À la place, il fournit une adresse alternative désignée par l'administrateur réseau, telle qu'une adresse de bouclage ou un serveur de journalisation interne spécialisé.

En remplaçant l'adresse IP de destination, le résolveur garantit que le client n'initie jamais de phase d'établissement de connexion TCP avec la machine de l'attaquant. La connexion prend fin sans conséquence au sein de l'environnement local.

Fonctionnement du « sinkholing » DNS

Pour comprendre le fonctionnement d'un « sinkhole » DNS, il faut d'abord examiner le rôle du résolveur récursif dans le trafic quotidien d'une entreprise. Lorsqu'un poste de travail interne envoie une requête, celle-ci est acheminée directement vers un résolveur local. Vous pouvez consulter notre analyse sur ce qu’est un serveur DNS pour comprendre comment fonctionnent les recherches récursives standard sur les réseaux distribués.

Le « sinkholing » DNS introduit trois composantes opérationnelles essentielles dans ce cycle de recherche :

1. Flux d'informations sur les menaces et listes noires de domaines

Un « sinkhole » repose sur des données de menaces précises et actualisées. Les équipes de sécurité alimentent les résolveurs avec des listes de domaines malveillants connus, issues de flux de menaces open source, de fournisseurs commerciaux de renseignements sur les menaces, de données télémétriques relatives à la réponse aux incidents et de groupes de partage d'informations au sein du secteur. Ces listes contiennent des URL de hameçonnage actives, des nœuds de distribution de ransomware et des domaines de commande et de contrôle (C2) connus.

2. La substitution de la politique de résolution

Lorsqu'un terminal envoie une requête de recherche, le résolveur évalue le domaine demandé à l'aune des règles de sa zone de politique avant d'appliquer les indications de racine Internet standard ou de transférer les requêtes en amont. Si le domaine correspond à une entrée de la liste noire, le résolveur interrompt le processus de résolution sortant. Les résolveurs modernes y parviennent grâce aux zones de politique de réponse (RPZ), une technologie qui permet aux administrateurs de réécrire dynamiquement les réponses DNS en fonction de politiques personnalisées.

3. La destination « Sinkhole »

Une fois que le résolveur déclenche une redirection, il renvoie une adresse prédéfinie. En fonction des objectifs de l'équipe de sécurité, cette adresse peut prendre l'une des deux configurations suivantes :

• Adresse nulle non routable: Le résolveur renvoie une adresse IP telle que 0.0.0.0 ou 127.0.0.1. Le périphérique client tente de se connecter à lui-même ou rejette immédiatement le paquet, mettant ainsi fin à la session avec une surcharge minimale en ressources.
• Serveur de journalisation contrôlé (collecteur « sinkhole ») : Le résolveur redirige l'appareil vers un serveur interne isolé hébergeant un écouteur HTTP ou un enregistreur de paquets léger. Lorsque l'hôte infecté se connecte, le serveur « sinkhole » capture les en-têtes HTTP entrants, les chaînes d'agent utilisateur, les adresses IP internes et les horodatages.

Cette fonctionnalité de journalisation transforme le « sinkhole » d’un simple outil de blocage passif en un capteur actif de détection des menaces. Alors qu’un journal de pare-feu peut se contenter d’indiquer une requête sortante vers une adresse IP externe, le collecteur « sinkhole » identifie précisément le poste de travail interne à l’origine de la requête malveillante, ce qui permet aux équipes d’intervention en cas d’incident d’isoler immédiatement le périphérique compromis.

Types de « sinkholes » DNS

Les « sinkholes » DNS sont déployés à différents niveaux de l'écosystème Internet et remplissent des fonctions opérationnelles distinctes selon l'entité qui les gère.

Gouffres internes à l'entreprise

Les entreprises déploient des « sinkholes » internes sur leurs résolveurs DNS locaux, leurs pare-feu de nouvelle génération (NGFW) ou leurs passerelles Web sécurisées. L’objectif principal est de protéger les terminaux de l’entreprise et de surveiller l’intégrité du réseau interne. Lorsqu’un collaborateur clique sur un lien de hameçonnage ou qu’un logiciel malveillant en arrière-plan tente d’accéder à un serveur C2, le « sinkhole » de l’entreprise bloque la connexion sortante et alerte le centre des opérations de sécurité (SOC) en lui communiquant l’adresse IP interne de l’appareil.

FAI et résolveurs DNS publics de protection

Les fournisseurs d’accès à Internet et les opérateurs de DNS publics (tels que Quad9 ou le service 1.1.1.2 de Cloudflare) mettent en place des « sinkholes » afin de protéger un large public de particuliers et d’entreprises. Plutôt que d’exploiter des collecteurs de journaux à des fins d’analyse approfondie des hôtes, ces fournisseurs privilégient la couverture à grande échelle. Ils redirigent les requêtes vers des domaines dangereux vers des routes nulles ou des pages d’avertissement hébergées, empêchant ainsi des volumes massifs de trafic malveillant d’atteindre leurs abonnés.

Recherche et lutte contre la cybercriminalité (démantèlement de botnets)

Lors d’opérations de lutte contre la cybercriminalité à grande échelle, les autorités judiciaires et les chercheurs en sécurité mettent en place des « sinkholes » au niveau des bureaux d’enregistrement ou des registres. Grâce à des mandats judiciaires, les enquêteurs prennent le contrôle des domaines malveillants codés en dur dans les variantes de logiciels malveillants. Ils modifient les enregistrements des serveurs de noms faisant autorité pour ces domaines, redirigeant ainsi des millions de bots infectés à travers le monde vers des serveurs de recherche. Cela rompt le contrôle exercé par le groupe criminel sur les ordinateurs infectés et permet aux chercheurs d’évaluer la taille et la répartition géographique du botnet.

Exemples concrets de « sinkholing » DNS

Le « sinkholing » DNS a joué un rôle central dans la résolution de certains des incidents de cybersécurité les plus graves de l'histoire récente.

Le « kill switch » du ransomware WannaCry (2017)

En mai 2017, le ransomware WannaCry s'est propagé à l'échelle mondiale, paralysant des hôpitaux, des entreprises de télécommunications et des réseaux de transport dans plus de 150 pays. Le ver s'est propagé de manière autonome en exploitant la faille EternalBlue.

En analysant le fichier binaire du logiciel malveillant, le chercheur en sécurité Marcus Hutchins a découvert un domaine non enregistré codé en dur dans le code source. L'auteur du logiciel malveillant avait intégré un mécanisme de vérification : avant de chiffrer le disque dur de l'hôte, le code envoyait une requête DNS à ce domaine. Si la requête échouait, le rançongiciel procédait au chiffrement des fichiers. Si le domaine répondait, le logiciel malveillant interrompait son exécution. Hutchins a enregistré le domaine pour une dizaine de dollars et l'a redirigé vers un serveur « sinkhole ». Lorsque des ordinateurs du monde entier ont réussi à résoudre le domaine, la logique intégrée a interrompu la routine d'exécution, mettant ainsi involontairement un terme à la propagation mondiale de la menace.

Opération Avalanche (2016)

Le réseau Avalanche a fonctionné pendant plus de sept ans comme une plateforme illicite d’hébergement « bulletproof » et de diffusion de logiciels malveillants, hébergeant plus d’une vingtaine de chevaux de Troie bancaires et de souches de ransomware telles que GozNym et TeslaCrypt. L’infrastructure utilisait une double technique « fast-flux », faisant tourner les adresses IP et les serveurs de noms toutes les quelques minutes afin d’échapper à la détection.

Fin 2016, une coalition multinationale regroupant des services répressifs de quarante pays, en collaboration avec Europol et le ministère américain de la Justice, a démantelé ce réseau. Selon des documents publiés par Europol, les autorités ont saisi, bloqué ou redirigé vers des serveurs « sinkhole » plus de 800 000 domaines. En remplaçant les serveurs de noms utilisés par les criminels par des serveurs « sinkhole » contrôlés, les enquêteurs ont déconnecté des centaines de milliers d'ordinateurs infectés de leurs opérateurs, ce qui constitue l'une des plus importantes opérations collaboratives de démantèlement de botnets jamais menées.

Avantages du « sinkholing » DNS

La mise en place d'un « sinkhole » DNS offre des avantages stratégiques uniques pour la défense du réseau :

• Prévention des menaces à un stade précoce : La résolution DNS a lieu avant la poignée de main TCP ou la négociation TLS. Intercepter une menace à ce stade garantit que les charges utiles malveillantes n'atteignent jamais la mémoire tampon du réseau.
• Localisation rapide des infections : Un collecteur « sinkhole » enregistre l'adresse IP source de chaque client interne émettant des requêtes figurant sur la liste noire. Cela permet aux équipes de sécurité d'identifier les appareils compromis, les ordinateurs portables non autorisés ou les appareils IoT non autorisés qui ne disposent pas d'agents de sécurité traditionnels pour les terminaux.
• Empreinte nulle sur les terminaux : Comme le « sinkholing » s'exécute directement au sein de l'architecture du résolveur DNS, les administrateurs n'ont pas besoin d'installer ni de gérer d'agents côté client sur les ordinateurs, téléphones ou systèmes d'exploitation des serveurs individuels.
• Une couche de défense économique : Les organisations peuvent mettre en place des systèmes de « sinkhole » efficaces à l’aide de logiciels DNS open source tels que BIND ou Unbound, associés à des flux d’informations sur les menaces gratuits et gérés par la communauté.

Associer la protection des requêtes au niveau du réseau à des meilleures pratiques en matière de sécurité DNS permet de mettre en place une défense en profondeur solide, garantissant ainsi que les postes de travail internes et les nœuds périphériques externes conservent un niveau de sécurité élevé.

Limites des « sinkholes » DNS

Bien que le « sinkholing » DNS offre une couche de filtrage efficace, il ne s'agit pas d'une solution de sécurité exhaustive. Les équipes réseau doivent tenir compte de plusieurs contraintes structurelles :

• Rappels IP directs: Les acteurs malveillants programment souvent des logiciels malveillants pour qu'ils se connectent directement à des adresses IP numériques externes. Si le logiciel malveillant contourne le résolveur du système et envoie une demande de connexion directement à 203.0.113.10, le « sinkhole » ne détecte jamais ce trafic.
• Contournement du DNS chiffré (DoH et DoT) : Les navigateurs modernes et les charges utiles malveillantes peuvent interroger des résolveurs publics externes à l’aide des protocoles DNS-over-HTTPS (DoH) ou DNS-over-TLS (DoT). Ces requêtes transitent par des canaux chiffrés, contournant ainsi les résolveurs internes de l’entreprise et les politiques locales de redirection vers des « sinkholes », à moins que les règles relatives aux ports sortants ne bloquent strictement ou ne déchiffrent ce trafic.
• Algorithmes de génération de domaines (DGA) : Les variantes avancées de logiciels malveillants utilisent des algorithmes pour générer chaque jour des centaines de noms de domaine pseudo-aléatoires. Les listes noires de sécurité sont souvent à la traîne par rapport aux nouveaux domaines générés par les DGA, ce qui permet aux logiciels malveillants d'établir une connexion vers l'extérieur avant que les analystes n'identifient et ne redirigent vers un « sinkhole » le nouveau domaine.
• Résolution et mise en cache côté client : Si un appareil client a résolu une adresse avant qu’un administrateur n’ajoute ce domaine à la zone « sinkhole », le système d’exploitation conserve l’adresse IP d’origine dans son cache local jusqu’à l’expiration du délai de vie (TTL) de l’enregistrement.
• Faux positifs : Le recours à des flux d’alertes agressifs ou non validés peut entraîner le détournement vers des serveurs de piégeage de services légitimes, de réseaux de diffusion de contenu ou d’adresses d’hébergement mutualisé, ce qui perturbe le travail des équipes internes.

Comment configurer un « sinkhole » DNS

La mise en place d'un « sinkhole » DNS fonctionnel est possible dans différents environnements, des laboratoires personnels aux services d'annuaire d'entreprise. Le processus consiste principalement à modifier les politiques des résolveurs afin d'intercepter les requêtes malveillantes.

1. Zones de politique de réponse (RPZ) sur BIND ou Unbound

Les environnements Unix d'entreprise utilisant le démon Berkeley Internet Name Domain (BIND) ou Unbound ont couramment recours aux zones de politique de réponse (RPZ). Souvent appelées « pare-feu DNS », les règles RPZ configurent le serveur récursif local pour qu'il renvoie une réponse modifiée lorsqu'un client demande une zone bloquée.

Un administrateur crée un fichier de zone dédié contenant des données sur les menaces :

$TTL 1 h
@ IN SOA localhost. root.localhost. ( 2026102401 1 h 15 min 30 j 2 h )
NS localhost.

; Rediriger les domaines malveillants vers un serveur de journalisation interne
malicious-site.example.com CNAME sinkhole.internal.network.
phishing-domain.example.net A 192.168.10.50
*.bad-actor-infrastructure.org A 192.168.10.50

Toute requête correspondant à ces enregistrements est résolue directement vers l'adresse 192.168.10.50, sans passer par les serveurs racines.

2. Stratégies DNS de Windows Server

Dans les environnements Active Directory, le service DNS de Windows Server intègre des fonctionnalités de stratégie natives qui permettent aux administrateurs de bloquer ou de rediriger des requêtes sans avoir recours à un logiciel externe. En configurant des stratégies de résolution des requêtes via PowerShell, les administrateurs peuvent comparer les critères des noms de domaine complets (FQDN) entrants à une liste noire de domaines malveillants et renvoyer une adresse IP statique nulle :

Add-DnsServerQueryResolutionPolicy -Name « SinkholePolicy » -Action DENY -FQDN « EQ,*.maliciousdomain.com »

3. Outils de protection spécialisés (par exemple, Pi-hole)

Pour les bureaux à domicile et les réseaux de petites entreprises, les filtres DNS au niveau matériel, tels que Pi-hole, offrent des services de « sinkhole » clés en main. Installé sur un petit serveur ou une machine virtuelle, Pi-hole fait office de résolveur principal du réseau local. Il consulte les listes de blocage établies par la communauté de la sécurité et renvoie l’adresse 0.0.0.0 chaque fois qu’un appareil demande un domaine associé à des réseaux publicitaires, à des systèmes de suivi télémétrique ou à des domaines de logiciels malveillants.

Gestion des caches clients locaux

Chaque fois que vous appliquez de nouvelles politiques de « sinkhole », les appareils actifs sur le réseau peuvent continuer à accéder aux anciennes adresses jusqu'à ce que le cache interne de leur système d'exploitation arrive à expiration. Lors du dépannage ou de la vérification du bon fonctionnement d'une règle de « sinkhole », les administrateurs doivent savoir comment vider le cache DNS sur les terminaux concernés afin d’effacer les tables de cache existantes et de forcer une requête immédiate vers le résolveur.

« Sinkhole DNS » vs « filtrage DNS » vs « blackhole DNS »

Dans les débats sur la sécurité, les termes « sinkhole », « blackhole » et « filtrage » sont souvent utilisés de manière interchangeable. Bien qu’ils aient pour objectif commun d’atténuer les menaces au niveau de la couche de résolution des noms, leur fonctionnement est différent.

Un « blackhole » DNS se contente de refuser de répondre ou d'indiquer à l'appareil que l'entrée n'existe pas. Un « sinkhole », quant à lui, renvoie délibérément une adresse qui redirige le client vers un environnement isolé où le personnel de sécurité peut surveiller les actions qu'il tente d'entreprendre ensuite.

Foire aux questions

Un « DNS sinkhole » est-il la même chose qu'un « Pi-hole » ?

Un Pi-hole est une implémentation spécifique d'un « sinkhole » DNS conçue pour les réseaux locaux. Alors que les « sinkholes » d'entreprise se concentrent principalement sur l'enregistrement des communications des botnets et la détection des infections par des logiciels malveillants, un Pi-hole utilise avant tout les techniques de « sinkholing » pour bloquer les publicités, le suivi en ligne et les connexions télémétriques indésirables avant qu'elles n'atteignent les écrans des utilisateurs finaux.

Quelle adresse IP utilise un « sinkhole » ?

Un « sinkhole » utilise généralement soit une adresse non routable, soit une adresse de collecte spécialisée. Parmi les adresses non routables courantes, on trouve notamment 127.0.0.1 (l'adresse de bouclage de l'hôte) ou 0.0.0.0 (une méta-adresse non routable). Lorsque l'objectif est de recueillir des preuves judiciaires, le « sinkhole » renvoie l'adresse IP interne privée d'un serveur de surveillance dédié qui enregistre les détails des connexions entrantes.

Un logiciel malveillant peut-il contourner un « sinkhole » DNS ?

Oui. Un logiciel malveillant peut contourner un « sinkhole » DNS en intégrant des adresses IP brutes directement dans son code, ce qui lui évite d’avoir à interroger les noms de domaine. Il peut également contourner les résolveurs locaux en utilisant des protocoles chiffrés tels que le DNS-over-HTTPS (DoH) ou le DNS-over-TLS (DoT) pointant vers des serveurs publics externes, ou encore en modifiant les fichiers de configuration du système local.

Le « sinkholing » DNS est-il légal ?

Oui, au sein du réseau interne d’une organisation, le « sinkholing » DNS constitue une pratique de sécurité courante. Les propriétaires de réseaux conservent un contrôle total sur la manière dont leurs résolveurs gèrent le trafic interne. Lorsqu’il est appliqué sur l’Internet public pour prendre le contrôle de domaines externes, le « sinkholing » nécessite des mandats judiciaires, la coopération des registres ou des opérations coordonnées des forces de l’ordre à l’échelle internationale.

Réflexions finales

Les « sinkholes » DNS constituent une ligne de défense essentielle pour le trafic sortant : ils empêchent les machines internes de communiquer avec des infrastructures malveillantes et permettent de détecter les infections cachées. Cependant, sécuriser le trafic sortant de vos postes de travail ne représente que la moitié du chemin. Vous devez également protéger le nom de domaine de votre entreprise contre toute exploitation dans le cadre de cyberattaques sortantes visant des partenaires et des clients externes.

Sans surveillance continue, des dérives de configuration subtiles, la création non autorisée d'enregistrements ou des pointeurs orphelins peuvent exposer votre organisation au détournement de domaine et à l'usurpation d'adresse e-mail. Grâce à la surveillance automatisée de la sécurité et de la conformité DNS, vous pouvez suivre en temps réel les modifications apportées à vos zones faisant autorité, détecter instantanément les modifications anormales et protéger la réputation de votre domaine contre toute altération non autorisée.