Analyse de la panne CenturyLink.
Nous n'avons jamais trop communiqué sur ce sujet (si ce n'est dans nos comptes-rendus de réunion, ou d'assemblé générale), cette configuration n'est maintenant plus d'actualité puisque Alsace Réseau Neutre vole maintenant de ses propres ailes et même bien mieux, ils disposent d'un quart de baie en data center!
Introduction
Dans le cadre de Lorraine Data Network (Association pour la défense d'un Internet Libre Décentralisé et Neutre, dont un des moyens d'action est d'être fournisseur d'accès à Internet), pour des contraintes techniques et de future indépendance, nous avons mis en place deux AS (Autonomous System) sur une même machine physique.
Ce type de configuration n'est pas très commune, les autres solutions sont soit de virtualiser. Mais pour des routeurs de bordure (recevant une full-view (toutes les routes d'Internet)) ce n'est généralement pas conseillé, pour des raisons de performance (les fameux paquets par secondes), soit on utilise deux machines physiques :) mais nous sommes une petite association, et le but était de lancer une association amie ARN (Alsace Réseau Neutre) à moindre frais, et donc sur un seul serveur (celui-ci étant en Data Center).
Après de longues concertations et différents tests en bac à sable, nous avons finalement opté pour une solution à base de bird (daemon libre de routage) dans des namespaces réseau (netns).
RouteFlow is an open source project to provide virtualized IP routing services over OpenFlow enabled hardware.
A typical RouteFlow use scenario is composed by an OpenFlow controller application (RFProxy), an independent RouteFlow server (RFServer), and a virtual network environment that reproduces the connectivity of a physical infrastructure and runs IP routing engines (e.g. Quagga).
The routing engines generate the forwarding information base (FIB) into the Linux routing tables according to the configured routing protocols (e.g., OSPF, BGP). In turn, the Linux IP and ARP tables are collected by RouteFlow client (RFClient) processes and then translated into OpenFlow tuples that are finally installed in the associated OpenFlow-enabled devices in the forwarding plane.
Les travaux de l’observatoire de la résilience de l’Internet français ont conduit l’ANSSI et les opérateurs de communication partenaires l’Association Kazar, France-IX, Jaguar Network, Neo Telecoms, Orange, RENATER et SFR à concevoir une définition des bonnes pratiques d’interconnexion entre opérateurs (interconnexion BGP).
En effet, la façon dont sont configurés les équipements qui assurent les échanges entre opérateurs conditionne aussi les capacités de détection ou de prévention des erreurs. Cela signifie donc qu’elle contribue à la résilience de l’Internet.
Le guide propose des exemples concrets de configuration correspondant aux bonnes pratiques à développer pour les principaux équipements du commerce.
L’ANSSI encourage les acteurs de l’Internet à s’approprier ces recommandations pour les appliquer dès que cela est envisageable.
Le pdf:
http://www.ssi.gouv.fr/uploads/IMG/pdf/guide_configuration_BGP.pdf
La RFC 7454 qui va bien:
https://www.bortzmeyer.org/7454.html
There was quite a bit of chaos on the Internet today, including major fiber cuts in California. To add to this confusion, between 5:24pm and around 6:10pm Pacific on June 30th, social media and outage reports indicated some issues with Amazon, AWS and a variety of services that run on AWS. In our office, we realized HipChat (our internal messaging system) and Okta (our SSO provider) were not working. And neither was our corporate website, which is hosted on AWS EC2 and fronted by AWS CloudFront.
Suite de deux articles sur le protocole BGP. https://blog.opendns.com/2015/06/25/bgp-and-the-system-of-trust-that-runs-the-internet-pt-2/ Il aborde les erreurs d'annonce de routes , "leaks", les hijacks
Tout l'Internet repose sur le protocole BGP, qui permet l'échange de routes entre opérateurs Internet. (BGP est normalisé dans le RFC 4271.) La sécurité de BGP est donc cruciale pour l'Internet, et elle a fait l'objet de nombreux travaux. Ce nouveau RFC résume l'état actuel des bonnes pratiques en matière de sécurité BGP. Du classique, aucune révélation, juste la compilation de l'état de l'art. Ce RFC porte aussi bien sur la protection du routeur, que sur le filtrage de l'information (les routes) reçues et transmises.
Ce genre de compilation aurait plutôt due être faite dans le cadre du project BCOP mais celui-ci semble mort.
La section 2 de ce RFC rappelle qu'il n'a pas de caractère obligatoire : il expose des pratiques de sécurité générales, et il est toujours permis de faire des exceptions, en fonction des caractéristiques spécifiques du réseau qu'on gère.
Donc, au début (sections 4 et 5 du RFC), la protection de la discussion entre deux routeurs, deux pairs BGP qui communiquent (sécurité du canal). Ensuite (sections 6 à 11), la protection des informations de routage échangées, le contrôle de ce qui est distribué (sécurité des données).
Une grande partie de ce cours a pu être faite grâce à l'expérience acquise en concevant et en déployant le réseau de l'opérateur Internet Gitoyen.
Ce document est fourni pour vous permettre de comprendre et de configurer BGP. Le ou les auteurs ne sont évidemment pas responsables des dégâts que vous causerez à votre réseau.
BGP étant un protocole de routage entre entités administratives distinctes, toute erreur de manipulation peut être vue à l'extérieur de votre organisation, voire dans tout l'Internet. Prudence !
Ce document est distribué sous les termes de la GNU Free Documentation License. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
Résumé
Ce document explique la conception et la configuration d'un réseau TCP/IP d'opérateur, interconnecté avec d'autres opérateurs et utilisant le routage dynamique, en l'occurrence avec le protocole BGP.
Il se veut pratique : l'accent est mis sur une configuration simple qui devrait couvrir la plupart des cas. Il ne remplace donc pas un cours complet sur BGP.
Sub-allocation of a legacy “class A” network (a /8, in modern parlance). Apparently, DuPont sold a part of its IPv4 to Amazon || https://www.arin.net/policy/nrpm.html#eight3 Section 8.4 even describes inter-RIR
The Syrian national Telecommunications Establishment (STE) has been in the news numerous times over the last few years, mostly because of the long lasting large scale Internet outages in Syria. This morning however we observed a new incident involving the two Autonomous systems for STE (AS29386 and AS29256). Starting at 08:33 UTC we detected that hundreds of new prefixes were being announced by primarily AS 29386. The new BGP announcements by STE (AS29386) were for prefixes that are not owned or operates by the Syrian Telco and as a result triggered ‘hijack / origin AS’ alerts for numerous BGPmon users. The announcements lasted for a few minutes only and we saw paths changing back to the original origin AS at about 08:37 UTC.
VolumeDrive is a Pennsylvania-based hosting company that uses Cogent and (since late May of this year) Atrato for Internet transit. A routing leak this morning by VolumeDrive was passed on to the global Internet by Atrato causing disruptions to traffic in places as far-flung from the USA as Pakistan and Bulgaria.
Toutes les communications Internet sont vulnérables à des attaques contre le système de routage, notamment celles utilisant le protocole BGP. En effet, lorsqu’on croit parler à 192.0.2.34, on parle peut-être en fait à une machine qui a usurpé cette adresse, puis annoncé le préfixe IP correspondant (mettons 192.0.2.0/24) à tout l’Internet, attirant ainsi tout (ou presque tout) le trafic vers ce préfixe.
A RIPE Meeting is a five-day event where Internet Service Providers (ISPs), network operators and other interested parties from all over the world gather. | Slides et ou Videos
Continuing our discussion about visualizing DDoS attacks from last week, today we are going to look at an attack against a multinational bank. Whereas last week’s example focused on path visualization, this week’s will touch upon how Border Gateway Protocol (BGP) plays a role in rerouting traffic during an attack.
Tout le monde le sait, le système de routage de l'Internet, fondé sur le protocole BGP, n'est pas sûr. Il est trop facile d'y injecter des annonces de routes mensongères. Le premier pas vers une sécurité plus forte était de sécuriser la communication entre routeurs (RFC 5925). Un second pas a été réalisé avec le déploiement de la RPKI. Un troisième pas avec la normalisation de la solution RPKI+ROA. Cette dernière protège uniquement l'origine d'une annonce BGP. Cela suffit à arrêter pas mal d'erreurs mais une attaque délibérée gardera probablement l'origine authentique et trichera sur le chemin d'AS présent dans l'annonce BGP. D'où la nécessité de continuer le travail. C'est le projet PATHSEC (Path Security) pour lequel ce nouveau RFC énumère les motivations. (Le terme de BGPSEC avait été utilisé dans le passé mais PATHSEC semble plus fréquent aujourd'hui.)
We used several levels of aggregation to simplify and clarify the data for these charts. For client IP addresses that run multiple tests with conflicting results, we only use the most recent valid test, ignoring tests that could not determine whether spoofing was possible.
We mapped each IP address to its network prefix as seen in Route Views BGP tables (manually collected from the route-views.routeviews.org text dumps), and use the most recent 12 months of tests from IP addresses within any given prefix. Prefixes in which all tested client addresses result in the same status are labeled as "spoofable" or "unspoofable"; prefixes with conflicting results from different IP addresses are labeled "inconsistent". We extrapolate our results to the entire announced address space by assigning each prefix's status to every IP address covered by that prefix.
To infer the status of ASes, we count the status of each network prefix a given AS announces into the BGP table, and compute the fraction of prefixes that permit spoofing versus total tested prefixes from the AS in question. The inconsistent ASes are subdivided into those with less than half their nets considered spoofable (which are labeled "partly spoofable") and those with at least half spoofable (which are labeled "mostly spoofable").
L'article « Quelques pistes sur le renforcement de la sécurité autour du protocole de routage BGP » a été publié aux pages 60-65 du numéro 70 (novembre/décembre 2013) de MISC. Ayant un peu étudié la sécurité de BGP, je souhaite donner mon avis qui tiendra compte du format (revue papier) qui oblige les auteurs à fortement résumer leurs propos.
http://www.guiguishow.info/wp-content/uploads/2014/01/MISC70-BGP.pdf
Aujourd'hui, vers 19:30 UTC, une coupure complète de la connexion Internet de Saint-Pierre-et-Miquelon a eu lieu. C'est l'occasion de regarder ce que fait le protocole de routage de l'Internet, BGP, dans ce cas, puisque toutes les données sont publiques.
La panne a été signalée par BGPmon sur Twitter. Il y a normalement quatre préfixes d'adresses IP, qui sont émis depuis l'île, 70.36.4.0/22, 70.36.12.0/22, 70.36.8.0/22 et 70.36.0.0/22. Tous pourraient s'agréger en un 70.36.0.0/20 mais ce n'est pas le cas. Il y a apparemment un seul opérateur à Saint-Pierre-et-Miquelon, SPM Télécom (qui gère le portail http://www.cheznoo.net à l'adresse 70.36.0.23). Tous ces services étaient inaccessibles (cela remarche désormais). On notera que le domaine cheznoo.net n'a que deux serveurs DNS, ce qui est insuffisant, et que les deux sont dans les préfixes affectés
L’aiguillage des flux sur la Toile est faillible. Des experts ont observé, pour la première fois, des détournements massifs permettant de siphonner des données en toute tranquillité. Mais leur origine reste mystérieuse.