Question 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

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 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.

J'ai proposé 2 autres solutions, quelqu'un peut-il les commenter comme étant bonnes ou non.

  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 au fur et à 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 que je peux bloquer les hôtes qui ne sont pas sous la bonne forme.

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 occurrences et de vous 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 Journal de bord Linux. 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.


80
2018-03-24 05:33


origine




Réponses:


À partir de 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 de 400 (mauvaise requête) à cette requête, 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 inclut un correctif pour mod_uniqueid que vous pourriez 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.


34
2018-03-29 13:17



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
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. Ça y ressemble peut ont été une sorte d'analyse de vulnérabilité axée sur les routeurs DLink. (Selon d'autres sources) - Imo
Est-ce qu'il y a au moins un moyen de sortir ces champs de mon apache error_log - Saif Bechan
Vous peut être capable de le faire via mod_log :: httpd.apache.org/docs/2.2/mod/mod_log_config.html#customlog - Imo
Mon indice supplémentaire serait: configurez votre défaut virtualhost à côté de ceux réellement utilisés. Les tentatives mentionnées ci-dessus se retrouveront dans les journaux du défaut virtualhost. - Koos van den Hout


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

15
2018-05-09 16:21



spamcleaner.org/en/misc/w00tw00t.html solution similaire, mais un peu plus détaillée. - Isaac
Un problème avec le filtrage des 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


Iv a également commencé à voir ces types de messages dans mes fichiers journaux. Un moyen d’empêcher ces types d’attaques consiste à configurer fail2ban ( http://www.fail2ban.org/ ) et configurez des filtres spécifiques pour lister 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 filter === 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 =

11
2017-08-19 17:46



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
@Saif Bechan, si quelqu'un s'inquiète de la "réussite des attaques", il / elle 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
@SaifBechan, je ne suis pas d'accord. w00tw00t est un scanner de vulnérabilités, et une machine qui émet de telles demandes ne peut pas faire confiance à d'autres types de demandes. Par conséquent, si je suis un administrateur système et qu'il me faut 2 minutes pour interdire de tels clients pendant des jours, je le ferais. Je ne baserais cependant pas toute mon implémentation de sécurité sur une telle approche. - Isaac


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.


3
2018-06-01 11:20



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 réserves (FAI non autorisé, opérateurs de routeur, etc.), voir security.stackexchange.com/q/37481/53422 - Anthony Geoghegan


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)

2
2018-03-24 07:06



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 d'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


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 remarquerez même 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. Sinon, vous pouvez également les filtrer dans un fichier journal séparé, de sorte 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

Soyez conscient, cette approche utilisera réellement plusieurs fois plus de ressources utilisé à l’origine en enregistrant directement 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 d'IPTables est une idée, mais vous pouvez vous retrouver avec une très grande liste de blocage d'iptables, ce qui peut avoir des implications 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.


2
2018-03-30 11:09



Bonne réponse, j'aime les différentes approches. En y réfléchissant, 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 tous les 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


Vous dites dans la mise à jour 2:

Problème qui reste encore   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 existe-t-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.


1
2018-03-31 08:52



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 un élément GET placé 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
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 journal des accès était des entrées qui avaient été transmises via le journal des erreurs et qui étaient effectivement 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


Pourquoi ne pas 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'"

1
2017-08-09 08:23