Attaque par amplification DNS : défense côté source et côté cible

Les attaques par amplification DNS comptent parmi les vecteurs volumétriques les plus courants, et elles présentent une caractéristique qui les distingue de la plupart des autres : un même réseau peut être à la fois la cible et l’arme. L’attaquant n’envoie pas le trafic directement à la victime : il se sert pour cela des serveurs DNS d’autrui, en multipliant le volume au passage.

Cet article traite les deux faces du problème : comment ne pas devenir la source d’une telle attaque, et comment limiter les dégâts lorsque votre propre réseau en est la cible.

Le mécanisme d’une attaque par amplification DNS en trois phrases

L’attaquant envoie une requête DNS avec une adresse source usurpée, en y substituant l’adresse de la victime. Le serveur DNS, qui n’a aucun moyen de vérifier l’expéditeur, renvoie la réponse à cette adresse. Comme la réponse peut être plusieurs fois plus volumineuse que la requête, et comme l’attaquant arrose simultanément des milliers de serveurs, la victime reçoit un trafic sans commune mesure avec ce que l’attaquant a dû envoyer.

Deux conclusions pratiques en découlent. D’abord, le trafic atteint la victime depuis un très grand nombre d’adresses authentiques, non usurpées : ce sont de vrais serveurs DNS, pas des bots. Ensuite, l’attaque n’est possible que parce que, quelque part sur le chemin, un acteur a permis l’usurpation de l’adresse source, et un autre a exposé un serveur qui répond à des inconnus.

Première partie : ne pas être la source

C’est la partie que l’on oublie facilement, parce que le problème ne pénalise pas votre propre réseau. Et pourtant : un résolveur ouvert dans votre espace d’adressage signifie que le réseau participe à des attaques contre des tiers, génère du trafic sortant, charge vos propres liens et finit dans des rapports sur les menaces, d’où il revient sous forme de restrictions imposées par les fournisseurs de transit.

Détecter les résolveurs ouverts

Le plus simple consiste à scanner vos propres préfixes à la recherche de serveurs qui répondent à des requêtes récursives venant de l’extérieur. Une requête de test envoyée depuis l’extérieur du réseau doit être refusée ; si une réponse valide revient, le résolveur est ouvert :

dig @<server-address> +short example.com A

Si vous fournissez des services d’accès, répétez le même test sur l’espace d’adressage de vos clients : les résolveurs ouverts sur les routeurs des abonnés sont bien plus fréquents que sur les serveurs des opérateurs.

Restreindre la récursion

Un serveur récursif ne doit répondre qu’à ses propres utilisateurs, et un serveur faisant autorité ne doit fournir aucune récursion. Dans BIND, les deux rôles sont séparés explicitement :

acl "trusted" { 10.0.0.0/8; 192.0.2.0/24; localhost; };

options {
    recursion yes;
    allow-recursion { trusted; };
    allow-query-cache { trusted; };
    additional-from-cache no;
};

Si le serveur fait autorité, définissez recursion no; et ne laissez allow-query { any; }; que pour les zones qu’il sert réellement.

Limiter le débit des réponses

Un serveur faisant autorité qui ne peut pas être fermé au reste du monde se protège par la limitation du débit des réponses (Response Rate Limiting). Ce mécanisme détecte les requêtes répétitives et identiques provenant d’une même plage et commence à omettre ou à tronquer une partie des réponses, ce qui retire tout intérêt économique à l’attaque :

rate-limit {
    responses-per-second 10;
    window 5;
    slip 2;
};

Les valeurs s’ajustent au profil de trafic du serveur concerné : considérez celles ci-dessus comme un point de départ pour l’observation, et non comme une recette toute faite.

Bloquer l’usurpation d’adresse à la source

C’est la mesure la plus efficace contre toute la classe des attaques par amplification, et en même temps celle que l’on omet le plus souvent. Si un réseau n’émet pas de paquets dont l’adresse source se trouve hors de son propre espace, aucune attaque à source usurpée ne peut en partir.

En bordure côté clients, activez la validation de l’adresse source par rapport à la table de routage : en mode strict là où le trafic est unidirectionnel, en mode loose là où le routage peut être asymétrique.

Juniper:  set interfaces ge-0/0/0 unit 0 family inet rpf-check
Cisco:    ip verify unicast source reachable-via rx

Deuxième partie : être la cible

Lorsque votre adresse est la cible, la situation est différente. Le trafic arrive de vrais serveurs DNS répartis dans le monde entier, si bien que bloquer par adresse source n’a aucun sens : la liste serait sans fin, et vous couperiez au passage des serveurs dont vous dépendez réellement.

Ce qui peut être filtré

Ce vecteur se caractérise par un port source fixe, le 53, en UDP, avec des réponses volumineuses et souvent fragmentées. Cela suffit pour construire une règle de filtrage, à condition que vous n’ayez pas besoin, à ce moment-là, de recevoir des réponses DNS sur l’adresse attaquée.

Une règle BGP FlowSpec correspondant à ce motif agit sur le routeur de bordure et supprime le trafic avant qu’il n’entre dans le réseau. Dès que WanGuard détecte l’anomalie, il génère automatiquement une telle règle à partir du vecteur reconnu, et l’opérateur peut la restreindre ou l’élargir.

Ce qui ne peut pas être filtré

Mieux vaut connaître les limites de cette méthode pour ne pas nourrir de fausses attentes. Si l’attaque utilise des ports source aléatoires ou mélange plusieurs vecteurs à la fois, les critères de correspondance cessent d’être disjoints et le filtrage commence à capturer du trafic légitime. Dans ce cas, il reste la limitation de débit sur le motif, ou la coupure de l’adresse par un blackhole.

La fragmentation pose le même problème : les fragments non initiaux ne portent pas d’en-têtes de couche 4, si bien qu’une règle portant sur le port source ne les couvrira pas. Ils doivent être traités séparément.

Le blackholing en dernier recours

Lorsque le volume menace les liens, la seule issue est de couper le trafic destiné à l’adresse attaquée. Le blackholing met fin à l’attaque au prix de cette seule adresse, et protège le reste du réseau. Pour qu’il fonctionne correctement, sans charger la console ni le routeur, la route discard doit être configurée convenablement ; nous traitons ce point dans un article distinct consacré au blackholing sécurisé.

Liste de contrôle

• Préfixes scannés à la recherche de résolveurs ouverts, y compris l’espace d’adressage des abonnés.
• Les serveurs récursifs ne répondent qu’à leurs propres utilisateurs.
• La récursion est désactivée sur les serveurs faisant autorité.
• La limitation du débit des réponses est activée sur les serveurs exposés publiquement.
• La validation de l’adresse source est active sur les liens d’abonnés (et pas en mode strict aux frontières de transit).
• Les seuils de détection couvrent le vecteur DNS, et les règles de filtrage sont préparées avant une attaque plutôt que pendant.
• La procédure de blackholing a été testée en dehors de toute attaque.

Les recommandations sur la validation de l’adresse source s’appuient sur BCP 38 (RFC 2827) et BCP 84 (RFC 3704).