NPDS
Responsive

OK j'ai mis toutes les ip que j'ai pu identifier à 5 pour l'avenir.

Je vous ferai mon petit rapport de cette expérience, je ne sais pas si le module de sécurité à la possibilité de gérer ce genre d'attaque mais toute expérience est bonne à partager.

La base est réouverte depuis ce midi et pour l'instant ça tient.

Je vous fait l'historique tout d'abord :

Ma base a été fermée jeudi soir une première fois, OVH m'indiquant une surcharge du serveur sql en m'indiquant des requêtes tout à fait habituelles. J'ai d'abord pensé qu'il s'agissait d'une recrudescence de fréquentation et ai donc mis en service le système de cache du site de manière à alléger le serveur.

Ma base a été réactivée vendredi AM et a été remise en état closed presqu'immédiatement.

J'ai donc cherché dans mes logs et là j'ai vite compris qu'il s'agissait d'une attaque de type DDOS. ==> http://pharmechange.free.fr/txt/logweb.txt

J'ai donc par la suite renommé le fichier concerné par l'URL visée et au fil du temps l'attaque a progressivement diminué.

Bien sur j'ai trouvé trace de ces attaques ensuite dans mes logs d'erreur. ==> http://pharmechange.free.fr/txt/logerror.txt
J'ai noté dans les logs qu'il y avait eu dans les minutes précédent le bombardement un scan de plusieurs URL

J'ai mis un maximum de ces ip dans ipban sans prétendre les avoir misent toutes.

Maintenant il me reste beaucoup de question.

Pourquoi cette URL?
Le fichier htaccess proposé par aidadomicil est-il plus efficace qu'ipban?
Notre CMS préféré a t'il la capacité à nous protéger de ce type d'attaque, actuellement non, mais dans l'avenir?

je t'ai proposé une solution via fichier htaccess parceque tu semblais ne pas avoir accès à ton site et à ta base de données, il te suffisait d'envoyer ce fichier par ftp, il était opérationnel immédiatement.
Maintenant que tu as un accès normal, tu peux utiliser ipban, je te garanti qu'il bloque bien les problèmes dans le genre du tien !!!
Tu n'es pas obligé dans ip ban d'entrer toutes les adresse ip recontrés dans tes logs juste les trois premieres series de chiffres, ca bloque la totalité de la derniere plage ex pour 122.53.52.10 tu peux indiquer 122.53.52 ce qui bloque de 122.53.52.0 à 122.53.52.255
bon courage :=!



Notre CMS préféré a t'il la capacité à nous protéger de ce type d'attaque, actuellement non, mais dans l'avenir?



Aucun logiciel ne le peux

Cette nuit ça a continué toujours sur la même !url(!heureusement), bien qu'ajouter dans ipban il y a une ip qui est passée dans le log d'erreur.

[Tue Dec 02 07:33:20 2008] [error] [client 61.19.42.46] [host www.pharmechange.com] script not found or unable to stat: /home.2/pharmech/www/minisite.php

dans spam.log j'ai 61.19.42.46:5 c'est normal?

"Aucun logiciel ne le peux" Ce n'est pas très rassurant, et au niveau du serveur? Parceque en utilisation une url identique appelée à raison de x fois à la seconde ce n'est pas un comportement normal.
Quand un bot passe il n'appelle pas x fois la même url, on ne peut donc pas confondre.

Autre question les fichiers log doivent être à quel chmod.

Oui c'est normal :5 c'est denied.

WIKI DIT :



Comment éviter ces attaques [modifier]

Les attaques de type DoS peuvent être évitées en repérant l'adresse de la machine hostile, dans le cas d'une attaque à distance, et de bannir celle-ci. Les paquets IP provenant de cette machine seront donc dès lors rejetés directement sans être traités.

Les attaques de type DDoS sont beaucoup plus difficiles à éviter, on peut seulement limiter leurs effets dévastateurs en repérant les machines hostiles effectuant trop de requêtes en un temps limité (comportement client anormal) afin de les bannir au fur et à mesure. Cependant une attaque massive et rapide ne sera sans doute pas enrayée ainsi. Une architecture répartie, composée de plusieurs machines serveurs offrant le même service gérées de sorte que chaque adresse IP de machine cliente ne soit prise en charge que par l'un d'entre eux, permet de répartir les points d'accès aux services voulus et offre un mode dégradé (ralentissement) souvent acceptable. L' utilisation de SYN cookies est également une solution envisageable pour éviter les attaques de type SYN flooding mais ne permet pas cependant d'éviter la saturation de la bande passante du réseau.


c'est donc exactement ce que tu fais ... maintenant a voir avec ton hebergeur qui a peut etre d'autres solutions

L'hébergeur botte en touche en disant que c'est à moi de veiller à la sécurité de mes fichiers...vu que ce n'est pas ça qui est en jeu...

Je me posais une question si la cible est un fichier qui dispose du cache : forum.php par ex: est-ce que ça protège le serveur sur ce type d'attaque?

non pas vraiment / en fait contre un DOS il n'y a pas vraiment de bonne contre mesure au niveau PHP parce que quel que soit la solution on arrive toujours à saturer Apache, Mysql ou même le serveur

Bon ben il reste donc à bruler un cierge pour qu'on m'oublie.

Alors ?

Pourvu que ça dure.

oui ...