Brute force DNS

Brute force DNS

1 – Introduction au brute force DNS

Tout le monde sait que la première étape d’une attaque consiste à explorer le domaine ciblé via un brute force.

Il faut agir dans l’ordre suivant : d’abord lister les machines appartenant au réseau de la cible puis identifier les services qui tournent sur chacune de ces machines et leurs versions. Cet article vient donc en amont de l’article précédent « Les Scan UDP et TCP »

Il parait tout a fait logique que si un pirate ne peut pas lister les machines du domaine ciblé, il n’a plus aucun support à attaquer.
Ce chapitre suppose une connaissance de base du protocole DNS. Pour apprendre les bases du fonctionnement de la DNS, lisez ce document.

2 – Théorie

Il y a quelques années, les pirates faisaient appel aux transferts de zone DNS afin de lister l’ensemble des machines d’un domaine qu’ils prévoyaient d’attaquer. Le transfert de zones permet à un serveur DNS, en général un serveur secondaire, d’interroger le serveur primaire du domaine, pour lui demander la configuration DNS intégrale le concernant. C’est une opération très pratique, voire indispensable pour effectuer une synchronisation entre serveurs.

Désormais, le transfert de zone DNS est de moins en moins possible, car les politiques de sécurité sur les systèmes l’empêchent. De nos jours, il est classique de n’autoriser les transferts de zone DNS qu’entre le serveur DNS principal et les serveurs DNS secondaires de leur propre domaine, alors qu’auparavant, ce type de transferts étaient souvent autorisés à n’importe qui.

Il était ainsi possible à partir d’un domaine de déterminer les sous-domaines enregistrés dans le serveur DNS, et les adresses IP associées, grâce à une simple commande « host -l » tapée dans une console UNIX, ou nslookup pour windows :

C:\> nslookup yahoo.com
*** Impossible de trouver le nom de serveur pour l'adresse yahoo.com : Non-existent domain
*** Les serveurs par défaut ne sont pas disponibles
Serveur :  UnKnown
Address:  192.168.1.1
Réponse ne faisant pas autorité :
Nom :    yahoo.com
Addresses:  216.109.112.135, 66.94.234.13

Il a donc fallu trouver un moyen pour connaître les hôtes sans passer par cette méthode.

Pour déterminer les sous domaines utilisés, une recherche sur Google était donc un bon moyen. Le brute force DNS est également une possibilité, avec des outils comme ws-dns-bfx ou Txdns, Cela consiste simplement à envoyer en force brute des noms d’hôtes courants dans une requête DNS. D’après la réponse du serveur DNS, on peut identifier si cet hôte existe ou non.

3 – Pratique

3.1 – Moteur de recherche

Utilisons Google intelligemment :
Lançons la requête : « site:microsoft.com » (http://www.google.fr/search?q=site:microsoft.com). Nous obtenons environ 11 000 000 résultats. C’est bien, mais ce n’est pas exploitable, on va donc réduire cela avec la nouvelle requête : « site:microsoft.com -site:www.microsoft.com » On recherche tous les sous-domaines de mircosoft.com sans prendre en compte le sous-domaine «www», trivial. On obtient désormais 2,590,000 résultats. On a désormais une liste de sous-domaines de Microsoft, mais les résultats ne sont pas « uniques », on retrouve toujours les mêmes sous domaines (d’où les 2 millions de résultats). Cela reste encore inexploitable.

L’inconvénient avec les moteurs de recherche, c’est qu’ils n’indexent pas tout ; en effet, le fichier robots.txt permet d’empêcher un moteur de recherche d’indexer certain répertoire et sous domaines.

Nous allons donc voir une autre méthode, plus « aveugle » nommé le brute force DNS.

3.2 Utilisation du brute force DNS

Un programme permet d’automatiser la recherche d’hôtes, plus rapidement qu’a la main. Il envoie des requêtes DNS et avec la réponse, permet de savoir si le sous domaine existe ou non. Je vais utiliser le programme TXDNS (www.txdns.net), en mode console. Le programme est fourni avec un petit dictionnaire. Vous l’aurez compris, plus le dictionnaire contient de mots, plus la découvert d’hôtes sera réussie. Ce petit programme s’utilise avec différents mode. Détaillons-les.

3.2.1 Mode dictionnaire

Le programme ouvre le dictionnaire des noms d’hôtes les plus répandus et les lit un par un. Chaque entrée de ce fichier correspond à un nom d’hôte et est concaténée avec le nom de domaine, par exemple auth.microsoft.com, ftp.microsoft.com, etc. On envoi ensuite au server DNS chacun des domaines ainsi générés, le serveur DNS répond au client en disant « auth n’existe pas en tant qu’hôte chez microsoft.com » Grâce à cette réponse, le programme sait que cet hôte n’existe pas. Ou alors, le serveur DNS répond au client en disant « ftp chez microsoft.com pointe vers l’adresse IP A.B.C.D ». Grâce à cette réponse, le programme sait que cet hôte existe et que son adresse IP correspondante est A.B.C.D, ce qu’il va sauvegarder dans la liste des hôtes détectés. 

La syntaxe est la suivante :

$ Txdns -fm dictionnaire.txt microsoft.com

Le -fm signale qu’on va pré chargé en mémoire notre dictionnaire (améliore les performances) 

Mon petit dictionnaire compte environ 400 mots. Avec cela, on obtient 16 noms de domaines, comme le montre la figure suivante : 

brute-force-dns mode dictionnaire

Je vais maintenant réitérer l’opération avec un dictionnaire beaucoup plus conséquent : 66 000 mots anglais (puisqu’on scanne un hôte américain…)
Des listes de dictionnaire sont disponibles.

Voici le résultat :

txdns -fm dict.txt  microsoft.com
-----------------------------------------------------------------------------
TXDNS (http://www.txdns.net) 2.0.0 running STAND-ALONE Mode
-----------------------------------------------------------------------------
 > technet2.microsoft.com         - 207.46.196.114
 > uddi.microsoft.com             - 207.46.248.108
 > research.microsoft.com         - 131.107.65.14
 > advertising.microsoft.com      - 65.54.192.247
 > accounting.microsoft.com       - 207.68.165.50
 > billing.microsoft.com          - 65.54.159.250
 > directory.microsoft.com        - 131.107.115.87
 > example.microsoft.com          - 207.46.232.182
                                  | 207.46.197.32
 > exchange.microsoft.com         - 131.107.0.53
 > email.microsoft.com            - 209.11.136.150
 > ftp.microsoft.com              - 207.46.236.102
 > gallery.microsoft.com          - 207.46.28.21
 > mail.microsoft.com             - 131.107.1.71
 > marketing.microsoft.com        - 207.46.242.110
 > public.microsoft.com           - 131.107.1.70
 > research.microsoft.com         - 131.107.65.14
 > services.microsoft.com         - 207.46.132.190
 > smtp.microsoft.com             - 205.248.106.32
                                  | 131.107.115.214
                                  | 131.107.115.215
                                  | 205.248.106.64
                                  | 205.248.106.30
                                  | 131.107.115.212
 > shop.microsoft.com             - 207.46.197.32
                                  | 207.46.232.182
 > windows.microsoft.com          - 207.46.197.32
                                  | 207.46.232.182
 > mail.microsoft.com             - 131.107.1.71
 > ftp.microsoft.com              - 207.46.236.102
 > smtp.microsoft.com             - 205.248.106.30
                                     | 205.248.106.32
                                     | 131.107.115.215
                                     | 205.248.106.64
                                     | 131.107.115.212
                                     | 131.107.115.214
 > windows.microsoft.com          - 207.46.197.32
                                  | 207.46.232.182
 > exec.microsoft.com             - 207.46.248.35
 > ircs.microsoft.com             - 131.107.3.108

On remarque donc qu’il est tout à fait utile d’avoir un dictionnaire comportant beaucoup de mots pour ce type d’attaque (partie découverte).

3.2.2 – Mode brute force

Le mode brute force est tout simplement un test de chaque caractère alphanumérique. L’attaque est la même que pour le dictionnaire, on créé la requête, on l’envoie, et on observe la réponse.

$ txdns  -bb --min 2 --max 10 --charset 1 -v -x 30 microsoft.com

Je lance donc TXDNS en lui précisant le mode brute force (-bb), je lui dis de commencer sa recherche pour un hôte allant de 2 (–min) à 10 (–max) caractères alphabétique seulement (–charset 1). Je lui demande en plus d’être bavard (-v) et de traiter 30 (-x) threads à la fois. 
Résultat (limité à 3 caractères) :

-------------------------------------------------------------------------------
TXDNS (http://www.txdns.net) 2.0.0 running STAND-ALONE Mode
-------------------------------------------------------------------------------
 > fs.microsoft.com               - 131.107.0.125
 > im.microsoft.com               - 131.107.0.205
 > jp.microsoft.com               - 207.46.197.32
                                  | 207.46.232.182
 > aer.microsoft.com              - 213.199.138.26
 > aer.microsoft.com              - 213.199.138.26
 > bts.microsoft.com              - 207.46.140.107
 > cgo.microsoft.com              - 207.46.209.245
                                  | 207.46.18.253
 > cps.microsoft.com              - 207.46.197.32
                                  | 207.46.232.182
 > ftp.microsoft.com              - 207.46.236.102
 > mbn.microsoft.com              - 207.68.167.45
 > mcp.microsoft.com              - 131.107.100.158
 > mrs.microsoft.com              - 207.46.228.36
 > mrt.microsoft.com              - 207.46.197.122
 > oem.microsoft.com              - 216.52.28.110
 > pos.microsoft.com              - 207.46.197.32
                                  | 207.46.232.182
                                  | 207.46.175.69
 > rap.microsoft.com              - 131.107.0.6
 > rss.microsoft.com              - 207.46.232.182
                                  | 207.46.197.32
 > sba.microsoft.com              - 207.68.165.44
 > sba.microsoft.com              - 207.68.165.44
 > scs.microsoft.com              - 207.46.16.247
 > sip.microsoft.com              - 131.107.119.20
 > sls.microsoft.com              - 65.54.146.205
 > vua.microsoft.com              - 65.54.96.220
 > vua.microsoft.com              - 65.54.96.220

On découvre par cette méthode de nombreux hôtes qu’on n’aurait jamais pu trouver avec un dictionnaire…

3.2.3 – Mode « typo »

Ce mode n’est pas un mode d’attaque en lui-même. Il prend en argument le nom de domaine et cherche aux alentours dans le but de trouver des sites qui se font passer pour le domaine, alias cybersquatting, typosquatting.
Exemple :

$ txdns  -rt -t microsoft.com

On obtient ci-dessous des sites ressemblant de très près à microsoft.com.

brute-force-dns mode typo

3.3 – Le cache DNS d’un opérateur

Cette dernière méthode est très simple à mettre en oeuvre, mais n’est pas accessible à tous. En effet, où peut-on aller chercher des enregistrements DNS autre part que dans le serveur DNS lde zone lui même ?

Et bien, il est possible de regarder dans des serveurs DNS cache, qui comme le nom l’indique, possède les informations de correspondance en cache. Pour que cela soit intéressant, il faut un cache conséquent. En fait, les opérateurs et les FAI possèdent des serveurs DNS Cache assez monstrueux. 

Un serveur DNS cache est une machine qui possède un programme comme BIND (Berkeley Internet Name Domain) sans avoir de zone de configurée. Son but est de répondre aux requêtes des utilisateurs. Il agît très souvent le mandataire des utilisateurs (récursif une fois).

Suite aux requêtes des différents clients DNS, son cache se remplis d’enregistrement de correspondances adresse IP <> nom du domaine. C’est grâce à ces machines que l’ont fait correspondre mircrosoft.com à l’adresse IP 193.238.151.9.

Dans le cadre de Bind, les fichiers de configuration se trouvent dans le répertoire /etc/bind/. On y trouve notamment le fichier db.root, qui contient les adresses IP des serveurs DNS racines (i.e. les serveurs centraux du système DNS), et le fichier named.conf qui est le fichier de configuration principal de Bind. Le répertoire /var/cache/bind/ est destiné à accueillir les fichiers de zone pour ceux qui veulent configurer un serveur DNS primaire ou secondaire. Il est là plupart du temps « chrooté ». Le principe lors de l’exécution de BIND dans un environnement restreint (« chrooté ») est de limiter la quantité d’accès que n’importe quel individu malveillant pourrait gagner en exploitant une des vulnérabilités de BIND.

Le principal problème de cette méthode est, comme vous l’aurez compris, d’avoir un accès à ces serveurs. Deux cas se présentent donc à nous : vous avez réussi à avoir un accès plus ou moins légal à la machine, ou alors vous administrez le serveur. Voici ce que l’on peut trouver dans l’enregistrement DNS d’un opérateur français que nous ne pouvons pas citer :

test:/var/chroot_bind/var/cache/bind# grep microsoft named_dump.db 
28.115.107.131.in-addr.arpa. 1580 PTR crl.microsoft.com.
12.70.107.131.in-addr.arpa. 2196 PTR mail4.mssupport.microsoft.com.
107.210.46.207.in-addr.arpa. 2912 PTR redir.metaservices.microsoft.com.
43.248.46.207.in-addr.arpa. 3344 PTR delivery2.pens.microsoft.com.
191.138.199.213.in-addr.arpa. 1910 PTR smtp-dub.microsoft.com.
30.52.4.64.in-addr.arpa. 2519 PTR b.office.microsoft.com.
2519 PTR microsoftoffice2007.com.
2519 PTR microsoftoffice2007.net.
2519 PTR microsoftoffice2007.org.
2519 PTR microsoftofficesystem.com.
2519 PTR microsoftofficesystem.net.
2519 PTR microsoftofficesystem.org.
microsoft.be. 82190 NS ns1.msft.net.
microsoft.ca. 19801 NS ns1.msft.net.
fuckmicrosoft.com. 6920 NS ns1.thepublicinternet.net.
labo-microsoft.com. 83167 NS dns35.register.com.
microsoft.com. 167837 NS ns1.msft.net.
1865 MX 10 maila.microsoft.com.
1865 MX 10 mailb.microsoft.com.
1865 MX 10 mailc.microsoft.com.
activex.microsoft.com. 3197 CNAME activex.windowsmedia.com.akadns.net.
c.microsoft.com. 1924 CNAME c.microsoft.akadns.net.
codecs.microsoft.com. 213 CNAME codecs.windowsmedia.com.akadns.net.
crl.microsoft.com. 1057 A 131.107.115.28
msgr.dlservice.microsoft.com. 2415 CNAME msgr.dlservice.microsoft.nsatc.net.
msnsrch.dlservice.microsoft.com. 2445 CNAME 
msnsrch.dlservice.microsoft.nsatc.net.
download.microsoft.com. 901 CNAME main.dl.ms.akadns.net.
downloads.microsoft.com. 892 \-ANY ;-$NXDOMAIN
partners.extranet.microsoft.com. 2196 NS dns3.one.microsoft.com.
2196 NS dns4.one.microsoft.com.
2196 NS dns6.one.microsoft.com.
2196 NS dns7.one.microsoft.com.
forums.microsoft.com. 1629 CNAME forums.microsoft.akadns.net.
g.microsoft.com. 2458 CNAME g.msn.com.
genuine.microsoft.com. 1163 CNAME genuine.microsoft.akadns.net.
go.microsoft.com. 1826 CNAME www.go.microsoft.akadns.net.
i2.microsoft.com. 2754 CNAME i.toggle.www.ms.akadns.net.
i3.microsoft.com. 2754 CNAME i.toggle.www.ms.akadns.net.
6to4.ipv6.microsoft.com. 3186 A 192.88.99.1
teredo.ipv6.microsoft.com. 1309 A 65.54.227.120
maila.microsoft.com. 1865 \-AAAA ;-$NXRRSET
mailb.microsoft.com. 1865 \-AAAA ;-$NXRRSET
mailc.microsoft.com. 1865 \-AAAA ;-$NXRRSET
images.metaservices.microsoft.com. 2972 CNAME 
images.windowsmedia.com.edgesuite.net.
movie.metaservices.microsoft.com. 391 A 207.46.236.116
info.music.metaservices.microsoft.com. 396 CNAME 
music.metadata.windowsmedia.com.akadns.net.
toc.music.metaservices.microsoft.com. 3307 CNAME 
toc.music.metadata.windowsmedia.com.akadns.net.
redir.metaservices.microsoft.com. 880 \-AAAA ;-$NXRRSET
mgn.microsoft.com. 2122 CNAME office.microsoft.com.nsatc.net.
msdn.microsoft.com. 891 CNAME msdn.microsoft.akadns.net.
mail4.mssupport.microsoft.com. 2198 \-AAAA ;-$NXRRSET
_ldap._tcp.Premier-Site-par-defaut._sites.dc._msdcs.logon.netmeeting.microsoft.com. 
491 \-ANY ;-$NXDOMAIN
_ldap._tcp.dc._msdcs.logon.netmeeting.microsoft.com. 491 \-ANY ;-$NXDOMAIN
newsletters.microsoft.com. 3345 A 207.46.248.35
3345 MX 10 newsletters.microsoft.com.
oca.microsoft.com. 1801 CNAME oca.partners.extranet.microsoft.com.
office.microsoft.com. 2805 CNAME office.microsoft.com.nsatc.net.
config.office.microsoft.com. 451 CNAME 
config.office.microsoft.com.nsatc.net.
r.office.microsoft.com. 2106 CNAME r.office.microsoft.com.nsatc.net.
officeimages.microsoft.com. 2024 CNAME i.office.microsoft.com.nsatc.net.
dns3.one.microsoft.com. 2196 A 205.248.102.101
dns4.one.microsoft.com. 2196 A 205.248.102.103
dns6.one.microsoft.com. 2196 A 131.107.70.73
dns7.one.microsoft.com. 2196 A 207.46.55.8
delivery2.pens.microsoft.com. 3344 A 207.46.248.40
rad.microsoft.com. 472 CNAME rad.msn.com.
search.microsoft.com. 407 CNAME search.microsoft.akadns.net.
spynet2.microsoft.com. 1937 A 207.46.236.28
www.sqm.microsoft.com. 2173 CNAME sqm.msn.com.
svcs.microsoft.com. 2801 CNAME messenger.msn.com.
technet.microsoft.com. 1374 CNAME technet.microsoft.akadns.net.
update.microsoft.com. 381 CNAME update.microsoft.com.nsatc.net.
rs.update.microsoft.com. 34 CNAME toggle.rs.ms.akadns.net.
rs.rs.update.microsoft.com. 715 \-ANY ;-$NXDOMAIN
stats.update.microsoft.com. 1478 CNAME statsupdate.microsoft.com.nsatc.net.
urs.microsoft.com. 628 CNAME urs.microsoft.com.nsatc.net.
e450.voice.microsoft.com. 3152 CNAME 
e450.voice.msnmessenger.msn.com.akadns.net.
watson.microsoft.com. 2056 A 65.54.206.43
windowsbeta.microsoft.com. 1833 CNAME 
windowsbeta.partners.extranet.microsoft.com.
windowsupdate.microsoft.com. 2222 CNAME windowsupdate.microsoft.nsatc.net.
v4.windowsupdate.microsoft.com. 387 CNAME 
v4windowsupdate.microsoft.nsatc.net.
v5.windowsupdate.microsoft.com. 1556 CNAME update.microsoft.com.
v5stats.windowsupdate.microsoft.com. 3438 CNAME 
v5statswindowsupdate.microsoft.nsatc.net.
wm.microsoft.com. 239 CNAME wm.microsoft.akadns.net.
www.microsoft.com. 3076 CNAME toggle.www.ms.akadns.net.
microsoftnet.com. 1602 NS A1.RS2.Superkay.com.
home.microsoftnet.com. 8802 \-AAAA ;-$NXRRSET
thesource.ofallevil.com. 4198 CNAME www.microsoft.com.
trymicrosoftoffice.com. 2444 NS ns1.msft.net.
m.webtrends.com. 195 CNAME microsoft.webtrends.akadns.net.
shell.windows.com. 540 CNAME siweb.microsoft.akadns.net.
maila.microsoft.com.altitudetelecom.fr. 1865 \-ANY ;-$NXDOMAIN
mailb.microsoft.com.altitudetelecom.fr. 1865 \-ANY ;-$NXDOMAIN
mailc.microsoft.com.altitudetelecom.fr. 1865 \-ANY ;-$NXDOMAIN
mail4.mssupport.microsoft.com.altitudetelecom.fr. 2198 \-ANY ;-$NXDOMAIN
microsoft.fr. 95 A 193.238.151.9
microsoft.hr. 84034 NS ns1.msft.net.
1234 MX 10 mailb.microsoft.hr.
1234 MX 30 maila.microsoft.hr.
maila.microsoft.hr. 1234 A 194.152.243.102
mailb.microsoft.hr. 1234 A 217.198.97.181
c.microsoft.akadns.NET. 513 A 207.46.209.246
genuine.microsoft.akadns.NET. 139 A 207.46.236.175
www.go.microsoft.akadns.NET. 366 A 64.4.52.189
siweb.microsoft.akadns.NET. 60 A 207.46.232.182
toggle.rs.ms.akadns.NET. 257 CNAME 
rs.update.microsoft.com.edgesuite.net.
microsoft.webtrends.akadns.NET. 139 A 63.88.212.184
dlservice.microsoft.com.edgesuite.NET. 19671 CNAME a994.ms.akamai.net.
i.microsoft.com.edgesuite.NET. 6649 CNAME a1475.g.akamai.net.
rs.update.microsoft.com.edgesuite.NET. 18877 CNAME a1486.g.akamai.net.
microsoft.NET. 130827 NS ns1.msft.net.
office.microsoft.com.nsatc.NET. 105 A 64.4.52.30
config.office.microsoft.com.nsatc.NET. 104 A 64.4.52.57
i.office.microsoft.com.nsatc.NET. 468 A 64.4.52.53
statsupdate.microsoft.com.nsatc.NET. 810 \-AAAA ;-$NXRRSET
update.microsoft.com.nsatc.NET. 650 \-AAAA ;-$NXRRSET
urs.microsoft.com.nsatc.NET. 662 \-AAAA ;-$NXRRSET
msgr.dlservice.microsoft.nsatc.NET. 271 CNAME 
dlservice.microsoft.com.edgesuite.net.
v5statswindowsupdate.microsoft.nsatc.NET. 738 A 207.46.20.254
windowsupdate.microsoft.nsatc.NET. 590 A 207.46.225.221
download.microsoft.com.syrhano.NET. 1214 \-ANY ;-$NXDOMAIN
update.microsoft.com.syrhano.NET. 1433 \-ANY ;-$NXDOMAIN
ns0.forum-microsoft.org. 80222 A 194.140.247.20
ns1.forum-microsoft.org. 80222 A 194.140.247.21
laboratoire-microsoft.org. 2994 NS ns0.laboratoire-microsoft.org.
2994 NS ns1.laboratoire-microsoft.org.
ns0.laboratoire-microsoft.org. 27021 A 194.140.247.20
ns1.laboratoire-microsoft.org. 27021 A 194.140.247.21
www.laboratoire-microsoft.org. 2994 A 194.140.247.4
schemas.xmlsoap.org. 2719 CNAME msdn.microsoft.akadns.net.
microsoft.ru. 294108 NS ns1.actis.ru.
microsoft.CO.UK. 24320 NS ns1.msft.net.

La syntaxe du fichier est assez intuitive : lorsqu’un utilisateur tape « microsoft.fr » dans son navigateur et que l’opérateur Télécoms en question est interrogé, ce dernier nous renvoie l’adresse IP 193.238.151.9. Et si l’on entre « laboratoire-microsoft.org », le serveur ira chercher l’adresse IP à travers le serveur DNS primaire ns0.laboratoire-microsoft.org » qui contiendra l’adresse IP recherchée.

Cette méthode est donc utilisable par quelques « privilégiés » qui ont un accès au serveur. Par exemple : 

  • Les administrateurs de très grand compte qui ont accès au cache DNS de leur société
  • Les administrateurs des opérateurs télécoms et des Fournisseurs d’Accès à Internet
  • Les pirates qui accèdent à ces serveurs sans en posséder les droits officiels

Bien que restreinte, cette méthode permet d’obtenir très rapidement un grand nombre de noms de sous domaines que l’on aurait sûrement jamais découvert autrement, et aussi rapidement.

4 – Contre-mesures

La meilleure méthode permettant de détecter ce genre d’attaques consiste à surveiller les requêtes envoyées à votre serveur DNS et de rechercher la présence d’une grande quantité de requêtes à la suite, issues de la même IP et suivies de nombreuses réponses de type hôtes non-existants.

Pour automatiser le processus, il faudrait créer une règle pour le firewall (ou l’IDS) qui bannirait une adresse IP qui effectue plus de X mauvaises requêtes (hôtes non-existants.) à la seconde. On détecte ainsi un logiciel de type brute force qui semble beaucoup trop curieux.

Cela posera certainement des problèmes de maîtrises, et de performances pour le serveur qui est très demandé. On tombe alors dans le même compromis que le blocage des SYN pour éviter les attaques de type DOS, et les inconvénients de ce blocage.

5 – Conclusion

Même en présence de restrictions des transferts de zone DNS, un  pirate munit d’un outil de DNS brute force (ou DNS digger)  et d’un BON fichier de dictionnaire peut extraire une grande quantité d’hôtes, fonction très utile pour les attaques. De plus, le travail est hautement facilité si le pirate à un accès à la machine ou simplement le dit-fichier des enregistrements DNS issu du milieu underground.

N’oubliez pas que les listes incrémentales de mots peuvent se révéler très efficaces contre les grands domaines à l’échelle mondiale, mais nécessitent un long temps d’exécution. En revanche, ce type d’attaque ne sera pas efficace contre les sites à « taille humaine » (sites personnels..).

6 – Suivi du document

Création et suivi de la documentation par Jérémy AMIOT et _SebF

Modification de la documentation par _SebF

  • Ajout du chapitre « 3.3 – Le cache DNS d’un opérateur »

7 – Discussion autour du brute force DNS

Vous pouvez poser toutes vos questions, faire part de vos remarques et partager vos expériences à propos du brute force DNS. Pour cela, n’hésitez pas à laisser un commentaire ci-dessous :

Commentaire et discussion

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *