Faire face aux attaques HTTP w00tw00t

J'ai un serveur avec apache et j'ai récemment installé mod_security2 parce que je suis très attaqué par ceci:

Ma version d'apache est apache v2.2.3 et j'utilise mod_security2.c

Voici les entrées du journal des erreurs:

[Wed Mar 24 02:35:41 2010] [error] 
[client 88.191.109.38] client sent HTTP/1.1 request without hostname 
(see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

[Wed Mar 24 02:47:31 2010] [error] 
[client 202.75.211.90] client sent HTTP/1.1 request without hostname 
(see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

[Wed Mar 24 02:47:49 2010] [error]
[client 95.228.153.177] client sent HTTP/1.1 request without hostname
(see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

[Wed Mar 24 02:48:03 2010] [error] 
[client 88.191.109.38] client sent HTTP/1.1 request without hostname
(see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

Voici les erreurs de l'access_log:

202.75.211.90 - - 
[29/Mar/2010:10:43:15 +0200] 
"GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 392 "-" "-"
211.155.228.169 - - 
[29/Mar/2010:11:40:41 +0200] 
"GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 392 "-" "-"
211.155.228.169 - - 
[29/Mar/2010:12:37:19 +0200] 
"GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 392 "-" "-" 

J'ai essayé de configurer mod_security2 comme ceci:

SecFilterSelective REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind"
SecFilterSelective REQUEST_URI "\w00tw00t\.at\.ISC\.SANS"
SecFilterSelective REQUEST_URI "w00tw00t\.at\.ISC\.SANS"
SecFilterSelective REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind:"
SecFilterSelective REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind:\)"

La chose dans mod_security2 est que SecFilterSelective ne peut pas être utilisé, il me donne des erreurs. J'utilise plutôt une règle comme celle-ci:

SecRule REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind"
SecRule REQUEST_URI "\w00tw00t\.at\.ISC\.SANS"
SecRule REQUEST_URI "w00tw00t\.at\.ISC\.SANS"
SecRule REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind:"
SecRule REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind:\)"

Même cela ne fonctionne pas. Je ne sais plus quoi faire. Quelqu'un a un conseil?

Mise à jour 1

Je vois que personne ne peut résoudre ce problème avec mod_security. Jusqu'ici, utiliser ip-tables semble être la meilleure option pour le faire, mais je pense que le fichier deviendra extrêmement volumineux car l'adresse IP change plusieurs fois par jour.

Je suis venu avec 2 autres solutions, quelqu'un peut-il les commenter d'être bons ou pas.

1. La première solution qui me vient à l’esprit est d’exclure ces attaques de mes journaux d’erreur Apache. Cela me facilitera la tâche pour repérer d’autres erreurs urgentes à mesure qu’elles se produisent et pour ne pas devoir cracher dans un long journal.

2. La deuxième option est meilleure, je pense, et bloque les hôtes qui ne sont pas envoyés de la bonne façon. Dans cet exemple, l'attaque w00tw00t est envoyée sans nom d'hôte, je pense donc pouvoir bloquer les hôtes qui ne sont pas sous la forme correcte.

Mise à jour 2

Après avoir parcouru les réponses, je suis arrivé aux conclusions suivantes.

1. Avoir une journalisation personnalisée pour apache consommera des recours inutiles, et s'il y a vraiment un problème, vous voudrez probablement consulter le journal complet sans rien manquer.

2. Il est préférable d'ignorer les hits et de se concentrer sur une meilleure façon d'analyser vos journaux d'erreurs. Utiliser des filtres pour vos journaux est une bonne approche pour cela.

Réflexions finales sur le sujet

L’attaque mentionnée ci-dessus n’atteindra pas votre machine si vous avez au moins un système à jour, il n’ya donc aucun souci à vous faire.

Il peut être difficile de filtrer toutes les fausses attaques après un certain temps, car les journaux d’erreurs et d’accès deviennent extrêmement volumineux.

Empêcher que cela se produise de quelque manière que ce soit vous coûtera des ressources et c'est une bonne pratique de ne pas gaspiller vos ressources pour des tâches sans importance.

La solution que j'utilise maintenant est Linux Logwatch . Il m'envoie des résumés des journaux et ils sont filtrés et regroupés. De cette façon, vous pouvez facilement séparer les éléments importants des éléments non importants.

Merci à tous pour l'aide, et j'espère que ce post pourra être utile à quelqu'un d'autre aussi.

Depuis votre journal des erreurs, ils envoient une demande HTTP / 1.1 sans la partie hôte: de la demande. D'après ce que j'ai lu, Apache répond par une erreur 400 (mauvaise demande) à cette demande, avant de passer à mod_security. Donc, il ne semble pas que vos règles soient traitées. (Apache s'en occupant avant de devoir passer à mod_security)

Essayez vous-même:

Nom d'hôte telnet 80
GET /blahblahblah.html HTTP / 1.1 (entrez)
(entrer)

Vous devriez obtenir l'erreur 400 et voir la même erreur dans vos journaux. C'est une mauvaise demande et Apache donne la bonne réponse.

Une demande correcte devrait ressembler à:

GET /blahblahblah.html HTTP / 1.1
Hôte: blah.com

Une solution à ce problème pourrait consister à appliquer un correctif à mod_uniqueid, afin de générer un identifiant unique, même pour une requête ayant échoué, afin qu'apache transmette la requête à ses gestionnaires de requêtes. L’URL suivante est une discussion sur ce travail et comprend un correctif pour mod_uniqueid que vous pouvez utiliser: http://marc.info/?l=mod-security-users&m=123300133603876&w=2

Impossible de trouver une autre solution et je me demande si une solution est réellement nécessaire.

Filtrer les IP n'est pas une bonne idée, à mon humble avis. Pourquoi ne pas essayer de filtrer la chaîne que vous connaissez?

Je veux dire:

iptables -I INPUT -p tcp --dport 80 -m string --to 60 --algo bm --string 'GET /w00tw00t' -j DROP

Iv a également commencé à voir ces types de messages dans mes fichiers journaux. Un moyen d'éviter ces types d'attaques consiste à configurer fail2ban ( http://www.fail2ban.org/ ) et à installer des filtres spécifiques pour répertorier en noir ces adresses IP dans vos règles iptables.

Voici un exemple de filtre qui bloquerait l'adresse IP associée à la création de ces messages

[Mar 16 Août 02:35:23 2011] [erreur] [client] Le fichier n'existe pas: /var/www/skraps/w00tw00t.at.blackhats.romanian.anti-sec :) === apache w00t w00t messages jail - regex et filtre === Jail

 [apache-wootwoot]
 enabled  = true
 filter   = apache-wootwoot
 action   = iptables[name=HTTP, port="80,443", protocol=tcp]
 logpath  = /var/log/apache2/error.log
 maxretry = 1
 bantime  = 864000
 findtime = 3600

Filtre

 # Fail2Ban configuration file
 #
 # Author: Jackie Craig Sparks
 #
 # $Revision: 728 $
 #
 [Definition]
 #Woot woot messages
 failregex = ^\[\w{1,3} \w{1,3} \d{1,2} \d{1,2}:\d{1,2}:\d{1,2} \d{1,4}] \[error] \[client 195.140.144.30] File does not exist: \/.{1,20}\/(w00tw00t|wootwoot|WootWoot|WooTWooT).{1,250}
 ignoreregex =

w00tw00t.at.blackhats.romanian.anti-sec est une tentative de piratage informatique et utilise des adresses IP usurpées afin que des recherches telles que VisualRoute signalent la Chine, la Pologne, le Danemark, etc., en fonction de l'adresse IP détachée à ce moment-là. Il est donc pratiquement impossible de configurer une adresse IP refusée ou un nom d’hôte pouvant être résolu, car cela changera au bout d’une heure.

J'ai personnellement écrit un script Python pour ajouter automatiquement des règles IPtables.

Voici une version légèrement abrégée sans journalisation et autres indésirables:

#!/usr/bin/python
from subprocess import *
import re
import shlex
import sys

def find_dscan():
        p1 = Popen(['tail', '-n', '5000', '/usr/local/apache/logs/error_log'], stdout=PIPE)
        p2 = Popen(['grep', 'w00t'], stdin=p1.stdout, stdout=PIPE)

        output = p2.communicate()[0].split('\n')

        ip_list = []

        for i in output:
                result = re.findall(r"\b(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\b", i)
                if len(result):
                        ip_list.append(result[0])

        return set(ip_list)

for ip in find_dscan():
        input = "iptables -A INPUT -s " + ip + " -j DROP"
        output = "iptables -A OUTPUT -d " + ip + " -j DROP"
        Popen(shlex.split(input))
        Popen(shlex.split(output))

sys.exit(0)

Je pense que la raison pour laquelle mod_security ne fonctionne pas pour vous est qu’Apache n’a pas été en mesure d’analyser les demandes elles-mêmes, elles sont hors normes. Je ne suis pas sûr que vous ayez un problème ici - Apache enregistre des trucs bizarres qui se passent sur le net, s'il ne les enregistre pas, vous ne le saurez pas. Les ressources nécessaires pour consigner les demandes sont probablement minimes. Je comprends sa frustration que quelqu'un remplisse vos journaux - mais ce sera encore plus frustrant si vous désactivez la journalisation pour vous rendre compte que vous en avez vraiment besoin. Comme si quelqu'un entrait dans votre serveur Web et que vous aviez besoin des journaux pour montrer comment ils s'étaient introduits.

Une solution consiste à configurer ErrorLogging via syslog, puis à utiliser rsyslog ou syslog-ng pour filtrer et ignorer spécifiquement ces violations RFC concernant w00tw00t. Ou bien, vous pouvez les filtrer dans un fichier journal séparé simplement pour que votre ErrorLog principal soit facile à lire. Rsyslog est incroyablement puissant et flexible à cet égard.

Donc, dans httpd.conf, vous pourriez faire:

ErrorLog syslog:user 

puis dans rsyslog.conf vous pourriez avoir:

:msg, contains, "w00tw00t.at.ISC.SANS.DFind" /var/log/httpd/w00tw00t_attacks.log

Sachez que cette approche consomme en réalité beaucoup plus de ressources que la consignation initiale dans un fichier. Si votre serveur Web est très occupé, cela pourrait devenir un problème.

Il est recommandé de toujours envoyer tous les journaux à un serveur de journalisation distant le plus rapidement possible, ce qui vous permettra d’être victime d’une intrusion, car il est beaucoup plus difficile d’effacer la trace d’audit effectuée.

Le blocage des IPTables est une idée, mais vous pouvez vous retrouver avec une très grande liste de blocage iptables qui peut avoir des conséquences en termes de performances. Existe-t-il un motif dans les adresses IP ou provient-il d'un grand réseau de zombies distribué? Il faudra X% de doublons avant d’obtenir un avantage de iptables.

Vous dites dans la mise à jour 2:

Problème qui reste Le problème qui reste est le suivant. Ces attaques proviennent de robots qui recherchent certains fichiers sur votre serveur. Ce scanner particulier recherche le fichier /w00tw00t.at.ISC.SANS.DFind :).

Maintenant, vous pouvez simplement ignorer ce qui est le plus recommandé. Le problème demeure que si vous avez ce fichier sur votre serveur en quelque sorte un jour, vous rencontrez des problèmes.

D'après ma réponse précédente, nous avons compris qu'Apache renvoyait un message d'erreur en raison d'une requête HTML 1.1 mal formée. Tous les serveurs Web prenant en charge HTTP / 1.1 devraient probablement renvoyer une erreur lorsqu'ils reçoivent ce message (je n'ai pas vérifié la RFC deux fois - le RFC2616 nous le dit peut-être).

Avoir w00tw00t.at.ISC.SANS.DFind: sur votre serveur, certaines ne signifient pas "vous avez un problème" ... Si vous créez le fichier w00tw00t.at.ISC.SANS.DFind: dans votre DocumentRoot ou même DefaultDocumentRoot n'a pas d'importance ... le scanner envoie une requête HTTP / 1.1 cassée et Apache dit "non, c'est une mauvaise requête ... au revoir". Les données du fichier w00tw00t.at.ISC.SANS.DFind: ne seront pas servies.

L'utilisation de mod_security dans ce cas n'est pas obligatoire, sauf si vous le souhaitez vraiment (aucun point?) ... Dans ce cas, vous pouvez le corriger manuellement (lien dans une autre réponse).

Une autre chose que vous pourriez envisager d'utiliser est la fonctionnalité RBL de mod_security. Peut-être y at-il une RBL en ligne qui fournit des adresses IP w00tw00t (ou d’autres adresses IP malveillantes connues). Cela signifierait toutefois que mod_security effectue une recherche DNS pour chaque requête.

Que diriez-vous d'ajouter une règle à modsecurity? Quelque chose comme ça:

   SecRule REQUEST_URI "@rx (?i)\/(php-?My-?Admin[^\/]*|mysqlmanager
   |myadmin|pma2005|pma\/scripts|w00tw00t[^\/]+)\/"
   "severity:alert,id:'0000013',deny,log,status:400,
   msg:'Unacceptable folder.',severity:'2'"

Je constate que la plupart des solutions sont déjà décrites ci-dessus, mais je tiens à préciser que les requêtes HTTP / 1.1 envoyées par les clients sans attaques par nom d’hôte ne sont pas toutes dirigées directement sur votre serveur. Il existe de nombreuses tentatives d'empreinte et / ou d'exploitation du système réseau précédant votre serveur, par exemple:

client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /tmUnblock.cgi

cibler les routeurs Linksys, etc. Ainsi, il est parfois utile d’élargir votre objectif et de répartir vos efforts de défense entre tous les systèmes avec un partage égal, c’est-à-dire: implémentez des règles de routeur, implémentez des règles de pare-feu (espérons-le, votre réseau en a un), implémentez un pare-feu de serveur / table IP règles et services associés, c.-à-d. mod_security, fail2ban, etc.

que dis-tu de ça ?

iptables -I INPUT -p tcp --dport 80 -m string --to 70 --algo bm --string 'GET /w00tw00t.at.ISC.SANS.DFind' -j DROP
iptables -I INPUT -p tcp --dport 80 -m string --to 70 --algo bm --string 'GET /w00tw00t.at.ISC.SANS.DFind' -j LOG --log-level 4 --log-prefix Hacktool.DFind:DROP:

fonctionne bien pour moi.

Si vous utilisez hiawathaun serveur Web en tant que tel, reverse proxyces analyses sont automatiquement supprimées client. Il filtre XSSet CSRFexploite également.