Ich versuche, nicht verfügbare Skriptanforderungen an Nginx mit Fail2ban zu blockieren.
# Noscript filter /etc/fail2ban/filter.d/nginx-noscript.conf:
#
# Block IPs trying to execute scripts such as .php, .pl, .exe and other funny scripts.
#
# Matches e.g.
# 192.168.1.1 - - "GET /something.cgi
#
[Definition]
failregex = ^<HOST> -.*GET.*(\.asp|\.exe|\.pl|\.cgi|\scgi)
ignoreregex =
Dies erzeugt jedoch auch einen Treffer, wenn der Referrer im Zugriffsprotokoll das Skript-Tag enthält. Beispielsweise diese Zeile: (Ich habe die IP und den Referrer verschleiert und über mehrere Zeilen gekürzt. Im echten Protokoll stehen diese 4 Zeilen in einer Zeile.)
1.2.3.4 - - [16/Dec/2013:18:01:10 +0100] "GET / HTTP/1.1"
301 178 "http://referrer.com/default.aspx"
"Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.41 Safari/537.36"
Wie kann ich den regulären Ausdruck ändern, um nur das .aspusw. im GET /xxxxx HTTPAbschnitt zu finden?
Antwort1
Nun, es gibt sehr interessante Dinge bei regulären Ausdrücken, nämlich, dass reguläre Ausdrücke gierig sind.
Selbst wenn sie die Übereinstimmung am Anfang des Satzes finden, suchen sie weiter und suchen nach der letzten verfügbaren Übereinstimmung im Satz. In Ihrem Fall stimmt es mit „referrer.com/default.aspx“ überein, da Sie einen regulären Ausdruck für die Übereinstimmung mit .asp haben und dieser auch mit allem mit .asp* übereinstimmt.
Sie müssen beim Arbeiten mit regulären Ausdrücken also sehr genau sein.
Versuchen Sie hierzu Folgendes:
failregex = ^<HOST> -.*GET.*(\.asp|\.exe|\.pl|\.cgi|\scgi)\"\s\d*
So etwas sollte sehr gut funktionieren. Wenn es trotzdem nicht funktioniert, wissen Sie jetzt, wo das Problem liegt, und ich bin sicher, dass Sie es beheben können, indem Sie ein wenig in den regulären Ausdrücken herumstöbern.
Hoffe, das hat geholfen.