RFC 6952 : Analysis of BGP, LDP, PCEP and MSDP Issues According to KARP Design Guide
Dans le cadre du travail du groupe KARP de l’#IETF, consacré à la sécurisation des protocoles de #routage de l’Internet, ce #RFC est consacré à l’analyse de la sécurité des protocoles de routage utilisant TCP, notamment #BGP.
Bon, je refais un article en partant de zéro, pour stocker les informations sur l’attaque par déni de service Spamhaus/Cloudflare de ce mois de mars, celle présentée comme la plus grande qu’ait jamais connu l’Internet.
Ds articles généralistes, par CBC http://www.cbc.ca/news/world/story/2013/03/27/spamhaus-attack.html et par le New York Times ►http://www.nytimes.com/2013/03/27/technology/internet/online-dispute-becomes-internet-snarling-attack.html et en français par le Figaro http://www.lefigaro.fr/hightech/2013/03/27/01007-20130327ARTFIG00712-une-cyberattaque-geante-perturbe-le-trafic-intern
Un article sérieux mais reprenant un peu trop ce que dit CloudFlare sans nuancer http://arstechnica.com/security/2013/03/spamhaus-ddos-grows-to-internet-threatening-size
L’article technique par CloudFlare : ►http://blog.cloudflare.com/the-ddos-that-almost-broke-the-internet
Contrairement à ce que dit CloudFlare, rien de spectaculaire à l’AMS-IX : https://www.ams-ix.net/technical/statistics ou au DECIX : http://www.de-cix.net/about/statistics
Un bon article critique, expliquant qu’il y a une différence entre l’attaque (bien réelle) et la proclamation comme quoi l’Internet aurait été globalement affecté (ce que personne n’a constaté) : http://gizmodo.com/5992652 Un démenti (partiel) de cet article explique bien la différence entre « l’attaque a eu un impact » et « l’Internet est mort » : ►http://cluepon.net/ras/gizmodo
Un très bon article en français expliquant bien les détails
http://pro.clubic.com/it-business/securite-et-donnees/actualite-550362-spamhaus-ddos-cyberbunker.html En plus court et avec un bon dessin : http://www.lesinrocks.com/2013/03/29/actualite/cyberattaque-nucleaire-non-internet-ne-va-pas-seffondrer-11379197
Précédent article sur Seenthis : ►http://seenthis.net/messages/125474
Le danger des résolveurs DNS ouverts : http://www.bortzmeyer.org/5358.html et http://www.bortzmeyer.org/fermer-les-recursifs-ouverts.html
BCP 38, ou la nécessité d’epêcher l’usurpation d’adresses IP source : http://www.bortzmeyer.org/2827.html http://www.bortzmeyer.org/3704.html
(merci) Voir aussi :
http://www.mail-archive.com/frnog@frnog.org/msg23506.html
Ce serait la version hollandaise du buzz Carambar.
#cybersécurité #dns #marketing
So, what you actually saw here was an attack affecting a large number of smaller networks, with something which was really a completely unrelated and unintended side-effect of the original attack. It’s not going to take down the Internet, but it’s certainly a recipe for having a lot of people talking about it.
►http://cluepon.net/ras/gizmodo #interconnexion #peering (des liens au bas de l’article)
Ce faisant je retombe sur cet article #résilience :
How to destroy the internet
►http://gizmodo.com/5912383/how-to-destroy-the-internet
►http://www.slate.fr/story/71673/peut-on-casser-internet
Et donc :
http://seenthis.net/messages/7699
http://seenthis.net/messages/16077
Plus technique, l’attaque vue du côté de #BGP : http://www.bgpmon.net/looking-at-the-spamhouse-ddos-from-a-bgp-perspective
RFC 5575 : Dissemination of Flow Specification Rules
Lorsqu’on a un grand réseau compliqué, diffuser à tous les routeurs des règles de filtrage, par exemple pour faire face à une #attaque_par_déni_de_service, peut être complexe. Il existe des logiciels permettant de gérer ses routeurs collectivement mais ne serait-il pas plus simple de réutiliser pour cette tâche les protocoles existants et notamment #BGP ? On profiterait ainsi des configurations existantes et de l’expérience disponible. C’est ce que se sont dit les auteurs de ce #RFC. « #FlowSpec » (nom officieux de cette technique) consiste à diffuser des règles de traitement du trafic en BGP, notamment à des fins de filtrage.
Un cas d’utilisation d’un préfixe AfriNIC en dehors de l’Afrique
On le sait, les adresses IPv4 sont désormais épuisées dans la plupart des régions du monde et pas mal de sites n’ont toujours pas déployé IPv6, rendant cette pénurie pénible. Il est donc tentant, plutôt que de faire l’effort d’un passage à IPv6, d’aller chercher des adresses IPv4 là où il y en a encore, notamment en #Afrique. On a souvent dit que des entreprises extérieures au continent allaient « faire leurs courses » en Afrique en créant une filiale bidon qui allait demander à #AfriNIC des adresses qui seraient ensuite annoncées ailleurs. Mais, là, c’est plus amusant, c’est un préfixe qui fait partie de la réserve AfriNIC mais qui n’est pas enregistré.
RFC 6810 : The RPKI/Router Protocol
http://www.bortzmeyer.org/6810.html
Le protocole décrit dans ce #RFC fait partie de la grande famille des RFC sur la #RPKI, un ensemble de mécanismes permettant de sécuriser le #routage sur l’Internet. Il traite un problème bien particulier : comme la validation des annonces de route, potentiellement complexe en cryptographie, se fait typiquement sur une machine spécialisée, le cache validateur, comment communiquer le résultat de ces validations au routeur, qui va devoir accepter ou rejeter des routes ? C’est le rôle d’un nouveau protocole, #RTR (« RPKI/Router Protocol »), un protocole très simple.
RFC 6811 : BGP Prefix Origin Validation
http://www.bortzmeyer.org/6811.html
Il manquait un élément dans les normes de la sécurisarion du routage avec RPKI+ROA, une description de la façon exacte dont on valide une annonce #BGP lorsqu’on a des #ROA (« Route Origin Authorizations ») pour ce préfixe. Ce RFC comble ce manque. Jusqu’à présent, en suivant les RFC, on pouvait distribuer des certificats authentifiant le titulaire d’un préfixe IP (la RPKI) et on pouvait émettre des autorisations, pour un AS, d’annoncer un préfixe (les ROA). Désormais, on peut utiliser RPKI et ROA pour avoir une solution de sécurité complète.
Very good analysis of a recent #BGP hijacking, the one by Avenir Télématique. Its peculiarity is that the origin in the AS path was not modified.
La #Syrie est désormais presque complètement déconnectée de l’Internet. Bien qu’il n’y ait évidemment pas eu d’annonce officielle, l’hypothèse la plus vraisemblable est que le gouvernement a coupé l’accès extérieur, comme cela avait été fait en Égypte ou en Lybie.
Trois bons articles techniques sur la question :
http://www.renesys.com/blog/2012/11/syria-off-the-air.shtml
http://www.bgpmon.net/syria-shuts-down-the-internet
http://blog.cloudflare.com/how-syria-turned-off-the-internet
Un résumé convenable en français :
http://www.20minutes.fr/monde/syrie/1052910-syrie-rayee-carte-internet
#BGP
Nouveau cas de détournement de préfixe IP via #BGP, la victime était Google et le crétin incompétent #Moratel, un opérateur indonésien (dont le fournisseur amont est #PCCW, le même qui était le fournisseur de Pakistan Telecom dans l’affaire du détournement de YouTube).
http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about
Le routage, enjeu de cyberstratégie | Lois des réseaux
►http://reseaux.blog.lemonde.fr/2012/11/04/routage-enjeu-cyberstrategie
Aujourd’hui, l’Internet connaît deux problèmes politiques majeurs au niveau mondial : la sécurité et les modèles économiques des échanges entre les acteurs. Quand on analyse le fond des choses, on tombe forcément sur le fonctionnement du routage.
De plus, les États ont besoin de définir leurs cyber-stratégies. Or, mis à part les États-Unis, la Chine et une poignée de petit pays, les autres États commencent tout juste à appréhender les informations et les raisonnements nécessaires pour comprendre ce qui se passe dans les couches basses.
L’Internet est un réseau virtuel bâti sur du réel. C’est un nuage qui prend solidement ses assises dans du béton. Par ses fibres optiques, par ses satellites, par l’environnement politique, légal et économique, l’Internet présente des contraintes physiques, géographiques, économiques, politiques qui ont nécessité des investissements colossaux. La géographie de l’Internet, ce qu’on appelle la cyber-géographie est un enjeu majeur de la cyber-stratégie.
Il existe bien des zones de non-droits dans l’Internet (Salamatian préfère dire « zones grises ») mais elles ne sont pas là où le grand public pense qu’elles sont. L’interconnexion des domaines (routage) est l’enjeu de stratégies politique et commerciales. Ce peut être, à mon avis, un puissant moyen de contrôle ou d’influence de l’opinion. #Internet
Dans cet interview, Kavé Salamatian, chercheur en réseaux, explique le routage, BGP, les AS, etc et insiste que le fait que ces questions qui semblaient purement techniques ont une forte composante politique et stratégique. (Rafik Dammak me fait remarquer que c’est un effet WCIT : la renégociation en cours des accords internationaux sous l’égide de l’UIT fait qu’on se met à parler de ces questions de routage que l’ICANN, par exemple, a toujours soigneusement ignorées.)
Des formules choc (« BGP est le gluant de l’Internet », « le syndrome de la mobylette pakistanaise », « [l’Internet est] un nuage qui prend solidement ses assises dans du béton »), et pas trop d’erreurs techniques (personnellement, le fait qu’il confonde DNS et noms de domaines - quand il prétend qu’on peut aller sur facebook.com sans le DNS - m’embête).
Mais pas d’information inédite, rien de nouveau. Et, surtout, après les promesses du titre et du chapô, une grande frustration : aucune opinion politique exprimée, pas de ligne stratégique. L’auteur nous répète qu’il y a des enjeux politiques super-importants derrière le routage mais n’en expose aucun.
Sa seule prise de position est qu’il faut réguler le peering (« une régulation mondiale pourrait poser les cadres d’une connectivité minimale » et « pour les problèmes de BGP hijack et autres attaques informatiques, il faudrait pouvoir recourir à un tribunal arbitral »). mais il ne dit même pas dans quel sens. Obliger les récalcitrants à peerer ? Au contraire, devoir faire approuver chaque accord de peering par le Haute Autorité de Régulation de l’Internet National ?
PS : je ne suis pas d’accord avec son analyse du DNS. Certes, selon le modèle abstrait, le DNS est dans la couche Applications. Mais ce n’est pas une bonne façon de le décrire. Le DNS est une infrastructure, quelque chose qu’on ne voit pas mais qui est indispensable. Il est donc bien plus proche de BGP que des applications.
Oui, ceci dit, c’est article d’un blog du Monde.fr donc destiné à des lecteurs profanes et c’est vrai que ça n’invente pas « l’eau chaude ». L’article a au moins le mérite de poser le problème d’une régulation au niveau global mais là on peut toujours rêver. La remarque que j’ai faite mettait l’accent sur l’aspect « disponibles » des infos à travers le Net. Et le contrôle unilatéral du routage ou son contraire, la transparence, ce sont aussi des aspects de la neutralité du Net
Il y aura morcellement visible quand on ne sera plus obligé de passer par l’infrastructure internationale. Il en existe des mesures théoriques. Aujourd’hui, la longueur moyenne d’un trajet est d’environ 6 AS et de 15,6 routeurs . Les AS sont les autorités indépendantes de l’Internet. Quand on passe par beaucoup d’autorités, cela signifie qu’il n’y a pas d’autorité. Internet sera morcelé quand son diamètre se réduira. Le diamètre est la distance d’un extrême à l’autre par le plus court chemin. Aujourd’hui, le diamètre d’Internet est encore en expansion.
L’#IGP (Internet Governance Project <http://www.internetgovernance.org/>) vient de publier une bonne étude sur les transferts d’adresses #IPv4 entre titulaires. Son principal intérêt est de s’appuyer sur les faits : les auteurs ont pris les données disponibles (note au passage, l’Open Data chez les RIR comme le #RIPE-NCC, c’est pas encore ça, le travail a été compliqué) et mouliné le tout pour en extraire d’intéressantes statistiques.
Par exemple : le #RIR (Regional Internet Registry) avec le plus grand nombre de transferts, de loin, est #ARIN, qui a pourtant encore des adresses IPv4 pour un an. L’analyse des auteurs montre que Microsoft, par exemple, a payé 11 $ pièce des adresses qu’il aurait pu avoir pour 13 cents auprès d’ARIN. Mais les auteurs expliquent bien que l’achat à ARIN aurait obligé Microsoft à documenter son usage, à dévoiler ses plans et, en deux mots, à supporter la bureaucratie ARIN et ses chartes. En outre, il est possible (intéressant sujet d’examen pour des juristes...) que la « propriété » de ces adresses soit mieux garantie par un transfert depuis le marais (<http://www.bortzmeyer.org/nettoyage-marais.html>) que par une « location » légale auprès d’ARIN.
http://www.internetgovernance.org/2012/08/31/the-first-study-of-the-emerging-market-for-ipv4-numbers
Deux faiblesses à cet article : une est idéologique, les auteurs ont tellement envie de prouver que le marché des adresses IPv4 existe qu’ils qualifient de « marché » le système de transfert actuel. S’il est vrai qu’il ne faut pas se fier à la langue de bois des RIR (qui refuse ce terme de marché), avoir des achats et des ventes ne suffit pas à faire un marché. Il faut aussi une liquidité suffisante pour qu’il y ait formation de prix stables, et que les acteurs sachent à peu près à quoi s’en tenir.
La deuxième faiblesse est technique : les auteurs mélangent systématiquement « non routé sur l’Internet public » avec « inutilisé » et donnent donc des chiffres tendancieux. En réalité, il y a des tas de boîtes qui utilisent leurs adresses IP en interne, sans que cela se reflète dans #BGP...
Des tas de gens l’avaient déjà constaté mais voici une étude scientifique : la #censure ne respecte pas toujours les frontières. En raison des interconnexions entre opérateurs Internet, la censure dans un pays peut bloquer le même contenu dans un autre pays (dans le cas de l’article, l’Inde censure Oman, en plus de la propre censure de ce dernier).
L’article original, avec tous les détails techniques :
https://citizenlab.org/2012/07/routing-gone-wild
Un résumé : http://arstechnica.com/tech-policy/2012/07/internet-content-blocking-travels-downstream-affects-unwary-users
#BGP
Hier a vu la publication du premier « Rapport sur la résilience de l’Internet en France ». Il s’agit d’étudier quantitativement la résilience de l’#Internet dans ce pays (oui, je sais, l’Internet est mondial, mais il faut bien commencer quelque part). Le rapport définit donc un certain nombre d’indicateurs puis les mesure et publie le résultat.
Le rapport est un travail commun de l’#ANSSI et de l’#AFNIC. Il comprend deux grandes parties, une sur le protocole #BGP et une sur le #DNS. Dans le futur, d’autres protocoles pourront être étudiés. Espérons que cette édition 2011 sera suivie de bien d’autres.
Ce travail a déjà été présenté (en anglais) à une réunion OARC (supports disponibles). Il sera évoqué rapidement au prochain Frnog et surtout à la Journée du Conseil Scientifique de l’AFNIC le 4 juillet.
Le rapport : http://www.ssi.gouv.fr/fr/menu/actualites/l-anssi-et-l-afnic-publie-un-etat-des-lieux-de-l-internet-francais.html
Exposé OARC : http://www.bortzmeyer.org/oarc-londres-resilience.html
Journée du Conseil Scientifique de l’AFNIC : http://www.afnic.fr/fr/l-afnic-en-bref/actualites/actualites-generales/6083/show/journee-du-conseil-scientifique-de-l-afnic-le-4-juillet-2012-3.html
« Influence des bonnes pratiques sur les incidents #BGP » par Francois Contat, Guillaume Valadon et Sarah Nataf
Un très bon article, sur la sécurité du protocole de routage BGP. Il démarre doucement (trop doucment si vous connaissez déjà BGP) puis expose les faiblesses de sécurité et décrit très en détail plusieurs incidents BGP fameux. De l’excellent travail de fond !
https://www.sstic.org/2012/presentation/influence_des_bonnes_pratiques_sur_les_incidents_bgp
RFC 6608 : Subcodes for BGP Finite State Machine Error
Un très court #RFC pour enrichir la liste des codes d’erreur qu’un #routeur #BGP peut envoyer à son pair en cas de problèmes dans l’automate à états finis du protocole. Cela devrait permettre d’améliorer les messages d’erreur vus par les opérateurs de routeurs.
Un long article détaillé sur les questions politiques que soulève le déploiement de la #RPKI : « Negotiating a New Governance Hierarchy : An Analysis of the Conflicting Incentives to Secure Internet Routing » de Brenden Kuerbis et Milton Mueller.
Rien de très nouveau (l’article date de l’année dernière), il reprend et développe les idées que les auteurs avaient déjà exprimé : la #RPKI va déplacer le pouvoir depuis les opérateurs réseaux (qui routaient comme ils voulaient) vers les #RIR (qui vont gérer la RPKI, donc les certificats, donc les routes). Très bien fait, très pédagogique.
http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2021835
Pöur la question technique, voir http://seenthis.net/messages/55501
Un ancien article des mêmes auteurs : http://www.internetgovernance.org/wordpress/wp-content/uploads/RPKI-VilniusIGPfinal.pdf
Le système de sécurité #Rover, permettant de vérifier les routes #BGP, vient de bénéficier d’un certain buzz: The Register http://www.theregister.co.uk/2012/04/23/ip_hijack_prevention IT World http://www.itworld.com/security/272320/engineers-ponder-easier-fix-dangerous-internet-problem et Slashdot http://tech.slashdot.org/story/12/04/27/2039237/engineers-ponder-easier-fix-to-internet-problem en ont parlé.
Lors de la discussion qui a suivi sur #Nanog, l’expert #DNS Florian Weimer a bien expliqué les vraies raisons du déploiement de la #RPKI, le concurrent de Rover :
« Regarding the post-scarcity future, if most address holders never have to come back to the #RIR to request more addresses, the number of address-related RIR/LIR transactions will decrease. Organizations have a tendency to resist decreases in business (even non-profits), and RPKI is an obvious source of future business. »
Rover avait déjà été mentionné sur SeenThis : http://seenthis.net/messages/62143
ROVER, un système alternatif pour sécuriser BGP
Le protocole de routage #BGP, sur lequel repose tout l’Internet, est connu pour son absence de sécurité. N’importe quel maladroit peut annoncer les routes d’un autre opérateur et détourner ou couper le trafic. Il existe une solution de sécurisation, normalisée et activement déployée, #RPKI + ROA. Mais cette solution, plutôt complexe, ne fait pas que des heureux. Une alternative vient d’être annoncée, #ROVER (ROute Origin VERification).
Il existe principalement deux approches (pas forcément contradictoires) pour faire face aux détournements #BGP dans l’Internet (style Pakistan Telecom vs. YouTube) : empêcher les détournements par un système de validation des annonces de route (l’approche de la #RPKI et des #ROA) ou bien détecter le problème et prendre des actions correctives. Cette seconde approche est utilisée dans des systèmes comme #Cyclops ou #BGPmon. Ce nouveau système, #Argus, est légèrement différent.
Argus fonctionne en détectant les annonces qui changent et en testant (ping...) la connectivité de l’AS (Autonomous System) après le changement, pour éliminer des faux positifs (AS qui a réellement changé d’opérateur, par exemple). Cette approche, combinant le plan de contrôle (BGP) et le plan de données (ping) a l’avantage de limiter le nombre de faux positifs. Elle a l’inconvénient de ne pas marcher du tout si le détourneur redirige le trafic vers l’AS normal (« BGP shunt » comme dans l’attaque Kapela&Pilosov) ou s’il répond à la place de l’AS normal. Argus ne peut donc être utilisé que pour les détournements accidentels, pas contre les attaques.
Le site Web officiel :
http://argus.csnet1.cs.tsinghua.edu.cn
L’article originel :
http://argus.csnet1.cs.tsinghua.edu.cn/static/Argus.FIST11.pdf
Attention, comme beaucoup d’articles scientifiques, l’auteur exagère les capacités de son jouet et diminue celle des autres. Par exemple, contrairement à ce qu’il prétend, les systèmes d’alarmes existants comme Cyclops ou BGPmon ne se limitent pas à l’AS d’origine.
La longue marche de la sécurité du routage Internet : une étape importante, RPKI+ROA
On le sait, le protocole #BGP (normalisé dans le RFC 4271), sur lequel repose tout l’Internet, car c’est lui qui permet à l’information de routage de circuler entre les opérateurs, ce protocole, donc, est peu sûr. N’importe qui peut annoncer n’importe quelle route, dire « Je suis Google, envoyez-moi toutes les requêtes Google » et les autres le croient. Résoudre cette vulnérabilité n’est pas trivial, pour des raisons essentiellement non techniques. Néanmoins, le manque d’un mécanisme standard pour valider les routes était une des faiblesses du routage Internet. Une série de #RFC vient de partiellement combler ce déficit.
http://www.bortzmeyer.org/securite-routage-bgp-rpki-roa.html
#RPKI #ROA #sécurité #cryptographie
[Bon, c’est un article de 2006, mais c’est toujours bon.]
« Understanding the network-level behavior of spammers » par Anirudh
Ramachandran (Georgia Tech) et Nick Feamster (Georgia Tech) dans
« Proceeding SIGCOMM ’06 Proceedings of the 2006 conference on
Applications, technologies, architectures, and protocols for computer
communications »
Très bonne analyse technique des trucs réseaux utilisés par les spammeurs. C’était le première article à mettre en évidence le truc d’annoncer en BGP des préfixes #bogons, d’envoyer le spam, pis d’arrêter l’annonce BGP.
http://www.cc.gatech.edu/~avr/publications/p396-ramachandran-sigcomm06.pdf
Une série de chiffres en vaut une autre, pensez-vous ? Eh bien non. Quoique numériques, toutes les adresses IP ne se valent pas. Le préfixe 128.0.0.0/16, quoique parfaitement légal, est ainsi invisible depuis une bonne partie de l’Internet.
Le 26 novembre, à #Toulouse, j’ai eu le plaisir de faire un exposé lors de l’Ubuntu Party (organisée par #Toulibre) sur le sujet « Derrière la scéne : comment et grâce à qui l’Internet fonctionne t-il ? »
L’accroche était « Que se passe-t-il derrière ma box ? Qui dirige l’Internet ? Qu’est-ce qu’un #Tier-1 ? Pourquoi #Comcast et #Level-3 s’accusent-ils réciproquement de « patate chaude » ? À quoi sert un point d’échange ? #BGP fait-il mal ? Pourquoi un maladroit au Pakistan peut-il bloquer YouTube sur toute la planète ? Cet exposé sera consacré au fonctionnement technique d’Internet : le rôle des différents acteurs, les techniques utilisées pour synchroniser le routage, et les mécanismes qui font que, vaille que vaille, l’infrastructure marche. ».
Ce lundi 7 novembre 2011, vers 14h05 UTC, grande perturbation de la Force. Des tas de destinations deviennent injoignables sur l’Internet...
RFC 6382 : Unique Per-Node Origin ASNs for Globally Anycasted Services
Ce court #RFC propose un changement radical dans la gestion des annonces #BGP par les services anycastés. Actuellement, ils utilisent presque tous un seul numéro d’AS pour tous les noeuds d’un nuage #anycast. Notre RFC 6382, au contraire, suggère d’utiliser un numéro d’AS par noeud.
