Attaque DNS par amplification en demandant

Depuis au moins le 7 janvier, une série d'attaques DoS utilisant le DNS a lieu. Parfois nommée ISPrime, du nom de la première victime, cette attaque utilise une variante originale des attaques par amplification.

Le pincipe est que le DNS repose essentiellement sur UDP, protocole sans connexion et très vulnérable aux usurpations d'adresses IP. Tirant partie de l'absence de filtrage à la source par la grande majorité des FAI, l'attaquant envoie des paquets avec une fausse adresse source. Il est donc absurde de bloquer complètement ces adresses, ce sont celles des victimes, pas celles des attaquants.

L'attaque par amplification originale visait des serveurs récursifs ouverts, comme le détaille le RFC 5358. Cette variante actuelle, compte-tenu de la diminution du nombre de récursifs ouverts, utilise des serveurs qui n'acceptent pas de faire des requêtes récursives mais acceptent de répondre à la question "NS .", c'est à dire à une demande de la liste des serveurs de noms de la racine. La liste étant assez longue, l'attaquant réussit ainsi une amplification (la réponse, envoyée à la victime, est bien plus grosse que la requête, envoyée par l'attaquant).

Un bon article de l'OARC, Upward Referrals Considered Harmful explique pourquoi il faut configurer ses résolveurs pour éviter de répondre à ces questions "NS ." (et comment le faire pour BIND).

Vous pouvez vérifier que votre résolveur est sûr en lui demandant, depuis une machine à l'extérieur de votre réseau :

% dig @votre-machine NS .

et vous ne devez pas avoir de réponse (ou bien une réponse courte comme REFUSED ou SERVFAIL). Vous pouvez aussi tester depuis un site Web.

La plupart des utilisateurs de BIND voient ces requêtes dans leurs journaux :

/var/log/daemon.log:Jan 24 09:23:30 lilith named[31908]: client 63.217.28.226#28124: view external: query (cache) './NS/IN' denied
/var/log/daemon.log:Jan 24 09:23:31 lilith named[31908]: client 63.217.28.226#53227: view external: query (cache) './NS/IN' denied
/var/log/daemon.log:Jan 24 09:23:32 lilith named[31908]: client 66.230.160.1#1601: view external: query (cache) './NS/IN' denied

mais, si on utilise l'excellent outil de capture DNS dnscap, on peut aussi les voir en demandant les requêtes concernant la racine :

% sudo dnscap -i eth0 -w ~/tmp/isprime -g -s i -x '^\.$'
...
[45] 2009-01-24 22:22:41.094184 [#1300 eth0 0] \
[206.71.158.30].27234 [192.0.2.1].53 \
dns QUERY,NOERROR,23839,rd \
1 .,IN,NS 0 0 0
[45] 2009-01-24 22:22:42.251658 [#1301 eth0 0] \
[206.71.158.30].2960 [192.0.2.1].53 \
dns QUERY,NOERROR,41966,rd \
1 .,IN,NS 0 0 0
[45] 2009-01-24 22:22:42.553856 [#1302 eth0 0] \
[206.71.158.30].2204 [192.0.2.1].53 \
dns QUERY,NOERROR,7922,rd \
1 .,IN,NS 0 0 0

Un autre logiciel qui peut être utile est en http://www.smtps.net/pub/dns-amp-watch.pl. C'est un petit script Perl qui analyse le journal de BIND pour dresser une liste des attaques qui ont laissé une trace dans le fichier, si votre BIND est correctement configuré pour les refuser :

% perl dns-amp-watch.pl
Queries for root (probable DNS amplification attacks AGAINST these IPs
3564 206.71.158.30
148 66.230.160.1
98 63.217.28.226
51 76.9.16.171

Ici, on voit que la principale victime de la journée est 206.71.158.30

Posté le 28 janvier 2009 par _SebF - Sébastien FONTAINE - source Stéphane Bortzmeyer

Vous pouvez commenter cette nouvelle
en posant vos avis, questions et remarques
sur le forum actualité