# Faille de conception du systême DNS **URL:** \ **Category:** Pause Café\ **Created:** [Février 20, 2016, 5:50 UTC](https://www.debian-fr.org/t/faille-de-conception-du-systeme-dns/14641 "2016-02-20T17:50:13Z")\ **Posts on this page:** 20\ **Page:** 2
**Author:** ![micky979](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/m/d9b06d/32.png) [@micky979](https://www.debian-fr.org/u/micky979)\ **Post date:** [Février 20, 2016, 5:50 UTC](https://www.debian-fr.org/t/faille-de-conception-du-systeme-dns/14641/21 "2016-02-20T17:50:54Z")
> [@](#): > > Mais il est respecté par ses pairs et admiré par les autres. DJB a raconté énormément de choses, parfois il est tombé juste, souvent il a dit d’énormes bêtises. Par exemple : [cr.yp.to/djbdns/dot-fr.html](http://cr.yp.to/djbdns/dot-fr.html) (faux de A à Z et dangereux) [cr.yp.to/djbdns/idn.html](http://cr.yp.to/djbdns/idn.html) (Il n’a rien compris à Unicode) Comme, en outre, il est imbittable, insupportable et qu’il insulte tout le temps ses contradicteurs, il est parfaitement normal qu’il soit ignoré par la majorité. > [@](#): > > Ce que je ne comprends pas , c’est pourquoi son DJBDNS n’est pas plus utilisé par les grands ISP. Il a pourtant la réputation d’être plus facile à configurer que Bind non? Parce que les administrateurs des grands ISP sont d’un niveau plus élevé que le lecteur de Slashdot et qu’ils ne croient pas sur parole les affirmations du genre « C’est plus convivial » ou bien « C’est plus secure » ? Il existait déjà plusieurs résolveurs libres (contrairement au djbware) et standards (contrairement au djbware) qui n’avaient pas la vulnérabilité : - Unbound [unbound.net/](http://www.unbound.net/) - PowerDNS recursor [doc.powerdns.com/built-in-recursor.html](http://doc.powerdns.com/built-in-recursor.html) ---
**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\ **Post date:** [Février 20, 2016, 5:51 UTC](https://www.debian-fr.org/t/faille-de-conception-du-systeme-dns/14641/22 "2016-02-20T17:51:03Z")
> [@](#): > > slt, (…) oops j’oubliais une belle conversation des opérateurs français à ce sujet. [mail-archive.com/frnog@frnog … 03095.html](http://www.mail-archive.com/frnog@frnog.org/msg03095.html)[/quote]En relisant les inquiétudes de certains quand au fait que la faille n’était pas corrigée, mais juste moins facile à exploiter, je me demandais si ça n’allait pas pousser du monde à faire plus sérieusement de l’ipv6. A priori, si je me souviens bien, l’ipv6 a un systême de résolution complètement différent, non ? ---
**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\ **Post date:** [Février 20, 2016, 5:51 UTC](https://www.debian-fr.org/t/faille-de-conception-du-systeme-dns/14641/23 "2016-02-20T17:51:03Z")
En lisant l’explication, je me disais qu’en enclenchant simultanément genre ( nb max de requètes acceptées -1 ) requètes longues sur le serveur, il y avait peut être moyen de prévoir un peu mieux le port de la (nb max de requètes acceptées) iême requète. Il y a ça aussi: [bortzmeyer.org/faille-dns-em … ement.html](http://www.bortzmeyer.org/faille-dns-empoisonnement.html) ---
**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\ **Post date:** [Février 20, 2016, 5:51 UTC](https://www.debian-fr.org/t/faille-de-conception-du-systeme-dns/14641/24 "2016-02-20T17:51:03Z")
Le test simple: [quote]roc@roc:~$ dig +short [porttest.dns-oarc.net](http://porttest.dns-oarc.net) TXT [z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net](http://z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net). “89.3.163.99 is GOOD: 26 queries in 4.5 seconds from 26 ports with std dev 13625.33”[/quote]avant correctif, j’avais:[quote]roc@roc:~$ dig +short [porttest.dns-oarc.net](http://porttest.dns-oarc.net) TXT [z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net](http://z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net). “89.3.163.99 is POOR: 26 queries in 4.5 seconds from 1 ports with std dev 0.00”[/quote] 😉 ---
**Author:** ![stonfi](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/54ee81/32.png) [@stonfi](https://www.debian-fr.org/u/stonfi)\ **Post date:** [Février 20, 2016, 5:51 UTC](https://www.debian-fr.org/t/faille-de-conception-du-systeme-dns/14641/25 "2016-02-20T17:51:07Z")
hello, > [@](#): > > A priori, si je me souviens bien, l’ipv6 a un systême de résolution complètement différent, non ? A priori même en ipv6 on aura besoin du protocole dns, sans faire donner de cour ipv6 permet d’adresser sur 128bits avec quelque amélioration de la stack ip. > [@](#): > > ( nb max de requètes acceptées -1 ) requètes longues sur le serveur C’est tout à fait ça, d’ou le patch qui alloue aléatoirement les ports source, les id’s’. ---
**Author:** ![ripat](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/r/bc79bd/32.png) [@ripat](https://www.debian-fr.org/u/ripat)\ **Post date:** [Février 20, 2016, 5:53 UTC](https://www.debian-fr.org/t/faille-de-conception-du-systeme-dns/14641/26 "2016-02-20T17:53:59Z")
Aïe aïe aïe! Ça se gâte! Dan Kaminsky ne comptait dévoiler les détails de la faille que début août à la conférence Black Hat pour laisser le temps aux ISP de patcher leurs serveurs mais un petit malin, expert en reverse engineering, semble avoir mis le doigt sur le mécanisme de la faille. Ce qui fait dire à Dan Kaminsky: Patch. Today. Now! [doxpara.com/](http://www.doxpara.com/) Article: [theinquirer.net/feeds/rss/ge … re-details](http://www.theinquirer.net/feeds/rss/generic/en/GB/inq/latest/gb/inquirer/gb/inquirer/news/2008/07/22/dns-security-exposure-details) ---
**Author:** ![tntprog](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/t/eada6e/32.png) [@tntprog](https://www.debian-fr.org/u/tntprog)\ **Post date:** [Février 20, 2016, 5:54 UTC](https://www.debian-fr.org/t/faille-de-conception-du-systeme-dns/14641/27 "2016-02-20T17:54:01Z")
Je ne sais pas s’il a publié un proof of concept de son truc, mais à partir du moment où on publie quelques lignes de codes, on peut être sur qu’elles vont être reversées. J’avais plutôt lu que le mec en question avait réussi à déduire certaines infos et avait trouvé la faille à son tour en cherchant un peu et en recoupant quelques infos. ---
**Author:** ![ripat](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/r/bc79bd/32.png) [@ripat](https://www.debian-fr.org/u/ripat)\ **Post date:** [Février 20, 2016, 5:54 UTC](https://www.debian-fr.org/t/faille-de-conception-du-systeme-dns/14641/28 "2016-02-20T17:54:01Z")
Bon, mon ISP (Belgacom) semble avoir patché mais son router/firewall déclenche une mise en garde avec le test du blog de Dan Kamniski. Comme je suis prudent et que j’ai quand même un certain nombre d’utilisateurs derrière mon router, j’ai mis OpendDNS comme serveur DNS. Je viens de le tester et lui semble parfaitement OK. [opendns.com/](https://www.opendns.com/) A première vue, la résolution est aussi rapide qu’avant. C’est quoi encore la commande qui fait un timing de la résolution? Edit: J’ai trouvé. L’option -v de la commande host donne le timing de la résolution. ---
**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\ **Post date:** [Février 20, 2016, 5:54 UTC](https://www.debian-fr.org/t/faille-de-conception-du-systeme-dns/14641/29 "2016-02-20T17:54:02Z")
quote=“ripat” Comme je suis prudent et que j’ai quand même un certain nombre d’utilisateurs derrière mon router, j’ai mis OpendDNS comme serveur DNS. Je viens de le tester et lui semble parfaitement OK. [opendns.com/](https://www.opendns.com/) (…)[/quote] Voilà. C’est ça… ![:mrgreen:](https://www.debian-fr.org/uploads/default/original/1X/cc83e9b583138e48ff45f96609046b06d06c7f9d.gif "Mr. Green") Comme tu es prudent, tu préfères donc prendre tes infos de DNS auprés d’un prestataire privé qui pourrait, mettons, faire payer la retransmission des noms de domaines (ou accélèrer certains domaines et pas d’autres) et ne retransmettre correctement que ceux qui ont payé, ou bien rediriger ou il veulent n’importe quelle URL. Tu préfères donc utiliser ce service privé plutôt que le service public dns à cause d’une faille bientot obsolète pour cause d’ipv6, et qui n’a toujours pas d’exploit dix ans aprés sa découverte… Bon. ![:smt005](https://www.debian-fr.org/uploads/default/original/1X/cdd45e7dd754015ac5291329b843a2851a0d4fe8.gif) Pour info, j’ai réalisé que le “cache poisoning” ne pouvait intervenir que si le serveur acceptait des données entrantes. Si vous avez des dns non récursifs ou au pire secondaires uniquement pour des domaines logés en primaire uniquement sur des serveurs non récursifs (= le cas répandu des serveurs de zone intranet qui ne chargent rien venant de l’exterieur), ils ne sont pas susceptible d’être attaqués. Pas la peine de toucher à vos vieux 386 servant de dns d’entreprise sous bo (dommage pour ceux qui l’ont déjà fait 😆 ). ---
**Author:** ![tntprog](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/t/eada6e/32.png) [@tntprog](https://www.debian-fr.org/u/tntprog)\ **Post date:** [Février 20, 2016, 5:54 UTC](https://www.debian-fr.org/t/faille-de-conception-du-systeme-dns/14641/30 "2016-02-20T17:54:02Z")
[quote]Comme tu es prudent, tu préfères donc prendre tes infos de DNS auprés d’un prestataire privé qui pourrait, mettons, faire payer la retransmission des noms de domaines (ou accélèrer certains domaines et pas d’autres) et ne retransmettre correctement que ceux qui ont payé, ou bien rediriger ou il veulent n’importe quelle URL. Tu préfères donc utiliser ce service privé plutôt que le service public dns à cause d’une faille bientot obsolète pour cause d’ipv6, et qui n’a toujours pas d’exploit dix ans aprés sa découverte… Bon. ![:smt005](https://www.debian-fr.org/uploads/default/original/1X/cdd45e7dd754015ac5291329b843a2851a0d4fe8.gif) [/quote] Parce que tu penses qu’on peux faire plus confiance au service public en ce moment…? ![:mrgreen:](https://www.debian-fr.org/uploads/default/original/1X/cc83e9b583138e48ff45f96609046b06d06c7f9d.gif "Mr. Green") ---
**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\ **Post date:** [Février 20, 2016, 5:54 UTC](https://www.debian-fr.org/t/faille-de-conception-du-systeme-dns/14641/31 "2016-02-20T17:54:02Z")
[quote=“tntprog”]quoteTu préfères donc utiliser ce service privé plutôt que le service public (…) Bon. ![:smt005](https://www.debian-fr.org/uploads/default/original/1X/cdd45e7dd754015ac5291329b843a2851a0d4fe8.gif) [/quote]Parce que tu penses qu’on peux faire plus confiance au service public en ce moment…? ![:mrgreen:](https://www.debian-fr.org/uploads/default/original/1X/cc83e9b583138e48ff45f96609046b06d06c7f9d.gif "Mr. Green")[/quote]Bah y a pas encore le service minimum dns garanti ? Mais que fait Sarkocescu ? ---
**Author:** ![ripat](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/r/bc79bd/32.png) [@ripat](https://www.debian-fr.org/u/ripat)\ **Post date:** [Février 20, 2016, 5:54 UTC](https://www.debian-fr.org/t/faille-de-conception-du-systeme-dns/14641/32 "2016-02-20T17:54:03Z")
[quote=“mattotop”]Comme tu es prudent, tu préfères donc prendre tes infos de DNS auprés d’un prestataire privé qui pourrait, mettons, faire payer la retransmission des noms de domaines (ou accélèrer certains domaines et pas d’autres) et ne retransmettre correctement que ceux qui ont payé, ou bien rediriger ou il veulent n’importe quelle URL. Tu préfères donc utiliser ce service privé plutôt que le service public dns à cause d’une faille bientot obsolète pour cause d’ipv6, et qui n’a toujours pas d’exploit dix ans aprés sa découverte…[/quote] Je pensais être le seul à voir les méchants partout mais apparemment on est déjà deux… Quant au caractère public et désintéressé de mon ISP, j’ai des doutes. ---
**Author:** ![Grhim](https://www.debian-fr.org/user_avatar/www.debian-fr.org/grhim/32/5348_2.png) [@Grhim](https://www.debian-fr.org/u/Grhim)\ **Post date:** [Février 20, 2016, 5:54 UTC](https://www.debian-fr.org/t/faille-de-conception-du-systeme-dns/14641/33 "2016-02-20T17:54:03Z")
des news toutes fraiche sur zataz concernant la faille > [@](#): > > La faille visant le protocole DNS diffusée… par erreur [zataz.com/news/17479/DNS-Cac … ploit.html](http://www.zataz.com/news/17479/DNS-Cache-Poisoning--0day--exploit.html) [quote]Si la faille a été “rustinée”, elle est très loin d’être corrigée. La société Zynamics a diffusé lundi, par erreur, le concept de cette faille via un reverse engineering, une étude de la dite faille par un certain Halvar Flake, qui n’est rien d’autre que le patron de cette PME, Thomas Dullien [lire]. Bilan, les experts s’inquiètent à savoir si des pirates vont maintenant exploiter ces données. L’ingénieur en informatique qui avait découvert cette faille, Dan Kaminsky, de chez IOActive, doit démontrer et expliquer cette faille le 6 août prochain, lors du Black Hat de Las Vegas. [/quote] ---
**Author:** ![MisterFreez](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/m/bb73d2/32.png) [@MisterFreez](https://www.debian-fr.org/u/MisterFreez)\ **Post date:** [Février 20, 2016, 5:54 UTC](https://www.debian-fr.org/t/faille-de-conception-du-systeme-dns/14641/34 "2016-02-20T17:54:06Z")
> [@](#): > > Pour info, j’ai réalisé que le “cache poisoning” ne pouvait intervenir que si le serveur acceptait des données entrantes. Si vous avez des dns non récursifs ou au pire secondaires uniquement pour des domaines logés en primaire uniquement sur des serveurs non récursifs (= le cas répandu des serveurs de zone intranet qui ne chargent rien venant de l’exterieur), ils ne sont pas susceptible d’être attaqués. Pas la peine de toucher à vos vieux 386 servant de dns d’entreprise sous bo (dommage pour ceux qui l’ont déjà fait 😆 ). Donc pour mon tout nouveau cache DNS ça pose problème c’est ça ? 'fin il est à jour et ne reçoit de requête qu’en loop. ---
**Author:** ![ripat](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/r/bc79bd/32.png) [@ripat](https://www.debian-fr.org/u/ripat)\ **Post date:** [Février 20, 2016, 5:54 UTC](https://www.debian-fr.org/t/faille-de-conception-du-systeme-dns/14641/35 "2016-02-20T17:54:08Z")
Et bien ça y est. Un exploit est publié et déjà intégré dans la suite Metasploit bien connue des sysadmin et… script kiddies. [blogs.zdnet.com/security/?p=1545](http://blogs.zdnet.com/security/?p=1545) Si vous utilisez le DNS de votre FAI, testez sa résistance au bug. Il est temps. ---
**Author:** ![fran.b](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/f/d78d45/32.png) [@fran.b](https://www.debian-fr.org/u/fran.b)\ **Post date:** [Février 20, 2016, 5:54 UTC](https://www.debian-fr.org/t/faille-de-conception-du-systeme-dns/14641/36 "2016-02-20T17:54:10Z")
Pour ceux qui comme moi ont des serveurs sarge, j’ai fait un backport fonctionnel de bind9 etch patché. deb [boisson.homeip.net/debian](http://boisson.homeip.net/debian) sarge divers dig +short [porttest.dns-oarc.net](http://porttest.dns-oarc.net) TXT [z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net](http://z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net). “81.57.102.55 is GOOD: 32 queries in 545.4 seconds from 27 ports with std dev 18883.63” 🙂 Matt, tu sais que c’est le serveur de potato qui tournait 🙂 ---
**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\ **Post date:** [Février 20, 2016, 5:54 UTC](https://www.debian-fr.org/t/faille-de-conception-du-systeme-dns/14641/37 "2016-02-20T17:54:11Z")
quote="ripat" Quant au caractère public et désintéressé de mon ISP, j’ai des doutes.[/quote]Lui, non, mais son dns qui respecte la rfc, si. 😉 ---
**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\ **Post date:** [Février 20, 2016, 5:54 UTC](https://www.debian-fr.org/t/faille-de-conception-du-systeme-dns/14641/38 "2016-02-20T17:54:23Z")
Bon. Ceci étant, il y a du nouveau, l’exploit vient de sortir: [caughq.org/exploits/CAU-EX-2008-0002.txt](http://www.caughq.org/exploits/CAU-EX-2008-0002.txt) ---
**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\ **Post date:** [Février 20, 2016, 5:54 UTC](https://www.debian-fr.org/t/faille-de-conception-du-systeme-dns/14641/39 "2016-02-20T17:54:23Z")
[quote=“mattotop”]quote="ripat" Quant au caractère public et désintéressé de mon ISP, j’ai des doutes.[/quote]Lui, non, mais son dns qui respecte la rfc, si. 😉[/quote]Je viens de penser: rien n’empêche de s’installer un dns cache patché, et de ne déclarer aucun dns autres que les root-servers. Ca m’étonnerais qu’eux ne soient pas surprotègés contre les attaques. ---
**Author:** ![fran.b](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/f/d78d45/32.png) [@fran.b](https://www.debian-fr.org/u/fran.b)\ **Post date:** [Février 20, 2016, 5:54 UTC](https://www.debian-fr.org/t/faille-de-conception-du-systeme-dns/14641/40 "2016-02-20T17:54:25Z")
C’est ce que je fais pour le DNS du lycée où je travaille. [Page précédente](https://www.debian-fr.org/t/faille-de-conception-du-systeme-dns/14641.md?page=1) [Page suivante](https://www.debian-fr.org/t/faille-de-conception-du-systeme-dns/14641.md?page=3)