Bonjour,

Il est tout à fait possible de développer des modules Apache. En analysant le code source de mod_evasive, je ne suis pas en mesure de définir à quel moment le module est appelé : avant ou après la création du processus pour répondre à la page. A priori, il a l'air d'être appelé après, car selon son travail, il renvoie "OK" ou "FORBIDDEN" (constantes).

Or, si je souhaiterais intervenir avant tout.

Je précise que, hélas, après deux nuits entières à chercher, je n'ai pas trouvé de solutions pour les DOS. LA seule pseudo solution est de placer MaxClients à 10, en partant du plus pessimiste des situations que chaque appel soit à des pages PHP très lourdes (15 mo de RAM). Cela n'empêche en rien un simple DOS, brute force ou autre, car les autres requetes sont mises en attentes, et rend les performances médiocres sur un scénario pessismiste. EN plus, mod_evasive ne fonctionne pas bien, et il n'agit qu'après le processus créé (si mon hypothèse est bonne).

Donc, je suis reparti sur un calcul simple en faisant une moyenne des pages, pour une moyenne de 3 Mo par ressource (Php / Image), et j'ai remonté MaxClients à 30.

Je regarde donc à mettre Nginx en serveur frontal afin d'éviter ce genre de limite, et de jouer le filtre avant de transmettre une page à Apache. Je pourrai alors donner un nombre important de requêtes possibles sur les ressources statiques, et partir sur une moyenne de ressource par processus pour Apache beaucoup plus réel (8-10 Mo). J'espère aussi et surtout trouver de quoi filtrer les abus, donc le plus tôt possible pour éviter le gachis de ressources et le DOS, et sinon développer un simple et léger module Apache, à la condition mentionnée ci-dessus.

Merci par avance ...

LOL ... Le code suivant marche bien en code "prepend". Le comportement à certains moments est quand même bizarre ...
Mod_evasive et Mod_security fonctionne bien sur le flood et tout ... quand on fait F5 F5 F5 F5 F5, paf ! On est viré ...
Mais quand on reste appuyé sur F5 ... C'est une autre histoire (????)

Donc, mon script fonctionne mais j'aime pas du tout. Je sens que je vais tout passer en worker pour voir car là, raz-la-casquette !

<?php

ini_set('display_errors',1);
error_reporting(E_ALL);

$ips = apc_fetch('ips');
if (!$ips) $ips = array();
$count = 0;
$ri = $_SERVER['REMOTE_ADDR'];

foreach ($ips as $k=>$ip)
{

        if ($ip['t'] <  time() - 6)
        {
                unset($ips[$k]);
        }
        else
        {
                if ($ip['i'] == $ri) $count++;
        }

}

if ($count > 2)
{
        header('HTTP/1.1 503 Service Unaivailable',true,503);
        exit;
}

array_push($ips,array('i'=>$ri,'t'=>time()));

apc_store('ips',$ips);

la solution ultime c'est de configurer un ids couplé à un firewall, c'est beaucoup plus carré et global comme solution.

Tu as des noms d'HIDS ?

LOL .. le mode WORKER a l'air de mieux fonctionner de ce côté là ... Problème de gestion de mémoire à tous les coups ...

Tu as des noms d'HIDS ?

option usine à gaz
http://www.prelude-technologies.com/fr/ ... index.html

option juste détection de base
http://www.snort.org/

lol j'ai regardé SNORT ... Rien trouvé.

Par contre, comme je l'ai dit, le mode WORKER offre l'avantage d'une mémoire partagée, et les problèmes viendraient de là. Associé à un script de contrôle lors d'abus qui peut gérer l'iptable, ca peut être du toner.

Sinon, SNORT pour tester malgré un keep-alive plusieurs requêtes ? Car, bien que la spécification précise qu'il faut une longueur de contenu précisée au retour par le serveur, je ne vois pas ce qui empêche le client de relancer une requête derrière, et le serveur la prendra certainement.