[FRnOG] [TECH] Chassons le résolveur DNS ouvert
Compte-tenu du danger de ces résolveurs ouverts, dénoncé depuis longtemps http://www.bortzmeyer.org/fermer-les-recursifs-ouverts.html http://www.rfc-editor.org/rfc/rfc5358.txt, et récemment illustré par l'attaque contre Spamhaus/Cloudflare, ce travail est l'occasion de se livre à une chasse aux résolveurs DNS ouverts sur votre réseau. Indiquez votre numéro d'AS à l'auteur et il vous indiquera les adresses dangereuses chez vous. --- Liste de diffusion du FRnOG http://www.frnog.org/ ---BeginMessage--- I've continued to update my dataset originally posted about two weeks ago. Please take a moment and review your CIDRs which may be running an open resolver. I've exposed one additional bit in the user-interface that may be helpful. Some DNS servers will respond with RCODE=0 (OK) but not provide recursion. nearly 90% of the servers in the database provide recursion. Some raw stats are also available via the 'breakdown' link on the main site. If you operate a DNS server, or have an internal group that does, please take a moment and review your networks. If you email me in private from a corporate address for your ASN, I can give you access to a per-ASN report. Due to a change in methodology, I have increased the number of servers observed from 27.2 million to 30.2 million hosts. 2013-04-07 results 30269218 servers responded to our udp/53 probe 731040 servers responded from a different IP than probed 25298074 gave the 'correct' answer to my A? for the DNS name queried. 13840790 responded from a source port other than udp/53 27145699 responses had recursion-available bit set. 2761869 returned REFUSED In addition, please do continue to deploy BCP-38 to prevent spoofing wherever possible. I know at $dayjob we have been auditing this and increased the number of customer interfaces that can not spoof. - Jared---End Message---
[FRnOG] [TECH] LLA et RFC1918 dans le backbone
Bonjour, Question technique existentielle pour bien démarrer la semaine. Je suis en plein design de plan d'adressage et de migration, et du coup en train de passer en revue les Best Current Practices. L'une des questions concerne l'adressage du backbone avec des adresses non routables ou au moins non routées. Je fais référence à ce draft de l'IETF : https://tools.ietf.org/html/draft-ietf-opsec-lla-only-03 Le cas est sensiblement différent que l'on parle d'IPv4 ou d'IPv6, même la question est différente d'ailleurs. En IPv4 : on pourrait vouloir adresser le backbone en RFC1918 afin d'économiser des adresses v4 publiques. On exclue le cas d'un backbone MPLS avec Internet dans une VRF, c'est pour la GRT dans ce cas. L'inconvénient en IPv4 est la lisibilité des traceroutes. L'inconvénient est qu'on bouffe au moins un /31 par interco, en plus d'un /32 pour la loopback habituellement. On *pourrait*, dans l'idée, utiliser des subnets en RFC1918 sur les intercos, tant qu'on en assure l'unicité, et n'annoncer que des loopbacks dans l'IGP. Pour le debug, on s'assurera que le routeur réponde aux messages ICMP depuis l'IP de la loopback. En prime, on y gagne une gestion plus facile des adresses de backbone : une seule IP publique par routeur, pas de quantité de reverse à gérer. L'inconvénient est qu'on pourrait vouloir cibler une interface précise en ICMP pour en surveiller l'état. Dans le draft LLA Only, les auteurs suggèrent de remonter ces infos autrement (SNMP / SSH). Dans le cas IPv4, des RFC1918 sont routables, il suffirait de les router dans le backbone pour pouvoir s'en servir à des fins de monitoring. Donc, en théorie, on peut utiliser du RFC1918 pour les intercos en GRT tant qu'on laisse des loopbacks en public et que le routeur accepte de spécifier l'interface dont doivent originer les réponses ICMP. J'ai trouvé facilement pour JunosE (ip icmp update-source) mais pas encore pour les autres. Est ce que ça vous semble correct ? En IPv6, au risque de répéter le draft, l'idée est d'utiliser des LLA _configurées statiquement_ et de n'annoncer que les loopbacks dans l'IGP. Même punition, même motif donc. Reste à savoir si la même bidouille que pour les réponses ICMP en v4 est implémentée en v6 dans nos routeurs. Des avis ? -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Chassons le résolveur DNS ouvert
On Sun, Apr 07, 2013 at 09:59:40PM +0200, Stephane Bortzmeyer bortzme...@nic.fr wrote a message of 161 lines which said: Indiquez votre numéro d'AS à l'auteur Donc, à Jared Mauch, pas à moi (je dis ça parce que j'ai déjà reçu plusieurs demandes). --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Chassons le résolveur DNS ouvert
Bonjour Stephane, Fermer les resolveurs ouverts ne résout pas le problème des DDoS amplifiés par DNS. Le jour où il n'y aura plus de serveur récursifs sur Internet (et ce n'est pas demain la veille), les attaques se feront sur les serveurs autoritaires. Il est plus facile de construire une liste de serveurs autoritaires que d'open-resolvers! La bonne solution c'est BCP-38 (rfc3704). Cordialement, Florent PS: Fermer les resolveurs ouverts, oui; mais pour différentes raisons: - least privilege - cache poisoning - cache snooping On Sun, 2013-04-07 at 21:59 +0200, Stephane Bortzmeyer wrote: Compte-tenu du danger de ces résolveurs ouverts, dénoncé depuis longtemps http://www.bortzmeyer.org/fermer-les-recursifs-ouverts.html http://www.rfc-editor.org/rfc/rfc5358.txt, et récemment illustré par l'attaque contre Spamhaus/Cloudflare, ce travail est l'occasion de se livre à une chasse aux résolveurs DNS ouverts sur votre réseau. Indiquez votre numéro d'AS à l'auteur et il vous indiquera les adresses dangereuses chez vous. --- Liste de diffusion du FRnOG http://www.frnog.org/ MHTML Document attachment (Open Resolver Dataset Update) Forwarded Message From: Jared Mauch ja...@puck.nether.net To: NANOG Group na...@nanog.org Subject: Open Resolver Dataset Update Date: Sun, 7 Apr 2013 13:46:14 -0400 I've continued to update my dataset originally posted about two weeks ago. Please take a moment and review your CIDRs which may be running an open resolver. I've exposed one additional bit in the user-interface that may be helpful. Some DNS servers will respond with RCODE=0 (OK) but not provide recursion. nearly 90% of the servers in the database provide recursion. Some raw stats are also available via the 'breakdown' link on the main site. If you operate a DNS server, or have an internal group that does, please take a moment and review your networks. If you email me in private from a corporate address for your ASN, I can give you access to a per-ASN report. Due to a change in methodology, I have increased the number of servers observed from 27.2 million to 30.2 million hosts. 2013-04-07 results 30269218 servers responded to our udp/53 probe 731040 servers responded from a different IP than probed 25298074 gave the 'correct' answer to my A? for the DNS name queried. 13840790 responded from a source port other than udp/53 27145699 responses had recursion-available bit set. 2761869 returned REFUSED In addition, please do continue to deploy BCP-38 to prevent spoofing wherever possible. I know at $dayjob we have been auditing this and increased the number of customer interfaces that can not spoof. - Jared signature.asc Description: This is a digitally signed message part
[FRnOG] Re: [TECH] Chassons le résolveur DNS ouvert
On Mon, Apr 08, 2013 at 09:03:48AM +0100, Florent Daigniere florent.daigni...@trustmatta.com wrote a message of 100 lines which said: Fermer les resolveurs ouverts ne résout pas le problème des DDoS amplifiés par DNS. En sécurité (ou en santé publique, domaine qui a beaucoup de points communs avec la sécurité de l'Internet) aucune mesure ne « résoud » les problèmes. On les minimise, c'est tout. Le jour où il n'y aura plus de serveur récursifs sur Internet (et ce n'est pas demain la veille), On peut dire cela (« ça va prendre des siècles ») de toutes les campagnes d'hygiène informatique (exemple de BCP 38 cité plus bas). C'est plutôt pour moi une raison pour commencer tout de suite. les attaques se feront sur les serveurs autoritaires. Je prends ma casquette de nazi grammairien deux secondes : un adjudant est autoritaire. Un serveur DNS fait autorité. Ensuite, je repasse à la technique : il y a déjà eu des attaques sur les serveurs faisant autorité. Comme toujours en sécurité (ou en santé publique), la question n'est pas trouver LA bonne technique. Il n'existe pas de balle en argent (comme disent les compatriotes de Stephenie Meyer). Il faut fermer les résolveurs ouverts *et* il faut sécuriser les serveurs faisant autorité. Ceci dit, si les serveurs faisant autorité présentent quelques avantages pour les attaquants (grosses machines bien connectées), ils ont aussi des inconvénients (contrairement aux résolveurs ouverts, ce sont en général des machines gérées, donc surveillées et avec déploiement de contre-mesures - comme la limitation de trafic). Il est plus facile de construire une liste de serveurs autoritaires que d'open-resolvers! Comme le montre le travail cité au début de ce fil, construire une liste de serveurs résolveurs ouverts est possible (et pas spécialement difficile, sans vouloir dire du mal de l'excellent travail de Jared Mauch). La bonne solution c'est BCP-38 (rfc3704). Mais c'est quoi cettte obsession de LA bonne et vraie solution ? Dans le monde réel, cela n'existe jamais. Si les geeks voulaient bien sortir de l'informatique et étudier les domaines qui ont ce genre de problème depuis des siècles (lutte contre la délinquance, santé publique), ils sauraient qu'il n'y a pas de solution magique, qu'il faut attaquer sur plusieurs fronts à la fois. Se demander s'il faut déployer BCP 38 OU BIEN fermer les résolveurs ouverts, c'est aussi à côté des pompes que de se demander s'il vaut se laver les mains OU BIEN développer des antibiotiques. IL FAUT LES DEUX. - cache poisoning - cache snooping Ces deux problèmes ne gènent que les utilisateurs du résolveur ouvert. Les attaques par amplification gênent tout l'Internet. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [TECH] Chassons le résolveur DNS ouvert
Le 08/04/2013 10:19, Stephane Bortzmeyer a écrit : les attaques se feront sur les serveurs autoritaires. Je prends ma casquette de nazi grammairien deux secondes : un adjudant est autoritaire. Un serveur DNS fait autorité. Tu m'avais déjà fait cette remarque mais en cherchant bien autorité en tant que nom féminin, je ne vois pas quel adjectif autre qu'autoritaire pour l'accoler à serveur dns sans mettre un verbe. En même temps un serveur dns faisant autorité est bien autoritaire puisqu'il impose sa réponse à une question donnée :) Quand on impose son point de vue on est bien autoritaire non? signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Re: [TECH] Chassons le résolveur DNS ouvert
On Mon, 2013-04-08 at 10:19 +0200, Stephane Bortzmeyer wrote: On Mon, Apr 08, 2013 at 09:03:48AM +0100, Florent Daigniere florent.daigni...@trustmatta.com wrote a message of 100 lines which said: Fermer les resolveurs ouverts ne résout pas le problème des DDoS amplifiés par DNS. En sécurité (ou en santé publique, domaine qui a beaucoup de points communs avec la sécurité de l'Internet) aucune mesure ne « résoud » les problèmes. On les minimise, c'est tout. Le jour où il n'y aura plus de serveur récursifs sur Internet (et ce n'est pas demain la veille), On peut dire cela (« ça va prendre des siècles ») de toutes les campagnes d'hygiène informatique (exemple de BCP 38 cité plus bas). C'est plutôt pour moi une raison pour commencer tout de suite. les attaques se feront sur les serveurs autoritaires. Je prends ma casquette de nazi grammairien deux secondes : un adjudant est autoritaire. Un serveur DNS fait autorité. Ensuite, je repasse à la technique : il y a déjà eu des attaques sur les serveurs faisant autorité. Comme toujours en sécurité (ou en santé publique), la question n'est pas trouver LA bonne technique. Il n'existe pas de balle en argent (comme disent les compatriotes de Stephenie Meyer). Il faut fermer les résolveurs ouverts *et* il faut sécuriser les serveurs faisant autorité. Un problème peut avoir une solution ultime. Dans ce cas précis, si le problème est: Les attaques DDoS par amplification DNS, la solution c'est d'empêcher le spoofing à la source; pas de changer la configuration des serveurs DNS. Ceci dit, si les serveurs faisant autorité présentent quelques avantages pour les attaquants (grosses machines bien connectées), ils ont aussi des inconvénients (contrairement aux résolveurs ouverts, ce sont en général des machines gérées, donc surveillées et avec déploiement de contre-mesures - comme la limitation de trafic). Il est plus facile de construire une liste de serveurs autoritaires que d'open-resolvers! Comme le montre le travail cité au début de ce fil, construire une liste de serveurs résolveurs ouverts est possible (et pas spécialement difficile, sans vouloir dire du mal de l'excellent travail de Jared Mauch). La bonne solution c'est BCP-38 (rfc3704). Mais c'est quoi cettte obsession de LA bonne et vraie solution ? Dans le monde réel, cela n'existe jamais. Si les geeks voulaient bien sortir de l'informatique et étudier les domaines qui ont ce genre de problème depuis des siècles (lutte contre la délinquance, santé publique), ils sauraient qu'il n'y a pas de solution magique, qu'il faut attaquer sur plusieurs fronts à la fois. Si BCP-38 était implémenté, cela résoudrait toute une famille d'attaques par amplification - DNS, mais aussi smurfing, ... https://en.wikipedia.org/wiki/Smurf_attack Se demander s'il faut déployer BCP 38 OU BIEN fermer les résolveurs ouverts, c'est aussi à côté des pompes que de se demander s'il vaut se laver les mains OU BIEN développer des antibiotiques. IL FAUT LES DEUX. Je ne suis pas d'accord. Ni sur le fond, ni sur le choix de la métaphore. C'est un cas classique: Donner des solutions sans formuler le problème. Le problème c'est vous qui l'avez formulé: premier paragraphe sur votre blog: Suite, notamment, à une nouvelle attaque - cache poisoning - cache snooping Ces deux problèmes ne gènent que les utilisateurs du résolveur ouvert. Les attaques par amplification gênent tout l'Internet. On est d'accord sur ce point. signature.asc Description: This is a digitally signed message part
Re: [FRnOG] [TECH] Fibre optique pro dans les réseau d'initiative publique
Le 6 avr. 2013 à 08:33, Rémi Bouhl remibo...@gmail.com a écrit : Et pourtant, c'est la volonté publique qui nous a doté d'un réseau de téléphonie RTC partout en France. Et c'est cette même volonté publique qui en même temps faisait le choix de la commutation par paquet en mode connecté, renvoyant dans leurs 22m ceux qui avaient l'outrecuidance de préconiser une approche alternative non connectée. Car, vous comprenez, faire le choix du X.25, c'était assurer la pérennité des champions nationaux de l'industrie électronique. Cette même volonté publique qui 20 ans plus tard estimait du temps du monopole que l'ADSL n'avait pas vocation à couvrir plus de la moitié des lignes. Et que l'avenir, c'était ATM, fierté nationale, et surtout pas Ethernet ce truc qui n'est pas de chez nous tout juste bon à connecter des PC entre eux. --- Le lancement de Wanadoo s'est opéré sur une infrastructure surchargée et mal adaptée au transport de données sur Internet. De même, le nombre d'accès en mode Internet au réseau de transport de données s'est révélé rapidement insuffisant pour permettre une bonne qualité de service. Cette situation a beaucoup nui à la qualité de l'Internet grand public en France. --- dixit La Cour des Comptes, dans son rapport annuel de 1999, qui revenait sur la politique de FT héritière de la DGT dans les services en ligne sur 1991/1996, p.970 (http://www.ladocumentationfrancaise.fr/var/storage/rapports-publics/004000257/.pdf pour les flemmards). Donc clairement si Dieu avait voulu que la volonté publique domine le monde de la vraie vie des réseaux, Cisco s'appellerait Alcatel. -- Alec, --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Fibre optique pro dans les réseau d'initiative publique
On 2013-04-08 16:21, Alexandre Archambault wrote: Le 6 avr. 2013 à 08:33, Rémi Bouhl remibo...@gmail.com a écrit : Et pourtant, c'est la volonté publique qui nous a doté d'un réseau de téléphonie RTC partout en France. Et c'est cette même volonté publique qui en même temps faisait le choix de la commutation par paquet en mode connecté, renvoyant dans leurs 22m ceux qui avaient l'outrecuidance de préconiser une approche alternative non connectée. Car, vous comprenez, faire le choix du X.25, c'était assurer la pérennité des champions nationaux de l'industrie électronique. c'est pas spécifique à la France, les États-Uniens, à la même période, faisaient eux aussi, un usage immodéré de X.25, puis de son recyclage ultérieur en Frame Relay... --- Le lancement de Wanadoo s'est opéré sur une infrastructure surchargée et mal adaptée au transport de données sur Internet. De même, le nombre d'accès en mode Internet au réseau de transport de données s'est révélé rapidement insuffisant pour permettre une bonne qualité de service. Cette situation a beaucoup nui à la qualité de l'Internet grand public en France. --- marrant... maintenant, on pourrait en dire de meme de l'infrastructure d'interconnexion du réseau proxad avec le reste du monde. ca sature entre 18h et 4h du matin, tous les jours Alec, au fait, c'en est ou la video de ton troll a la dernière réunion ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] LLA et RFC1918 dans le backbone
Le 8 avril 2013 09:42, Jérôme Nicolle jer...@ceriz.fr a écrit : En IPv6, au risque de répéter le draft, l'idée est d'utiliser des LLA _configurées statiquement_ et de n'annoncer que les loopbacks dans l'IGP. Même punition, même motif donc. Reste à savoir si la même bidouille que pour les réponses ICMP en v4 est implémentée en v6 dans nos routeurs. Ta question fait echo sur ce point à cette discussion sur ipv6-ops de la semaine dernière: http://lists.cluenet.de/pipermail/ipv6-ops/2013-April/008741.html La norme sur ICMPv6 dit que le device doit prendre l'adresse qu'il prendrait normalement pour envoyer un message au destinataire - la source d'origine (cas ttl expired du traceroute par exemple): http://tools.ietf.org/html/rfc4443#section-2.2 the Source Address of the ICMPv6 packet MUST be a unicast address belonging to the node. The address SHOULD be chosen according to the rules that would be used to select the source address for any other packet originated by the node, given the destination address of the packet. D'expérience, ça ne marche pas forcément sur tout le matos; certains prennent celle de l'iface d'arrivée (même si link local), d'autres une au pif parmi celles dispo, d'autres l'adresse source d'origine (!!!), etc.. Mon avis serait pour IPv6 d'adresser tes liens avec des adresses publiques uniques redistribuées dans ton IGP *pour le moment*. Ce qui t'évitera d'avoir trop de comportements étranges à troubleshooter. Guillaume --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] LLA et RFC1918 dans le backbone
Salut Guillaume, Le 08/04/2013 17:10, Guillaume Leclanche a écrit : Ta question fait echo sur ce point à cette discussion sur ipv6-ops de la semaine dernière: Oh chic, un peu de lecture :D La norme sur ICMPv6 dit que le device doit prendre l'adresse qu'il prendrait normalement pour envoyer un message au destinataire - la source d'origine (cas ttl expired du traceroute par exemple): J'ai pour habitude de sourcer telnet / ssh de la loopback dédiée, mais je ne trouves pas de commande similaire pour ICMP. J'en conclue qu'à priori la source de réponse étant déterminée par voir plus ou moins pifométrique, fonction du constructeur, ça complique pas mal les choses. Et ce aussi bien en v4 qu'en v6. Peut-on en conclure que l'utilisation de LLA ou RFC1918 sur les intercos ne peut pas être dissimulé au traceroute ? @+ -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Chassons le résolveur DNS ouvert
Le 8 avr. 2013 à 10:29, Wallace wall...@morkitu.org a écrit : Le 08/04/2013 10:19, Stephane Bortzmeyer a écrit : les attaques se feront sur les serveurs autoritaires. Je prends ma casquette de nazi grammairien deux secondes : un adjudant est autoritaire. Un serveur DNS fait autorité. Tu m'avais déjà fait cette remarque mais en cherchant bien autorité en tant que nom féminin, je ne vois pas quel adjectif autre qu'autoritaire pour l'accoler à serveur dns sans mettre un verbe. Référent serait à mon sens le plus proche de cette idée dans le sens que sa réponse fait référence. Cordialement Emmanuel Thierry --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [TECH] Chassons le résolveur DNS ouvert
2013/4/8 Wallace wall...@morkitu.org En même temps un serveur dns faisant autorité est bien autoritaire puisqu'il impose sa réponse à une question donnée :) Quand on impose son point de vue on est bien autoritaire non? Ah ben non, dans ce cas on est péremptoire. Ça sonne bien ça, « serveur DNS péremptoire » ;-) -- Guillaume, péremptoirement. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Chassons le résolveur DNS ouvert
Le 07/04/2013 21:59, Stephane Bortzmeyer a écrit : Indiquez votre numéro d'AS à l'auteur et il vous indiquera les adresses dangereuses chez vous. Je serais curieux de savoir comment il fait ? S'agit t'il d'un nmap de tous les préfixes de l'AS et vérification des ports 53 ouverts ? Solarus --- Liste de diffusion du FRnOG http://www.frnog.org/
