Re: [FRnOG] [ALERT] Datacenter down
Lequel ? Alexis 2018-07-27 16:06 GMT+02:00 Thomas : > C'est moi où tout le DC est down ? > > Thomas > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Grosse panne OVH ce matin
De mon côté ça repart tranquillement j'ai l'impression. (sur RBX) Cordialement, Alexis VACHETTE. On 09/11/2017 10:17, Jules-Henri Gavetti wrote: Salut, Moi je pense aux équipes techniques, c'est une véritable épreuve psychologique. Bon courage Jules -Message d'origine- De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de Dominique Rousseau Envoyé : jeudi 9 novembre 2017 09:54 À : frnog@frnog.org Objet : Re: [FRnOG] [TECH] Grosse panne OVH ce matin Le Thu, Nov 09, 2017 at 09:32:20AM +0100, Julien Escario [esca...@azylog.net] a écrit: Bonjour, Ca ne vaut probablement pas trop le coup de faire les kékés sur cette liste. +1 Je pense que pas grand monde ici n'a des infra du ampleur comparable a celles d'OVH pour pouvoir donner son avis... Je ne vous rappelle qu'un truc : Redbus, 2006. Nous étions nombreux à ne pas faire les malins à cette époque. J'espere pour eux qu'ils auront assez de café et un bbq (crepes, whatever, hein ;-) pour se reconforter apres. Courage aux équipes d'Oles qui doivent bien être sous pression avec une obligation de résultat (rapide) dans une situation déjà bien dégradée. Et aux autres qui font le support pour les clients qui ne savent plus vers qui se tourner. Carrement, bon courage a ceux qui sont sur le pont, et a tous ceux qui vont devoir repondre aux clients. -- Dominique Rousseau Neuronnexion, Prestataire Internet & Intranet 21 rue Frédéric Petit - 8 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Cherche retours d'expérience SFR - fibre 100M en ZVS
Par expérience SFR en pro et particulier. Le service n'est clairement plus au rendez-vous. On 03/10/2017 17:01, Nathan delhaye wrote: Le 3 octobre 2017 à 11:25, Sébastien Lesimple < sebastien.lesim...@iguanetel.fr> a écrit : Le 03/10/2017 à 11:08, Felix Defrance a écrit : Le service est-il au rendez-vous? NON! +1 Sur un lien SFR hérité de l'infra Completel y'a 2 semaines j'ai eu 3 jours de coupure avec comme justification : "Bha on as eu une coupure physique sur un gros FO du coup c'est un incident générique alors la GTR s'applique pas" 1. Faut m'expliquer comment UNE coupure, surtout sur un gros FO, ca down un lien en plein Paris pendant 3 jours 2. La GTR s'applique pas parce qu'on est plusieurs a être impacté!?!? WTF !?!? Business plan parfait en somme... 3. Des explications genre "Ils arrivent sur site à 8h30" et le même jour l'aprem à 15h "Ha l'équipe viens d'arriver sur place", c'est moyen niveau com. Ou peut être que SFR as tellement baissé les prix qu'ils peuvent plus acheter de GPS aux équipes de terrain. 4. Mon incident n'était pas listé dans les "incidents génériques" a ce moment là et je n'ai pas recu de mail de déclaration d'incident, encore une fois, niveau com" c'est pas génial. +700€ le lien 100Mbps avec ca comme réponse et comme service, ca fait mal au c.. En tout cas pour moi, fibre noire, lambda, "fibre internet", ADSL, SDSL, IP over Avian Carrier ou Minitel, à n'importe quel prix SFR c'est fini. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Problème SFR ?
Bonjour, Je confirme également un KO sur le netcenter de Courbevoie depuis 13h également. On 18/08/2017 14:15, Olivier Lange wrote: Pareil, on a une trentaine de lien ADSL qui sont tombé, sur du SFR. Ils confirment un incident majeur sur leurs infrastructure, mais pas plus d'info pour le moment. Le 18 août 2017 à 14:04, Olivier Benghozi a écrit : Tout à fait, ça semble HS sur plusieurs sites. Le 18 août 2017 à 13:53, Emmanuel D. a écrit : Nous rencontrons un problème de connectivité depuis peu avant 13h00 sur 4 liens SFR partant de Telehouse2 et Interxion 5. La couche physique (link up) et ethernet (via CDP) semble OK mais l'IP est KO. Est-ce que vous constateriez des problèmes similaires de votre côté ? --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Adresses RFC 1918 dans l'infrastructure
A la lecture du document c'est plus cons?quent que ce que pensais. Envoy? de mon iPhone Le 2 mai 2016 ? 12:36, Alexis VACHETTE mailto:avache...@sisteer.com>> a ?crit : Bonjour Kave, Il ne me semble pas que l'Iran soit sur un Intranet ? l'heure actuelle ? Sauf erreur de ma part. Je sais que lors d'un r?cent voyage l?-bas, le DNS menteur ?tait l?gion. Alexis VACHETTE | Network and System Engineer On 02/05/2016 12:29, Kave Salamatian wrote: Tr?s utilis? en Iran, Chine, Russie. bref tout pays qui souhaiterait pouvoir basculer son r?seau "internet" en intranet rapidement. Pour l'Iran bonne ?tude faite par Collin Anderson http://arxiv.org/abs/1209.6398 Nv Envoy? de mon iPhone Le 2 mai 2016 ? 12:03, Stephane Bortzmeyer <mailto:bortzme...@nic.fr> a ?crit : Ce petit truc de s?curit? <https://twitter.com/farrokhi/status/727052382920658944/><https://twitter.com/farrokhi/status/727052382920658944/> repose sur l'hypoth?se que rares sont les op?rateurs s?rieux qui num?rotent leur infra avec du RFC 1918. Je me demande s'il existe des chiffres pr?cis ? ce sujet. Je sais que cette (mauvaise) pratique existe mais a-t-on une id?e de l'ampleur ? --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Adresses RFC 1918 dans l'infrastructure
Bonjour Kave, Il ne me semble pas que l'Iran soit sur un Intranet à l'heure actuelle ? Sauf erreur de ma part. Je sais que lors d'un récent voyage là-bas, le DNS menteur était légion. *Alexis VACHETTE | Network and System Engineer *On 02/05/2016 12:29, Kave Salamatian wrote: Très utilisé en Iran, Chine, Russie. bref tout pays qui souhaiterait pouvoir basculer son réseau "internet" en intranet rapidement. Pour l'Iran bonne étude faite par Collin Anderson http://arxiv.org/abs/1209.6398 Nv Envoyé de mon iPhone Le 2 mai 2016 à 12:03, Stephane Bortzmeyer a écrit : Ce petit truc de sécurité <https://twitter.com/farrokhi/status/727052382920658944/> repose sur l'hypothèse que rares sont les opérateurs sérieux qui numérotent leur infra avec du RFC 1918. Je me demande s'il existe des chiffres précis à ce sujet. Je sais que cette (mauvaise) pratique existe mais a-t-on une idée de l'ampleur ? --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Adresses RFC 1918 dans l'infrastructure
Je viens de me rendre compte que cette personne est en Iran en plus ! Cordialement, *Alexis VACHETTE | Network and System Engineer* On 02/05/2016 12:03, Stephane Bortzmeyer wrote: Ce petit truc de sécurité <https://twitter.com/farrokhi/status/727052382920658944/> repose sur l'hypothèse que rares sont les opérateurs sérieux qui numérotent leur infra avec du RFC 1918. Je me demande s'il existe des chiffres précis à ce sujet. Je sais que cette (mauvaise) pratique existe mais a-t-on une idée de l'ampleur ? --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [MISC] Re: Problems sur plateformes Centile
Bonjour David, Nous n'avons aucun détail sur cette attaque. Je doute que cela soit disclose sur une liste publique. En revanche, il serait bon de savoir si plusieurs clients sont impactés par ce genre de comportement. Pour avoir comme contact un vendeur de solution Centile, pas de retour alarmant à ce jour. Comme le souligne la personne juste avant moi est-ce que ce Centrex avait des logins de type ipbx/ipbx voir root/root. La sécurité d'une interconnexion avec un prestataire tiers est essentiel à mon sens. Cordialement, Alexis. On 11/03/2016 12:40, ADENIS | David MARCIANO wrote: C'est assez grave comme information, si qq a plus d'informations, je veux bien partager en private Bonne réception David Marciano 163 Avenue Gallieni - 93170 Bagnolet - France Tel : +33 (0)1 48 24 07 07 - Fax : +33 (0)1 48 24 07 08 Mail : dmarci...@adenis.fr -Message d'origine- De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de slesim...@laposte.net Envoyé : jeudi 10 mars 2016 13:14 À : Alexis VACHETTE Cc : Frnog misc Objet : Re: [FRnOG] [MISC] Problems sur plateformes Centile Parceque du forensic a été fait sur les deux machines concernées. - Mail original ----- De: "Alexis VACHETTE" À: slesim...@laposte.net, "Frnog misc" Envoyé: Jeudi 10 Mars 2016 13:08:59 Objet: Re: [FRnOG] [MISC] Problems sur plateformes Centile Bonjour, RAS sur un Centrex. Pourquoi est-ce que tu affirmes que ça vient du VPN de Centile ? Cordialement, Alexis VACHETTE. On 10/03/2016 11:21, slesim...@laposte.net wrote: Hello, Un petit mot pour informer la communauté qu'un problème est apparu ce WE sur deux instance Centiles de ma connaissance. - Pour l'une, un binaire a été installé via le VPN de service Centile et lancé des attaque en amplification DNS à partir de la machine; (accès au VPN plus connexion à la VM sans aucuns brute-force, suppression des historiques et 500meg open bar sur la machine!) - Pour l'autre, toujours via le VPN Centile, une attaque en DDoS de ladite machine cette fois, du type ICMP flood. Certains d'entre vous on-t-ils constatés des soucis avec leur Centile ce WE? Sont-ce deux cas totalement isolés ou tous le monde a-t-il eu droit a son lot de soucis? Bonne journée à tous! Seb. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Problems sur plateformes Centile
Bonjour, RAS sur un Centrex. Pourquoi est-ce que tu affirmes que ça vient du VPN de Centile ? Cordialement, Alexis VACHETTE. On 10/03/2016 11:21, slesim...@laposte.net wrote: Hello, Un petit mot pour informer la communauté qu'un problème est apparu ce WE sur deux instance Centiles de ma connaissance. - Pour l'une, un binaire a été installé via le VPN de service Centile et lancé des attaque en amplification DNS à partir de la machine; (accès au VPN plus connexion à la VM sans aucuns brute-force, suppression des historiques et 500meg open bar sur la machine!) - Pour l'autre, toujours via le VPN Centile, une attaque en DDoS de ladite machine cette fois, du type ICMP flood. Certains d'entre vous on-t-ils constatés des soucis avec leur Centile ce WE? Sont-ce deux cas totalement isolés ou tous le monde a-t-il eu droit a son lot de soucis? Bonne journée à tous! Seb. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] réseau OVH en carafe ?
David, Le full-feed j'ai l'impression mais attention je ne suis pas un expert BGP. Le TCAM exception d'OVH dans le task n'indique pas justement ce soucis ? J'avais cru voir que c'était une espace de stockage software sur le nainternet. Pour Francfort, je pense qu'il n'y a même pas de débat. Cordialement, ** On 12/02/2016 10:48, David Ponzone wrote: Oui. Plus précisément, sur un point de peering comme le DECIX, tu échanges tes routes avec celles de ton peer. Tes routes, c’est tes IP, et éventuellement celles de tes clients qui t’achètent du transit. Dans le jargon, on dit "les AS derrière toi". Ton peer fait de même. C’est un principe de réciprocité qui justifie la gratuité du peering, dans la plupart des cas. Quand les 2 peers sont disproportionnés, il est fréquent que le gros refuse le peering au petit, car le petit a plus à y gagner que le gros. Il va alors souvent lui faire un devis si son métier est de vendre du transit (Orange, HE, etc…), soit lui dire de revenir plus tard quand il aura plus de trafic (Facebook, Microsoft, Akamai, …). La seule fois où tu annonces tout internet à un peer, c’est donc justement si tu lui vends du transit. Tu imagines bien que tu n’a pas envie qu’un autre gus passe par toi et tes transits, qui te coûtent de l’argent, gratuitement. Dans le cas précis de l’AS 31500, il annonce en temps normal environ 117 routes sur un point de peering. Et donc il s’est mis à annoncer peut-être tout Internet, donc 570 000 routes, à OVH. 2 problèmes possibles: -le routeur d’OVH là-bas n’était pas capable de gérer un full-feed (inquiétant…) et/ou -si pour une raison X ou Y dans l’algo de sélection du best-path (un peu long à décrire ici, mais généralement, on met des poids forts sur les routes venant des peering pour les privilégier puisque pas chères), les routeurs d’OVH partout en France se sont mis à envoyer une grosse partie du trafic vers le DECIX, peut-être que les liaisons vers Francfort n’étaient pas dimensionnées pour supporter ça (c’est même quasi sûr). Le 12 févr. 2016 à 10:19, Alexis VACHETTE a écrit : Bonjour, Disons qu'en BGP il faut faire attention à ce que tu annonces. Si tu annonces des routes que tu ne dois pas annoncer, forcément tu as un risque que ça génère des choses incohérentes pour d'autres personnes. Cordialement, *Alexis VACHETTE | Network and System Engineer * Sisteer France: 43 rue Pierre Valette, 92240 Malakoff – France Direct line: +33 1 70 95 51 19 | Fax: +33 1 70 95 50 90 www.sisteer.com <http://www.sisteer.com> On 12/02/2016 10:11, gael_aj...@yahoo.fr wrote: Bonjour à tous, Je reviens un petit peu sur les déboires d'OVH hier pour en comprendre. Pour cela j'avoue compter sur vos lumières :) Pour moi, le BGP c'est encore un peu nouveau, et j'aimerai mieux saisir ce qu'il s'est passé. J'ai pu lire ceci : This leak has impacted some of our routers (6k) which could pass in TCAM exception. -> Je comprend que la mémoire TCAM était pleine et donc ça à vite posé un problème. Suis-je dans le vrai ? J'ai également lu ceci : L'origine du problème vient d'un point de peering DECIX à Francfort où l'un des réseaux AS31500 nous a annoncé via le BGP "tout Internet". Conséquence, 75% de notre trafic a été aspiré par ce réseau, à travers Francfort. -> Sur ce point, j'ai un peu plus de mal. Le principe même d'un routeur BGP n'est il pas d'annoncé l'ensemble des meilleurs routes qu'il connaient ? Charge, au routeur qui les reçoit de choisir ses best routes si il a plusieurs point de peering Il y a forcement un point que je n'ai pas saisi. Pourriez vous éclairer ma lanterne ? Merci d'avance à celui qui prendra quelque minutes pour m'aider à comprendre. Cordialement G. A. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] réseau OVH en carafe ?
Bonjour, Disons qu'en BGP il faut faire attention à ce que tu annonces. Si tu annonces des routes que tu ne dois pas annoncer, forcément tu as un risque que ça génère des choses incohérentes pour d'autres personnes. Cordialement, *Alexis VACHETTE | Network and System Engineer * Sisteer France: 43 rue Pierre Valette, 92240 Malakoff – France Direct line: +33 1 70 95 51 19 | Fax: +33 1 70 95 50 90 www.sisteer.com <http://www.sisteer.com> On 12/02/2016 10:11, gael_aj...@yahoo.fr wrote: Bonjour à tous, Je reviens un petit peu sur les déboires d'OVH hier pour en comprendre. Pour cela j'avoue compter sur vos lumières :) Pour moi, le BGP c'est encore un peu nouveau, et j'aimerai mieux saisir ce qu'il s'est passé. J'ai pu lire ceci : This leak has impacted some of our routers (6k) which could pass in TCAM exception. -> Je comprend que la mémoire TCAM était pleine et donc ça à vite posé un problème. Suis-je dans le vrai ? J'ai également lu ceci : L'origine du problème vient d'un point de peering DECIX à Francfort où l'un des réseaux AS31500 nous a annoncé via le BGP "tout Internet". Conséquence, 75% de notre trafic a été aspiré par ce réseau, à travers Francfort. -> Sur ce point, j'ai un peu plus de mal. Le principe même d'un routeur BGP n'est il pas d'annoncé l'ensemble des meilleurs routes qu'il connaient ? Charge, au routeur qui les reçoit de choisir ses best routes si il a plusieurs point de peering Il y a forcement un point que je n'ai pas saisi. Pourriez vous éclairer ma lanterne ? Merci d'avance à celui qui prendra quelque minutes pour m'aider à comprendre. Cordialement G. A. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] réseau OVH en carafe ?
SDSL et dedicated cloud. J'ai l'impression que ça va mieux maintenant. Cordialement, On 11/02/2016 17:03, Romain Valentin wrote: Bonjour, Vous avez aussi des problème sur le réseau OVH? Merci --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Le pare-feu du geek barbu
David, Je ne parlais que de l'identification d'une personne physique avec une IP. Chez toi quand tu as une famille tu te rends compte qu'hormis faire la police et encore le blocage des services pour faire des choses pas net c'est pas forcément le plus simple. Je suis au niveau de l'accès ADSL bien entendu. De plus je n'ai jamais dit qu'Internet était une zone de non droit, bien que certains le pensent. Cordialement, Alexis. On 04/01/2016 16:53, David Ponzone wrote: il y a un flou artistique pour les hotspot public, ce qui rejoint les discussions récentes à ce sujet. Pour l’accès Internet depuis ton ADSL ou ton mobile, je pense quand même que le détenteur du contrat d’abonnement est la personne qui sera identifiée comme utilisant l’IP publique (avec éventuellement les logs du CGN dans certains cas). Après, on retombe sur le problème: est-ce qu’un particulier est censé être capable de sécuriser complètement son accès WIFI ? Evidemment que non, sauf avec un moyen très simple: pas de WIFI. Peut-il se protéger de toute malware/bot/… ? Non, sauf en coupant Internet, auquel cas le problème de départ ne se pose plus. Le législateur, il a besoin de légiférer. Depuis des dizaines d’année, un abonnement EDF identifie une personne physique (les piratages sont quand même assez rares), de même pour l’eau, et même le téléphone (quand un mec vous collait 10kF d’appels internationaux avec des pinces crocos, je pense qu’il était difficile d’expliquer à Orange que vous étiez innocents). Il n’y a pas de raison qu’un accès Internet soit une zone de non-droit sous prétexte que la technique est défaillante. Le 4 janv. 2016 à 16:35, Alexis VACHETTE <mailto:avache...@sisteer.com>> a écrit : Merci, ça fait plaisir de lire quelque chose de sensé. Cordialement, Alexis. On 04/01/2016 16:23, Edouard Chamillard wrote: non, une adresse IP identifie un périphérique sur le réseau, pas une personne. c'est pas parce que la distinction est suffisamment peu claire pour le législateur qu'il nous pond régulièrement ce genre d’aberration que c'est magiquement vrai. qui plus est, justement parce que cette relation d'identité n'est que un concept juridique, elle n'est pas vraie partout, et donc encore moins utilisable en production. Le 04/01/2016 16:03, Renaud a écrit : Edouard Chamillard a écrit : Par ailleurs, je trouve un peu problématique d'associer identité et adresse IP. Au mieux une adresse IP est une indication géographique. Mais il existe de nos jours beacoup trop de points d'accès ouverts ou d'adresses IPs partagées par de nombreuses personnes pour qu'on puisse continuer à considérer qu'une adresse IP permet d'identifier une personne. Quoiqu'il en soit, si ton réseau ne permet d'accéder qu'à des services privées, je peux comprendre le filtre. Ceci dit, il empêchera également de faire tourner un relai Tor à l'intérieur : un relai a besoin de pouvoir contacter tous les autres relais. et soit dit en passant, une adresse IP c'est pas une identité. qu'elle soit v4 ou v6. si tu as besoin d'identifier des utilisateurs, y'a des mécanismes pour ça. sinon le mème raisonnement conduit a bloquer les hotspots, les opérateur qui font du CGN, etc... l'adresse IP est une donnée à caractère personnelle, justement car elle permet l'identification. Sans moyen "de brouillage" un utilisateur peut être suivi dans la plus part des cas sur la seule base de cette IP. Dans le cas des Hotspot et des CGN il y a une obligation de pouvoir suivre des connexions IP (principalement IP+PORT/TCP) à l'IP qui est derrière le NAT qui elle même est reliée à une identité. Il existe biensur plein de moyen de contourner ceci et TOR en fait parti. Le but étant avant tout de garder controle sur mes données (et les meta aussi). Renaud --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Le pare-feu du geek barbu
Merci, ça fait plaisir de lire quelque chose de sensé. Cordialement, Alexis. On 04/01/2016 16:23, Edouard Chamillard wrote: non, une adresse IP identifie un périphérique sur le réseau, pas une personne. c'est pas parce que la distinction est suffisamment peu claire pour le législateur qu'il nous pond régulièrement ce genre d’aberration que c'est magiquement vrai. qui plus est, justement parce que cette relation d'identité n'est que un concept juridique, elle n'est pas vraie partout, et donc encore moins utilisable en production. Le 04/01/2016 16:03, Renaud a écrit : Edouard Chamillard a écrit : Par ailleurs, je trouve un peu problématique d'associer identité et adresse IP. Au mieux une adresse IP est une indication géographique. Mais il existe de nos jours beacoup trop de points d'accès ouverts ou d'adresses IPs partagées par de nombreuses personnes pour qu'on puisse continuer à considérer qu'une adresse IP permet d'identifier une personne. Quoiqu'il en soit, si ton réseau ne permet d'accéder qu'à des services privées, je peux comprendre le filtre. Ceci dit, il empêchera également de faire tourner un relai Tor à l'intérieur : un relai a besoin de pouvoir contacter tous les autres relais. et soit dit en passant, une adresse IP c'est pas une identité. qu'elle soit v4 ou v6. si tu as besoin d'identifier des utilisateurs, y'a des mécanismes pour ça. sinon le mème raisonnement conduit a bloquer les hotspots, les opérateur qui font du CGN, etc... l'adresse IP est une donnée à caractère personnelle, justement car elle permet l'identification. Sans moyen "de brouillage" un utilisateur peut être suivi dans la plus part des cas sur la seule base de cette IP. Dans le cas des Hotspot et des CGN il y a une obligation de pouvoir suivre des connexions IP (principalement IP+PORT/TCP) à l'IP qui est derrière le NAT qui elle même est reliée à une identité. Il existe biensur plein de moyen de contourner ceci et TOR en fait parti. Le but étant avant tout de garder controle sur mes données (et les meta aussi). Renaud --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] RFC 7610: DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers
Je n'ai surement pas employé le bon terme. Ce que je voulais dire c'est que finalement la mise en oeuvre n'est pas forcément si simple dans certains cas. Espèrons également que les constructeurs suivent ses recommandations. Cordialement, Alexis VACHETTE. On 07/09/2015 10:31, Stephane Bortzmeyer wrote: On Mon, Sep 07, 2015 at 10:24:41AM +0200, Alexis VACHETTE wrote a message of 465 lines which said: Si je comprends bien c'est un compromis et non une solution clé en main ? Là, c'est moi qui ne comprends pas. C'est une solution technique à un problème. Elle est classique puisque c'est la même que le "DHCP snooping" d'IPv4. Elle est clé en main si votre vendeur de commutateurs l'a mise en œuvre dans son firmware. Sinon, parlez à votre commercial. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] RFC 7610: DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers
Bonjour Stéphane, Si je comprends bien c'est un compromis et non une solution clé en main ? Cordialement, Alexis VACHETTE.* *<http://www.sisteer.com> On 07/09/2015 10:15, Stephane Bortzmeyer wrote: Pour ceux qui gèrent des data centers avec IPv6 et DHCP : http://www.bortzmeyer.org/7610.html Auteur(s) du RFC: F. Gont (SI6 Networks / UTN-FRH), W. Liu (Huawei Technologies), G. Van de Velde (Alcatel-Lucent) Un peu de sécurité IPv6 sur le réseau local : comment protéger les pauvres machines Ipv6 contre un méchant serveur DHCP, qui répond à la place du serveur légitime, et plus rapidement que lui ? Pas de surprise, la solution est la même qu'en IPv4 ("DHCP snooping") et est détaillée dans ce RFC : le commutateur bloque les réponses DHCP qui viennent d'un port où aucun serveur DHCP n'est censé être présent. Le mécanisme porte le doux nom de "DHCP Shield". DHCP, normalisé dans le RFC 3315, est très proche en IPv6 et en IPv4 et, dans les deux cas, n'offre quasiment aucune sécurité. Sur un réseau sans serveur DHCP officiel, une machine peut prétendre être serveur DHCP et tout le monde va la croire et accepter ses annonces. C'est une des plaies des réseaux locaux, d'autant plus qu'authentifier le serveur DHCP est très difficile puisqu'on utilise justement DHCP pour ne rien avoir à configurer sur les machines clientes. Sur un réseau avec serveur DHCP légitime, un faux serveur peut parfois se faire écouter, par exemple s'il répond plus vite. Et, même quand il n'y a qu'un seul serveur DHCP, rien ne garantit que les machines utiliseront uniquement les adresses IP qui leur ont été allouées officiellement. Pour "DHCP Shield", le mode de fonctionnement normal est que l'administrateur réseaux configure le commutateur en lui disant sur quels ports du commutateur se trouve le serveur DHCP légitime. Le commutateur examine alors tous les messages et rejette les réponses DHCP qui viendraient d'un autre port. Le problème d'un serveur DHCP pirate est très proche de celui d'un routeur IPv6 pirate qui envoie des "Router Advertisement" (RFC 4861, section 4.2) trompeurs et la solution est donc très proche (pour les RAcailles, les RA illégitimes, le problème était exposé dans le RFC 6104 et la solution, "RA Guard", dans les RFC 6105 et RFC 7113). Voilà pour le principe, les détails maintenant. Un commutateur ordinaire ne protège pas contre les serveurs DHCP pirates. Il faut un "DHCPv6 Shield Device" (section 3 du RFC), commutateur « intelligent » capable de mettre en œuvre la technique décrite dans ce RFC. Demandez à votre vendeur avant d'acheter, s'il y a bien les fonctions de "DHCP Shield". Il faut ensuite le configurer explicitement (le commutateur pourrait apprendre seul, en regardant les réponses mais c'est risqué : si le serveur pirate est déjà en service au moment où le commutateur démarre, ce dernier pourrait prendre le pirate pour le serveur légitime). Cette configuration est faite par l'administrateur réseaux, qui désigne le ou les ports du commutateur qui peuvent légitimement voir arriver des réponses DHCPv6, car un serveur légitime se trouve derrière (section 4 du RFC). Dit comme cela, ça a l'air simple. Mais, dans les réseaux réels, plein de complications peuvent survenir et la section 5 du RFC, sur les problèmes possibles, est *beaucoup* plus longue que la section 4 qui décrit l'algorithme. Premier gag possible, les en-têtes d'extension IPv6 qui sont très difficiles à analyser <http://www.bortzmeyer.org/analyse-pcap-ipv6.html>. Notre RFC impose donc aux mises en œuvre de "DHCP shield" d'analyser *tout* le paquet, de ne pas se limiter arbitrairement aux N premiers octets, car la liste des en-têtes peut être longue. (La section 6 note que cela peut être difficile sur le "fast path" - mis en oeuvre dans le matériel - des commutateurs et suggère de jeter le paquet si on ne peut pas l'analyser complètement, mais avec une liste de protocoles de transport qui soit configurable, pour éviter de bloquer les nouveaux protocoles apparus après la vente du commutateur.) Pour aider un peu les pauvres commutateurs, le RFC 7112 impose que, dans un paquet fragmenté, la *totalité* des en-têtes soit dans le premier fragment (autrement, un serveur DHCPv6 pirate pourrait « tricher » en « cachant » la réponse IPv6 dans le deuxième fragment et en espérant qu'il en soit pas analysé). Le commutateur doit donc jeter les paquets fragmentés dont le premier fragment ne contient pas toute la chaîne des en-têtes. (Interdire que les réponses DHCP soient fragmentées aurait été encore plus efficace mais pouvait être gênant dans certains cas, où il y a un besoin légitime d'envoyer de grandes réponses.) Cette
Re: [FRnOG] Re: [ALERT] OVH down ?
Encore un peu de lag. Cordialement, On 29/07/2015 15:55, Stephane Bortzmeyer wrote: On Wed, Jul 29, 2015 at 01:47:53PM +, ALDO wrote a message of 32 lines which said: Bonjour, suite appel à OVH, le support me demande de suivre sur travaux.ovh.net, mais injoignable. OVH.com injoignable également.OVH ne prévoit aucune communication.Bon courage! Ça semble remarcher, Jean-Kevin a fini de recâbler. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] OVH down ?
Même constat, sauf que ça commence à faire beaucoup. Cordialement, On 29/07/2015 15:47, Charles-Henri BERNARD wrote: "Le POP de Globalswitch est down. Nous investiguons." Ca semble remonté à l'instant Le 29 juillet 2015 15:44, a écrit : Bonjour, je sais pas si le sujet à déjà été ouvert. ovh semble down. 5 serveurs HS chez nous, et plusieurs liens SIP HS également mon mail est chez OVH... j'ai du me réinscrire sur la liste avec un mail perso:'( vous avez des nouvelles? --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeur intermediaire pour aiguiller le trafic vers différentes adsl
Je confirme pour l'APU et la RAM, ça fonctionne parfaitement. Cordialement, On 28/07/2015 13:22, Vincent wrote: Bonjour, J’appuie le choix d’un PC Engine. J’utilise un APU¹ pour mon routeur (et ce qui doit rester dans un tmux, style mutt, IRC et XMPP) à la maison, ça marche nickel. [1] http://www.pcengines.ch/apu1d.htm Pour ma part, j'emploie la petite sœur de chez PC Engine à base de Géode pour faire de la QOS, du routage, du vpn, point d'accès etc. sous openwrt. Ca marche vraiment bien : http://www.pcengines.ch/alix2d13.htm J'ai voulu a un moment y mettre du pfsense, mais c'est trop court en RAM... Par contre sur une APU, ça doit fonctionner sans soucis. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeur intermediaire pour aiguiller le trafic vers différentes adsl
Bonjour, Pour un budget minimum, c'est une solution envisageable s'il dispose d'une machine avec suffisament de carte réseau. Cordialement, On 28/07/2015 10:43, Clement Cavadore wrote: Hello, Tu peux aussi utiliser un firewall sous linux et classifier a la mimine le type de traffic qu'il route. J'ai eu fait ca quand j'étais étudiant: Par exemple, avec la table "mangle" et "-j MARK" de iptables, tu marques les paquets qui correspondent aux ports de surf (80/443) et de mail (25/465/110/995/143/993), et les renvoient sur la liaison 1, et une route par défaut sur la liaison 2. Clément Cavadore On Tue, 2015-07-28 at 07:59 +0100, Antoine Durant wrote: Bonjour, Actuellement j'ai une ADSL qui est utilisé pour monter un VPN vers un autre bureau afin d'utiliser les ressources de là bas. Le problème est que de temps en temps ça rame un peux quand on utilise le VPN et qu'on surf en même temps. Je voudrais rajouter une seconde ADSL qui serait uniquement utilisé pour le surf/mail. L'ADSL 1 serait utilisée pour le VPN et l'ADSL 2 serait utilisée pour le reste du trafic. Déjà est-ce que cela est possible a faire ? Il va falloir que j'intercalle un routeur en dessous de mes deux box ADSL afin de créer une route VPN vers la BOX1 et le reste vers la BOX2. Est-ce que c'est faisable ? Quel routeur CISCO me conseillez vous (très petit budget - de 500€) Merci pour vos retours. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Banques CIC et CM HS ?
Du moins le prestataire qui s'occupe de l'hébergement. *Cordialement,*<http://www.sisteer.com> On 20/07/2015 18:22, Alexis VACHETTE wrote: Bonjour, Etant en relation avec eux sur un projet. Ils avaient un problème de connectivité Internet, pour ma part ça semble résolu. Cordialement, On 20/07/2015 18:17, Arthur Mayrand wrote: Pour info, voici le mail reçu la semaine dernière par les sites utilisant la solution de paiement du CIC et du Crédit Mutuel, la date de l'intervention correspond... [...] Nous sommes amenés à renouveler les certificats présents sur nos serveurs car la fonction de hachage cryptographique "SHA-1" employée par les certificats de nos serveurs Internet ne sera plus reconnue comme suffisamment sécurisée en 2016. Ce changement est une amélioration de la sécurité globale de la solution mais ne remet absolument pas en question la sécurisation actuelle des échanges. Le renouvellement de nos certificats prévu le 20/07/2015 impose un changement d'autorité racine et il y a un risque pour que ce changement bloque les requêtes de service que vous réalisez actuellement sur nos serveurs. Les applications de service potentiellement touchées chez vous sont: capture_paiement.cgi, emulationtpe.cgi, emulation3ds.cgi, etatpaiement.cgi, gestion_aliascb.cgi et recredit_paiement.cgi. Ce seront des erreurs intervenant lors de l'établissement de la connexion qui seront détectées de votre point de vue si notre nouveau certificat est signé par une autorité non reconnue sur votre système. Nous vous invitons à valider dès que possible votre compatibilité avec la nouvelle autorité en réalisant des requêtes en remplaçant votre URL habituelle par « paiement.e-i.com/api ». Exemples: https://paiement.creditmutuel.fr/emulation3ds.cgi sera remplacé pour ce test par https://paiement.e-i.com/api/emulation3ds.cgi https://ssl.paiement.cic-banques.fr/test/etatpaiement.cgi sera remplacé pour ce test par https://paiement.e-i.com/api/test/etatpaiement.cgi La page de paiement (« paiement.cgi ») n’est pas concernée par cette validation. En cas d'erreur: il vous faudra intégrer à votre magasin de certificats la nouvelle racine "VeriSign Class 3 Public Primary Certification Authority - G5" téléchargeable à l'adresse http://www.symantec.com/page.jsp?id=roots Si la mise à niveau des certificats ne résolvait pas le problème de connectivité: veuillez nous contacter à l'adresse infos...@e-i.com. Cordialement, *__* }}} Euro-Information Développements @rthur Le 20 juillet 2015 17:38, Xavier ROCA a écrit : Depuis ce matin BPCA aussi. Mais on avait bien leur site web, seule la partie cyberplus HS. Un peu de temps après un jolie message de MAJ Mdr copier coller du CIC ou inversement ... A l'instant ca tombe en marche. -Message d'origine- De : Michel Luczak [mailto:fr...@shrd.fr] Envoyé : lundi 20 juillet 2015 16:51 À : David Ponzone Cc : Guillaume Tournat; frnog-al...@frnog.org Objet : Re: [FRnOG] [ALERT] Banques CIC et CM HS ? On 20 Jul 2015, at 16:41, David Ponzone wrote: Soit c’est rétabli, soit c’est pas une coupure totale, j’accède bien aux sites. Tentative de paiement à l’instant sur un site qui les utilise, KO (erreur bizarre par contre, 403). ++ ic --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Banques CIC et CM HS ?
Bonjour, Etant en relation avec eux sur un projet. Ils avaient un problème de connectivité Internet, pour ma part ça semble résolu. Cordialement, On 20/07/2015 18:17, Arthur Mayrand wrote: Pour info, voici le mail reçu la semaine dernière par les sites utilisant la solution de paiement du CIC et du Crédit Mutuel, la date de l'intervention correspond... [...] Nous sommes amenés à renouveler les certificats présents sur nos serveurs car la fonction de hachage cryptographique "SHA-1" employée par les certificats de nos serveurs Internet ne sera plus reconnue comme suffisamment sécurisée en 2016. Ce changement est une amélioration de la sécurité globale de la solution mais ne remet absolument pas en question la sécurisation actuelle des échanges. Le renouvellement de nos certificats prévu le 20/07/2015 impose un changement d'autorité racine et il y a un risque pour que ce changement bloque les requêtes de service que vous réalisez actuellement sur nos serveurs. Les applications de service potentiellement touchées chez vous sont: capture_paiement.cgi, emulationtpe.cgi, emulation3ds.cgi, etatpaiement.cgi, gestion_aliascb.cgi et recredit_paiement.cgi. Ce seront des erreurs intervenant lors de l'établissement de la connexion qui seront détectées de votre point de vue si notre nouveau certificat est signé par une autorité non reconnue sur votre système. Nous vous invitons à valider dès que possible votre compatibilité avec la nouvelle autorité en réalisant des requêtes en remplaçant votre URL habituelle par « paiement.e-i.com/api ». Exemples: https://paiement.creditmutuel.fr/emulation3ds.cgi sera remplacé pour ce test par https://paiement.e-i.com/api/emulation3ds.cgi https://ssl.paiement.cic-banques.fr/test/etatpaiement.cgi sera remplacé pour ce test par https://paiement.e-i.com/api/test/etatpaiement.cgi La page de paiement (« paiement.cgi ») n’est pas concernée par cette validation. En cas d'erreur: il vous faudra intégrer à votre magasin de certificats la nouvelle racine "VeriSign Class 3 Public Primary Certification Authority - G5" téléchargeable à l'adresse http://www.symantec.com/page.jsp?id=roots Si la mise à niveau des certificats ne résolvait pas le problème de connectivité: veuillez nous contacter à l'adresse infos...@e-i.com. Cordialement, *__* }}} Euro-Information Développements @rthur Le 20 juillet 2015 17:38, Xavier ROCA a écrit : Depuis ce matin BPCA aussi. Mais on avait bien leur site web, seule la partie cyberplus HS. Un peu de temps après un jolie message de MAJ Mdr copier coller du CIC ou inversement ... A l'instant ca tombe en marche. -Message d'origine- De : Michel Luczak [mailto:fr...@shrd.fr] Envoyé : lundi 20 juillet 2015 16:51 À : David Ponzone Cc : Guillaume Tournat; frnog-al...@frnog.org Objet : Re: [FRnOG] [ALERT] Banques CIC et CM HS ? On 20 Jul 2015, at 16:41, David Ponzone wrote: Soit c’est rétabli, soit c’est pas une coupure totale, j’accède bien aux sites. Tentative de paiement à l’instant sur un site qui les utilise, KO (erreur bizarre par contre, 403). ++ ic --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/