Comment prévenir les attaques DNS : bonnes pratiques de sécurité DNS

Les attaques contre le service de noms de domaine (DNS) menacent chaque connexion à internet, car elles peuvent bloquer, intercepter et détourner les connexions. Alors qu’internet joue un rôle croissant dans les activités des entreprises, la sécurisation du DNS est essentielle à la fois pour les opérations et pour la sécurité.

Cet article explique comment sécuriser le protocole DNS, les serveurs DNS et l’accès au DNS contre un large éventail d’attaques grâce aux mesures suivantes :

Pour une vue d’ensemble de la sécurité DNS, commencez par lire Qu’est-ce que la sécurité DNS ? Tout ce que vous devez savoir.

3 bonnes pratiques générales pour prévenir les attaques DNS

Bien que les serveurs DNS établissent toutes les connexions à internet, ils résolvent également les noms d’hôte et les adresses IP de tous les appareils locaux (par exemple, les imprimantes) du réseau local. Ces rôles variés garantissent la connexion d’un très grand nombre d’appareils, d’applications et de services au serveur DNS — et les attaquants exploiteront ces connexions dès qu’ils le pourront.

Pour se protéger contre les attaques, il faut appliquer des bonnes pratiques au protocole DNS, au serveur sur lequel il s’exécute et à tous les accès aux processus DNS. La mise en œuvre de ces bonnes pratiques protégera non seulement le DNS, mais aussi la sécurité du réseau en général, car un DNS correctement protégé peut également protéger les e-mails, les terminaux et les autres systèmes réseau contre les attaques.

Protéger le protocole DNS

Le vénérable protocole DNS n’avait pas anticipé notre environnement actuel, peuplé d’adversaires agressifs. Le DNS communique en texte brut et, sans modification, considère que toutes les informations qu’il reçoit sont exactes, authentiques et faisant autorité.

Pour protéger le protocole, les bonnes pratiques consistent à ajouter des protocoles supplémentaires au processus afin de chiffrer les communications DNS et d’authentifier les résultats. Comme leur mise en œuvre ne coûte rien, ces protocoles constituent généralement les premières mesures prises pour améliorer la sécurité DNS.

Chiffrement DNS

Le chiffrement DNS peut être obtenu avec le protocole DNSCrypt, DNS over TLS (DoT) ou DNS over HTTPS (DoH). Le protocole DNSCrypt nécessite un agent serveur et gagne en efficacité lorsqu’un agent de terminal est installé afin d’établir une connexion entièrement chiffrée. TLS et HTTPS créent intrinsèquement des sessions de communication sécurisées et chiffrées.

Authentification DNS

L’authentification DNS repose généralement sur le protocole d’extension de sécurité DNS (DNSSEC). Les URL compatibles avec DNSSEC publient une clé de chiffrement publique avec leur nom de domaine et leur adresse IP.

Lorsqu’un serveur DNS envoie une requête à un résolveur DNS, celui-ci télécharge et vérifie la clé de chiffrement publique afin de confirmer l’authenticité et l’exactitude de l’adresse IP associée à l’adresse URL demandée.

Protéger le serveur DNS

Une fois le protocole DNS renforcé, l’organisation peut se consacrer à la protection du serveur DNS. Les organisations qui gèrent leurs propres serveurs doivent isoler, renforcer, maintenir et auditer les serveurs DNS comme elles le feraient pour tout autre serveur à haut risque gérant des informations sensibles. Les organisations qui ne disposent pas de ressources internes peuvent externaliser les services DNS auprès d’un fournisseur tiers tel que Cloudflare, Google ou F5.

Isolation du serveur DNS

L’isolation du serveur DNS contribue à sécuriser le processus DNS en permettant un contrôle plus strict des ports ouverts, des applications et des services autorisés à s’exécuter sur le serveur. Elle améliore également la surveillance et la détection des anomalies, car elle réduit globalement l’activité du serveur.

Les petites organisations ou les bureaux régionaux qui ne peuvent pas se permettre des serveurs physiques distincts peuvent utiliser des serveurs virtuels séparés. Toutefois, l’équipe de sécurité doit tout de même protéger correctement l’environnement de machines virtuelles afin de sécuriser les ressources critiques.

Renforcement du serveur DNS

Le renforcement d’un serveur DNS peut être très complexe et dépendre de l’architecture environnante. Nous entrerons dans le détail plus bas, mais voici les grandes lignes :

Refuser les services inutiles sur le serveur qui ne sont pas nécessaires au DNS.
Concevoir une architecture de serveur robuste pour améliorer la redondance et la capacité, afin de résister aux pannes ou aux attaques DDoS.
Renforcer les pare-feu pour fermer les ports inutiles.
Mettre en œuvre une limitation du débit afin de se protéger contre les attaques DDoS et par tunneling DNS.
Limiter les informations et masquer les numéros de version des logiciels, les noms d’utilisateur et autres indices que les attaquants peuvent utiliser pour rechercher des faiblesses.

Maintenance du serveur DNS

La maintenance du serveur DNS exige que les serveurs DNS et les logiciels soient prioritaires pour les mises à jour et l’application des correctifs dans le cadre des infrastructures critiques d’une organisation. Les attaquants ciblent régulièrement les serveurs et services DNS, ce qui les classe parmi les cibles à haut risque, à forte valeur et présentant une forte probabilité d’attaque. Ces exigences de maintenance prioritaire doivent également s’appliquer aux autres solutions de sécurité qui protègent les serveurs DNS, notamment les pare-feu et les applications antivirus.

Audits des serveurs DNS

Les audits des serveurs DNS nécessitent l’utilisation et l’examen réguliers des fichiers journaux du serveur DNS et des requêtes DNS. Les audits peuvent être réalisés en continu par un centre des opérations de sécurité (SOC), un fournisseur de services de sécurité informatique gérés (MSSP) ou un système de gestion des informations et des événements de sécurité (SIEM).

La surveillance continue est préférable, mais les fichiers journaux peuvent également être audités périodiquement. Toutefois, la période entre deux audits doit être inférieure à un mois pour permettre une détection rapide des attaques.

En plus de vérifier les requêtes enregistrées dans les fichiers journaux, les audits doivent contrôler périodiquement les paramètres DNS. Les modifications effectuées depuis le dernier audit doivent être examinées afin de vérifier leur autorisation et leur exactitude, et les paramètres les plus anciens doivent être régulièrement réévalués pour s’assurer qu’ils restent exacts.

Protéger l’accès au DNS

Une fois le protocole et les serveurs renforcés, l’équipe de sécurité doit surveiller les services actifs du protocole et protéger le serveur contre les modifications malveillantes.

Inspection du trafic DNS

L’inspection du trafic DNS à l’aide de pare-feu de nouvelle génération (NGFW), de pare-feu DNS, de services de protection contre les intrusions (IPS) et de la détection des anomalies peut servir à se protéger contre le tunneling DNS et à bloquer les requêtes DNS malformées utilisées dans les attaques DDoS. La protection DNS peut également être intégrée à d’autres offres de sécurité, comme le secure service edge (SSE), le secure access service edge (SASE) ou les solutions de zero trust network access (ZTNA).

L’adoption généralisée des algorithmes d’intelligence artificielle (IA) et d’apprentissage automatique (ML) dans les solutions de sécurité avancées peut améliorer la détection des anomalies. Des événements tels que des transferts de données ou un nombre excessif de requêtes provenant d’une source donnée peuvent déclencher des actions automatisées et proactives pour bloquer les attaques potentielles plus rapidement qu’une équipe composée uniquement d’humains.

Filtrage DNS

Le filtrage DNS examine les URL demandées par les utilisateurs et les URL qui transmettent des données via le DNS. Les URL connues comme malveillantes sont bloquées et les URL suspectes sont mises en quarantaine. Le filtrage DNS est souvent intégré aux mêmes outils que ceux qui assurent l’inspection du trafic DNS, ainsi qu’aux passerelles web sécurisées (SWG) ou aux services de sécurité DNS tels que ceux de Cloudflare, Cisco Umbrella, Palo Alto DNS Security et NS1.

Contrôle des accès DNS

Le contrôle des accès DNS doit être mis en œuvre de manière stricte, limité aux administrateurs de confiance et protégé contre les accès et modifications non autorisés. Les serveurs peuvent être protégés en autorisant uniquement certains utilisateurs et appareils de confiance, grâce à la gestion des accès à privilèges (PAM) et à l’authentification multifacteur (MFA).

Les méthodes MFA doivent être sélectionnées avec soin. Les SMS ne doivent pas être utilisés, car ils sont trop vulnérables à l’interception, à l’usurpation et aux attaques par échange de carte SIM. Une meilleure sécurité repose sur des applications d’authentification, des clés de sécurité ou des cartes d’identité.

Une MFA renforcée permet également de :

Limiter l’accès à des appareils spécifiques à l’aide de certificats ou d’adresses MAC autorisées.
Limiter l’accès à des réseaux spécifiques à l’aide d’adresses IP autorisées.
Limiter l’accès à des groupes ou à des utilisateurs grâce à des utilisateurs ou groupes autorisés.

Conseils pour prévenir les attaques contre les serveurs DNS

Il est facile d’exiger l’application de bonnes pratiques, mais plus difficile de les mettre en œuvre — en particulier pour les serveurs DNS, qui peuvent être déployés de nombreuses façons. La sécurité se complique encore en raison des besoins différents des divers composants DNS :

Les serveurs DNS faisant autorité contiennent les informations DNS de l’organisation (associations entre noms de domaine et adresses IP) ; ils sont généralement hébergés par le bureau d’enregistrement du domaine de l’organisation, mais peuvent être gérés par celle-ci.
Les résolveurs DNS externes recherchent les domaines et adresses externes (internet) ; ils sont généralement hébergés par un fournisseur d’accès à internet (FAI) ou un résolveur DNS public (Google, Cloudflare, etc.), mais peuvent également être gérés par l’organisation.
Les résolveurs DNS internes recherchent les ressources du réseau interne local (imprimantes, baies de stockage accessibles sur le réseau (NAS), etc.) ; ils sont généralement hébergés et gérés localement sur un serveur.

Pour fournir des conseils adaptés à un large éventail de besoins, nous répartissons les détails dans les catégories suivantes :

Conseils de prévention pour tous les serveurs DNS
Conseils de prévention pour les serveurs DNS internes (résolveurs)
Conseils de prévention pour les serveurs DNS hébergés (faisant autorité et résolveurs)
Conseils de prévention pour les serveurs des bureaux d’enregistrement de noms de domaine (serveurs DNS faisant autorité)

Conseils de prévention pour tous les serveurs DNS

Seules les grandes organisations gèrent leurs propres serveurs DNS faisant autorité, mais il est très courant que les organisations de toutes tailles gèrent des résolveurs DNS internes dans chaque bureau régional afin d’améliorer la vitesse de résolution DNS. Quelle que soit l’architecture mise en œuvre, toutes les organisations doivent appliquer les protections supplémentaires suivantes aux serveurs DNS :

Sauvegarder les informations du serveur DNS ou mettre en œuvre des solutions de reprise après sinistre comme pour toute autre donnée critique :
- Utiliser l’automatisation pour éviter les erreurs humaines.
- Effectuer des sauvegardes relativement fréquentes (quotidiennes ou au moins hebdomadaires).
- Conserver des sauvegardes locales pour un accès rapide.
- Conserver des sauvegardes dans le cloud en cas de défaillance locale.
- Conserver des sauvegardes hors ligne pour empêcher leur suppression.
L’isolation des services renforce davantage la bonne pratique de l’isolation des serveurs en séparant le service DNS faisant autorité des services de résolution DNS ou des services récursifs ; la séparation des services simplifie la sécurité et permet de renforcer davantage le DNS.
La résilience des services évite un point de défaillance unique en exécutant des serveurs redondants ou des services DNS de secours en cas de panne.

Les organisations plus petites et plus ciblées ne veulent pas s’encombrer de la gestion et de la surveillance des différentes attaques DNS. Elles tenteront d’externaliser autant de fonctions DNS que possible auprès de fournisseurs de services managés (MSP) ou de fournisseurs de solutions de serveurs DNS tels que Cisco Umbrella, Cloudflare DNS, Google Cloud DNS ou F5 Distributed Cloud DNS.

Cependant, même lorsque de nombreux aspects sont externalisés, l’organisation assume la responsabilité finale de vérifier toutes les fonctions de service conformément aux termes de l’accord et de satisfaire à toutes les exigences de sécurité et de conformité. Les grandes organisations peuvent effectuer des audits, et toutes les organisations peuvent demander la confirmation que le fournisseur de services a réalisé et réussi des tests d’intrusion ou des audits de sécurité.

Conseils de prévention pour les serveurs DNS internes

Tous les réseaux, sauf les plus simples, doivent faire fonctionner des serveurs DNS internes pour gérer l’accès aux appareils réseau tels que les imprimantes, les NAS et les autres ressources réseau. Ces serveurs DNS internes doivent être configurés séparément dans chaque bureau régional et peuvent nécessiter un certain niveau de gestion locale pour prendre en charge les modifications des ressources du réseau local.

De nombreuses organisations négligent d’appliquer les bonnes pratiques sur les réseaux locaux considérés comme sûrs. Cependant, l’augmentation du volume des cyberattaques rend ces hypothèses extrêmement risquées et parfois coûteuses. Même les serveurs DNS internes doivent respecter les bonnes pratiques afin d’empêcher un appareil compromis d’intercepter le trafic DNS ou d’exploiter des serveurs locaux mal protégés.

En plus des bonnes pratiques, les serveurs DNS locaux doivent définir explicitement des résolveurs DNS ou services DNS externes spécifiques et les inscrire sur une liste d’autorisation. Les communications entre les serveurs DNS locaux et externes doivent être chiffrées et surveillées.

Conseils de prévention pour les serveurs DNS hébergés

Certaines grandes organisations souhaitent conserver le contrôle de fonctions DNS entièrement autogérées. Cependant, les fournisseurs de services managés (MSP) et les FAI gèrent également les services DNS de certains de leurs clients. Dans les deux cas, l’hébergement de services DNS nécessite une architecture robuste, une configuration sécurisée et des couches de protection supplémentaires.

Architecture sécurisée des serveurs DNS

Une conception soigneuse de l’architecture des serveurs peut réduire les risques et améliorer les performances face aux nombreux types d’attaques DNS.

La résilience après sinistre des serveurs DNS nécessite la redondance des serveurs locaux ainsi que des résolveurs DNS primaires et secondaires, afin de se protéger contre les défaillances des appareils ou des processus.

La planification de la capacité résiste aux attaques DDoS en spécifiant des exigences de capacité nettement supérieures au trafic attendu, en utilisant des équilibreurs de charge et en mettant en œuvre une limitation du débit des réponses.

Restreindre l’utilisation des résolveurs aux utilisateurs des réseaux desservis (réseau interne, au sein du FAI, etc.) afin d’empêcher les pirates d’empoisonner leur cache. Les pirates ciblent les résolveurs exposés à internet, ou résolveurs ouverts, qui peuvent être détectés à l’aide de l’outil en ligne de Measurement Factory.

Masquer le serveur DNS primaire de l’accès public grâce à l’isolation du réseau et à la configuration du pare-feu. Les serveurs DNS internes ou accessibles au public doivent être des appareils esclaves qui ne peuvent être mis à jour que par le serveur DNS maître masqué, ce qui transforme les serveurs visibles en appareils en lecture seule pour les attaquants.

Centraliser les fonctions DNS externes afin de permettre une gestion plus sécurisée et plus efficace. De nombreux éléments de configuration sont de petits détails dont le déploiement peut être fastidieux dans de nombreuses implémentations différentes. Même si le DNS local doit parfois être géré localement, tous les serveurs peuvent être reliés à une fonction DNS inscrite sur une liste d’autorisation et gérée de manière centralisée pour effectuer les recherches externes. Dans les environnements géographiquement dispersés, les serveurs peuvent également devoir être répartis, mais ils peuvent toujours être gérés à distance par une équipe centralisée afin de réduire les écarts, les lacunes et les instances obsolètes.

Configuration sécurisée des serveurs DNS

Pour protéger correctement les fonctions DNS, le protocole DNS et l’hôte doivent être configurés pour assurer résilience et sécurité. Ces détails peuvent être mis en œuvre pour améliorer encore les bonnes pratiques de contrôle des accès et contrer certains types d’attaques.

La configuration du contrôle des accès améliore la sécurité générale du contrôle des accès en définissant explicitement les adresses IP des résolveurs DNS primaires et secondaires afin d’empêcher le détournement, l’usurpation et l’empoisonnement du cache. La définition explicite des accès peut également contribuer à déclencher des alertes pour les systèmes de surveillance et la détection des anomalies. Voici quelques exemples de contrôles des accès configurés spécifiquement :

Autoriser uniquement certaines adresses IP et adresses MAC d’appareils pour l’architecture DNS maître-esclave, les serveurs DNS primaires et les serveurs DNS redondants.
Limiter explicitement les transferts de zone DNS à certains serveurs afin d’empêcher les transferts de zone non autorisés permettant de connaître les appareils et l’architecture du réseau interne.
Les règles de pare-feu peuvent être configurées pour bloquer le trafic DNS sortant sauf vers les résolveurs DNS autorisés et inscrits sur une liste d’autorisation.

La configuration anti-empoisonnement du cache intégrée aux logiciels DNS et aux options des serveurs peut compliquer l’insertion par un pirate d’une réponse falsifiée dans le cache. Les options de configuration comprennent :

Verrouiller le cache DNS stocké sur un serveur DNS en définissant et en appliquant une durée de vie (TTL) clairement définie, afin d’empêcher son écrasement par un attaquant.
Randomiser le port source des requêtes DNS en utilisant un pool de sockets au lieu d’utiliser systématiquement le port UDP 53 ; certains systèmes d’exploitation prennent cette option en charge par défaut.
Randomiser l’identifiant de requête afin qu’un attaquant ne puisse pas usurper le numéro suivant d’une séquence.
Randomiser la casse des lettres des noms de domaine envoyés pour être résolus ; les serveurs de noms traitent example.com et ExaMPle.com de manière identique pour la résolution, mais répondent en utilisant la même casse que la requête d’origine.

Les configurations anti-DDoS peuvent renforcer l’architecture des serveurs afin de protéger le DNS contre les attaques DDoS. Voici quelques configurations détaillées à envisager :

Rejeter les requêtes qui ne sont pas DNS vers le port UDP 53 (ou vers le port DNS actuel en cas d’utilisation d’un pool de sockets.
Rejeter les requêtes DNS abusives correspondant à des structures de noms de domaine complets (FQDN) ou à des types d’enregistrements mal formés, ainsi que les requêtes DNS ANY.
Apprendre les FQDN demandés afin d’empêcher les sous-domaines pseudo-aléatoires falsifiés.
Limiter le nombre total de requêtes adressées au serveur DNS protégé.
Limiter les temps de réponse des requêtes DNS afin d’empêcher les attaques DDoS provenant de la même source.
Limiter les débits auxquels les requêtes sont acceptées (ce qui peut limiter les attaques DDoS) ou les données transmises (ce qui peut limiter les attaques par tunneling) vers une même adresse IP.
Suivre les réponses NXDomain des demandeurs et définir un seuil maximal.

Sécurité DNS supplémentaire

Un serveur DNS soigneusement conçu et renforcé reste vulnérable aux attaques externes, même si le risque est réduit. Pour réduire davantage ce risque, des solutions de sécurité DNS externes peuvent ajouter des couches de protection.

services d’atténuation des attaques DDoS surveillent le trafic, peuvent fournir une bande passante supplémentaire et bloquent de nombreux types d’attaques DDoS.

Les services de filtrage et de sécurité DNS dans le cloud tels que Cisco Umbrella, Palo Alto DNS Security et NS1 protègent le processus DNS en suivant et en bloquant les sources malveillantes connues. Le filtrage peut également être étendu pour bloquer les sites inutiles, comme les sites de jeux d’argent ou ceux qui hébergent du contenu pour adultes.

Conseils de prévention pour les DNS gérés par un bureau d’enregistrement de noms de domaine

Pour les serveurs de noms de domaine faisant autorité gérés par un bureau d’enregistrement ou un autre tiers, les fonctionnalités suivantes, lorsqu’elles sont proposées, peuvent contribuer à garantir la sécurité de vos enregistrements DNS :

Le verrouillage des modifications DNS propose des processus de sécurité spécifiques, comme l’appel à un numéro donné pour vérifier l’identité d’une personne désignée de l’organisation avant toute modification des informations DNS.
La connexion dépendante de l’adresse IP définit une adresse IP unique ou une plage d’adresses IP pour la connexion afin de limiter l’accès des pirates externes ; conseil : utilisez plusieurs adresses IP pour éviter un point de défaillance unique en cas de panne d’un réseau ou d’un appareil.

Comment prévenir chaque type d’attaque DNS

Pour comprendre pleinement pourquoi plusieurs couches de protection sont nécessaires pour protéger le DNS, nous répertorions 14 attaques DNS distinctes, leur fonctionnement, la possibilité de les détecter et les moyens de s’en protéger.

Balayage DNS

Le balayage DNS est un type d’attaque par tunneling DNS qui fait fonctionner des botnets via le port 53 ou via du trafic DNS chiffré (HTTPS, TLS, etc.). Ce type d’attaque peut principalement être détecté par l’inspection des paquets ou l’analyse des anomalies. Pour éliminer une attaque, il peut être nécessaire de mettre l’URL de commande sur liste noire et d’éliminer l’infection du botnet sur les terminaux.

Empoisonnement du cache DNS

L’empoisonnement du cache DNS pirate un serveur DNS local ou un résolveur DNS afin de remplacer des adresses IP dans le cache. Ce type d’attaque remplace l’adresse IP de sites web légitimes par des adresses IP malveillantes, qui peuvent ensuite être transmises aux utilisateurs lors de futures requêtes DNS.

Les attaquants peuvent manipuler directement le cache, mais une autre technique consiste à envoyer une fausse « réponse » DNS avec une adresse IP source usurpée. Cette technique tente de se faire passer pour la réponse du résolveur DNS à une demande d’informations provenant du serveur DNS.

Les serveurs qui n’utilisent pas de techniques permettant de détecter ce type d’attaque stockeront simplement la fausse réponse pour les futures requêtes DNS, en tant que réponse faisant autorité. Une fois empoisonné, le cache fournira les fausses informations pour toute demande ultérieure, jusqu’à leur expiration.

L’empoisonnement du cache DNS peut être détecté et contré par :

DNSSEC
Le verrouillage du cache DNS
La manipulation de la casse des requêtes DNS
Des contrôles d’accès stricts

Les réseaux internes touchés par un empoisonnement du cache DNS devront être réinitialisés afin que les informations DNS empoisonnées ne se propagent pas.

Attaque DDoS par verrouillage de domaine DNS

Les attaques DNS par verrouillage de domaine, de type déni de service distribué (DDoS), submergent les serveurs DNS légitimes en créant des connexions TCP, puis en envoyant lentement des paquets aléatoires afin de consommer les ressources. Il s’agit d’une technique DDoS courante, mais toutes les équipes ne préparent pas activement le DNS contre les attaques DDoS.

Les attaques DDoS peuvent être contrées en renforçant les serveurs DNS contre les attaques DDoS, en utilisant des services anti-DDoS (Cloudflare, etc.) et des pare-feu DNS.

Attaque DDoS par inondation DNS

Les attaques DDoS par inondation DNS submergent un serveur DNS de requêtes DNS utilisant le protocole UDP, en très grand nombre. La plupart du temps, les attaques DDoS touchent principalement l’organisation victime, mais les services et entreprises associés peuvent également être affectés.

Les attaques par inondation peuvent également être menées au sein d’un réseau à l’aide d’équipements des locaux du client (CPE) compromis. Cette forme d’attaque DDoS par inondation DNS peut être appelée attaque CPE basée sur un botnet.

Les attaques DDoS par inondation DNS peuvent être contrées en renforçant les serveurs DNS contre les attaques DDoS, en utilisant des services anti-DDoS (Cloudflare, etc.) et des pare-feu DNS.

Interception DNS

L’interception DNS capture une requête DNS et redirige la demande vers une ressource malveillante qui redirigera les utilisateurs vers des sites web malveillants. Le plus souvent, ce type d’attaque est mené par le biais d’attaques par hameçonnage sur un terminal, où la requête DNS de l’URL ou de l’adresse IP figurant dans l’e-mail d’hameçonnage est redirigée vers un serveur DNS malveillant.

Ce type d’attaque nécessite généralement une détection sur le terminal ou par l’intermédiaire de la sécurité de la messagerie, car il peut contourner la surveillance centralisée — en particulier pour les utilisateurs distants. Les solutions qui redirigent les requêtes des terminaux distants, telles que DNSCrypt, le secure service edge (SSE), les passerelles web sécurisées (SWG), l’accès réseau zero trust (ZTNA) et le secure access service edge (SASE), peuvent également empêcher cette attaque si le DNS est contraint de passer par une surveillance et un traitement centralisés pour tous les utilisateurs et appareils.

Détournement DNS

Le détournement DNS redirige les requêtes vers des sites malveillants au moyen de logiciels malveillants, d’un serveur DNS compromis ou d’équipements réseau compromis (routeurs, etc.), en remplaçant les informations de l’enregistrement DNS. Ces attaques fonctionnent de la même manière que l’empoisonnement du cache DNS, mais compromettent directement les enregistrements DNS ou le serveur de noms DNS faisant autorité, au lieu de ne compromettre que le cache.

Les attaquants accèdent au serveur en volant des identifiants ou en compromettant des appareils qui contiennent des informations DNS. Les serveurs DNS sont souvent exposés aux attaques parce qu’ils sont directement exposés à internet, et les équipements réseau sont parfois exposés à internet pour l’accès administrateur ou par l’intermédiaire de terminaux réseau compromis (hameçonnage, identifiants volés, serveurs VPN compromis, etc.).

La forme la plus grave du détournement DNS compromet les enregistrements DNS faisant autorité auprès du bureau d’enregistrement du nom de domaine et transforme l’URL d’une organisation en redirection vers une adresse IP malveillante. Cette attaque aggrave les difficultés liées au détournement DNS en pouvant ajouter le domaine de l’organisation aux listes noires de nombreux produits antivirus et flux de renseignement sur les menaces.

Ces types d’attaques peuvent être détectés ou contrés par la surveillance des fichiers journaux, les systèmes de détection ou de protection contre les intrusions (IDS ou IPS), l’inspection des paquets par un pare-feu de nouvelle génération (NGFW), la détection des anomalies et des contrôles d’accès stricts. La compromission du bureau d’enregistrement du nom de domaine DNS peut être impossible à détecter ; elle doit donc être contrée par des contrôles d’accès stricts et une authentification multifacteur.

Attaque DDoS par requêtes DNS malformées

Les attaques DDoS par requêtes DNS malformées submergent un serveur DNS de requêtes intentionnellement mal configurées afin d’augmenter les ressources nécessaires au serveur DNS pour les traiter. Lorsqu’elles sont transmises en grand nombre, ces requêtes peuvent saturer les ressources de traitement et arrêter un serveur DNS.

Les attaques DDoS peuvent être contrées en renforçant les serveurs DNS contre les attaques DDoS, en utilisant des services anti-DDoS (Cloudflare, etc.) et des pare-feu DNS.

Attaque DDoS DNS NXDOMAIN

Les attaques DDoS DNS NXDOMAIN (domaine inexistant) submergent un serveur DNS de requêtes portant sur des enregistrements inexistants ou de faux noms de domaine. Le serveur DNS établit des connexions avec les résolveurs DNS et le client à l’origine de la requête, ce qui consomme les ressources au point d’empêcher le traitement des requêtes DNS légitimes. Les attaques DDoS peuvent être contrées en renforçant les serveurs DNS contre les attaques DDoS, en utilisant des services anti-DDoS (Cloudflare, etc.) et des pare-feu DNS.

Attaque DDoS par domaine fantôme DNS

Les attaques DDoS par domaine fantôme DNS submergent un serveur DNS de requêtes visant à se connecter à des serveurs de domaine inexistants ou répondant lentement. Les attaques DDoS peuvent être contrées en renforçant les serveurs DNS contre les attaques DDoS, en utilisant des services anti-DDoS (Cloudflare, etc.) et des pare-feu DNS.

Attaques DDoS par réflexion-amplification DNS

Les attaques DDoS par réflexion-amplification DNS utilisent des bots pour envoyer des requêtes DNS avec des adresses IP usurpées, en utilisant l’adresse IP de la victime, afin que la réponse DNS soit envoyée de manière à submerger la ressource associée à cette adresse IP usurpée. Les attaques DDoS DNS cherchent à bloquer l’accès général des utilisateurs à internet. Les attaques DDoS par réflexion-amplification DNS peuvent être contrées en renforçant les serveurs DNS contre les attaques DDoS, en utilisant des services anti-DDoS (Cloudflare, etc.) et des pare-feu DNS.

Usurpation DNS

L’usurpation DNS introduit de fausses adresses IP DNS dans un cache DNS, soit par empoisonnement du cache DNS, soit en se faisant passer pour un serveur DNS légitime ; cette technique est similaire au détournement DNS, mais cible le cache et non l’enregistrement DNS lui-même.

L’usurpation DNS peut être détectée et contrée par la surveillance du serveur DNS et le renforcement du serveur contre les falsifications (contrôle des accès, listes d’autorisation et de refus, etc.). Des services ou protocoles tels que DNSSEC, qui vérifient l’authenticité des réponses DNS, peuvent également contrer l’usurpation.

Attaque DDoS par sous-domaine DNS

Les attaques DDoS par sous-domaine DNS submergent un serveur DNS de requêtes portant sur des sous-domaines d’URL inexistants (EX. : idonotexist.esecurityplanet.com, esecurityplanet.com/idonotexist/). Les attaques DDoS peuvent être contrées en renforçant les serveurs DNS contre les attaques DDoS, en utilisant des services anti-DDoS (Cloudflare, etc.) et des pare-feu DNS.

Tunneling DNS

Le tunneling DNS n’attaque pas le processus DNS, mais utilise plutôt le trafic DNS comme camouflage pour transmettre des logiciels malveillants aux utilisateurs, exécuter des commandes ou exfiltrer des données. Par défaut, la plupart des pare-feu et des serveurs font confiance aux communications DNS sur le port 53, et les attaquants peuvent en profiter pour dissimuler leurs actions. Dans certains cas, les attaquants utilisent également des requêtes DNS chiffrées sur les protocoles SSH, TCP ou HTTP afin de mieux dissimuler leurs actions.

Le tunneling DNS peut être détecté et bloqué en inspectant le trafic DNS, en contrôlant strictement l’accès au serveur DNS et en surveillant l’adresse IP ou le domaine auquel les informations DNS sont envoyées. Si des journaux sont utilisés pour détecter les attaques par tunneling, recherchez de nombreuses paires de requêtes et de réponses provenant de domaines complexes ou suspects, ainsi qu’un nombre de requêtes bien supérieur à la normale.

Interception DNS non chiffrée

Contrairement à d’autres attaques, l’interception d’informations DNS non chiffrées n’est généralement pas utilisée pour compromettre, contrôler ou refuser l’accès aux processus DNS ou aux équipements réseau. Les attaquants se contentent plutôt d’intercepter les requêtes DNS envoyées par défaut en texte clair afin de suivre et de surveiller les demandes d’accès à internet.

Les informations volées peuvent être utilisées pour recueillir des renseignements en vue d’attaques futures et sont presque impossibles à détecter, car elles n’ont aucun impact sur les systèmes ou les processus. Ce type d’attaque ne peut être neutralisé qu’en adoptant un protocole de requêtes DNS chiffrées.

En résumé : protéger les opérations de l’entreprise en protégeant le DNS

Sans DNS, les utilisateurs ne peuvent pas localiser les imprimantes réseau, accéder aux applications SaaS ou se connecter aux ressources internet. Pour de nombreuses organisations, une défaillance du DNS entraînera la panne de l’ensemble des systèmes informatiques de l’organisation, ce qui peut engendrer des pertes commerciales et des coûts de reprise importants.

Qu’elle utilise des services DNS externalisés, un résolveur DNS interne limité ou une architecture DNS robuste à plusieurs fonctions, une organisation doit reconnaître le DNS comme une ressource essentielle à sa mission et régulièrement attaquée. Pour garantir des fonctions DNS sécurisées et opérationnelles, chaque organisation devrait au minimum appliquer les bonnes pratiques et, si possible, mettre en place une sécurité encore plus rigoureuse pour ce service informatique critique.

Pour plus d’informations sur des sujets connexes liés à la sécurité, consultez :

Cet article a été initialement rédigé par Paul Rubens et publié le Chad Kime le 8 décembre 2023.