Avant de poursuivre …
Tu n’as fait nul référence à la version Debian (et ce qu’il s’en suit …) en place chez ovh.
ps : des sauvegardes, bien sûr 
[/quote]
Centros 6 - Cpanel
Sur un forum Debian, cela va être chaud, bien que …
j avoue c est limite … mais bon c est pareil 
ou presque ,
je suis tellement deseperé …
[quote=“jjm”][quote=“BelZéButh”]
Tu n’as fait nul référence à la version Debian (et ce qu’il s’en suit …) en place chez ovh.
[/quote]
Centros 6 - Cpanel[/quote]
Voici les infos que j’obtiens, via le managerv3.
[quote=“ovh”]Parmi les système d’exploitation Linux, OVH vous propose: des distributions classiques ou des distributions prêtes à l’emploi
- Distribution de base
OVH vous offre le choix entre les Linux suivants :
Système d’exploitation CentOS 6.5
32 bits 64 bits[/quote]
[quote=“ovh”]Parmi les système d’exploitation Linux, OVH vous propose: des distributions classiques ou des distributions prêtes à l’emploi
- Distribution prête à l’emploi
OVH vous offre le choix entre les systèmes suivants :
Système d’exploitation Cpanel 11 (CentOS 6)
[/quote]
N’auriez vous pas pris un peu de retard dans les mises à jour … a l epoque
Le tout, gérer via une interface graphique, pour bien faire … 
Centos je ne pratique pas, mais j’imagine que …
Tu pourrais songer sérieusement à migrer de CentOS-6 vers CentOS-6.5, impliquant la mise à jour d’Apache2, Php5, Mysql, etc … je suppose, de même pour Cpanel.
Cela devrait déjà régler bon nombre de soucis/failles. 
tu devrais mettre un varnish en front , ça t’éviterai ce genre de souci 
Tu peux expliquer le lien de cause à effet, parce que je ne vois pas.
Je suis peut-être naïf, mais soit ce sont des requêtes légitimes mais le serveur ne tient plus la charge, soit c’est un flood, une attaque, et il me semble que peu importe que le site soit bien conçu ou non, l’objectif du flood étant de le saturer de toute façon (et si le serveur répond plus vite alors il recevra plus de requêtes). Dans les deux cas les solutions ne sont pas du tout les mêmes.
Fait pété ta configuration fail2ban, le filter.d et le jail.conf ( la partie concernant le filtre que tu mets pour ton index.php?XYZ), pour voir ce qui va pas. On est bien d’accord que les requêtes “type” index.php?XYZ ne sont pas faites dans le cas d’une utilisation normale?
Tu peux testé ta regex avec la commande fail2ban-regex /etc/fail2ban/filter.d/tonfiltre /var/log/apache2/tonfichier.log
[Definition]
failregex = (?P[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}) .+ 404 [0-9]+ "
ignoreregex = favicon.ico
[apache-postflood]
enabled = true
filter = apache-404.conf
logpath = /home/monsite/access-logs/monsite.com
findtime = 10
maxretry = 10
action = iptables-multiport[name=BadBots, port=“http,https”]
sendmail-buffered[name=BadBots, lines=5, dest=you@example.com]
Tu match les 404 ? Si ton fichier index.php existe, tu obtiens un tout sauf un 404, non ?
Pascal, si j’en crois un bon nombre de docs, l’activation des syncookies serait un drastique affaiblissement du protocole TCP (au niveau sécurité et fonctionnalités)
M’enfin, je n’ai jamais testé
en fait je les intercepte avec htaccess , et les dirige sur une page 404
je devrais faire comment ?
Tu aurais un exemple de ce bon nombre de docs stp ?
Par exemple : http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_9-4/syn_flooding_attacks.html
M’enfin;
jjm: tu dois match les entrée comme “POST /index.php?95984847”
Cet article est intéressant, une bonne partie de son contenue a été reprise voire enrichie par l’IETF sous forme de RFC 4987. Mais ils datent un peu.
-
Concernant les problèmes fonctionnels, les syn cookies du noyau Linux supportent les options “de performance” les plus fréquentes (window scaling, SACK) en utilisant les timestamps depuis la version 2.6.26. Certes ils ne supportent pas d’autres options moins fréquemment utilisées mais qui ont un impact moindre sur les performances, ni de futures éventuelles options (il faudra mettre à jour). Et ne pas oublier que les syncookies ne sont effectivement activés que lorsque le nombre de connexions incomplètes (“half-open”, comme celles créées par un syn flood) dépasse le seuil défini par net.ipv4.tcp_max_syn_backlog, donc dans une situation ou les nouvelles connexions ne pourraient de toute façon pas être acceptées sans les syn cookies.
-
Concernant les problèmes de sécurité provoqués par les syn cookies, je n’ai rien vu dans ces documents. La page de Wikipédia dédiée aux syn cookies mentionne un risque d’inefficacité du firewall car ils permettent théoriquement d’établir une connexion TCP sans envoyer de SYN, mais ce risque n’existe pas avec un firewall sérieux à état.
Essaye peut etre plutot ceci , sans le htaccess qui redirige vers les 404 (ou commente pour testé).
failregex = (?IP<host>index.php?[0-9]*)Enfin test la , j’ai pas testé la règle ;X. Tu peux la test avec le fail2ban-regex, ensuite si ta règle match correctement, tu devrais 1 : descendre le maxretry et 2 augmenté le findtime
findtime = 3600 (1H , voir 86400 = 1 semaine)
maxretry = 1
C’ets bourrin, mais si t’es sur que ce type de requête n’est pas naturel… tu peux les dégager à la pelle. Après j’espère que t’es sur hein :p. Avant d’activé la règle testes la bien .