|
Découverte d'hôtes par via un brute force DNS
Par Jérémy AMIOT
1 - Introduction
2 - Théorie
3 - Pratique
3.1 - Moteur de recherche
3.2 - Utilisation d'un brute force DNS
3.3 - Le cache DNS d'un opérateur
4 - Contre-mesures
5 - Conclusion
6 - Discussion autour de la
documentation
7 - Suivi du document
Tout le monde sait que la première étape d'une attaque consiste à explorer le domaine ciblé. 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.
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. 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 :
 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). 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... 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.
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.
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.
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..).
Vous pouvez poser toutes vos questions,
vos remarques et vos expériences à propos des scanner. Pour cela,
rendez-vous sur le Forum
Sécurité.
Version 1.2, le 17 juin 2007, par Jérémy AMIOT et Sébastien FONTAINE, Ajout du
chapitre "3.3 - Le cache DNS d'un opérateur"
Version 1.1, le 24 avril 2007, par Sébastien FONTAINE, validation du document.
Version 1.0, le 5 avril 2007, par
Jérémy AMIOT, création du document. |