Re: [FRnOG] [ALERT] Nerim is dead ?
On Thu, 2014-11-20 at 19:18 +0100, Antoine Versini wrote: Nous en cherchons la cause, mais nous savons déjà que l'origine n'est pas un changement de configuration d'un équipement, aucun commit ou clear quelconques n'ayant été effectués pendant les heures avant l'évènement. Je sens que nos amis de Junipe(u)r vont encore en prendre pour leur grade... Il serait intéressant de savoir exactement ce qui s'est passé (en privé, si tu préfères), pour la culture. -- Clément Cavadore --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Nerim is dead ?
Bonjour, Je plusoie, on-list ou off-list. Bon courage aux équipes NERIM. Y. Le 21 novembre 2014 09:00, Clement Cavadore clem...@cavadore.net a écrit : On Thu, 2014-11-20 at 19:18 +0100, Antoine Versini wrote: Nous en cherchons la cause, mais nous savons déjà que l'origine n'est pas un changement de configuration d'un équipement, aucun commit ou clear quelconques n'ayant été effectués pendant les heures avant l'évènement. Je sens que nos amis de Junipe(u)r vont encore en prendre pour leur grade... Il serait intéressant de savoir exactement ce qui s'est passé (en privé, si tu préfères), pour la culture. -- Clément Cavadore --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Youssef BENGELLOUN-ZAHR --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: RE: [TECH] RFC 7404: Using Only Link-Local Addressing Inside an IPv6 Network
From: Stephane Bortzmeyer bortzme...@nic.fr To: Clement Cavadore clem...@cavadore.net Cc: Jérôme Nicolle jer...@ceriz.fr, frnog-t...@frnog.org Subject: Avenir de AS 112 (Was: RFC 7404: Using Only Link-Local Addressing Inside an IPv6 Network X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.23 (2014-03-12) On Fri, Nov 21, 2014 at 12:18:57AM +0100, Clement Cavadore clem...@cavadore.net wrote a message of 17 lines which said: Ca va juste faire quelques zones à rajouter dans AS112, ça parait pas mortel, si ? Ouais, euh en fait, le plus mortel, ca serait d'arriver à les faire rajouter à *tous* les noeuds anycastés de l'AS112. Au risque de se retrouver avec des lame nameserver pour les noeuds non mis à jour... Exactement. La nature même de l'AS 112 http://www.bortzmeyer.org/6304.html fait qu'il est impossible de changer la configuration de tous les nœuds. Même si l'IETF, l'ARCEP, l'ICANN, la NSA, Pouzin, l'AFNIC et Jean-Kevin étaient tous d'accord, on ne pourrait pas garantir qu'il ne traine pas des nœuds AS 112 ayant l'ancienne liste. L'IETF a donc choisi une voix différente pour l'évolution de l'AS 112 : créer un nouveau préfixe, qui recevra les délégations des nouveaux in-addr.arpa et ip6.arpa. Les nœuds utilisant ce nouveau préfixe utiliseront une nouvelle technique, à base de DNAME http://tools.ietf.org/html/draft-ietf-dnsop-as112-dname/, pour ne *pas* avoir à être configuré avec la liste des domaines à servir. Cela permettra de faire évoluer cette liste, ce qui est organisationnellement impossible avec les préfixes actuels de l'AS 112. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Quelqu'un a un bâillon ? - FRNOG 23
Re, Voilà, c'est fait. Au passage, les slides et vidéos de la dernière réunion sont en ligne. A noter que j'ai oublié d'appuyer sur le bouton REC pour la première partie de la réunion, d'où le manque de quelques vidéos :) Cordialement, Philippe Bourcier On 2014-11-21 00:01, Philippe Bonvin wrote: Vu que je me suis aussi ramassé son autorépondeur, j’y vois pas d’objection. On 20 Nov 2014, at 17:53, Jérôme Nicolle jer...@ceriz.fr wrote: Plop, Je suppose que vous êtes nombreux à avoir reçu le répondeur automatique de Marie Colin ( a.k.a. https://www.linkedin.com/pub/marie-colin/37/789/202 ). Si quelqu'un d'EXA Technologies lis ça, ce serait sympa de traiter les mails envoyés au support et de couper son répondeur immédiatement. En attendant confirmation, je suggère la désinscription de la liste. Philippe, ton avis ? Le 20/11/2014 23:40, mco...@exatechno.com a écrit : Bonjour, Je suis absente jusqu'au 1er decembre 2014. Pour toute demande urgente, merci d'envoyer un mail à supp...@exatechno.com . Cordialement, Marie Colin -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Philippe Bourcier web : http://sysctl.org/ blog : https://www.linkedin.com/today/author/2298865 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Nerim is dead ?
Le 21 nov. 2014 à 09:00, Clement Cavadore clem...@cavadore.net a écrit : Je sens que nos amis de Junipe(u)r vont encore en prendre pour leur grade... Il serait intéressant de savoir exactement ce qui s'est passé (en privé, si tu préfères), pour la culture. Hello Clément, Je n'ai pas l'intention de jeter l'opprobre sur un constructeur ou l'autre. Nous ne pratiquons pas ce type de communication. D'autant plus que pour le moment la seule chose apparente se sont des messages assez laconiques dans les journaux qui indiquent des pertes simultanées de sessions eBGP dans *une seule VRF* (la pire, certes) sur un bon nombre de machines et sans action associée. Tous nos partenaires de peerings ont pu s'en apercevoir ;) See you! -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [MISC] Video tutorial : Connect your network to France-IX
http://i.imgur.com/XP9GL1u.gifv -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] BGP Hijacking
Bonjour, je voulais aborder un sujet que je n'ai pas vu passer sur la mailing-list (j'espère ne pas me tromper !) : le BGP Hijacking. Existe-t-il des parades contre ce genre d'attaque ? Es-ce que le fait de faire tomber/remonter le peering avec son opérateur est suffisant pour reprendre la main ? Existe-t-il des bonnes pratiques afin de réduire les risques ? Si le ce genre d'attaque est si simple, pourquoi les grands acteurs ne semblent pas régulièrement impactés ? Bonne journée Hugo --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] BGP Hijacking
Le 21/11/2014 15:35, Hugo Deprez a écrit : je voulais aborder un sujet que je n'ai pas vu passer sur la mailing-list (j'espère ne pas me tromper !) : le BGP Hijacking. C'est pas secret, c'est discret. Parce que c'est un vrai problème. Existe-t-il des parades contre ce genre d'attaque ? Es-ce que le fait de faire tomber/remonter le peering avec son opérateur est suffisant pour reprendre la main ? Clearer une session permet de rendre la route plus récente chez ton peer, donc potentiellement de redéclencher un best-path-selection, ce qui peut suffire si les autres critères de sélection sont équivalents. Mais c'est rarement le cas. Existe-t-il des bonnes pratiques afin de réduire les risques ? Oui : gagner la visibilité par la conception de ton réseau. Il va s'agir, en version simplifiée, de mettre en place les décisions suivantes : - Regrouper tes services critiques (DNS, mail, frontaux web) sur un /24 (en fait un ou deux /25) de ton réseau et désagréger cette annonce (et uniquement celle ci). Tu peux proposer à tes peers directs de désagréger le /25 afin de garantir qu'il sera préféré et jamais hijacké, mais tu ne peux pas balancer le /25 sur des route-server ou des transits qui sont censés le filtrer. - Être le plus interconnecté possible avec le plus grand nombre d'AS possible pour s'assurer d'avoir les paths les plus courts dans la plupart des cas de figure. Donc présence sur tous les IX possibles. - Avoir le maximum de contacts avec le maximum d'opérateurs possibles afin de pouvoir leur demander de shooter une annonce illégitime. En clair : un mec qui fait tous les *nog, *ix et *RIR meetings pour serrer les bonnes paluches. - Surveiller les annonces concernant tes prefixes, avec les différents projets de monitoring existants : le RIS, NLNog-Ring, Cymru et j'en passe. - Bien entendu, signer tes routes (RPKI+ROA) et tenir tes enregistrement (IRR) de façon très strictes. Ca vaut pas grand chose comme contre-mesure, mais ça facilite la détection. Attention toutefois : plus d'interconnexions, c'est plus de boulot à maintenir, plus de boulot pour les routeurs, et plus de points d'entrée dans ton réseau, qu'il faudra sécuriser si tu veux aussi te prémunir de DDoS. La facture peut monter très haut, très rapidement. Si le ce genre d'attaque est si simple, pourquoi les grands acteurs ne semblent pas régulièrement impactés ? Parce que c'est difficile à détecter, surtout pour une grosse structure inertielle dont les décideurs ne comprennent rien à la technique. -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] BGP Hijacking
Merci pour ces explications ! Et dans le cas d'une infrastructure plus petite : AS avec un simple /24 et multi-homing via deux operateurs X et Y, Dans ce cas de figure on délègue notre visibilité à nos opérateurs. Es-ce que ces opérateurs ont un rôle à jouer dans ce cas de figure ? Hugo 2014-11-21 15:46 GMT+01:00 Jérôme Nicolle jer...@ceriz.fr: Le 21/11/2014 15:35, Hugo Deprez a écrit : je voulais aborder un sujet que je n'ai pas vu passer sur la mailing-list (j'espère ne pas me tromper !) : le BGP Hijacking. C'est pas secret, c'est discret. Parce que c'est un vrai problème. Existe-t-il des parades contre ce genre d'attaque ? Es-ce que le fait de faire tomber/remonter le peering avec son opérateur est suffisant pour reprendre la main ? Clearer une session permet de rendre la route plus récente chez ton peer, donc potentiellement de redéclencher un best-path-selection, ce qui peut suffire si les autres critères de sélection sont équivalents. Mais c'est rarement le cas. Existe-t-il des bonnes pratiques afin de réduire les risques ? Oui : gagner la visibilité par la conception de ton réseau. Il va s'agir, en version simplifiée, de mettre en place les décisions suivantes : - Regrouper tes services critiques (DNS, mail, frontaux web) sur un /24 (en fait un ou deux /25) de ton réseau et désagréger cette annonce (et uniquement celle ci). Tu peux proposer à tes peers directs de désagréger le /25 afin de garantir qu'il sera préféré et jamais hijacké, mais tu ne peux pas balancer le /25 sur des route-server ou des transits qui sont censés le filtrer. - Être le plus interconnecté possible avec le plus grand nombre d'AS possible pour s'assurer d'avoir les paths les plus courts dans la plupart des cas de figure. Donc présence sur tous les IX possibles. - Avoir le maximum de contacts avec le maximum d'opérateurs possibles afin de pouvoir leur demander de shooter une annonce illégitime. En clair : un mec qui fait tous les *nog, *ix et *RIR meetings pour serrer les bonnes paluches. - Surveiller les annonces concernant tes prefixes, avec les différents projets de monitoring existants : le RIS, NLNog-Ring, Cymru et j'en passe. - Bien entendu, signer tes routes (RPKI+ROA) et tenir tes enregistrement (IRR) de façon très strictes. Ca vaut pas grand chose comme contre-mesure, mais ça facilite la détection. Attention toutefois : plus d'interconnexions, c'est plus de boulot à maintenir, plus de boulot pour les routeurs, et plus de points d'entrée dans ton réseau, qu'il faudra sécuriser si tu veux aussi te prémunir de DDoS. La facture peut monter très haut, très rapidement. Si le ce genre d'attaque est si simple, pourquoi les grands acteurs ne semblent pas régulièrement impactés ? Parce que c'est difficile à détecter, surtout pour une grosse structure inertielle dont les décideurs ne comprennent rien à la technique. -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] BGP Hijacking
Hello, quelques commentaires: Le 21 nov. 2014 à 15:46, Jérôme Nicolle jer...@ceriz.fr a écrit : Clearer une session permet de rendre la route plus récente chez ton peer, donc potentiellement de redéclencher un best-path-selection, ce qui peut suffire si les autres critères de sélection sont équivalents. Mais c'est rarement le cas. Par défaut, en eBGP sur la plupart des routeurs, route plus récente = route moins préférée. Donc action contre-productive. Cf (par exemple): http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html item 10. http://www.juniper.net/techpubs/en_US/junos13.3/topics/reference/general/routing-ptotocols-address-representation.html http://www.juniper.net/techpubs/en_US/junos13.3/topics/reference/general/routing-ptotocols-address-representation.html item 11 - Regrouper tes services critiques (DNS, mail, frontaux web) sur un /24 (en fait un ou deux /25) de ton réseau et désagréger cette annonce (et uniquement celle ci). Tu peux proposer à tes peers directs de désagréger le /25 afin de garantir qu'il sera préféré et jamais hijacké, mais tu ne peux pas balancer le /25 sur des route-server ou des transits qui sont censés le filtrer. En fait tout le monde (de sensé) est censé filtrer plus petit qu'un /24, sauf accords particuliers entre AS. Donc ça semble compliqué. Du coup et par ailleurs les best practices bortzmeyeriennes (bortzmeyeristes?) suggèrent a priori plutôt de distribuer ses DNS dans des /24 séparées (cela-dit même des gens très biens ne le font pas). a+ Olivier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] BGP Hijacking
Le 21/11/2014 19:00, Olivier Benghozi a écrit : Par défaut, en eBGP sur la plupart des routeurs, route plus récente = route moins préférée. Donc action contre-productive. Cf (par exemple): http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html item 10. http://www.juniper.net/techpubs/en_US/junos13.3/topics/reference/general/routing-ptotocols-address-representation.html http://www.juniper.net/techpubs/en_US/junos13.3/topics/reference/general/routing-ptotocols-address-representation.html item 11 C'est tout à fait exact, si l'implémentation est correcte. Mais dans le cas d'un hijack, tu te bas contre une annonce illégitime potentiellement volatile. Cela dit j'aurais du être plus précis : si un hijack est détecté, la première chose à faire est de désagréger et stopper tout prepend éventuel sur les blocs attaqués et forcer tes peers à réapprendre les routes. Tu peux regagner l'adjacence avec le path, vu que celui de l'attaquant contient normalement l'AS qui lui sert de route de retour pour assurer son return-path. En fait tout le monde (de sensé) est censé filtrer plus petit qu'un /24, sauf accords particuliers entre AS. Donc ça semble compliqué. Waip, je parle bien d'accords spécifiques, à établir au cas par cas. Du coup et par ailleurs les best practices bortzmeyeriennes (bortzmeyeristes?) suggèrent a priori plutôt de distribuer ses DNS dans des /24 séparées (cela-dit même des gens très biens ne le font pas). Irais-je jusqu’à dire qu'au moins un de tes DNS devrait être hors de ton AS ? ;) -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] BGP Hijacking
Hugo Deprez a écrit : je voulais aborder un sujet que je n'ai pas vu passer sur la mailing-list : le BGP Hijacking. Tu ne lis pas depuis assez longtemps. C'est trolldi, nom de dieu. Existe-t-il des parades contre ce genre d'attaque ? Ca dépend de ton compte en banque. Es-ce que le fait de faire tomber/remonter le peering avec son opérateur est suffisant pour reprendre la main ? Non. Existe-t-il des bonnes pratiques afin de réduire les risques ? Ca dépend de ton compte en banque. Si le ce genre d'attaque est si simple, pourquoi les grands acteurs ne semblent pas régulièrement impactés ? Facile : ils on un gros compte en banque. Ils annoncent leurs préfixe(s) directement à plusieurs tier-1, donc la longueur de leur AS-PATH est 2 ou 3, donc quand bitos kidnappe leur préfixe(s), les seuls qui s'en aperçoivent sont les clients de bitos. Autre effet kiss-cool, ils donnent assez d'argent aux tier-1 en question pour annoncer des /25 avec no-export, ce qui limite aussi la casse. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
