Il y a quelques semaines, certains serveurs DNS avaient été patchés pour corriger une faille de sécurité, dont BIND si je ne me trompe pas.
Apparemment, BIND aurait besoin d'un second patch :
Evgeniy Polyakov a réussi à "contaminer" un serveur Bind (version 9.5.0-P2 dans le test) en 10 heures. Certes, il a utilisé deux PC reliés en gigabit ethernet avec le serveur BIND.
Réf :
http://www.nytimes.com/2008/08/09/technology/09flaw.html
http://tservice.net.ru/~s0mbre/blog/devel/networking/dns/200(...)
Journal BIND, 2ème édition
12
août
2008
# Bah oui...
Posté par Aefron . Évalué à 10.
Le problème est déjà inhérent à l'utilisation, pour quelque chose d'aussi crucial que la résolution de noms, d'un truc comme UDP, qui ne va garantir en rien que c'est bien la bonne personne qui nous répond ; surtout si les vilain-méchants sont en train de faire un DDOS sur le serveur qui a autorité à nous répondre, sur internet (typiquement, le serveur DNS du FAI) et le mettent à genoux...
Bon, on a quand même des contre-mesures... comme le TXID, qui va donner un numéro à la demande d'un nom à un serveur, et n'accepter que la réponse contenant ce numéro... sauf que 16 bits de contre-mesure, ça devient un peu léger, vu les vitesses des connexion actuelles, ainsi que l'ardeur et l'astuce que prennent les attaques...
... alors, pour donner du mou, tout le monde est plus ou moins passé aux ports sources aléatoires : en gros, on va changer le port par lequel on fait une demande à chacune d'elles, et de manière crytpologiquement aléatoire, ie, pas une simple incrémentation ou toujours le même port. Il devient alors plus difficile de deviner comment envoyer une fausse-bonne réponse à notre résolveur. Et zou, 16 bits en plus pour deviner comment créer une réponse plausible.
En gros, on essaye de ne pas écouter n'importe quoi, n'importe comment, mais sans authentification, et sur UDP : une technique de renard, certes, mais de renard galeux...
Maintenant, c'est un problème d'échelle : pour avoir une bonne contre-mesure, il faut avoir assez d'entropie pour rendre moins prédictible le forgeage d'une réponse, qu'il soit déraisonnable d'espérer empoisonner le cache... bon, maintenant, tout le monde essaye de faire sur 32 bits... youpi. Mais forcément, avec une connexion énorme sur laquelle écouter les réponses de tout et n'importe quoi, les 32 bits, ils deviennent faiblards... rien de bien neuf sous le soleil.
Après, surtout si on a une grosse connexion comme ça, on commence peut-être par filtrer les adresses auxquelles le resolver-cache est autorisé à poser des questions et recevoir des réponses, plutôt que d'autoriser n'importe qui à lui répondre n'importe quoi.
... et un jour, on pourra peut-être espérer avoir un accès authentifiant aux DNS externes auxquels on donne autorité... m'enfin, d'ici à ce que DNSSEC se généralise partout, vu qu'il semble qu'il faille déjà saluer l'ensemble de l'industrie pour avoir quand même mis 6 mois après de nouvelles méthodes bien plus dangereuses d'empoisonnement de cache, avant de rajouter 16 bits d'entropie à un truc bancal qui menaçait de plus en plus de se casser la gueule, on a le temps de voir passer quelques gros orages... Gare à toi, Tata Jeanine...
Ou alors, ils vont nous faire un truc du genre de ce qu'ils font avec les serveurs SMTP : on ne pourra contacter que les serveurs DNS de nos FAI... au passage, ça permettrait de faire un petit low-kick-balayette aux crypto-communistes qui se servent d'autres DNS pour passer outre les restrictions bienveillantes des autorités, même si ça n'empêcherait toujours pas de passer par Tor et de demander à l'exit-node de faire la résolution de nom lui-même...
[^] # Re: Bah oui...
Posté par Maclag . Évalué à 1.
...
...
Le Tor dont tu parles, il a un rapport avec la mythologie nordique?
-----------> [ ]
[^] # Re: Bah oui...
Posté par fox (site web personnel) . Évalué à 2.
[^] # Re: Bah oui...
Posté par M . Évalué à 2.
C'est difficile :
- dans les fausses réponses que tu envoies tu peux même une adresse IP source que tu veux (donc pas filtrée).
[^] # Re: Bah oui...
Posté par M . Évalué à 3.
PS : c'est possible parce que c'est de l'UDP (contrairement au SMTP) et que tu n'attends pas de réponse.
PS2: une solution serait de forcer le passage à tcp, mais ça passera pas à l'echelle
[^] # Et SCTP ?
Posté par benoar . Évalué à 3.
SCTP a été créé par l'IETF pour avoir le meilleur des mondes de TCP et d'UDP, tout en ayant le choix d'avoir des données réordonnées ou non. Il est vraiment très peu (voire pas ?) utilisé actuellement, mais ça a l'air d'être l'avenir. Il a quand même un gros défaut : il n'est pas implémenté dans Windows ....
Bon, niveau sécurité, il ne fait pas mieux que les 32 bits qu'on a avec ce patch des DNS (quoique, je ne sais pas exactement comment se passe cette vérification), mais TCP c'est pareil ....
[^] # Re: Et SCTP ?
Posté par Epy . Évalué à 3.
Ils ont un train de retard mais ce n'est pas nouveau, en tout cas si les serveurs du monde se mettent petit à petit à un nouveau protocole pour des raisons de sécurité, ils y viendront rapidement !
Par contre, est-ce implémentable "par dessus" c'est à dire avec une mise à jour de l'OS ? (je pose la question pour Windows, pour les GNU/Linux et BSD j'imagine que ça l'est vu la modularité)
[^] # Re: Et SCTP ?
Posté par inico (site web personnel) . Évalué à 1.
- http://www.sctp.be/sctplib/ (vieux et pour Windows XP)
- http://www.co-conv.jp/en/product/sctpDrv/20080313/ (récent et pour XP et Vista)
Pour aprés, le souci c'est toute la partie UI.
[^] # Re: Et SCTP ?
Posté par M . Évalué à 3.
Parce que TCP serait deja mieux que UDP, mais les serveurs ne tiendrait pas la charge...
[^] # Re: Et SCTP ?
Posté par benoar . Évalué à 2.
[^] # Re: Et SCTP ?
Posté par Aefron . Évalué à 4.
Parce que le système est déjà au taquet... cf les excellents liens sur le blog de Dan Kaminsky, donnés par Matthieu C ci-dessous (qui changent de la "merde de taureau" usuelle comme quoi "c'est trop génial, tout le monde a patché, on est trop saikioure").
... si la bande passante et le reste des ressources des serveurs root n'est pas dimensionnée pour encaisser le double de paquets, avec du statefull en prime, c'est de toute façon mort pour le moment. Pas plus TCP que DNSSEC ne sont alors implémentables en l'état...
C'est moche... mais on ne fait pas bouger les DNS root (et tout ce qui est derrière... toutes les boxes diverses et avariées ont-elles les moyens d'encaisser du DNSSEC de manière confortable ? Je n'en sais rien...) comme ça... déjà que c'est la merde pour ne serait-ce que savoir qui a le droit d'en avoir un sur son territoire... et ça prendra encore beaucoup de temps avant d'avoir quelque chose de propre à ce niveau, aussi capital qu'il soit...
M'enfin, le gros net mondial "sekioure", ce n'est pas comme si des gens sérieux croyaient que les homo sapiens (voire sapiens) étaient déjà arrivés à le mettre en place... ... ... si ?
[^] # Re: Et SCTP ?
Posté par herodiade . Évalué à 5.
Les serveurs, même de taille modeste tiendraient la charge il me semble (sauf peut-être les root servers ?). Surtout s'ils utilisent les syncookies et ont suffisamment de RAM.
Les problèmes que causeraient une utilisation systématique de TCP pour le DNS sont plutôt les risques liés aux congestion, et aux augmentations de latence.
Le premier type de problème (congestion) n'est pas insoluble. L'augmentation du débit n'a pas que des conséquences néfastes (comme la possibilité de flooder/bruteforcer les DNS), elle permet aussi de gérer un trafic légitime plus important ; les outils de routage et de QoS se sont améliorés depuis l'invention du DNS en 1983 :).
La latence des réseaux s'est aussi améliorée, mais une généralisation absolue du TCP pour le DNS n'est pas possible bien sûr. Il faudrait toujours des solution de replis pour par ex. les liaisons satellites, gprs, TOR, & co, quitte à ce que les providers leurs fournissent des caches qui fassent passerelles UDP en interne <->TCP vers le monde. Je crois - de mémoire - que MaraDNS fournis un proxy de ce type, et il y a aussi le proxy de TOR (ttdnsd).
Sinon, notez au passage que le protocole DNS prescrit _déjà_ le support TCP (utilisation obligatoire pour les paquets de plus de 512 bytes, utilisation facultative en deçà). Les serveurs DNS (et les bibliothèques de résolution des OS) implémentent ce support depuis longtemps déjà.
L'article DNS de la Wikipédia en langue anglaise dit que le resolver d'HP-UX utilise déjà systématiquement TCP pour ses requêtes DNS. J'adorerais avoir la même possibilité de forcer l'utilisation systématique de TCP sous Linux aussi (par ex. avec une option de resolv.conf). Et aussi, de pouvoir paramétrer un cache bind de la sorte (ie. "utilisation systématique de TCP pour toutes les requêtes sortantes / partout où je ne suis pas authoritative").
Ah, aussi : OpenDNS fournis des serveurs DNS récursifs publics supportant le TCP.
Enfin : TCP seul (sans crypto, ie. DNSEC )laissant la possibilité d'attaques man-in-the-middle, ce n'est pas suffisant pour se protéger des censures/redirections de traffic au niveau des opérateurs et des FAI. Je crois que c'est ainsi que l'Italie bloque l'accès à The Pirate Bay, et je ne serais pas surpris que notre gouvernement actuel (ou une loi européenne) contraigne les FAI à ce genre de cochonneries...
[^] # Re: Et SCTP ?
Posté par Hank Lords . Évalué à 1.
L'article DNS de la Wikipédia en langue anglaise dit que le resolver d'HP-UX utilise déjà systématiquement TCP pour ses requêtes DNS.
C'est selon moi une violation grave des rfcs qui n'exigent pas qu'un serveur dns accepte du tcp. Si les resolvers d'HP-UX font vraiment ça, ils sont serieusement bogués.
[^] # Re: Et SCTP ?
Posté par herodiade . Évalué à 1.
Ouais, d'après la page de man, à l'heure actuelle il semble qu'UDP soit le choix par défaut, puis que le resolver offre une option pour forcer le TCP. A moins que la phrase de WP signifie que les utilitaires systèmes d'HP-UX requètent explicitement avec le bit RES_USEVC ? http://docs.hp.com/en/B3921-90010/resolver.3N.html
> des rfcs qui n'exigent pas qu'un serveur dns accepte du tcp.
La RFC 1035 n'« exige » (must ou shall) rien mais indique, si l'on peut dire à pied d'égalité (section 4.2) « The Internet supports name server access using TCP [RFC-793] on server port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP port 53 (decimal) ». Et précise aussi : « Messages carried by UDP are restricted to 512 bytes ».
La RFC 1034 discute d'ailleurs brièvement de l'utilisation de TCP dans les resolvers (et précise, à toutes fins utiles que « Because accuracy is essential, TCP or some other reliable protocol must be used for AXFR requests. » (encore heureux)).
[^] # Re: Et SCTP ?
Posté par Hank Lords . Évalué à 1.
D'après la RFC 1123 Requirements for Internet Hosts -- Application and Support :
6.1.3.2 Transport Protocols
DNS resolvers and recursive servers MUST support UDP, and SHOULD support TCP, for sending (non-zone-transfer) queries. Specifically, a DNS resolver or server that is sending a non-zone-transfer query MUST send a UDP query first. If the Answer section of the response is truncated and if the requester supports TCP, it SHOULD try the query again using TCP.
DNS servers MUST be able to service UDP queries and SHOULD be able to service TCP queries. A name server MAY limit the resources it devotes to TCP queries, but it SHOULD NOT refuse to service a TCP query just because it would have succeeded with UDP.
Là c'est clair, un resolver doit faire une requête UDP avant une requête TCP. (Et le serveur devrait savoir répondre en TCP).
La RFC 1034 discute d'ailleurs brièvement de l'utilisation de TCP dans les resolvers (et précise, à toutes fins utiles que « Because accuracy is essential, TCP or some other reliable protocol must be used for AXFR requests. » (encore heureux)).
De mon point de vue, les RFCs qui spécifient le protocole DNS sont mal écrites. D'une part il y'en a beaucoup, éparpillées un peu partout, certaines tentant de décrire des bonnes pratiques, de clarifier les anciennes, de pallier a des limitations arbitraires (les fameux 512 octets), etc...
Ces problèmes découlent du fait qu'elles sont écrites en pensant uniquement à l'implémentation de référence BIND.
Par exemple, selon moi les transfert de zone (AXFR) ne font pas partie du protocole DNS, c'est une problématique satellite. Il existe d'autre méthodes pour transferer ses zones : http, rsync, ssh, par clé USB, etc...
[^] # Re: Et SCTP ?
Posté par herodiade . Évalué à 2.
Ah bin oui, tu as tout à fait raison.
> selon moi les transfert de zone (AXFR) ne font pas partie du protocole DNS,
> c'est une problématique satellite. Il existe d'autre méthodes pour transferer
> ses zones : http, rsync, ssh, par clé USB, etc...
Ah oui mais là ton transfert n'est pas interopérable entre serveurs : ça devient un transfert de fichiers au format d'une implémentation de serveur DNS. Or interop => protocole+specs, c'est donc pas plus mal que cette question soit normalisée ;)
Un autre intérêt d'AXFR, c'est que le proto est implémenté par le serveur lui-même (au lieu d'un outil externe comme rsync), et ça lui permet de savoir qu'il doit recharger la zone dès qu'elle est rafraichie (rsync, ssh ou http ne font que transférer des fichiers, sans se préoccuper de l'applicatif).
Cela dit, je suis d'accord pour le qualificatif de « problématique satellite ».
# ...
Posté par M . Évalué à 4.
Les slides du même monsieur a black hat sont très intéressante : http://www.doxpara.com/?p=1204
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.