1) Oui je l'attendais celle-la :).
Néanmoins, si on additionne 1&1, Ikoula, Online et nombre d'autres, on
dépasse largement les dédiés d'OVH.
Pourquoi 90% des attaques proviennent d'OVH ? (Et je ne suis pas le seul à
le dire).
Ce n'était pas le cas avant. Pourquoi ?

2) Réactif oui, voir même très réactif. Sur les gros flood solitaire et
ciblé, cela se voit rapidement vu que l'attaquant ne ping plus.

3) Pourquoi devrais-je demander à souscrire une option qui coûte 2 à 5 fois
le prix normal de mon transit pour me protéger du principal hébergeur
français ?
Je dois faire pareil pour me protéger de Online ? D'Ikoula ? De 1&1 ?
95% des attaques n'impactent pas mes clients. 90% des attaques sont une
tentative de saturation de la bande passante. 90% des attaques sont depuis
un seul réseau.
Je ne trouve pas cela normal et ce n'est pas à moi de payer des solutions
supplémentaires.

4) Les 3 attaques de dimanche n'ont pas impactés le réseau (à
40Mbits prêt...). Le problème n'est pas la.

5a) En effet et l'explication est très simple. Il n'y a aucune statistique
réelle sur l'upstream total si ce n'est l'annonce des gros chiffres par
moment.
Il y a quelques temps, (et ceux qui sont clients peuvent aussi le
confirmer), il y avait tout un système anti flood/anti scan sortant. (Très
performant d'ailleurs).
Ce système se basait a priori sur du netflow.
Seulement voila, les routeurs sont très limite niveau CPU et le netflow a
été désactivé presque partout.
Par contre, le réseau est protégé en entrée surement grâce à des ACL qui
est nettement moins gourmand que du netflow.
Pourquoi ne pas faire la même chose en sortie ? On ne saura pas vu que bien
que j'ai demandé plusieurs fois, il n'y a jamais eu de réponse.

5b) Et les politiques de restriction de trafic à 50Mbits en entrant pour le
trafic UDP, cela ne bloque pas du trafic légitime ? NFS, VPN et compagnie ?
Pour contrer ce problème, OVH a mit en place un système d'ip supplémentaire
à 2 ou 3 euros qui ne sont pas protégés.
Pourquoi ne pas faire la même chose sur le trafic sortant ?

6) Octave est réactif sur son twitter et il le dit lui-même. En cas
d'urgence, mail, twitt. Un flood à x9/X10 ma BP, pour moi c'est urgence.
6a) On en revient au fait qu'il dira que ce n'est pas son travail de base
et que ce sera facturé en sus. (Le retour d'autres opérateurs à ce sujet,
ce serait bien d'ailleurs).


Il n'y a pas de fumée sans feu en effet. Des abuses j'en reçois, je traite
au plus vite (moins de 24h), je remercie et j'informe de l'action
entreprise.
Quand un botnet d'une centaines d'ip attaque un serveur web avec 1500 sites
sur le port search-agent, j'ai du mal à comprend qui est visé.
Quand un serveur solitaire tente une saturation de la bande passante en
visant un VPS, j'ai bien la cible en effet. Un VPS avec 256 de ram qui fait
tourner un minecraft...


Cet opérateur ne joue pas le jeu de la neutralité, c'est tout à fait le
problème.
A la rigueur, bloquer mes 3 ranges vers les ranges de ses dédiés, pourquoi
pas.
Bloquer sur la backbone, c'est démesuré.

Je gère une partie de mes produits (plus de 2000) via l'api d'OVH. Mon
serveur de gestion n'y a plus accès.
Il n'est plus possible à mes clients d'indiquer mes serveurs DNS sur leurs
domaines. En effet, le manager OVH fait un zonecheck notamment pour les
.Fr. Le Zonecheck répond que mes serveurs DNS ne ping pas.
Il n'est plus possible à des clients ADSL OVH d'accéder à mes sites et aux
sites de mes clients.


Elle est ou la neutralité que vante OVH ?
Elle est ou la recommandation de l'ARCEP ?

Ce problème dépasse de loin mes quelques perturbations que je peux avoir.
Il démontre qu'un gros opérateur peut sans problème, sans discussion,
censurer et bloquer des petits à la suite d'un "désaccord".
Je n'ai pas fait ce mail pour que Octave débloque mes pools (je crains que
la situation n’évolue pas avant quelques temps), mais pour avoir des avis
et attirer l'attention sur des problématiques que n'importe quel petit
hébergeur pourrait avoir.



Gurvan.



Le 13 février 2012 05:49, Yann Dufour <yann.duf...@gmail.com> a écrit :

> Bonsoir,
>
> Si je résume bien :
> 1/ Vous subissez des attaques de DDOS en provenance d'hôtes appartenant au
> réseau du principal hébergeur français.
> 2/ Vous avez fait part de vos problèmes au service abuse qui a traité les
> incidents.
> 3/ Les DDOS font augmenter votre connectivité de +/- 100Mbps à +/- 900Mbps.
> 4/ Vous avez poser des restrictions sur votre réseau pour prévenir le DDOS.
> 5/ Vous ne comprenez pas pourquoi cet hébergeur n'applique pas les mêmes
> règles de traitement afin de limiter le DDOS sortant de leur réseau.
> 6.a/ Vous avez twitter un dirigeant de cette société pour lui faire part
> de vos problèmes.
> 6.b/ Ce dirigeant impose maintenant un blocage total entre votre réseau et
> le sien.
> 6.c/ Vous ne savez pas (plus ?) comment agir face à cette solution
> radicale.
>
> Alors :-)
>
>
> 1/ Bienvenue dans le monde de l'Internet ! Ce n'est pas vraiment étonnant
> que ce réseau soit la source de DDOS. Il représente quand même beaucoup de
> clients en tout genre (18M web site, 110K dedicated servers, 50k xDSL, 100k
> VoIP (dixit (p******db)).
>
>
> 2/ Limite, c'est peut être une chance que ce soit un réseau avec un
> support en France (réactif ? je ne sais pas car je ne l'ai jamais essayé
> :-)) ! Cela doit grandement faciliter la résolution des incidents "dans des
> délais raisonnables" ;-) Quand on a à faire face à des DDOS provenant
> d'hébergeurs exotiques, c'est un peu plus compliqué à gérer... :-/ Et en
> général, un Black Hole temporaire est souvent nécessaire !
>
>
> 3/ C'est effectivement fâcheux de faire face à cela... Après si on regarde
> chez votre fournisseur de connectivité, il propose dans son offre de
> transit ip une option "Serveur Black Hole pour combattre les DDOS" ! Amha,
> il serait judicieux de se rapprocher de lui pour étudier cela (d'un point
> de vue technique et économique). Il y a de forte chance que ce soit
> efficace pour faire face à des DDOS (pas que pour ceux en provenance de
> O**) ;-)
>
>
> 4/ D'après ce que j'ai pu voir, vous avez un assigned PI annoncé par votre
> fournisseur sur son AS. Quelques soit les restrictions appliquées sur votre
> infrastructure (la plus simple et efficace étant une ACL en entrée qui
> discard le trafic en provenant d'hôte malveillant), cela n'empêchera pas
> votre fournisseur de forwarder le trafic vers votre infrastructure, et donc
> de vous facturer le trafic supplémentaire.
>
>
> 5/ Effectivement cet opérateur n'applique pas une politique identique
> concernant le DDOS entrant et sortant. Il peut y avoir plusieurs
> explications à cela :
>
> a) O** c'est quand même +/- 530Gbps en upstream vers Internet. Supposons
> qu'ils ont un ratio 1/4, et donc qu'ils ont +/- 130Gbps en downstream
> depuis Internet. Mettre en œuvre des règles anti DDOS pour 130Gbps, c'est
> déjà assez conséquent en terme de ressources machines. Je vous laisse
> imaginer pour 660Gbps !
>
> b) Il n'est pas évident/simple d'être pro-actif au niveau du DDOS en
> sortie, car on risque d'avoir des faux positifs pouvant bloquer du trafic
> client légitime.
>
>
> 6/ Malheureusement, Twitter n'est pas un outil de communication qu'on
> utilise pour régler ce genre de problème ! Si un jour vous avez un problème
> avec F***, vous allez twitter X***** N*** ?
>
> Je pense que votre problème n'est pas la priorité de ce dirigeant... Amha
> il a d'autres "problèmes" beaucoup plus sérieux à traiter comme son CDN
> EU/US, son ISP xDSL, ses équipements/fournisseurs parfois capricieux (ses
> LNS Redback, ses cœurs de réseau Cisco ASR, ses opérateurs de collecte
> rouge ou orange...), le lancement de sa filiale canadienne... Et puis, il a
> aussi peut être une vie personnelle le dimanche :-P
>
> Normalement vous auriez du contacter le support de votre fournisseur
> gérant votre assigned PI qui :
> a) Applique des contres mesures sur son réseau pour réduire les impacts
> sur votre prestation
> b) Contacte le noc/abuse de l'opérateur source pour que les agissements
> illicites cessent
> c) Informe son client de l'avancement de son incident
>
>
> Enfin bref... Effectivement la réaction est un peu disproportionnée...
> Mais bon de là à dire sur cette liste que cet opérateur ne joue pas le jeu
> de la neutralité (enfin de ce que j'en sais), alors qu'il communique sur
> cela et essaye d'être relativement transparent au niveau de la vie de son
> réseau :^)
>
> Contacter le support de l'hébergeur en expliquant que vous avez eu un DDOS
> provenant de leur réseau, et que suite à cela, votre réseau ne peut plus
> communiquer avec le leur. Normalement ça devrait se régler ;-)
>
> Et puis comme a dit Benjamin, faire un petit ménage devant votre porte ne
> devrait pas faire de mal car il n'y a pas de fumé sans feu !
>
> Cordialement,
> Yann
>
> Le 12 février 2012 19:07, Gurvan Rottier-Ripoche <inulo...@gmail.com> a
> écrit :
>
>> Bonjour,
>>
>> Ceci n'est pas un mail pour venir pleurer/troller sur OVH mais plutôt pour
>> prendre des conseils et chercher à comprendre.
>>
>>
>> Notre réseau est régulièrement la cible d'attaques depuis des machines
>> OVH.
>> Indifféremment depuis des serveurs hackés participant dans des botnets que
>> depuis des serveurs clients légitimes qui réalisent des attaques ciblés
>> notamment via des offres low-cost "jetables".
>> Je fais de nombreux report à leur service abuse qui intervient dans des
>> délais raisonnables.
>>
>> La période des vacances a démarré et très souvent, c'est une
>> grande effervescence de ce type d'attaques.
>> Nous avons reçu plusieurs attaques ce Dimanche 12 Février 2012 allant
>> jusqu'a 900Mbits depuis 9 serveurs OVH. (A relativiser avec notre 95
>> percentile de 100Mbits).
>> J'ai twitté Octave pour lui faire part de mon mécontentement du fait du
>> nombre important d'attaques en une journée.
>>
>> A chaque fois ses réponses sont virulentes (très proches de la
>> diffamation)
>> et fermés à la discussion :
>> "C'est pas mon problème."
>> "Tu as une activité de hackeur."
>> "C'est à toi de gérer ton réseau."
>>
>> Alors que je suis la cible dans cette histoire et que je ne vois pas
>> comment agir...
>> De notre côté, nous appliquons des restrictions entrantes et sortantes
>> mais
>> ces nombreuses attaques ont des répercussions sur le coût du trafic
>> entrant
>> en amont de notre réseau.
>> Notre fournisseur de transit nous fait payer malgré tout le coût de
>> l'attaque et c'est logique.
>> Ces attaques dépassent parfois de beaucoup (pratiquement x10) l'usage
>> normal de notre bande passante.
>>
>>
>> Ce que je ne comprend pas, c'est qu'OVH disposent bien de mécanismes de
>> protections mais uniquement sur son trafic entrant.
>> Par contre, ils n'appliquent pas les mêmes mécaniques en sens inverse pour
>> éviter ou limiter les attaques sortantes de leur réseau.
>>
>> Comme seule solution, aujourd'hui suite à mes reports, Octave impose un
>> blocage total entre nos deux réseaux.
>> Cela gène nombre de mes clients qui ne peuvent plus opérer de redondance,
>> simplement communiquer envers les deux réseaux (plus de DNS, SQL etc...)
>> et
>> moi-même qui ne peut plus du tout accéder aux services d'OVH que j'utilise
>> également. (Ne serait-ce que le site OVH.COM...).
>> J'imagine également que les clients ADSL d'OVH ne peuvent plus accéder à
>> l'ensemble de mes services.
>>
>> Qu'en pensez-vous ?
>> Un fournisseur d'accès a-t-il le droit de bloquer comme cela une partie du
>> trafic internet, portant atteinte à la neutralité d'internet et aux
>> recommandations de l'ARCEP sur la transparence et la non-discrimination
>> des
>> flux.
>> Les mesures prises me semblent disproportionnées.
>> Quelles sont les solutions que vous appliquez sur vos réseaux ?
>> Avez-vous déjà eu ce type de problème ?
>>
>> Cordialement, Gurvan.
>>
>> ---------------------------
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>
>

---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/

Répondre à