j'ai eu un message donc de l'hébergeur qui me signale que j'ai dépassé la limite cpu (4.5%) et il suspens mon site temporairement (solution facile au lieu de sécuriser le serveur)

Bonjour,

C'est justement cette sécurisation du serveur qui bloque votre site, c'est à vous de sécuriser votre application pour limiter le nombre de connexions simultanées sur un script lourd, tout simplement.
L'hébergeur ne peut pas forcément savoir si ce traffic est légitime ou pas, il peut simplement choisir de laisser passer (pour assurer l'accessibilité de votre site) et de vous déléguer la responsabilité de ne pas consommer trop de ressources. Bien sur il existe aussi des modules qui vont renvoyer des erreurs 403 aux clients suspectés de flooder le serveur, encore faut il que le déni de service soit mal réalisé (quelques ips uniques, énormément de connexions en même temps..), ce qui n'est peut être pas votre cas ici.

j'ai eu un message donc de l'hébergeur qui me signale que j'ai dépassé la limite cpu (4.5%) et il suspens mon site temporairement (solution facile au lieu de sécuriser le serveur)

Bonjour,

C'est justement cette sécurisation du serveur qui bloque votre site, c'est à vous de sécuriser votre application pour limiter le nombre de connexions simultanées sur un script lourd, tout simplement.
L'hébergeur ne peut pas forcément savoir si ce traffic est légitime ou pas, il peut simplement choisir de laisser passer (pour assurer l'accessibilité de votre site) et de vous déléguer la responsabilité de ne pas consommer trop de ressources. Bien sur il existe aussi des modules qui vont renvoyer des erreurs 403 aux clients suspectés de flooder le serveur, encore faut il que le déni de service soit mal réalisé (quelques ips uniques, énormément de connexions en même temps..), ce qui n'est peut être pas votre cas ici.

Ca ça se fait au niveau du parefeu. Au niveau PHP c'est complètement useless parce que c'est déjà trop tard…

On ne limite pas l'accès à un script PHP lourd (consommant du CPU - la raison invoquée lors du blocage) avec un parefeu:
- une personne requiert une page web et on lui dit que le serveur n'est pas accessible (parce qu'il se retrouve bloqué par le firewall) au lieu de lui présenter un message clair d'attente ?
- un compte web sur un serveur mutualisé n'a - espérons le - pas ce genre de droits

Le parefeu est le dernier recours de l'hébergeur lui même en cas de souci, pas de l'hébergé.

Sur mon serveur fail2ban sert justement à détecter facilement ce genre d'attaque simpliste... Je pensais que ce type de solution était un minimum

Dans le cas de amin2009 , fai2ban serai inefficace , car il ne relève que les erreurs ( tentative de charger une page qui n'existe pas ) ce qui permet de bloquer rapidement les scans par exemple , seulement là , la page qui est chargé de tres nombreuses fois , est valide , fail2ban ne verrai donc rien.

Un premiére solution ( en amont du code ) serait le mod_evasive d'apache , et/ou ensuite , un niveau du firewall , avec une règle netfilter qui limite par ip le nombre de connexions simultané sur la même requête

existe t'il d'autres solutions alternatives ( hors code php ) ?

Je suis désolé mais une attaque DoS ou DDos, on ne l'arrête pas au niveau applicatif avec un joli message d'erreur, tout en XHTML/CSS avec des belles images : "Désolé, mais nous ne pouvons pas afficher cette page", on l'arrête au niveau du parefeu, en essayant en plus de maintenir la connexion ouverte le plus longtemps possible pour bloquer le script appelant.
Et ce genre d'attaques est parfaitement détectable, puisque quand un bon million de clients demande la même page en une intervalle de quelques secondes, sur un site qui n'a pas vocation à dépasser le dizaine de milliers de vistes par jour, c'est très louche.

Alors, T0aD, que tu argues qu'il est préférable que l'hébergé face attention à ce genre de problèmes, je l'admets, mais que tu affirmes que c'est à lui de se protéger, et que l'hébergeur n'a aucune responsabilité, ça c'est tout simplement faux. C'est en premier lieu à l'hébergeur d'assurer la pérénité de son service, et quand une attaque DoS réussit, il n'a pas à retourner la responsabilité contre le client, car dans ce cas c'est bel et bien l'hébergeur qui ne fait pas son boulot…

Un DoS réseau / requêtes oui je suis d'accord bien sûr, une surconsommation de CPU, non. Là je revenais sur la personne qui se plaignait que son hébergeur ne soit pas sécurisé et lui proposais une solution à son niveau (elle ne pourra pas forcément convaincre son hébergeur à changer de stratégie).

Et extrapolons aussi sur le fait qu'un firewall n'est pas non plus la solution miracle à tous les DDoS
Un de nos confrères se fait quelque fois complètement saturer la bande passante suite à ce genre d'attaques

Oui, sauf quand la charge CPU est dûe à une attaque :

j'ai reçu une attaque sur mon site sous forme d'une page web contenant des milliers d'iframes appelant mon site ce qui augmente la charge CPU du serveur

Et dans ce cas, l'hébergeur n'a pas à rejeter sur son client une faute qui n'est pas la sienne…

Au niveau du script, on le conçoit de telle manière à ce qu'il ait une consommation acceptable par visiteur, au cours d'un fonctionnement normal du site. Mais logguer les connexions pour se prémunir des attaques (déjà est incompatible avec certaines CGU comme celles de 1and1 qui interdisent de logguer les connexions sur certains mutualisés) est une surcharge inutile pour le script.
Beaucoup de fournisseurs de services mettent dans leurs CGU qu'ils ne seront pas imputables de pénalités en cas de force majeure, je ne vois pas pourquoi le client serait imputable de quoi que ce soit en cas d'attaque, qui est pour lui aussi une force majeure (moins pour l'hébergeur par contre)…

Je poste pour confirmer que mod_evasive est un bon mod, je l'ai déjà tester, en même temps il y'a aussi iptables, mais bon pour les débutants en serveur, il vaut mieux mettre en place mod_evasive, quand on le peut, mais biensur il protège que sur les http flood, genre 10 get et/ou post en 2 secondes selon la configuration.