Gérer les attaques HTTP w00tw00t
J'ai un serveur avec Apache et j'ai récemment installé mod_security2 parce que je suis souvent attaqué par ceci:
Ma version Apache est Apache v2.2.3 et j'utilise mod_security2.c
Ce sont 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 du 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é, cela me donne des erreurs. Au lieu de cela, j'utilise 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-t-il des conseils?
Mise à jour 1
Je vois que personne ne peut résoudre ce problème en utilisant mod_security. Jusqu'à présent, l'utilisation d'ip-tables semble être la meilleure option pour ce faire, mais je pense que le fichier deviendra extrêmement volumineux car l'ip change plusieurs fois par jour.
J'ai trouvé 2 autres solutions, quelqu'un peut-il les commenter en étant bon ou pas.
La première solution qui me vient à l'esprit est d'exclure ces attaques de mes journaux d'erreurs Apache. Cela rendra plus facile pour moi de repérer d'autres erreurs urgentes lorsqu'elles se produisent et de ne pas avoir à cracher dans un long journal.
La deuxième option est meilleure, je pense, et qui bloque les hôtes qui ne sont pas envoyés de la bonne manière. Dans cet exemple, l'attaque w00tw00t est envoyée sans nom d'hôte, donc je pense que je peux bloquer les hôtes qui ne sont pas sous la bonne forme.
Update 2
Après avoir parcouru les réponses, je suis arrivé aux conclusions suivantes.
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.
Il vaut mieux simplement ignorer les hits et se concentrer sur une meilleure façon d'analyser vos journaux d'erreurs. L'utilisation de 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, donc il n'y a pratiquement pas de soucis.
Il peut être difficile de filtrer toutes les fausses attaques des vraies après un certain temps, car les journaux d'erreurs et les journaux d'accès deviennent extrêmement volumineux.
Empêcher cela de se produire de quelque façon que ce soit vous coûtera des ressources et c'est une bonne pratique de ne pas gaspiller vos ressources sur des choses 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 l'important de l'important.
Merci à tous pour l'aide, et j'espère que ce message pourra être utile à quelqu'un d'autre aussi.
À partir de votre journal d'erreurs, ils envoient une demande HTTP/1.1 sans la partie Host: de la demande. D'après ce que j'ai lu, Apache répond avec une erreur 400 (mauvaise demande) à cette demande, avant de passer à mod_security. Il ne semble donc pas que vos règles seront traitées. (Apache s'en occupe avant de devoir passer à mod_security)
Essayez-vous:
nom d'hôte telnet 80 GET /blahblahblah.html HTTP/1.1 (entrez) (entrez)
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 appropriée devrait ressembler à:
GET /blahblahblah.html HTTP/1.1 Hôte: blah.com
Une solution à ce problème pourrait être de corriger mod_uniqueid, afin de générer un ID 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 inclut un correctif pour mod_uniqueid que vous pouvez utiliser: http://marc.info/?l=mod-security-users&m=123300133603876&w=2
Impossible de trouver d'autres solutions et de se demander si une solution est réellement requise.
Filtrer les adresses 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. Une façon de prévenir ces types d'attaques consiste à configurer fail2ban ( http://www.fail2ban.org/ ) et à configurer des filtres spécifiques pour mettre en liste noire 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 prison - regex et filtre === Prison
[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 et utilise des adresses IP frauduleuses, donc les recherches telles que VisualRoute rapporteront la Chine, la Pologne, le Danemark, etc. en fonction de l'adresse IP détachée à ce moment-là. Ainsi, la configuration d'une adresse IP refusée ou d'un nom d'hôte résoluble est quasiment impossible car elle changera dans une heure.
Je crois que la raison pour laquelle mod_security ne fonctionne pas pour vous est qu'Apache n'a pas pu analyser les demandes elles-mêmes, elles sont hors spécifications. Je ne suis pas sûr que vous ayez un problème ici - Apache enregistre des trucs bizarres qui se produisent sur le net, s'il ne le connecte pas, vous ne vous en rendrez pas compte. Les ressources nécessaires pour enregistrer les demandes sont probablement minimes. Je comprends qu'il est frustrant que quelqu'un remplisse vos journaux - mais ce sera plus frustrant si vous désactivez la journalisation uniquement pour constater que vous en avez vraiment besoin. Comme si quelqu'un est entré par effraction dans votre serveur Web et que vous avez besoin des journaux pour montrer comment ils sont entrés.
Une solution consiste à configurer ErrorLogging via syslog, puis à l'aide de rsyslog ou syslog-ng, vous pouvez spécifiquement filtrer et éliminer ces violations RFC concernant w00tw00t. Vous pouvez également 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 utilisera en fait plusieurs fois plus de ressources que la connexion utilisée initialement dans un fichier. Si votre serveur Web est très occupé, cela pourrait devenir un problème.
Il est préférable que tous les journaux soient envoyés à un serveur de journalisation distant dès que possible de toute façon et cela vous sera bénéfique en cas de casse, car il est beaucoup plus difficile d'effacer la piste d'audit de ce qui a été fait.
Le blocage d'IPTables est une idée, mais vous pouvez vous retrouver avec une très grande liste de blocage iptables qui peut avoir des implications de performances en soi. Existe-t-il un modèle dans les adresses IP ou provient-il d'un grand botnet distribué? Il devra y avoir X% de doublons avant de bénéficier d'iptables.
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 fichiers 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)
Vous dites dans la mise à jour 2:
Problème qui subsiste Le problème qui subsiste 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 l'ignorer, ce qui est le plus recommandé. Le problème reste que si vous avez un jour ce fichier sur votre serveur, vous avez des ennuis.
D'après ma réponse précédente, nous avons compris qu'Apache renvoie 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 revérifié la RFC - peut-être que RFC2616 nous le dit).
Avoir w00tw00t.at.ISC.SANS.DFind: sur votre serveur certains où cela ne signifie pas mystiquement "vous avez des ennuis" ... Si vous créez le fichier w00tw00t.at.ISC.SANS.DFind: dans votre DocumentRoot ou même DefaultDocumentRoot cela 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 nécessaire à moins que vous ne le vouliez vraiment (pas de point?) ... auquel cas, vous pouvez envisager de le patcher manuellement (lien dans une autre réponse).
Une autre chose que vous pourriez envisager d'utiliser est la fonctionnalité RBL dans mod_security. Peut-être existe-t-il un RBL en ligne qui fournit des adresses IP w00tw00t (ou d'autres adresses IP malveillantes connues). Cela signifierait cependant que mod_security effectue une recherche DNS pour chaque demande.
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 vois que la plupart des solutions sont déjà couvertes ci-dessus mais je voudrais souligner que toutes les attaques le client a envoyé la requête HTTP/1.1 sans nom d'hôte visent directement sur votre serveur. Il existe de nombreuses tentatives différentes pour identifier et/ou exploiter le système réseau précédant votre serveur, c'est-à-dire en utilisant:
client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /tmUnblock.cgi
pour cibler les routeurs Linksys etc. règles et services associés, à savoir mod_security, fail2ban et ainsi de suite.
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 hiawatha serveur Web comme reverse proxy ces analyses sont automatiquement supprimées en tant qu'ordures et client bannies. Il filtre également les exploits XSS & CSRF.