DNS sinkhole expliqué : comment stopper les rappels malveillants
Un DNS sinkhole redirige les requêtes de logiciels malveillants vers un leurre, bloquant les rappels et révélant les appareils infectés. Découvrez son fonctionnement et son déploiement.
Published 2 novembre 2026
Un client connecte un ordinateur portable au réseau WiFi de votre caféWiFi, ouvre un navigateur et poursuit sa journée. En arrière-plan, un logiciel malveillant présent sur cet ordinateur tente de contacter son serveur de contrôle. Vous ne pouvez pas installer de logiciel de sécurité sur l'appareil de chaque visiteur, mais vous pouvez contrôler la manière dont votre réseau répond aux requêtes de cet appareil pour accéder à des destinations Internet.
Un DNS sinkhole vous permet d'interrompre cette tentative de rappel et d'enregistrer des preuves méritant une investigation. La question utile n'est pas seulement de savoir ce qu'il bloque. Il s'agit de savoir si vous pouvez identifier l'appareil concerné, prouver que votre politique s'applique et rétablir l'accès légitime lorsqu'une règle commet une erreur.
Table des matières
- Ce qu'est un DNS Sinkhole en termes simples
- Comment un Sinkhole répond à une requête malveillante
- L'attaque Conficker qui a fait des Sinkholes une norme
- Transformer les hits Sinkhole en pistes d'équipements infectés
- Modèles de déploiement pour les réseaux partagés et invités
- Faux positifs et moyen de rétablissement rapide
- Déterminer si un Sinkhole est adapté à votre réseau
Ce qu'est un sinkhole DNS en termes simples
L'ordinateur portable infecté doit trouver son contrôleur avant de pouvoir demander des instructions. Si le logiciel malveillant utilise un nom de domaine, l'ordinateur demande d'abord à un résolveur DNS de traduire ce nom en une adresse IP.
Considérez le DNS comme un annuaire téléphonique. Le domaine est le nom que vous cherchez, et l'adresse IP est le numéro que vous devez appeler. Un résolveur protecteur vérifie s'il doit fournir ce numéro.
Un sinkhole DNS remplace la réponse pour un domaine malveillant connu par une destination contrôlée, ou bloque la réponse, de sorte que l'appareil ne peut pas utiliser cette recherche pour atteindre l'attaquant.
Strictement parlant, le sinkholing consiste à rediriger le trafic vers un point de terminaison contrôlé. Les administrateurs utilisent également ce terme de manière plus large pour désigner les politiques DNS qui bloquent les recherches malveillantes sans fournir de destination.
L'analogie de l'annuaire aide à séparer la recherche de nom de la connexion qui suit.
Le blocage DNS n'est pas un blocage d'IP
Un DNS sinkhole agit sur le nom demandé avant que l'appareil n'utilise la réponse pour contacter cette destination. Une règle de pare-feu ordinaire évalue les paquets, souvent en utilisant leur adresse IP de destination, et peut rejeter la tentative de connexion initiale. Un pare-feu n'a pas besoin d'attendre qu'une connexion soit établie.
Cette distinction est importante lorsque des services légitimes et malveillants partagent la même infrastructure d'hébergement. Bloquer une adresse IP entière peut affecter des services non liés, alors qu'une politique DNS peut cibler un nom d'hôte particulier. Aucune de ces approches ne remplace l'autre.
Sur le WiFi partagéWiFi, le résolveur est utile car l'opérateur n'a pas besoin d'un accès d'administration à l'ordinateur portable. Cependant, stopper un rappel ne supprime pas l'infection. Cela offre à l'opérateur une opportunité de confinement et, avec une journalisation appropriée, une piste pour l'investigation.
Comment un sinkhole répond à une recherche malveillante
Une recherche DNS est une demande d'information, et non une connexion au site web demandé. La réponse du résolveur détermine ce que l'appareil peut tenter ensuite.
Le chemin de base sépare l'équipement, la vérification de la politique et la destination contrôlée.
- L'appareil demande son domaine de rappel. Il envoie une requête au résolveur configuré.
- Le résolveur identifie la politique qui s'applique au réseau d'origine, comme un réseau invité SSID ou personnel VLAN.
- Le nom est vérifié par rapport au renseignement sur les menaces et aux règles locales, y compris les catégories de commande et contrôle (C2), d'hameçonnage et de logiciels malveillants.
- En cas de correspondance entraînant un blocage, le résolveur fournit une adresse contrôlée, renvoie une réponse de type "nom inexistant", ou refuse ou supprime la réponse.
- L'appareil tente de se connecter à la leurre ou n'arrive pas à obtenir une destination exploitable. Les noms autorisés sont résolus normalement.
Avant qu'un appareil n'ouvre un site ou une application, il demande au DNS où le trouver, et Shield répond en utilisant la politique propre à ce réseau. Si un domaine est bloqué, la connexion vers cette destination ne démarre jamais et l'appareil affiche à la place la page de blocage personnalisée du client. Cette expérience utilisateur ne doit pas être confondue avec un logiciel malveillant qui tente à nouveau un rappel échoué.
Choisir la réponse adaptée aux preuves dont vous avez besoin
Choix de réponses du sinkhole et ce que chacun révèle
| Réponse | Ce que l'appareil subit | Ce que les équipes de défense apprennent | Compromis principal |
|---|---|---|---|
| Nom inexistant (NXDOMAIN) | La recherche échoue et la connexion ne démarre jamais | Qu'une recherche a été tentée et bloquée | Stoppe le rappel (callback) mais ne fournit aucun comportement de connexion ultérieur |
| Adresse de sinkhole | La recherche renvoie l'adresse d'un serveur contrôlé | Adresse IP source, fréquence des rappels, schéma de réessai et protocole observable | Nécessite un point de terminaison surveillé et un stockage rigoureux des journaux |
| Réponse refusée ou supprimée | Le résolveur refuse la requête ou la laisse sans réponse | Peu d'informations au-delà de la tentative elle-même, sauf si la journalisation du résolveur est activée | Rapide à appliquer, mais certains clients réessaient de manière agressive |
NXDOMAIN me efface pas les informations de source ou d'horodatage. Un résolveur peut enregistrer les deux. Ce qu'il ne peut pas collecter à partir de cette recherche échouée, c'est la connexion que le logiciel malveillant aurait établie par la suite.
Une évaluation évaluée par des pairs sur la capture de paquets sinkhole a fait état d'une amélioration multipliée par cinq de la capture de paquets malveillants grâce à une architecture de collecte avancée par rapport à une mise en œuvre classique. Il s'agit d'une preuve concernant l'architecture de collecte, et non d'une promesse que chaque sinkhole offrira la même amélioration.
Cette vidéo offre une autre manière de suivre le mécanisme.
La réponse que vous choisissez détermine le comportement ultérieur que vous pouvez observer. Conservez les collecteurs isolés et ne partez pas du principe que la redirection générera une page d'avertissement claire pour chaque application chiffrée.
L'attaque Conficker qui a fait des sinkholes une norme
Conficker a montré comment les défenseurs pouvaient transformer la recherche d'instructions d'un logiciel malveillant en une source de renseignements. Plutôt que d'inspecter chaque ordinateur infecté, les chercheurs ont intercepté les destinations que le ver était programmé pour contacter.
L'archive Conficker de la CAIDA décrit l'épidémie détectée pour la première fois en novembre 2008, avec des premières variantes générant environ 250 noms de domaine pseudo-aléatoires par jour. Le ver contactait les noms générés via HTTP pour obtenir des instructions ou des logiciels malveillants supplémentaires.
Des chercheurs et des opérateurs réseau ont enregistré des domaines sélectionnés avant que les cybercriminels ne puissent les utiliser, puis ont pointé ces noms vers des serveurs contrôlés. Les ordinateurs infectés ont par conséquent appelé des infrastructures exploitées par les défenseurs.
La recherche DNS est devenue un point de mesure
Ces rappels ont aidé les équipes d'intervention à identifier les systèmes infectés, à évaluer la propagation du ver et à suivre l'avancement du nettoyage sans communiquer directement avec le réseau de commande criminel. Une interception réussie a donc fait plus que refuser une mise à jour : elle a enregistré un ordinateur tentant toujours d'en obtenir une.
- Pour le confinement, les équipes d'intervention ont empêché des noms sélectionnés d'aboutir à des infrastructures contrôlées par l'attaquant.
- Pour l'investigation, les journaux de rappels ont permis d'identifier les systèmes nécessitant une intervention.
- Pour le suivi de la remédiation, la poursuite des rappels indiquait que le nettoyage restait incomplet.
Les variantes ultérieures de Conficker ont élargi l'ensemble des noms générés et ajouté des mises à jour en peer-to-peer. Les équipes d'intervention ont dû coordonner l'enregistrement et le blocage plutôt que de s'appuyer sur une liste restreinte et statique.
Le déploiement historique différait également de la politique de filtrage locale d'une entreprise. Les chercheurs ont modifié les destinations des domaines qu'ils contrôlaient, affectant ainsi les ordinateurs infectés qui résolvaient ces noms via un DNS ordinaire. Un opérateur de site applique généralement sa politique au niveau de son propre résolveur récursif.
La couverture était la contrainte dans les deux cas. Les défenseurs pouvaient intercepter les rappels vers les noms sous leur contrôle, mais cela ne signifiait pas que toutes les routes de mise à jour possibles avaient disparu. Conficker a établi le sinkholing comme une technique de confinement et un outil de mesure, mais non comme un substitut à la réparation des ordinateurs infectés.
Transformer les détections par sinkhole en pistes d'équipements infectés
Un client qui interroge de manière répétée un domaine de command-and-control (C2) bloqué mérite une attention particulière. Ce modèle peut fournir une piste utile même si vous ne disposez pas d'agent sur le point de terminaison, d'inspection de la charge utile ou d'enregistrements détaillés du pare-feu.
La dépendance est importante : le document de recherche sur la défense contre les botnets de l'Université de l'Arizona explique qu'une redirection DNS efficace exige d'identifier l'infrastructure C2 du botnet et d'obtenir la coopération de l'opérateur DNS utilisé par le bot. Un résultat positif montre simplement qu'une requête spécifique a rencontré votre politique, et non que vous avez découvert l'ensemble des chemins de communication.
Conserver suffisamment de contexte pour identifier le client
Enregistrez ces champs ensemble plutôt que de les disperser sur des tableaux de bord déconnectés :
- Horodatage : Corrélez l'événement avec les baux réseau et les enregistrements d'authentification.
- SSID ou VLAN : Identifiez la limite de réseau et de politique concernée.
- Identifiant client : Conservez une référence d'appareil exploitable, et pas seulement l'adresse publique du site.
- Domaine interrogé : Conservez le nom d'hôte exact qui a déclenché la règle.
- Catégorie de politique : Distinguez une classification de menace d'une restriction de contenu.
- Action de réponse : Enregistrez si le résolveur a réorienté, refusé ou renvoyé NXDOMAIN.
Une adresse IP source publique peut représenter de nombreux invités derrière la même passerelle. Pour identifier un appareil individuel, corrélez les observations des points de terminaison avec les enregistrements du résolveur et du réseau. Ne qualifiez pas l'ensemble du site d'infecté parce qu'un collecteur voit son adresse partagée.
Règle d'investigation : Traitez une détection par sinkhole comme une piste avec du contexte justificatif, et non comme un verdict automatique contre le propriétaire de l'équipement.
Valider le signal et maintenir la couverture
Comparez les requêtes répétées au comportement normal sur ce réseau et vérifiez la classification par rapport aux flux de renseignements sur les menaces actualisés. Les domaines générés, l'hébergement à changement rapide, les adresses codées en dur et les canaux de secours peuvent laisser des failles. L'absence de requêtes n'est pas une preuve de la propreté d'un appareil.
Le statut du domaine nécessite également un réexamen continu. Une étude académique de 2019 sur le retrait des domaines malveillants a révélé que plus de 14 % des domaines retirés au cours des dix mois précédents étaient ensuite revenus sur le marché commercial des noms de domaine.
Révisez régulièrement la provenance, la propriété et la classification des règles. Si vous gérez vous-même des domaines sinkhole enregistrés, protégez leur configuration DNS et leurs renouvellements. Restreignez l'accès aux journaux au niveau du client et définissez des durées de conservation conformes aux lois locales et à vos besoins d'investigation.
Modèles de déploiement pour les réseaux partagés et invités
Un sinkhole protège le chemin DNS que vous contrôlez. Le navigateur ou l'application d'un invité peut sélectionner à la place un résolveur chiffré externe, ce qui ne laisse rien à évaluer pour votre politique locale.
Une analyse technique du DNS chiffré explique pourquoi le DNS-over-HTTPS externe peut contourner la surveillance DNS conventionnelle. La décision de déploiement concerne donc l'application des résolveurs et le comportement des clients, et pas seulement la qualité d'une liste de blocage.
Modèles de déploiement de sinkhole pour les réseaux partagés
| Modèle | Emplacement du contrôle | Usage idéal | Limite principale |
|---|---|---|---|
| Solveur réseau sur WiFi invité | Solveur transmis à chaque client par le réseau | Hôtels, pubs, WiFi public | Les clients disposant de leur propre solveur codé en dur ou chiffré peuvent le contourner |
| Inspection DNS du pare-feu | À l'intérieur d'un pare-feu ou d'une passerelle existants | Bureaux disposant d'un parc de pare-feu établi | L'inspection DNS classique ne détecte pas le DoH externe acheminé via HTTPS |
| Politique de navigateur ou d'équipement géré | Le navigateur ou le système d'exploitation définit le solveur et désactive le DoH alternatif | Équipements d'entreprise ou scolaires gérés | Ne s'applique pas aux équipements personnels non gérés |
| DNS protecteur basé sur le cloud | Solveur hébergé par le fournisseur vers lequel pointe le DNS du réseau | Établissements et sites multiples | Dépend de la disponibilité du fournisseur et de l'accès à la télémétrie |
Le chiffrement et l'application des règles sont des choix distincts
Le DNS chiffré améliore la confidentialité entre le client et le résolveur. Il n'affaiblit pas nécessairement le filtrage : un résolveur de protection approuvé peut accepter des requêtes chiffrées tout en appliquant la politique de sécurité. Le problème de visibilité survient lorsque le client choisit un résolveur externe qui n'applique pas vos règles.
Pour les appareils gérés, les politiques du navigateur et du système d'exploitation peuvent spécifier le service approuvé. Sur les réseaux invités, vous devez établir une position documentée concernant le DNS chiffré alternatif, la confidentialité des utilisateurs et les exceptions autorisées. Bloquer tout le trafic web chiffré pour stopper le DoH n'est pas une stratégie globale réalisable.
Placer le contrôle à une frontière que vous pouvez tester
Distribuez le résolveur approuvé à travers la configuration réseau. Limitez le DNS conventionnel sortant direct aux résolveurs approuvés, en couvrant à la fois les protocoles de transport et les deux familles d'IP. La rédirection transparente peut intercepter le DNS conventionnel envoyé ailleurs, mais elle ne résout pas de manière transparente le DNS chiffré arbitraire.
Utilisez la segmentation réseau pour séparer les politiques du personnel, des invités et des appareils spécialisés. Une règle stricte pour les invités ne doit pas interrompre les équipements cliniques ou les applications du personnel.
- Tester la résolution ordinaire : confirmez que les applications autorisées fonctionnent toujours.
- Tester les chemins de contournement : vérifiez les résolveurs sélectionnés par le navigateur ainsi que les autres tunnels autorisés.
- Tester l'attribution : confirmez qu'une correspondance de politique contrôlée apparaît pour le réseau et le client corrects.
Une modification du DNS au niveau du réseau peut appliquer un filtrage sur l'ensemble des appareils participants sans installer de logiciel sur chacun d'eux. Prouvez la couverture par des tests, plutôt que de supposer que la distribution d'une adresse de résolveur force chaque application à l'utiliser.
Faux positifs et comment rétablir le service rapidement
Une liste de blocage plus longue n'est pas automatiquement plus sûre. Une règle générale s'appliquant aux infrastructures cloud partagées peut interrompre les portails fournisseurs, les flux de paiement ou les applications d'apprentissage sans pour autant améliorer la protection contre la menace visée.
Une étude de mise en œuvre du sinkholing de 2025 a signalé des faux positifs nécessitant une gestion manuelle de la liste d'autorisation et du personnel formé. La responsabilité opérationnelle doit figurer dans le plan de déploiement, et pas seulement dans la file d'attente des incidents.
Le processus de rétablissement doit prendre en compte les services partagés et les exceptions à portée restreinte.
Rétablir l'accès sans supprimer la protection
Démarrez les nouvelles politiques en mode journalisation seule pendant une période d'observation convenue. Capturez le client, la catégorie et la règle correspondante afin que les décisions ultérieures disposent d'une piste d'éléments probants.
Symptômes de sinkhole, causes probables et premières actions
| Symptôme | Cause probable | Première action |
|---|---|---|
| L'appareil d'un collaborateur ne peut pas accéder au site d'un fournisseur | Domaine cloud partagé bloqué par catégorie | Vérifiez la catégorie enregistrée, puis ajoutez l'hôte exact à la liste d'autorisations, et non l'ensemble du domaine |
| Un appareil invité déclenche des accès au sinkhole chaque minute | Appareil infecté ou application agressive qui réessaie la connexion | Identifiez et isolez le client, puis organisez l'inspection de l'appareil |
| Pic de requêtes bloquées après une modification de politique | Entrée trop large dans la liste de blocage ou règle avec caractère générique | Annulez la dernière modification et examinez sa portée pour SSID ou VLAN |
| Les applications fonctionnent mais un SSID n'affiche aucun blocage | Les clients utilisent peut-être un DNS chiffré en dehors du résolveur | Exécutez un test de politique contrôlé et inspectez la configuration du résolveur ainsi que les chemins DNS sortants |
Un rapport vide ne suffit pas à établir l'existence d'un contournement. Il se peut que le réseau n'ait généré aucune requête correspondante.
Mesurez les connexions nocives évitées, le taux de faux positifs, le délai de résolution des recours et les exceptions par site. Le seul volume de requêtes bloquées peut augmenter simplement parce qu'une application réessaie de manière répétée.
Avant d'activer une règle, confirmez :
- Classification : La catégorie de menace du domaine est prise en charge.
- Usage partagé : Les applications métier ne dépendent pas du même hôte ou domaine parent.
- Restauration : La politique précédente et la procédure de restauration sont enregistrées.
- Périmètre : Le ou la SSID ou VLAN visé(e) est explicite.
- Responsabilité : Une personne désignée gère les demandes d'exception et révise leur expiration.
Déterminer si un sinkhole est adapté à votre réseau
Pour un petit bureau avec des terminaux gérés, commencez par la journalisation DNS et la politique relative aux terminaux. Vous disposez peut-être déjà des contrôles d'appareils nécessaires pour enquêter directement sur les requêtes suspectes ; évitez donc d'ajouter un collecteur que vous ne pouvez pas entretenir.
Pour les réseaux invités, publics ou étudiants, priorisez l'application des limites et l'attribution des clients. Les appareils non gérés rendent les contrôles au niveau du résolveur utiles, mais un opérateur a toujours besoin d'un moyen sûr d'enquêter sur un appareil ou de le confiner sans accuser son propriétaire prématurément.
Adapter le modèle d'exploitation à votre parc informatique
Une organisation multi-site bénéficie d'une politique de résolveur centralisée, d'exceptions spécifiques au réseau et de rapports consolidés. Comparez les services en fonction des preuves qu'ils fournissent et des contrôles que vous pouvez tester, et non seulement de leur nombre de catégories.
Choisissez un sinkhole lorsque vous pouvez assumer l'ensemble du processus : politique, couverture, investigation, exceptions et rétablissement.
Commencer par un déploiement limité :
- Cartographiez le chemin du résolveur. Identifiez le résolveur utilisé par chaque réseau et les endroits où un DNS alternatif ou des tunnels pourraient contourner la politique.
- Exécutez une période d'observation documentée en mode journalisation seule. Enregistrez les requêtes correspondantes avec leur client, catégorie et réseau, puis examinez les dépendances applicatives légitimes.
- Activez d'abord les blocages à haute confiance. Commencez par les destinations C2 et logiciels malveillants confirmés, conservez un plan de retour en arrière écrit et attribuez un responsable des exceptions.
Séparez la correction des points de terminaison du confinement réseau. Un rappel bloqué est une intervention réussie, mais l'appareil nécessite toujours une investigation. Votre déploiement est prêt lorsque le personnel peut faire la démonstration à la fois d'un blocage contrôlé et d'une restauration sécurisée de l'accès légitime.
Purple Shield propose un DNS protecteur doté de politiques et de rapports spécifiques à chaque réseau, vous permettant d'évaluer le blocage des domaines malveillants tout en disposant des preuves nécessaires à sa gestion. Visitez Purple Shield pour organiser un essai gratuit de 30 jours, pointez le DNS de votre réseau vers Shield et testez le filtrage sur votre réseau en direct sans aucun nouveau matériel ni agent logiciel.