Sorry, you need to enable JavaScript to visit this website.

Image CAPTCHA
Saisir les caractères affichés dans l'image.

DNS Poisoning : Premières attaques

DNS Poisoning : Premières attaques
2008-07-302013-02-11sécurité des réseauxfr
Les attaques exploitant les serveurs DNS vulnérables à faille de "DNS Poisoning" ont démarrées. Si vous n'est pas encore protégés, il est temps de le faire : Même si la période actuelle de congés n'est pas propice pour mobiliser les personnes, remontez le problème au niveau...
Publié le 30 Juillet 2008 par Jean-François Audenard dans sécurité des réseaux

Les attaques exploitant les serveurs DNS vulnérables à faille de "DNS Poisoning" ont démarrées.

Si vous n'est pas encore protégés, il est temps de le faire : Même si la période actuelle de congés n'est pas propice pour mobiliser les personnes, remontez le problème au niveau de votre direction générale. Rester inactif ne vous apportera que des problèmes : L'été devrait être chaud, les semaines à venir particulièrement.

Tout d'abord, la vision "macro" présentée sur le Blog de la société "Arbor Networks, 30 Days of DNS Attack Activity, July 28, 2008" montre bien que des changements de comportement du trafic DNS sont clairement perceptibles au niveau Internet global.

De façon plus précise, les informations obtenues en provenance de plateformes DNS localisées sur le territoire Français indiquent clairement que des attaques (ou tentatives d'attaques) sont en cours : Nous avons pu constater que les serveurs DNS reçoivent un très grand nombre de requêtes DNS pour des domaines fantaisistes et aléatoires comme ediju6tgeed.domaine-sous-attaque.net, 45euegsg.domaine-sous-attaque.net, etc... ou encore des TLD (Top-Level Domain) dans cet autre cas : tguueg6776t.net, y7pj7dg.net, etc.... Louche, très louche.

Plus concrètement, des attaques ayant réussies à l'encontre de serveurs DNS d'un grand opérateur de télécommunications américain, ont récemment été publiées: PC World, DNS Attack Writer a Victim Of His Own Creation, July 30, 2008. Dans ce cas précis, la cible de la redirection via empoisonnement du cache DNS aurait été le site de Google avec un objectif clairement affiché : L'argent.

Selon nous, il y a de très fortes chances que le nombre d'attaques aille crescendo dans les prochains jours : C'est une trop belle occasion que le crime organisé sur Internet ne saurait laisser passer.

En cas de suspicion, une réponse simple est de vider le cache de vos serveurs DNS resolvers. Celui-ci "oubliera" donc les données malicieuses comme les bonnes : Cela aura un impact négatif en terme de performances mais entre deux maux, il faut choisir le moindre non ?

6 Commentaires

  • 12 Août 2008
    2008-08-12
    par
    Cher Daniel, merci pour votre commentaire et désolé pour le temps de réponse durant cette période estivale.
    En effet, DNSSEC est un bon moyen s'assurer l'intégrité des informations et donc de se protéger des tentatives de détournement. Les moyens techniques sont là (notamment dans ISC Bind) : Il reste l'épineuse question du déploiement à grande échelle... C'est bien là que le problème réside.
  • 7 Août 2008
    2008-08-12
    par
    Daniel Migault
    La solution au DNS cache poisoning est d'authentifier la source émettrice du nom de domaine. Cela signifie que l'on doit savoir qui fournit l'information au cache. Le protocole DNSSEC par exemple permet de fournir ce renseignement. Cependant il nécessite d'être mis en place sur les serveurs authoritaires.
  • 31 Juillet 2008
    2008-08-12
    par
    Merci pour le lien vers les signatures Snort.
    Dans la même catégorie, un plugin NESSUS est disponible afin d'identifier les serveurs vulnérables:
    http://www.nessus.org/plugins/index.php?view=single&id=33447
  • 31 Juillet 2008
    2008-08-12
    par
  • 31 Juillet 2008
    2008-08-12
    par
    JF.Audenard
    Question effectivement pertinente : La réponse est malheureusement négative.
    Une première idée de protection était de monter le TTL (Time To Live) sur les zones/informations au niveau des serveurs DNS autoritaires : De la sorte, ces informations auraient été conservées/cachées plus longtemps par les DNS caches/resolvers.... Mais cela ne fonctionne pas : L'attaque permet de remplacer des données en cache même si celle-ci sont marquées comme venant de serveurs ayant autorité et pour lesquelles le TTL n'est pas expiré...
    Une piste serait les certificats SSL mais comme les utilisateurs cliquent allègrement sur le bouton "OK Continue" des fenêtres d'avertissement on ne va pas loin non plus de ce coté.

Pages

Ajouter un commentaire

comments

  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Tags HTML autorisés : <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd> <br>

Plain text

  • Aucune balise HTML autorisée.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.

Email HTML

  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
Image CAPTCHA
Saisir les caractères affichés dans l'image.
Changer d'affichage