Résumé
Résumé
Le 19 mai 2020, Microsoft a publié l’avis de sécurité ADV200009. Cet avis décrit une attaque d’amplification DNS qui a été identifiée par des chercheurs israéliens. L’attaque, connue sous le nom de NXNSAttack, peut cibler n’importe quel serveur DNS, y compris les serveurs Microsoft DNS et BIND faisant autorité pour une zone DNS.
Pour les serveurs DNS qui résident sur des intranets d’entreprise, Microsoft évalue le risque de cette vulnérabilité comme étant faible. Cependant, les serveurs DNS qui résident sur les réseaux de périmètre sont vulnérables à NXNSAttack. Les serveurs DNS pré-Windows Server 2016 qui résident sur les réseaux de périmètre doivent être mis à niveau vers Windows Server 2016 ou des versions ultérieures prenant en charge la limite de taux de réponse (Response Rate Limit, RRL). La RRL réduit l’effet d’amplification lorsqu’un résolveur DNS ciblé interroge vos serveurs DNS.
Symptômes
Lorsqu’une attaque d’amplification DNS est lancée, vous pouvez observer un ou plusieurs des symptômes suivants sur un serveur affecté :
-
L’utilisation du processeur pour DNS est élevée.
-
Les temps de réponse DNS augmentent et les réponses peuvent cesser.
-
Un nombre inattendu de réponses NXDOMAIN sont générées par votre serveur d’authentification.
Présentation de l’attaque
Les serveurs DNS ont toujours été vulnérables à un large éventail d’attaques. Pour cette raison, les serveurs DNS sont généralement placés derrière des équilibreurs de charge et des pare-feux dans une zone démilitarisée.
Pour exploiter cette vulnérabilité, un attaquant devrait avoir plusieurs clients DNS. Typiquement, cela comprendrait un botnet, l’accès à des dizaines ou des centaines de résolveurs DNS qui sont capables d’amplifier l’attaque, et un service de serveur DNS spécialisé dans les attaques.
La clé de l’attaque est le serveur DNS attaquant spécialement conçu et qui fait autorité pour un domaine que l’attaquant possède. Pour que l’attaque soit réussie, les résolveurs DNS doivent savoir comment atteindre le domaine de l’attaquant et le serveur DNS. Cette combinaison peut générer beaucoup de communication entre les résolveurs récursifs et le serveur DNS de la victime faisant autorité. Le résultat est une attaque DDoS.
Vulnérabilité pour MS DNS sur les intranets d’entreprise
Les domaines internes et privés ne sont pas résolvables par l’intermédiaire d’indications de racine et de serveurs DNS de domaine de haut niveau. Lorsque vous suivez les meilleures pratiques, les serveurs DNS qui font autorité pour les domaines privés et internes, tels que les domaines Active Directory, ne sont pas accessibles à partir d’Internet.
Même si une attaque NXNSAttack d’un domaine interne à partir du réseau interne est techniquement possible, il faudrait que le réseau interne soit compromis par un utilisateur malveillant avec un accès de niveau administrateur, et qu’il configure des serveurs DNS internes pour pointer vers les serveurs DNS du domaine de l’attaquant. Cet utilisateur doit également être en mesure de créer une zone malveillante sur le réseau et de mettre un serveur DNS spécial qui serait capable d’effectuer l’attaque NXNSAttack sur le réseau d’entreprise. Un utilisateur qui dispose de ce niveau d’accès préfèrera généralement la furtivité plutôt que d’annoncer sa présence en lançant une attaque DNS DDoS très visible.
Vulnérabilité pour des DNS MS de périmètre
Un résolveur DNS sur Internet utilise des indications de racine et des serveurs de domaines de premier niveau (TLD) pour résoudre les domaines DNS inconnus. Un attaquant peut utiliser ce système DNS public pour utiliser n’importe quel résolveur DNS via Internet pour essayer l’amplification NXNSAttack. Après la découverte d’un vecteur d’amplification, il peut être utilisé dans le cadre d’une attaque par déni de service (DDoS) contre tout serveur DNS hébergeant un domaine DNS public (le domaine victime).
Un serveur DNS de périmètre qui agit comme un résolveur ou un redirecteur peut être utilisé comme vecteur d’amplification pour l’attaque si les requêtes DNS entrantes non sollicitées qui proviennent d’Internet sont autorisées. L’accès public permet à un client DNS malveillant d’utiliser le résolveur dans le cadre de l’attaque d’amplification globale.
Les serveurs DNS faisant autorité pour les domaines publics doivent permettre le trafic DNS entrant non sollicité à partir de résolveurs effectuant des recherches récursives à partir de l’infrastructure d’indications de racine et DNS TLD. Dans le cas contraire, l’accès au domaine échoue. De ce fait, tous les serveurs DNS du domaine public faisant autorité sont des victimes potentielles d’une attaque NXNSAttack. Les serveurs Microsoft DNS de périmètre doivent exécuter Windows Server 2016 ou une version ultérieure pour obtenir un support RRL.
Résolution
Pour résoudre ce problème, utilisez la méthode suivante pour le type de serveur approprié.
Pour les serveurs MS DNS via intranet
Le risque de cette vulnérabilité est faible. Surveillez les serveurs DNS internes pour détecter tout trafic inhabituel. Désactivez les NXNSAttackers internes qui résident sur votre intranet d’entreprise au fur et à mesure qu’ils sont découverts.
Pour les serveurs DNS de périmètre faisant autorité
Activez la RRL prise en charge par Windows Server 2016 et les versions ultérieures de Microsoft DNS. L’utilisation de la RRL sur les résolveurs DNS minimise l’amplification initiale de l’attaque. L’utilisation de la RRL sur un serveur DNS faisant autorité dans le domaine public réduit toute amplification qui est reflétée vers le résolveur DNS. Par défaut, la RRL est désactivée. Pour plus d’informations relatives à la RRL, consultez les articles suivants :
|
Exécutez le cmdlet PowerShell SetDNSServerResponseRateLimiting pour activer la RRL en utilisant des valeurs par défaut. Si l’activation de la RRL provoque l’échec des requêtes DNS légitimes parce qu’elles sont limitées trop strictement, augmentez progressivement les valeurs des paramètres Response/Sec et Errors/Sec seulement jusqu’à ce que le serveur DNS réponde aux requêtes qui échouaient précédemment.
D’autres paramètres peuvent également aider les administrateurs à mieux gérer les paramètres RRL. Ces paramètres comprennent des exceptions RRL.
Pour plus d'informations, voir l'article Microsoft Docs suivant :
Forum aux questions
Q1 : L’atténuation qui est résumée ici s’applique-t-elle à toutes les versions de Windows Server ?
R1 : Non. Ces informations ne s’appliquent pas à Windows Server 2012 ou 2012 R2. Ces versions héritées de Windows Server ne prennent pas en charge la fonctionnalité RRL qui réduit l’effet d’amplification lorsqu’un résolveur DNS ciblé interroge vos serveurs DNS.
Q2 : Que doivent faire les clients s’ils ont des serveurs DNS qui résident sur les réseaux de périmètre et qui exécutent soit Windows Server 2012, soit Windows Server 2012 R2 ?
R2 : Les serveurs DNS qui résident sur les réseaux de périmètre qui exécutent soit Windows Server 2012 ou Windows Server 2012 R2 devraient être mis à niveau vers Windows Server 2016 ou les versions ultérieures prenant en charge la RRL. La RRL réduit l’effet d’amplification lorsqu’un résolveur DNS ciblé interroge vos serveurs DNS.
Q3 : Comment déterminer si la RRL entraîne l’échec de requêtes DNS légitimes ?
R3 : Si la RRL est configurée en mode LogOnly, le serveur DNS effectue tous les calculs RRL. Cependant, au lieu de prendre des mesures préventives (telles que l’abandon ou la troncation des réponses), le serveur enregistre plutôt les actions potentielles comme si la RRL était activée, puis continue à fournir les réponses habituelles.
