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 ?
Merci, Nicolas
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
Bonjour,
Le 30/08/2010 21:43, Nicolas Steinmetz a écrit :
Avez-vous des pistes à me conseiller ?
Je suis tombé là dessus récemment, peut-être que ça peut répondre à vos besoins :
http://geekosphere.org/898/limit-bandwidth-per-vhost-in-apache2-on-debianlen...
Bonsoir,
Le 31 août 2010 10:53, Greg greg-frsag@duchatelet.net a écrit :
Je suis tombé là dessus récemment, peut-être que ça peut répondre à vos besoins :
http://geekosphere.org/898/limit-bandwidth-per-vhost-in-apache2-on-debianlen...
Merci, cela se rapproche pas mal de cband mais en moins abouti a priori.
Nicolas
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'
Bonsoir,
Le 31 août 2010 11:00, Olivier Buisson obuisson1976@gmail.com a écrit :
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
Cela a l'air pas mal du tout.
Merci à tout le monde pour les pistes suggérées, y a plus qu'à étudier et implémenter la solution qui sera retenue.
Bonne soirée, Nicolas
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
Bonsoir Nicolas,
Bonsoir,
Le 31 août 2010 11:00, Olivier Buisson obuisson1976@gmail.com a éc rit :
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
Cela a l'air pas mal du tout.
Merci à tout le monde pour les pistes suggérées, y a plus qu'à étudier et implémenter la solution qui sera retenue.
Tu peux rajouter à ton étude HAproxy:
Petit article :
http://blog.serverfault.com/post/1016491873/better-rate-limiting-for-all-wit...
Je ne sais pas si Haproxy est la solution à ton problème. En tout cas il a beaucoup d'atouts, le code est propre et la documentation claire. Il est designé pour la performance et pourtant ne manque pas de fonctionalités.
My 2 cents
-- Nicolas Carlier "Never lose a holy curiosity" AE
2010/8/30 Nicolas Steinmetz nsteinmetz@gmail.com:
Bonsoir,
<Zip>
Merci, Nicolas -- Nicolas Steinmetz
Bonjour Nicolas,
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.
Florian MAURY
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
-
Florian MAURY -
Greg -
Mehdi AMINI -
Nicolas Carlier -
Nicolas Steinmetz -
Olivier Buisson -
Xavier Beaudouin