Bonsoir, Le 30 août 2010 à 21:43, Nicolas Steinmetz a écrit :

Bonsoir,

Au bureau, pour protéger des sites publics de l'aspiration des données de station par des applications codées parfois de façon assez étrange / bourrine, notre RSSI avait codé un script bash qui tourne au niveau des reverse proxys (sous Apache 2.2 + Mod_proxy). Si le client dépasse un certain seuil de consultations pour une heure donné, il est blacklisté jusqu'à ce que son traffic sur l'heure glissante redescende en dessous du fameux seuil.

Comme nous allons prochainement utilisé les services d'un CDN, il nous faut modifier ce script et personne n'a envie ni le temps de le mantenir. Je me pose alors la question de repartir sur un module apache. Je me suis rappelé de mod_evasive [1] mais il n'a plus l'air maintenu.

mod_security ne me semble pas adapté pour ce que je souhaite faire : autoriser la consultation d'une url dans la limite d'un seuil donné.

Avez-vous des pistes à me conseiller ?

mod_evasive (anciennement appellé mod_dosevasive) me semble approprié pour ce genre de choses. Comme tu dis il a l'air plus maintenu... mais je suis plutôt a penser qu'il n'y as pas grand chose a maintenir ... A part les API apache qui ne changent pas beaucoup.... Xavier

Le 30 août 2010 21:43, Nicolas Steinmetz <nsteinmetz@gmail.com> a écrit :

Avez-vous des pistes à me conseiller ?

Pour limiter le nombre de requête par seconde, j'utilise ce module : http://mod-qos.sourceforge.net/ Il a l'air de faire son travail A+ Oliv'

Salut,

Pour moi, mod_evasive fait mal son travail puisqu'il agit trop tard pour rejeter les bourrins : mod_evasive agit au niveau d'Apache, autrement dit trop tard pour empêcher qu'Apache, l'élement actif, ne se prenne de la charge.

La solution pour moi réside dans Iptables avec le module limit.

mod_evasive peut se coupler avec iptables et le blocage est alors réaliser en amont d'apache. L'intérêt que je vois par rapport à iptables+limit c'est que la détection se fait de manière plus fine :-) Mehdi

Bonsoir, Je fais une réponse collective : Le 31 août 2010 14:02, Mehdi AMINI <joker.eph@gmail.com> a écrit :

Salut,

...

Pour moi, mod_evasive fait mal son travail puisqu'il agit trop tard pour rejeter les bourrins : mod_evasive agit au niveau d'Apache, autrement dit trop tard pour empêcher qu'Apache, l'élement actif, ne se prenne de la charge.

La solution pour moi réside dans Iptables avec le module limit.

mod_evasive peut se coupler avec iptables et le blocage est alors réaliser en amont d'apache. L'intérêt que je vois par rapport à iptables+limit c'est que la détection se fait de manière plus fine :-)

A la limite, si on bloque au niveau d'apache au stade des Reverse Proxy, c'est pas encore trop dramatique car cela préserve les frontaux applicatifs. Les Reverse Proxy tiennent très bien la charge pour le moment, c'est plutôt les frontaux applicatifs qu'on souhaite préserver. Je m'ajoute iptables dans mon étude, j'avoue ne pas y avoir songé. Merci, Nicolas -- Nicolas Steinmetz http://www.steinmetz.fr - http://nicolas.steinmetz.fr/

Bonjour, Sur ma production j'ai fait un peu différemment... Mais je n'ai pas non plus la même problématique que toi. J'ai n fronteaux derrière un bigip qui lui limite le nombre de connections par secondes, puis chaque fronteaux a un nginx qui fait juste proxy et qui revoie vers les apache derrière. Nginx a sont équivalent de mod_evasive, plus fin a priori que celui de apache. La cerise sur le gateau c'est que passer de apache 2.2 en prefork "a poil" a un nginx en face, m'as fait gagné.. pas loin de 20% de temps CPU sur les fronteaux. Prochaine étape dans l'optimization : utiliser 100% nginx sauf pour les truc de pages personnelles (php bref!)... Xavier