[FRnOG] Pb OVH ?!
Bonjour à tous, Je ne vois plus OVH à partir de Cogent ou Interoute. Quelqu'un sait ce qui ce passe ? Guillaume Digicube sas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Pb OVH ?!
Salut, Aucun soucis par ici, j'accède bien à OVH depuis divers réseaux. Kianouch - Guillaume Esnault gesna...@digicube.fr a écrit : Bonjour à tous, Je ne vois plus OVH à partir de Cogent ou Interoute. Quelqu'un sait ce qui ce passe ? Guillaume Digicube sas --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Pb OVH
Le Wed, 28 Apr 2010 13:58:06 +0100, Thomas Mangin thomas.man...@exa-networks.co.uk a écrit : Bloquer ICMP et forcer un MSS est courant dans les milieu telecom (internet 3G, etc.) c'est vraiment dommage de voir ces pratiques passer dans les réseaux des ISP/Hebergeurs, mais chacun gère sont réseau comme il veut. La plupart même ... des gros paquets finissent par être dropés et au final çà génère un poil plus de trafic ... a +. -- Jérôme Benoit aka fraggle La Météo du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D pgpRpoN6op6Q1.pgp Description: PGP signature
Re: [FRnOG] Pb OVH
Hello, Le 28 avr. 2010 à 13:37, Denis Alligand a écrit : Le 28 avril 2010 13:33, Jérôme Nicolle jer...@ceriz.fr a écrit : Le 28/04/10 13:23, Sébastien Mortier a écrit : Bonjour, A priori, OVH vient de limiter le trafic (limiter = interdire..??) ICMP Internet vers OVH. http://travaux.ovh.net/?do=detailsid=4140 A suivre... Cordialement, Filtrage de l'ICMP sur un réseau d'hébergeur, je suis le seul à trouver ça tendancieux ? Ne devraient ils pas plutôt inviter les administrateurs à configurer leurs firewalls ? Bon courage à tout ceux qui monitorent leurs serveurs chez OVH depuis un autre réseau... Je confirme, sapin de Noel sous nagios pour les qques serveurs que j ai sur OVH, packet loss 70%, ca va etre pratique pour le monitoring :) C'est un peu ce que je pensais... Bon... Bah, il suffit d'aller ailleurs pour les serveurs :) Xavier--- Liste de diffusion du FRnOG http://www.frnog.org/
Ip publiques (was Re: [FRnOG] Pb OVH)
Le 28 avril 2010 à 19:04, Radu-Adrian Feurdean a écrit: Le pire que j'ai vu c'est des IP publiques utilises dans le core mais pas annonces dans la table globale Des IP publiques peuvent être annoncées à des peers sans pour autant se retrouver dans la table globale. Ca me semble un fonctionnement certes inhabituel, mais normal en IPv4. -- Xavier Nicollet --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: Ip publiques (was Re: [FRnOG] Pb OVH)
Hello, On Thu, 2010-04-29 at 10:22 +0200, Xavier Nicollet wrote: Le 28 avril 2010 à 19:04, Radu-Adrian Feurdean a écrit: Le pire que j'ai vu c'est des IP publiques utilises dans le core mais pas annonces dans la table globale Des IP publiques peuvent être annoncées à des peers sans pour autant se retrouver dans la table globale. Ca me semble un fonctionnement certes inhabituel, mais normal en IPv4. Ce fonctionnement là ne me choque pas. Si on a un subnet alloué pour le backbone, il faut bien qu'il soit public (ie: non RFC1918), mais si la communication avec l'extérieur du réseau n'est pas nécessaire (ce qui est généralement le cas avec les IPs d'interco interne au réseau, ou les loopbacks), alors pourquoi l'annoncer ? C'est, IMHO, moins choquant que d'utiliser des IPs publiques dans un LAN NATé vers Internet... Egalement, dans les réseaux financiers (coucou a qui se reconnaîtra :)), ils utilisent des IPs publiques sur un internet parallèle. Même si ca me choque un peu personnellement, ca reste compliant avec les usages du RIPE (peut être des autres RIR), semble-t-il. L'allocation de ressources se fait, il me semble, sans que le RIR n'aie quoi que ce soit à dire quant à l'annonce (partielle ou totale) sur Internet desdites ressources. -- Clément Cavadore --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: Ip publiques (was Re: [FRnOG] Pb OVH)
On Thu, 29 Apr 2010 10:22:56 +0200, Xavier Nicollet nicol...@jeru.org said: Des IP publiques peuvent être annoncées à des peers sans pour autant se retrouver dans la table globale. Ca me semble un fonctionnement certes inhabituel, mais normal en IPv4. En occurence pas visible en tant que client, pas visible via leur transit, tres probablement pas visible du tout. ... cretainement tres efficace pour proteger des equipements de backbone ... -- Radu-Adrian Feurdean raf (a) ftml ! net --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: Ip publiques (was Re: [FRnOG] Pb OVH)
Clement Cavadore wrote: Ce fonctionnement là ne me choque pas. Si on a un subnet alloué pour le backbone, il faut bien qu'il soit public (ie: non RFC1918), mais si la communication avec l'extérieur du réseau n'est pas nécessaire (ce qui est généralement le cas avec les IPs d'interco interne au réseau, ou les loopbacks), alors pourquoi l'annoncer ? Disons que tu peux avoir communication si un routeur est amenné à proposer une fragmentation à l'éméteur du paquet qu'il détruit. Communication unidirectionnelle, certes, mais communication tout de même. Sur 5410 j'avais totalement filtré en entrant les classes servant à la numération des loopbacks et des /30 d'interco sur tout l'edge du réseau. C'est encore la moins pire des protections. Pour les probes venant de l'intérieur (les abonnés), une policy-map sur le control-plane est suffisante. Bref, on en revient à l'origine de la discussion, filtrer ICMP vers l'ensemble de ses blocs est inepte sachant que n'importe quel mioche peut trouver le switch UDP ou TCP de son botnet. --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: Ip publiques (was Re: [FRnOG] Pb OVH)
Tout cela dépend d'une politique d'annonce et de stratégie de sécurité on peut très bien adresser tout son backbone en privé ou décider d'utiliser des blocs publique qui seront Null routé sur les routeurs de bordures et les routeurs servant de gateway au clients. Pour vivre heureux vivons caché ;-) Michaël Villar -Message d'origine- De : nicol...@jeru.org [mailto:owner-fr...@frnog.org] De la part de Xavier Nicollet Envoyé : jeudi 29 avril 2010 10:23 À : frnog@FRnOG.org Objet : Ip publiques (was Re: [FRnOG] Pb OVH) Le 28 avril 2010 à 19:04, Radu-Adrian Feurdean a écrit: Le pire que j'ai vu c'est des IP publiques utilises dans le core mais pas annonces dans la table globale Des IP publiques peuvent être annoncées à des peers sans pour autant se retrouver dans la table globale. Ca me semble un fonctionnement certes inhabituel, mais normal en IPv4. -- Xavier Nicollet --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: Ip publiques (was Re: [FRnOG] Pb OVH)
Le 29 avril 2010 à 11:28, Antoine Versini a écrit: Disons que tu peux avoir communication si un routeur est amenné à proposer une fragmentation à l'éméteur du paquet qu'il détruit. Communication unidirectionnelle, certes, mais communication tout de même. Le routeur prend-il l'ip de la loopback pour émettre l'icmp ? Il me semblerait plus logique qu'il utilise l'ip de l'interface de sortie. PS: je ne pensais pas particulièrement aux loopbacks quand j'ai posté. -- Xavier Nicollet --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: Ip publiques (was Re: [FRnOG] Pb OVH)
Xavier Nicollet wrote: Le 29 avril 2010 à 11:28, Antoine Versini a écrit: Disons que tu peux avoir communication si un routeur est amenné à proposer une fragmentation à l'éméteur du paquet qu'il détruit. Communication unidirectionnelle, certes, mais communication tout de même. Le routeur prend-il l'ip de la loopback pour émettre l'icmp ? Il me semblerait plus logique qu'il utilise l'ip de l'interface de sortie. Le comportement standard est bien d'utiliser l'adresse IP (principale pour un certain vendeur ;) ) de l'interface par laquelle s'est présenté le paquet détruit. PS: je ne pensais pas particulièrement aux loopbacks quand j'ai posté. Ok. -- Antoine Versini Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Pb OVH
Bonjour a tous Avez-vous aussi des problèmes vers OVH depuis le DECIX Cordialement Thierry
Re: [FRnOG] Pb OVH
Bonjour, A priori, OVH vient de limiter le trafic (limiter = interdire..??) ICMP Internet vers OVH. http://travaux.ovh.net/?do=detailsid=4140 A suivre... Cordialement, Seb. Le 28/04/2010 12:55, WideVOIP a écrit : Bonjour a tous Avez-vous aussi des problèmes vers OVH depuis le DECIX Cordialement Thierry
Re: [FRnOG] Pb OVH
Entièrement d'accord avec toi Jérôme.. Je trouve ça moyen-moyen.. Mais je crois définitivement que nous ne sommes plus à l'ère de la responsabilisation des admins... Quand Free filtre le SMTP par défaut sur ses freeboxs : OK (d'autant plus que c'est désactivable)... mais là... Le 28/04/2010 13:33, Jérôme Nicolle a écrit : Le 28/04/10 13:23, Sébastien Mortier a écrit : Bonjour, A priori, OVH vient de limiter le trafic (limiter = interdire..??) ICMP Internet vers OVH. http://travaux.ovh.net/?do=detailsid=4140 A suivre... Cordialement, Filtrage de l'ICMP sur un réseau d'hébergeur, je suis le seul à trouver ça tendancieux ? Ne devraient ils pas plutôt inviter les administrateurs à configurer leurs firewalls ? Bon courage à tout ceux qui monitorent leurs serveurs chez OVH depuis un autre réseau... --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Pb OVH
Qui prend le pari que c'est un changement qui va être défait a' cause de la pression clientèle ? Avec de la chance ils filtrent correctement et path MTU discovery marche encore :p Thomas On 28 Apr 2010, at 12:37, Denis Alligand wrote: Le 28 avril 2010 13:33, Jérôme Nicolle jer...@ceriz.fr a écrit : Le 28/04/10 13:23, Sébastien Mortier a écrit : Bonjour, A priori, OVH vient de limiter le trafic (limiter = interdire..??) ICMP Internet vers OVH. http://travaux.ovh.net/?do=detailsid=4140 A suivre... Cordialement, Filtrage de l'ICMP sur un réseau d'hébergeur, je suis le seul à trouver ça tendancieux ? Ne devraient ils pas plutôt inviter les administrateurs à configurer leurs firewalls ? Bon courage à tout ceux qui monitorent leurs serveurs chez OVH depuis un autre réseau... Je confirme, sapin de Noel sous nagios pour les qques serveurs que j ai sur OVH, packet loss 70%, ca va etre pratique pour le monitoring :) Denis -- Jérôme Nicolle
Re: [FRnOG] Pb OVH
Bonjour, Le Wednesday 28 Apr, vers 13:33, Jérôme Nicolle exprimait : http://travaux.ovh.net/?do=detailsid=4140 Filtrage de l'ICMP sur un réseau d'hébergeur, je suis le seul à trouver ça tendancieux ? OVH ne fait pas que de l'hébergement. Ne devraient ils pas plutôt inviter les administrateurs à configurer leurs firewalls ? L'un n'empêche pas l'autre, et je ne suis pas assez informé pour te dire qu'ils ne l'ont pas fait. Mais attendre les autres ne règle pas ton problème. Bon courage à tout ceux qui monitorent leurs serveurs chez OVH depuis un autre réseau... Si tu monitores par ICMP, c'est à toi que je souhaite bon courage :-) À plus tard.. -- « Si un dieu était si puissant qu'il ait créé le monde, mais qu'ensuite il ne fasse rien pour y corriger les problèmes, à quoi bon l'adorer ? Ne serait-il pas plus juste de le juger ? » - Richard M. Stallman --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Pb OVH
Le 28/04/10 13:42, Jean-Michel Planche a écrit : Ceci dit monitorer avec de l'icmp, est ce bien raisonnable ... ;-) Ca fait partie des tests de base sur un schéma plus global. Niveau best practices, j'en arrive grosso modo à ce schéma : - ICMP (smokeping et traceroute si variation de latence) vers une machine par réseau, depuis chaque réseau, pour detecter les changements de route et les variations de latence en bas niveau - ICMP moins fréquent (30 à 180 secondes de période) vers toutes les machines (test de base pour l'uptime et la dispo) - Tests applicatifs (HTTP replay, typiquement) toutes les 5 à 10 minutes pour surveiller la charge des applis - Remontée de sonde locale en burst toutes les 60 à 300 secondes Ca minimise la charge induite par le monitoring tout en remontant toutes les infos dont j'ai besoin. Et dans tous les cas l'ICMP est indispensable... Mais j'ai l'impression que nous en reparlerons lors du prochain frnog en vrai Oui, d'ailleurs, c'est quand ? Philippe ? Des nouvelles ? -- Jérôme Nicolle signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Pb OVH
Le 28/04/10 13:44, Stephane Kanschine a écrit : OVH ne fait pas que de l'hébergement. Et ? Tant qu'ils y font de l'hébergement, s'ils le font sur un réseau (pas taper) quasi-neutre, c'est un problème Ne devraient ils pas plutôt inviter les administrateurs à configurer leurs firewalls ? L'un n'empêche pas l'autre, et je ne suis pas assez informé pour te dire qu'ils ne l'ont pas fait. Mais attendre les autres ne règle pas ton problème. Les floods ICMP qui impactent le backbone, j'y crois moyennement. Ce serait plutôt du à une hausse des appels de support à cause de quelques cibles d'attaques de ce genre. Si c'est le backbone qui est impacté, je suppose que c'est un problème structurel. Pas de force majeure suffisante pour justifier le filtrage donc. Si c'est juste pour quelques serveurs, là c'est aux admins de ces serveurs de régler le problème. Et si c'est sur les mutus, la VoIP ou quelconque autre service, alors c'est aux admins d'OVH de sécuriser ces services. Si tu monitores par ICMP, c'est à toi que je souhaite bon courage :-) Répondu dans un autre mail ;) Mais si tu monitores sans ICMP, il y a plein de choses que tu ne dois pas voir et qui pourtant peuvent être importantes. -- Jérôme Nicolle signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Pb OVH
2010/4/28 Stephane Kanschine carx...@hexecho.net Bonjour, Le Wednesday 28 Apr, vers 13:33, Jérôme Nicolle exprimait : http://travaux.ovh.net/?do=detailsid=4140 Filtrage de l'ICMP sur un réseau d'hébergeur, je suis le seul à trouver ça tendancieux ? OVH ne fait pas que de l'hébergement. Ne devraient ils pas plutôt inviter les administrateurs à configurer leurs firewalls ? L'un n'empêche pas l'autre, et je ne suis pas assez informé pour te dire qu'ils ne l'ont pas fait. Mais attendre les autres ne règle pas ton problème. Bon courage à tout ceux qui monitorent leurs serveurs chez OVH depuis un autre réseau... Si tu monitores par ICMP, c'est à toi que je souhaite bon courage :-) ICMP ne se borne pas à du echo reply/request. Si tu filtres tout ICMP, tu casses la conformité réseau, dont les retours icmp type 3/6 qui ont du sens de notre point de vue... (avertissement en cas de MTU incorrect, etc...). Mais avant de crier au scandale, attendons des réponses, il s'agit d'une limitation, pas d'un blocage, avec un peu de chance c'est par ip source. À plus tard.. -- « Si un dieu était si puissant qu'il ait créé le monde, mais qu'ensuite il ne fasse rien pour y corriger les problèmes, à quoi bon l'adorer ? Ne serait-il pas plus juste de le juger ? » - Richard M. Stallman --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Steven Le Roux Jabber-ID : ste...@jabber.fr 0x39494CCB ste...@le-roux.info 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB
Re: [FRnOG] Pb OVH
Filtrage de l'ICMP sur un réseau d'hébergeur, je suis le seul à trouver ça tendancieux ? Ne devraient ils pas plutôt inviter les administrateurs à configurer leurs firewalls ? On ne peut pas faire changer les autres (surtout les clients de nos jours qui se croient tout permis parce qu'ils payent). Soit OVH fait avec et se prend des floods ICMP qui induisent une charge de travail supplémentaire, soit OVH fait sans et shape l'ICMP. Après si les clients ne sont pas contents, c'est pareil : On ne peut pas faire changer les autres, on ne peut changer que soi même, donc ils peuvent changer d'hébergeur plutôt que d'aller pleurer chez je ne sais qui :) Bon courage à tout ceux qui monitorent leurs serveurs chez OVH depuis un autre réseau... Enlever le check_icmp ou le remplacer par un autre check pour obtenir la latence vers le serveur en question n'a rien d'insurmontable d'un point de vue technique. Et puis voyons les choses de façon positives : des gens ont pu s'apercevoir que nagios fonctionnait toujours ;) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Pb OVH
Le message d'Octave sur la mailing list ovh http://pastebin.com/JkDPtzuf On Wed, 28 Apr 2010 13:55:34 +0200, Steven Le Roux ste...@le-roux.info wrote: 2010/4/28 Stephane Kanschine carx...@hexecho.net Bonjour, Le Wednesday 28 Apr, vers 13:33, Jérôme Nicolle exprimait : http://travaux.ovh.net/?do=detailsid=4140 Filtrage de l'ICMP sur un réseau d'hébergeur, je suis le seul à trouver ça tendancieux ? OVH ne fait pas que de l'hébergement. Ne devraient ils pas plutôt inviter les administrateurs à configurer leurs firewalls ? L'un n'empêche pas l'autre, et je ne suis pas assez informé pour te dire qu'ils ne l'ont pas fait. Mais attendre les autres ne règle pas ton problème. Bon courage à tout ceux qui monitorent leurs serveurs chez OVH depuis un autre réseau... Si tu monitores par ICMP, c'est à toi que je souhaite bon courage :-) ICMP ne se borne pas à du echo reply/request. Si tu filtres tout ICMP, tu casses la conformité réseau, dont les retours icmp type 3/6 qui ont du sens de notre point de vue... (avertissement en cas de MTU incorrect, etc...). Mais avant de crier au scandale, attendons des réponses, il s'agit d'une limitation, pas d'un blocage, avec un peu de chance c'est par ip source. À plus tard.. -- « Si un dieu était si puissant qu'il ait créé le monde, mais qu'ensuite il ne fasse rien pour y corriger les problèmes, à quoi bon l'adorer ? Ne serait-il pas plus juste de le juger ? » - Richard M. Stallman --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Pb OVH
Le 28 avril 2010 à 12:41, Thomas Mangin a écrit: Qui prend le pari que c'est un changement qui va être défait a' cause de la pression clientèle ? Avec de la chance ils filtrent correctement et path MTU discovery marche encore :p Le path MTU discovery ne marche déjà pas vers le site ovh.com qui filtre tout l'icmp sans distinction. D'un autre côté, il y en a surement d'autres. Si ces pratiques n'étaient pas courantes, la MTU moyenne utilisée sur Internet aurait pu grandir. Et ça, ça aurait limité le nombre de datagrammes routés par nos équipements. -- Xavier Nicollet --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Pb OVH
Le path MTU discovery ne marche déjà pas vers le site ovh.com qui filtre tout l'icmp sans distinction. D'un autre côté, il y en a surement d'autres. Si ces pratiques n'étaient pas courantes, la MTU moyenne utilisée sur Internet aurait pu grandir. Et ça, ça aurait limité le nombre de datagrammes routés par nos équipements. Dans ce cas tout les ISP qui ont des client avec des lignes DSL en PPoE (ou PPoA avec le router mal configure en PPPoE) SANS un MSS clamp de 1452 (ou quelque chose comme ça) du cote des LNS ne pourront pas voir les sites d'OVH. je sais qu'il y en a. Bloquer ICMP et forcer un MSS est courant dans les milieu telecom (internet 3G, etc.) c'est vraiment dommage de voir ces pratiques passer dans les réseaux des ISP/Hebergeurs, mais chacun gère sont réseau comme il veut. Thomas--- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Pb OVH
Le Wednesday 28 Apr, vers 13:49, Jérôme Nicolle exprimait : Le 28/04/10 13:42, Jean-Michel Planche a écrit : Ceci dit monitorer avec de l'icmp, est ce bien raisonnable ... ;-) Ca fait partie des tests de base sur un schéma plus global. Niveau best practices, j'en arrive grosso modo à ce schéma : - ICMP (smokeping et traceroute si variation de latence) vers une machine par réseau, depuis chaque réseau, pour detecter les changements de route et les variations de latence en bas niveau Ce sont des best pratices purement réseau, pas serveur. Quand tu monitores un serveur, tu ne te bases généralement pas sur ICMP. - ICMP moins fréquent (30 à 180 secondes de période) vers toutes les machines (test de base pour l'uptime et la dispo) L'uptime se récupère par sonde et celles ci sont généralement via TCP/UDP. - Tests applicatifs (HTTP replay, typiquement) toutes les 5 à 10 minutes pour surveiller la charge des applis - Remontée de sonde locale en burst toutes les 60 à 300 secondes Sonde qui ne se récupèrent pas en ICMP classiquement. Ca minimise la charge induite par le monitoring tout en remontant toutes les infos dont j'ai besoin. Et dans tous les cas l'ICMP est indispensable... Je ne voulais pas dire qu'ICMP était inutile, juste qu'il n'est pas courament utilisé pour monitorer un serveur, parce qu'on monitore des services qui ne sont pas en ICMP, que SNMP est en TCP/UDP, que les sondes modernes sont en TCP/UDP. Ce n'est pas l'objet de la liste, nous avons des points de vues différents, donc EOT. -- « Si un dieu était si puissant qu'il ait créé le monde, mais qu'ensuite il ne fasse rien pour y corriger les problèmes, à quoi bon l'adorer ? Ne serait-il pas plus juste de le juger ? » - Richard M. Stallman --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Pb OVH
Le message d'Octave sur la mailing list ovh http://pastebin.com/JkDPtzuf Je ne comprend pas ce genre de stratégie, je veux bien être le candide à qui on a besoin de faire un dessin pour comprendre les packets qui sont filtrés, ils seront bien passés par une ligne avant d'etre detruit par le routeur. Bon, il economise le reply, mais l'echo, Octave le paye quand meme sur sa (?) ligne. Si OVH a au total 10G de BP, et qu'il collecte 20G d'echo icmp qui bourre ses 10G, il detruira tous les echo, mais au final, il n'améliorera rien du tous sur ses lignes. C'est plus vrai ce que je raconte ? Parce que cela l'a été quand j'administrais, et je dirais meme plus (comme Dupond et Dupont) c'est un sujet pour la neutralité et la coordination entre opérateurs. CodeRed doit rappeller quelques souvenirs dans cette liste non ? Un nouveau CodeRed, et tous le monde dort sur ses 2 oreilles aujourd'hui ? Si oui, chapeau, c'est moi qui est obsolète, et je suis curieux de savoir comment vous faites, parce que la méthode d'Octave, elle ne marche pas, (de par mon experience) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Pb OVH
Hello, On Wed, 2010-04-28 at 15:33 +0200, Stephane Le Men wrote: Je ne comprend pas ce genre de stratégie, je veux bien être le candide à qui on a besoin de faire un dessin pour comprendre Je ne prends pas position sur la légitimité ou non de telles pratiques, mais: Je pense plutôt que si un serveur ne répond pas (ou plus) aux ICMP brutaux, alors l'attaquant (ou le kiddie script) pensera qu'il est arrivé à ses fins. Et le serveur, en prime, n'aura (presque) rien eu comme problème opérationnel. Après, une option freebox-SMTP-like permettant d'enlever la protection ICMP par défaut, après moults warning, ca serait pas mal :) -- Clément Cavadore --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Pb OVH
... chacun gère sont réseau comme il veut. ouff ! --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Pb OVH
les packets qui sont filtrés, ils seront bien passés par une ligne avant d'etre detruit par le routeur. Les packets passeront sur le lien entre le transitaire/peer et OVH - mais ce que OVH protège c'est son backbone, il ne cherche pas a réduire sa facture de transit mais a proteger ses liens internes (surtout si les données des ses serveurs sont maintenant sur des disques non-locaux : une saturation pourrait causer des problèmes de latence, etc.). En limitant le nombre de packet ICMP/bande passante pour ICMP par IP (ou globalement par lien), une DDOS de 1,000 serveurs a un impact calculable sur le réseau (1000x le maximum par IP - ou la limite maximale configure par lien). Sans cela, la limite est ce que les clients peuvent lui envoyer : _beaucoup_ plus. c'est un sujet pour la neutralité et la coordination entre opérateurs. Non ce n'a rien a voir avec la neutralité - et je me répète chacun gère son réseau (limite ICMP, etc.) comme il veut. Ce que je dirai par contre a' Octave, est : STP laisse passer Fragmentation Needed (Type 3, Code 4) http://en.wikipedia.org/wiki/Path_MTU_discovery CodeRed doit rappeller quelques souvenirs dans cette liste non ? Oui, je m'en souvient, j'avais deux machines infecte envoyant 2x100 Mb de traffic - pas drole de voir deux STM-1 saturer !! Mais les choses ont changes depuis 200. Le gros problème a ete le flap des connections BGP des transitaire. Maintenant grace au QOS, cela n'arrivera pas. Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Pb OVH
Le message d'Octave sur la mailing list ovh http://pastebin.com/JkDPtzuf Je ne comprend pas ce genre de stratégie, je veux bien être le candide à qui on a besoin de faire un dessin pour comprendre Le problème des 2 litres d'eau dans la carafe d'un litre, le filtrage n'y change rien, il n'y a pas besoin de dessin pour le comprendre :) les packets qui sont filtrés, ils seront bien passés par une ligne avant d'etre detruit par le routeur. Bon, il economise le reply, mais l'echo, Octave le paye quand meme sur sa (?) ligne. Si OVH a au total 10G de BP, et qu'il collecte 20G d'echo icmp qui bourre ses 10G, il detruira tous les echo, mais au final, il n'améliorera rien du tous sur ses lignes. Je ne sais pas comment OVH réalise ce filtrage mais à leur place je le ferais le plus près possible de la source. Dans leur cas c'est Internet la source, donc filtrer en périphérie de réseau serait (toujours selon moi) une bonne idée pour éviter de congestionner le backbone. Enfin je crois me souvenir d'un mail d'Octave sur cette même liste qui disait qu'en Europe de l'Est par exemple, les peerings ne se faisaient que dans le sens OVH - ISP, toutes les requêtes entrantes passaient par un lien de transit, donc l'ISP paye aussi pour envoyer les paquets qui causent le DDoS. Ca fait perdre de l'argent à l'ISP qui héberge les zombies/script kiddies/whatever et ça le fait réagir plus vite. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Pb OVH
On 28 Apr 2010, thomas.man...@exa-networks.co.uk wrote: Qui prend le pari que c'est un changement qui va être défait a' cause de la pression clientèle ? Chez OVH ? Je ne prendrais pas ce pari. -- Cyril Bouthors --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Pb OVH
Julien Reveret wrote: Je ne comprend pas ce genre de stratégie, je veux bien être le candide à qui on a besoin de faire un dessin pour comprendre Le problème des 2 litres d'eau dans la carafe d'un litre, le filtrage n'y change rien, il n'y a pas besoin de dessin pour le comprendre :) Et encore, ça risque d'être un choc culturel pour le monsieur quand il va s'apercevoir avec effroi qu'après avoir trouvé le bidule parfait pour caser la flotte, il va se faire soumettre sa carafe avec de la bierre. Bierre qu'il n'aura par ailleurs aucun moyen de filtrer puisque c'est précisément le breuvage qui intéresse ses clients. -- Antoine Versini Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Pb OVH
On Wed, 28 Apr 2010 16:25:11 +0200 (CEST), Julien Reveret shad...@c0a8.org said: Je ne sais pas comment OVH réalise ce filtrage mais à leur place je le ferais le plus près possible de la source. Dans leur cas c'est Internet la source, donc filtrer en périphérie de réseau serait (toujours selon moi) une bonne idée pour éviter de congestionner le backbone. Autre chose possible (selon moi), isoler les equipements backbone dans quelques subnets bien precis, et filtrer a gogo (y compris TCP et UDP) les subnets en question en bordure. Le pire que j'ai vu c'est des IP publiques utilises dans le core mais pas annonces dans la table globale (on retrouve le meme chose plus souvent fait avec des RFC1918). Apres, tout ca se prevoit au niveau design. ou alors ce ne sont pas les equipements eux-meme qu'il faut proteger . -- Radu-Adrian Feurdean raf (a) ftml ! net --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Pb OVH
les packets qui sont filtrés, ils seront bien passés par une ligne avant d'etre detruit par le routeur. Les packets passeront sur le lien entre le transitaire/peer et OVH - mais ce que OVH protège c'est son backbone, il ne cherche pas a réduire sa facture de transit mais a proteger ses liens internes Pas de probleme, mais je ne suis pas sûr que le but cherché soit atteint, le router et la ligne, c'est un ensemble, et regler le problème seulement sur le router, ne le règle pas sur la ligne. c'est un sujet pour la neutralité et la coordination entre opérateurs. Non ce n'a rien a voir avec la neutralité - et je me répète chacun gère son réseau (limite ICMP, etc.) comme il veut. Moi je pense que si, parce que j'estime qu'un hebergement est en droit de demander un filtrage en amont de ses peers, pour justement preserver ses lignes. Le filtrage sur le router, c'est une thérapie homéopatique, cela ne soulage que l'esprit. Libre aux herbegeurs de choisir le traitement qu'ils veulent mais jusqu'à preuve du contraire, quand un router detruit 99% du traffic entrant, la BP reelle est de 1% . À partir de ce constat, j'ai du mal à croire que tous les investisssements que les hebergeurs peuvent faire pour regler ce probleme leur restaureront leur BP nominale. Et c'est pour cela que je trouve normal (mais quasi impossible à faire) de pouvoir transmettre ses filtres à ses peers, pour faire remonter le filtrage le plus loin possible. Je crois que tout le monde a à y gagner, hebergeurs pour preserver leur visibilité, operateurs pour ne pas avoir à router du traffic qui sera de toute façon detruit . AMHA, toutes actions entreprises au niveau de l'hebergeur sans la participation de ses peers n'est que gesticulation. On tente de remedier à un vrai probleme par une fausse solution. Ce que je dirai par contre a' Octave, est : STP laisse passer Fragmentation Needed (Type 3, Code 4) Oui je suis aussi d'accord, mais là aussi chacun fait bien ce qu'il veut, on est bien d'accord là dessus, CodeRed doit rappeller quelques souvenirs dans cette liste non ? Oui, je m'en souvient, j'avais deux machines infecte envoyant 2x100 Mb de traffic - pas drole de voir deux STM-1 saturer !! Ben oui, je trouve que CodeRed avec d'autre comme SQLSlammer sont des cas d'ecole, (et perso, sans critique vis à vis de qui que soit), qui ne sont toujours pas compris. Qu'OVH claque du blé inutilement, cela fera plaisir à Cisco Co, mais ce qu'il compte faire pour resoudre CE probleme, désolé de vous le dire, c'est du placebo. Apres, chacun voit midi à sa porte. Un conseil, demandez un POC à vos fournisseurs et vous verrez bien. (Signé: Saint Thomas) --- Liste de diffusion du FRnOG http://www.frnog.org/
