Umgang mit HTTP-w00tw00t-Angriffen

Ich habe einen Server mit Apache und ich habe vor kurzem mod_security2 installiert, weil ich von diesem oft angegriffen werde:

Meine Apache-Version ist Apache v2.2.3 und ich verwende mod_security2.c

Dies waren die Einträge aus dem Fehlerprotokoll:

[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:)

Hier sind die Fehler aus dem 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 "-" "-" 

Ich habe versucht, mod_security2 folgendermaßen zu konfigurieren:

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:\)"

Die Sache in mod_security2 ist, dass SecFilterSelective nicht verwendet werden kann, es gibt mir Fehler. Stattdessen verwende ich eine Regel wie diese:

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:\)"

Auch das geht nicht. Ich weiß nicht mehr, was ich tun soll. Hat jemand einen Rat?

Update 1

Ich sehe, dass niemand dieses Problem mit mod_security lösen kann. Bisher scheint die Verwendung von IP-Tabellen die beste Option zu sein, aber ich denke, die Datei wird extrem groß, da sich die IP-Adresse mehrmals am Tag ändert.

Ich habe mir 2 andere Lösungen ausgedacht, kann sich jemand dazu äußern, ob man gut ist oder nicht.

1. Die erste Lösung, die mir in den Sinn kommt, ist das Ausschließen dieser Angriffe aus meinen Apache-Fehlerprotokollen. Dadurch kann ich andere dringende Fehler leichter erkennen, wenn sie auftreten, und muss kein langes Protokoll durchspucken.

2. Die zweite Option ist meiner Meinung nach besser und blockiert Hosts, die nicht in der richtigen Weise gesendet werden. In diesem Beispiel wird der w00tw00t-Angriff ohne Hostnamen gesendet, sodass ich denke, dass ich die Hosts blockieren kann, die nicht in der richtigen Form vorliegen.

Update 2

Nachdem ich die Antworten durchgesehen hatte, kam ich zu den folgenden Schlussfolgerungen.

1. Benutzerdefinierte Protokollierung für Apache zu haben, wird einige unnötige Ressourcen in Anspruch nehmen, und wenn es wirklich ein Problem gibt, möchten Sie wahrscheinlich das vollständige Protokoll anzeigen, ohne dass etwas fehlt.

2. Es ist besser, die Treffer einfach zu ignorieren und sich auf eine bessere Analyse Ihrer Fehlerprotokolle zu konzentrieren. Verwenden Sie dazu Filter für Ihre Protokolle.

Letzte Gedanken zum Thema

Der oben erwähnte Angriff wird Ihren Computer nicht erreichen, wenn Sie zumindest ein aktuelles System haben, sodass Sie sich im Grunde keine Sorgen machen müssen.

Es kann schwierig sein, alle falschen Angriffe nach einer Weile aus den echten herauszufiltern, da sowohl die Fehlerprotokolle als auch die Zugriffsprotokolle extrem umfangreich werden.

Wenn Sie verhindern, dass dies in irgendeiner Weise geschieht, werden Sie Ressourcen kosten, und es wird empfohlen, Ihre Ressourcen nicht für unwichtige Dinge zu verschwenden.

Die Lösung, die ich jetzt benutze, ist Linux Logwatch . Es sendet mir Zusammenfassungen der Protokolle, die gefiltert und gruppiert werden. Auf diese Weise können Sie das Wichtige leicht vom Unwichtigen trennen.

Vielen Dank für die Hilfe, und ich hoffe, dieser Beitrag kann auch jemand anderem weiterhelfen.

Aus Ihrem Fehlerprotokoll senden sie eine HTTP / 1.1-Anforderung ohne den Host: -Teil der Anforderung. Nach allem, was ich gelesen habe, antwortet Apache mit einem Fehler von 400 (ungültige Anforderung) auf diese Anforderung, bevor es an mod_security übergibt. Es sieht also nicht so aus, als würden Ihre Regeln verarbeitet. (Apache, der sich damit befasst, bevor er an mod_security übergeben muss)

Versuchen Sie es selbst:

Telnet-Hostname 80
GET /blahblahblah.html HTTP / 1.1 (Enter)
(eingeben)

Sie sollten den 400-Fehler erhalten und denselben Fehler in Ihren Protokollen sehen. Dies ist eine schlechte Anfrage und Apache gibt die richtige Antwort.

Die richtige Anfrage sollte so aussehen:

GET /blahblahblah.html HTTP / 1.1
Host: blah.com

Ein Workaround für dieses Problem könnte darin bestehen, mod_uniqueid zu patchen und eine eindeutige ID auch für eine fehlgeschlagene Anforderung zu generieren, damit Apache die Anforderung an seine Anforderungshandler weiterleitet. Die folgende URL enthält eine Diskussion zu dieser Problemumgehung und einen Patch für mod_uniqueid, den Sie verwenden können: http://marc.info/?l=mod-security-users&m=123300133603876&w=2

Konnte keine andere Lösung dafür finden und frage mich, ob tatsächlich eine Lösung erforderlich ist.

IPs zu filtern ist keine gute Idee, imho. Warum filtern Sie nicht die Zeichenfolge, die Sie kennen?

Ich meine:

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

Ich habe auch begonnen, diese Arten von Nachrichten in meinen Protokolldateien zu sehen. Eine Möglichkeit, diese Art von Angriffen zu verhindern, besteht darin, fail2ban ( http://www.fail2ban.org/ ) einzurichten und bestimmte Filter einzurichten, um diese IP-Adresse in Ihren iptables-Regeln aufzulisten.

Hier ist ein Beispiel für einen Filter, der die mit der Erstellung dieser Nachrichten verbundene IP-Adresse blockiert

[Di Aug 16 02:35:23 2011] [Fehler] [Client] Datei existiert nicht: /var/www/skraps/w00tw00t.at.blackhats.romanian.anti-sec :) === apache w00t w00t messages jail - Regex und Filter === Gefängnis

 [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

Filter

 # 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 ist ein Hacking-Versuch und verwendet gefälschte IPs, so dass Suchanfragen wie VisualRoute China, Polen, Dänemark usw. gemäß der zu diesem Zeitpunkt abgeordneten IP melden. Das Einrichten einer Verweigern-IP oder eines auflösbaren Hostnamens ist nahezu unmöglich, da sich dieser Wert innerhalb einer Stunde ändert.

Ich habe persönlich ein Python-Skript geschrieben, um IPtables-Regeln automatisch hinzuzufügen.

Hier ist eine leicht abgekürzte Version ohne Protokollierung und anderen Müll:

#!/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)

Ich glaube, der Grund, warum mod_security für Sie nicht funktioniert, ist, dass Apache die Anforderungen selbst nicht analysieren konnte, da sie nicht den Spezifikationen entsprechen. Ich bin nicht sicher, ob Sie hier ein Problem haben - Apache protokolliert seltsame Scheiße, die im Internet passiert. Wenn es sie nicht protokolliert, werden Sie nicht wissen, dass es überhaupt passiert. Die zum Protokollieren der Anforderungen erforderlichen Ressourcen sind wahrscheinlich minimal. Ich verstehe, dass es frustrierend ist, dass jemand Ihre Protokolle füllt - aber es wird frustrierender sein, wenn Sie die Protokollierung deaktivieren, nur um festzustellen, dass Sie sie wirklich benötigen. Als ob jemand in Ihren Webserver eingebrochen wäre und Sie die Protokolle benötigen, um zu zeigen, wie er eingebrochen ist.

Eine Lösung besteht darin, ErrorLogging über syslog einzurichten und dann mithilfe von rsyslog oder syslog-ng diese RFC-Verstöße in Bezug auf w00tw00t gezielt zu filtern und zu verwerfen. Alternativ können Sie sie auch in eine separate Protokolldatei filtern, damit Ihr Hauptfehlerprotokoll leicht lesbar ist. Rsyslog ist in dieser Hinsicht unglaublich leistungsfähig und flexibel.

In httpd.conf könnten Sie also Folgendes tun:

ErrorLog syslog:user 

dann in rsyslog.conf haben Sie vielleicht:

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

Beachten Sie, dass dieser Ansatz tatsächlich ein Vielfaches der Ressourcen beansprucht, die ursprünglich für die direkte Protokollierung in einer Datei verwendet wurden. Wenn Ihr Webserver sehr ausgelastet ist, kann dies zu einem Problem werden.

Es wird empfohlen, alle Protokolle sowieso so schnell wie möglich an einen Remote-Protokollierungsserver zu senden. Dies kommt Ihnen zugute, falls Sie jemals in das Protokoll einbrechen sollten, da es sehr viel schwieriger ist, den Audit-Trail zu löschen, der durchgeführt wurde.

Das Blockieren von IPTables ist eine Idee, aber es kann vorkommen, dass Sie eine sehr große iptables-Blockierungsliste haben, die Auswirkungen auf die Leistung haben kann. Enthält die IP-Adresse ein Muster oder stammt es von einem großen verteilten Botnetz? Es müssen X% der Duplikate vorhanden sein, bevor Sie von iptables profitieren können.

Sie sagen in Update 2:

Problem, das immer noch besteht Das Problem, das immer noch besteht, lautet wie folgt. Diese Angriffe stammen von Bots, die auf Ihrem Server nach bestimmten Dateien suchen. Dieser spezielle Scanner sucht nach der Datei /w00tw00t.at.ISC.SANS.DFind :).

Jetzt können Sie es einfach ignorieren, was am meisten empfohlen wird. Das Problem bleibt, dass Sie Probleme haben, wenn Sie diese Datei eines Tages auf Ihrem Server haben.

Aus meiner vorherigen Antwort ging hervor, dass Apache aufgrund einer schlecht geformten HTML 1.1-Abfrage eine Fehlermeldung zurückgibt. Alle Webserver, die HTTP / 1.1 unterstützen, sollten wahrscheinlich einen Fehler zurückgeben, wenn sie diese Nachricht erhalten (ich habe den RFC nicht doppelt überprüft - vielleicht teilt uns RFC2616 dies mit).

Wenn Sie w00tw00t.at.ISC.SANS.DFind haben: Auf Ihrem Server bedeutet dies nicht unbedingt "Sie sind in Schwierigkeiten" ... Wenn Sie die Datei w00tw00t.at.ISC.SANS.DFind erstellen: in Ihrem DocumentRoot oder sogar DefaultDocumentRoot spielt keine Rolle ... der Scanner sendet eine fehlerhafte HTTP / 1.1-Anfrage und Apache sagt "Nein, das ist eine schlechte Anfrage ... auf Wiedersehen". Die Daten in der Datei w00tw00t.at.ISC.SANS.DFind: werden nicht geliefert.

Die Verwendung von mod_security für diesen Fall ist nicht erforderlich, es sei denn, Sie möchten wirklich (kein Punkt?). In diesem Fall können Sie das Patchen manuell überprüfen (Link in anderer Antwort).

Eine andere Sache, die Sie möglicherweise mit ansehen könnten, ist die RBL-Funktion in mod_security. Möglicherweise ist eine RBL online, die w00tw00t-IPs (oder andere bekannte bösartige IPs) bereitstellt. Dies würde jedoch bedeuten, dass mod_security für jede Anforderung eine DNS-Suche durchführt.

Wie wäre es, wenn Sie der ModSecurity eine Regel hinzufügen? Etwas wie das:

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

Ich sehe, dass die meisten Lösungen bereits oben behandelt wurden. Ich möchte jedoch darauf hinweisen, dass nicht alle vom Client gesendeten HTTP / 1.1-Anfragen ohne Hostnamenangriffe direkt auf Ihren Server gerichtet sind. Es gibt viele verschiedene Versuche, das Netzwerksystem vor Ihrem Server mit einem Fingerabdruck zu versehen und / oder auszunutzen:

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

So ist es manchmal hilfreich, Ihren Fokus zu erweitern und Ihre Verteidigungsbemühungen auf alle Systeme mit gleichem Anteil aufzuteilen, z. B .: Routerregeln implementieren, Firewallregeln implementieren (hoffentlich hat Ihr Netzwerk eine), Server-Firewall / IP-Tabelle implementieren Regeln und verwandte Dienste, zB mod_security, fail2ban und so weiter.

Wie wäre es damit ?

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:

funktioniert gut für mich.

Wenn Sie einen hiawathaWebserver verwenden, werden reverse proxydiese Scans automatisch als Papierkorb und gesperrt gelöscht client. Es filtert XSSund CSRFnutzt auch.