Faire face aux attaques HTTP w00tw00t

82

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.

Saif Bechan
la source

Réponses:

34

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.

Imo
la source
Je vois le problème maintenant. Recommandez-vous la solution fournie dans l'article ou pensez-vous qu'il est préférable de le laisser tel quel. C'est un scanner pour toutes les portes arrière du système. Si je le laisse juste en numérisant, je pourrais un jour être attaqué.
Saif Bechan
1
Bonjour Saif, je pense que tant que vous gardez votre installation d'Apache à jour avec vos correctifs de sécurité pour les distributions (ou manuellement), tout devrait bien se passer. Une requête HTTP / 1.1 mal structurée (comme vous l'avez vu) ne devrait rien retourner d'autre qu'une erreur 400 d'apache. On dirait qu'il peut avoir été une sorte de balayage de vulnérabilité concentrée au niveau des routeurs DLink. (Selon certaines autres sources)
Imo
Y a-t-il au moins un moyen de sortir ces champs de mon apache error_log
Saif Bechan
Vous peut - être en mesure de le faire via mod_log :: httpd.apache.org/docs/2.2/mod/mod_log_config.html#customlog
Imo
Mon astuce supplémentaire serait: configurez votre virtualhost par défaut à côté de ceux réellement utilisés. Les tentatives mentionnées ci-dessus se retrouveront dans les journaux du virtualhost par défaut .
Koos van den Hout
16

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
Des
la source
spamcleaner.org/en/misc/w00tw00t.html solution similaire, mais un peu plus détaillée.
Isaac
Un problème avec le filtrage de chaînes dans le pare-feu est qu’il est "assez lent".
Alexis Wilke
@AlexisWilke avez-vous des preuves suggérant que le filtrage de chaînes iptables est plus lent que le filtrage au niveau apache?
Jrwren
@jrwren En fait, cela peut être assez lent si et seulement si vous ne transmettez pas le décalage de paquet pour arrêter la recherche, c'est-à-dire "--à 60" ici. Par défaut, il recherchera dans tout le paquet, la limite maximale étant fixée à 65 535 octets, la longueur maximale du paquet IP: blog.nintechnet.com/… Le manuel indique clairement "Si ce n'est pas passé, la taille du paquet est par défaut".
gouessej
c'est un max théorique. une longueur maximale plus réaliste sur Internet est ~ 1500.
Jrwren
11

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 =
Jackie Craig Sparks
la source
2
Il est vrai que vous pouvez les bloquer, mais ce n’est pas nécessaire car ce ne sont que de mauvaises requêtes. Il est préférable de simplement les ignorer, enregistrez votre travail et vous libérerez des ressources.
Saif Bechan
Pour @Saif Bechan, si quelqu'un s'inquiète de la "réussite des attaques", il devrait mieux réparer sa propre application au lieu de perdre du temps à trouver un moyen de bloquer cela.
Thomas Berger
Je vous ai donné +1, merci pour la réponse.
Saif Bechan
4
@SaifBechan, je ne suis pas d'accord. w00tw00t est un scanner de vulnérabilités, et une machine émettant de telles demandes ne peut pas être invitée à faire confiance à d'autres types de demandes. Par conséquent, si je suis administrateur système et qu'il me faut 2 minutes pour interdire de tels clients pendant plusieurs jours, je le ferais. Je ne baserais cependant pas toute mon implémentation de sécurité sur une telle approche.
Isaac
3

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.

PRW
la source
Ces analyses de vulnérabilité n'utilisent pas d'adresses IP usurpées. S'ils le faisaient, la négociation TCP à 3 voies ne serait pas terminée et Apache ne consignerait pas la demande. Pour les avertissements (FAI non autorisé, opérateurs de routeur, etc.), voir security.stackexchange.com/q/37481/53422
Anthony G - justice pour Monica
2

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)
Xorlev
la source
Est-ce pour empêcher l'attaque w00tw00t
Saif Bechan
Oui, je l’ai analysé les journaux d’erreurs Apache pour rechercher les adresses IP "w00tw00t" et les ajouter s’ils n’existent pas, bien que, pour des raisons de simplicité, je n’ai pas ajouté la vérification des doublons.
Xorlev
Ce script devrait probablement utiliser une table, ajouter des tonnes de règles supplémentaires aux chaînes iptables va ralentir considérablement le traitement.
Eric
Il utilise une table. Cependant, j'ai beaucoup simplifié, car il était adapté à mon système.
Xorlev
pensez-vous que c'est une meilleure solution que d'utiliser mod_security
Saif Bechan
2

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.

hellomynameisjoel
la source
Bonne réponse, j'aime les différentes approches. En y pensant, la journalisation personnalisée créera plus de recours, car tout doit être vérifié en premier, je suppose que cette option disparaît également. J'ai maintenant logwatch activé. Cela m'envoie un rapport 2 fois par jour avec des résumés de l'ensemble des systèmes. Les journaux Apache sont également vérifiés et il indique simplement que w00tw00t tente 300 fois. Je pense que je vais laisser la configuration telle qu'elle est pour le moment.
Saif Bechan
1

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.

Imo
la source
Je ne pense pas qu'apache les rejette, cela jette simplement l'erreur mais la recherche passe toujours. J'ai le même w00tw00t.at.ISC.SANS.DFind dans le journal des accès. Il fait un GET. La recherche est donc terminée et si vous avez le fichier sur votre machine, il sera exécuté. Je peux publier les entrées du journal d'accès, mais elles ont le même aspect que le journal des erreurs, mais avec GET devant elles. Apache lève l'erreur mais la requête passe. C'est pourquoi j'ai demandé si ce serait une bonne idée de bloquer ces requêtes sans noms d'hôtes. Mais je ne veux pas bloquer les utilisateurs normaux.
Saif Bechan
1
Bien sûr, vous obtenez la même entrée dans le journal des accès mais regardez le code d'erreur ... 400. Il n'est pas traité. HTTP / 1.1 (nomhôte) est utilisé pour indiquer à apache quel hôte virtuel doit envoyer la demande à ... sans la partie nomhôte de la demande HTTP / 1.1. Apache ne sait pas où envoyer la demande et renvoie une erreur "400 demandes incorrectes" retour au client.
Imo
Essayez vous-même ... créez vous-même une page html sur votre serveur Web et essayez de vous y rendre manuellement à l'aide de "nom d'hôte telnet 80" ... les autres étapes figurent dans ma première réponse. Je mettrais une prime importante sur le fait que vous ne puissiez pas afficher le fichier HTML à l'aide de HTTP / 1.1 sans le nom d'hôte.
Imo
Ah oui oui ça pour me l'avoir signalé. J'ai toujours pensé que le fichier access_log était constitué d'entrées passées dans le journal des erreurs et entrées dans votre ordinateur. Merci de me l'avoir signalé et je vais éditer mon post. J'apprécie vraiment votre aide.
Saif Bechan
Salut Saif, pas de problèmes, heureux d'avoir aidé. Cordialement, Imo
Imo
1

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'"
Kreker
la source
1

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.

Milan
la source
1

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.

Urbach-Webhosting
la source
J'ai recommandé l'ensemble de règles OWASP_CRS / 2.2.5 ou Grater pour mod_security
Urbach-Webhosting
Ce n'est vraiment pas une bonne idée. Vous allez vous retrouver avec beaucoup de connexions suspendues. De plus, si votre site a des discussions sur ces demandes, vous pouvez vous retrouver avec des faux positifs.
Kasperd
0

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

Stuart Cardall
la source