Une attaque par réflexion DNS est utilisée dans de nombreuses attaques par déni de service distribué (DDoS) pour faire tomber un tuyau Internet. L’attaque se déroule en deux étapes : l’attaquant envoie une grande quantité de requêtes à un ou plusieurs serveurs DNS légitimes tout en utilisant l’IP source usurpée de la victime cible. Le serveur DNS recevant les requêtes semi-légitimes répond à l’IP usurpée, lançant ainsi sans le savoir une attaque sur la victime cible avec des réponses à des requêtes que la victime n’a jamais envoyées.

L’internet est rempli de serveurs DNS proposés comme résolveurs ouverts qui serviront toute requête qui leur est envoyée, certains rapports citent des millions comme quantité. Ce nombre énorme rend très difficile la pré-identification de l’attaque en utilisant la réputation IP. En outre, les serveurs sont en fait des serveurs légitimes qui envoient habituellement du trafic légitime, ce qui rend tout service de réputation IP confus quant à leur nature malveillante ou non.

La plupart des requêtes DNS sont envoyées en utilisant UDP, un protocole qui ne permet pas la validation de l’IP source. C’est pourquoi le serveur DNS intermédiaire suppose que les requêtes arrivent de la victime et lui renvoie les réponses. Grâce à l’IP spoofing, il est extrêmement difficile pour le serveur victime de détecter l’attaquant, car il semble être attaqué par un serveur DNS légitime, et l’IP de l’attaquant est complètement cachée. L’usurpation d’adresse IP invalide également les services de réputation IP qui, s’ils ne sont pas écrits correctement, peuvent attribuer une mauvaise réputation à un serveur DNS légitime. Il supprime également toute tractabilité pour les attentes en matière de sécurité qui tentent d’identifier la source de l’attaque.

Un autre avantage pour l’usurpation d’identité est la possibilité d’attaquer n’importe quel serveur ou service. L’attaquant peut utiliser l’IP et le port du serveur public de la victime pour s’assurer que l’attaque est envoyée à n’importe quel service, pas seulement un service DNS. Le trafic ressemblera simplement à beaucoup de données et le serveur devra analyser et examiner les données pour s’assurer qu’il ne s’agit pas d’un trafic légitime.

Notez que l’usurpation d’IP est également une limitation de cette attaque – si l’usurpation d’IP n’est pas possible, l’attaque ne peut pas être lancée car il n’y a aucun moyen de diriger les réponses vers l’IP de la victime. C’est le cas des bots Mirai fonctionnant sur des appareils IoT derrière un routeur qui effectue un NAT. Cependant, les récentes tactiques d’infection de Mirai visent les routeurs domestiques eux-mêmes, contournant ainsi la limitation du NAT.

Le dernier et plus grand avantage contribuant au potentiel destructeur des inondations DNS réfléchies est l’amplification, qui peut être obtenue en utilisant les extensions DNS (EDNS0, définies dans le RFC 2671) et DNSSec. EDNS0 permet à la réponse DNS d’être plus grande que les 512 autorisés à l’origine, tandis que DNSSec permet l’authentification de la réponse pour empêcher l’empoisonnement du cache. DNSSec nécessite EDNS0 pour fonctionner puisqu’il ajoute des données cryptographiques à la réponse. Comme DNSSec devient populaire dans l’Internet d’aujourd’hui, sensible à la sécurité, il fait que de plus en plus de serveurs DNS supportent EDNS0 et permet à un attaquant d’obtenir des réponses importantes à ses demandes.

La taille possible de la réponse – jusqu’à 4096 octets, permet à l’attaquant d’envoyer un petit nombre de demandes courtes, tandis que les réponses envoyées par le serveur DNS sont largement amplifiées, épuisant le tuyau Internet de la victime. Les attaquants peuvent étudier le serveur DNS et trouver quelles requêtes légitimes peuvent donner lieu à des réponses volumineuses, et également utiliser DNSSec pour les rendre encore plus volumineuses avec des données cryptographiques. Dans de nombreux cas, la réponse peut atteindre le maximum de 4096 octets, ce qui donne un facteur d’amplification de x100 pour la requête originale.

Avec la grande connectivité Internet d’aujourd’hui, une connexion de 100 M à Internet peut envoyer une attaque modeste à elle seule et causer quand même quelques dommages à un site normal. Cependant, si l’attaquant a la possibilité d’utiliser cette énorme réponse de 4096 octets pour sa requête de 44 octets et d’obtenir une amplification de 100x, le serveur victime recevra 10G de trafic d’attaque, au-dessus de sa bande passante normale. Un tel trafic mettrait immédiatement hors service tout service normal. Imaginez ce que l’on peut obtenir avec un botnet composé de quelques bots de ce type.

Ajoutant à la taille de la réponse, vient le fait que de telles réponses ne peuvent pas tenir dans un paquet IP normal. Dans des cas comme celui-ci, les serveurs utilisent l’option de fragmentation IP, qui leur permet de diviser le message en plusieurs paquets. L’utilisation de trafic fragmenté dans l’attaque rend l’atténuation de l’attaque encore plus difficile – le mitigateur doit stocker les données de la couche 4 du premier paquet (ports UDP) dans une table et l’appliquer au reste des paquets du même message. De nombreuses entités réseau sont rapidement épuisées par un grand nombre de trafic fragmenté, ce qui rend cette attaque encore plus efficace.

La vidéo YouTube de Radware sur l’attaque par amplification DNS illustre graphiquement la structure et le flux d’une attaque par réflexion DNS.

Après avoir appris tous les tenants et aboutissants de l’attaque par réflexion DNS, une chose demeure : comment protéger une organisation contre une telle attaque et l’atténuer ? Contrairement à la sophistication de l’attaque elle-même, ce problème a une solution connue – pour atténuer une attaque par réflexion DNS, vous devez avoir un bon détecteur sur place pour détecter rapidement l’attaque et éviter les temps d’arrêt. Le détecteur doit être suffisamment intelligent pour comprendre que l’attaque qu’il voit sature la connexion Internet et que le trafic doit être détourné vers un centre de nettoyage en nuage. Une fois le trafic détourné vers le cloud scrubbing, il sera nettoyé et envoyé au site.

Le scrubbing lui-même dépend de la quantité de trafic similaire qui est considéré comme légitime – le site voit-il beaucoup de trafic UDP ? De trafic DNS ? Du trafic fragmenté ? Et si oui, qu’est-ce qui le distingue du trafic d’attaque ? L’utilisation d’une technique automatisée pour séparer le trafic légitime et le trafic d’attaque vous donnera une bonne et rapide atténuation du cloud et aussi, une certaine tranquillité d’esprit.

Pour plus d’informations, consultez mon blog précédent : DNS et attaques DNS

Lisez « Créer un environnement sûr pour les API sous-protégées » pour en savoir plus.

Télécharger maintenant

.