Gros problème apache - help :(

Support Debian
#1

bonjour et merci de me lire

mon serveur tourne sous debian sans aucun problème avec php mysql et apache 2. Tout se passe à merveille sauf quand un petit malin balance via je ne sais quel programme des requetes à fond la caisse.

Le module mod_evasive contre les attaques DoS est activé mais laisse tout passer. Il ne s’agit donc probablement pas de requetes http classiques mais d’autre choses je ne sais pas quoi.

Durant l’attaque, de plus en plus de processus sont marqués en W (sending reply) et y restent une fois qu’ils y sont. Donc de moins en moins de processus disponibles, puis plus aucun et donc plus aucun client n’est désservi (tous les processus bloqués à W)

voici un exemple de server_status après attaque:

350 requests currently being processed, 0 idle workers

WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWKWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWW…
…

Toutes les requetes appelent la meme page ou presque mais en même temps! Temporairement je deny l’ip du type qui génère ca dans httpd.conf et du coup ca se stoppe qd j’ai relancé apache mais ce n’est pas une solution.

Quelqu’un a t il une idée de la parade contre ce genre d’attaques ou au moins plus de précision sur le type f’attaque?

D’avance un grand merci à tous

#2

Ca ne va pas répondre directement à ta question mais installes Nessus et scanne ta machine. Nessus te fournira un bô rapport en pdf en t’expliquant en détail toutes les failles de sécurité qu’il a trouvé sur ta machine.
En plus, s’il est correctement configuré, il te fourni un lien html sur le patch à télécharger qui pourra te corriger une faille détectée.
Une perle ce Nessus… Je scanne systématiquement tous mes serveurs au boulot, avant la mise en production.

#3

Que donne l’access.log d’Apache?

Si tu parviens à indentifier le type de requête qui te bloque, le module mod_security te permettra de les stopper avant qu’elles ne soient traitées par le serveur http.

Il analysera le contenu de la requête (y compris le contenu du POST) et si elle correspond à un masque des requêtes interdites, il lui renverra une erreur 500 et l’éjectera.

C’est un “application firewall” une sorte d’iptables au niveau application.

apt-get install libapache2-mod-security

modsecurity.org/

#4

interressant.
Je pensais, en solution transitoire, à limiter, avec iptables, le débit des requètes arrivant depuis une même adresse, mais le module apache me semble pas mal…

#5

Il est même possible de modifier dynamiquement les règles iptables dès qu’un intrus est détecté par mod_security, mais…

[quote]Making ModSecurity talk to your firewall

In some cases, after detecting a particularly dangerous attack or a series of attacks you will want to prevent further attacks coming from the same source. You can do this by modifying the firewall to reject all traffic coming from a particular IP address (I have written a helper script that works with iptables, download it from here: apachesecurity.net).

This method can be very dangerous since it can result in a denial of service (DOS) attack. For example, an attacker can use a proxy to launch attacks. Rejecting all requests from a proxy server can be very dangerous since all legitimate users will be affected too.

Since most proxies send information describing the original client (some information on this is available here webkreator.com/cms/view.php/1685.html, under the “Stop hijacking” header), we can try to be smart and find the real IP address. While this can work, consider the following scenario:

*

  The attacker is accessing the application directly but is pretending to be a proxy server, citing a random (or valid) IP address as the real source IP address. If we start rejecting requests based on that deducted information, the attacker will simply change the IP address and continue. As a result we might have banned legitimate users while the attacker is still free searching for application holes.

Therefore this method can be useful only if you do not allow access to the application through proxies, or allow access only through proxies that are well known and, more importantly, trusted.

If you still want to ban requests based on IP address (in spite of all our warnings), you will need to write a small script that will executed on a filter match. The script should extract the IP address of the attacker from environment variables, and then make a call to iptables or ipchains to ban the IP address. We will include a sample script doing this with a future version of mod_security.

Source

[/quote]

#6

j’ai bien dit “solution transitoire”.
Mais, je pensais surtout au blocage abusif de grands LANs en NAT/masq, je n’avais pas pensé aux proxies.

#7

J’ai entendu parler que l’on pouvais filtrer les requêtes avec apache car c’est ce que mon hébergeur fait lorsqu’il y a un code hostile qui est exécuter sur le serveur mais je ne sais pas comment.