Seit einiger Zeit beobachtete ich erneut eine Riesenlast auf dem Apache Server. Eine unserer Webseiten wurde massiv von http HEAD Anfragen überhäuft. 60000 http HEAD Requests. Die aufgerufene Seite ist immer - wie sollte es auch anders sein - ein Joomla plugin, nämlich plugin_googlemap2. Scheinbar ist das so ein SEO Ding, da das Plugin benutzt wird, um andere  Seiten aufzurufen. Interessiert mich ja nicht wirklich, ich möchte bloß den Traffic nicht, zumal es ruckzuck über 250 Requests die Sekunde sind und mein Monit (schon bei 150) den Load bemerkt und den Apache restartet. Funktioniert ja, nur wenn man gerade am surfen ist, ist das nicht lustig wenn die Verbindung alle paar Minuten zurück gesetzt wird. Die manuelle Holzhammermethode war anfangs war:

iptables -I INPUT -s 89.248.162.169 -j DROP
und später zum Löschen
iptables -D INPUT -s 89.248.162.169 -j DROP

Funktioniert prächtig, nur nicht lange, denn wenige Stunden später kommt es von einer anderen IP. Ich versuchte es zuerst mit mod_evasive, über dieses apache plugin habe ich früher schon mal was geschrieben, doch diese Art von massiven Requests wurden davon nicht erfasst.

Zweite todsichere Methode wäre, das plugin googlemap2 einfach zu deinstallieren.

Wenn das nicht geht, muss man sich was anderes überlegen.

Nun ist ja die Frage, wer als Nutzer macht denn überhaupt HEAD Anfragen? Mir fällt niemand ein. Tools, die die Erreichbarkeit testen, kämen in Frage, die könnten aber genauso gut GET benutzen. Also war meine Idee, HEAD einfach zu verbieten. Die einzige Methode, die (bei mir) funktioniert, ist kein LIMIT Eintrag in der .htaccess des betreffenden Webs sondern eine RewriteRule.

RewriteEngine On
RewriteCond %{THE_REQUEST} !^(POST|GET)\ /.*\ HTTP/1\.1$ 
RewriteRule .* - [F]

Falls RewriteEngine On ohnehin bereits in der .htaccess drin ist, kann das entfallen. Ist bei Joomla Sites meist bereits auf on.

Nach dem reload des Webservers kann man allerdings weiterhin die Angriffe sehen, die werfen zwar nun einen Error 500 (Internal Server Error), aber den Trafic hat man immer noch, wenigstens können sie ihr Machwerk nicht erfolgreich zu Ende bringen.

89.248.162.169 - - [20/Feb/2016:09:01:37 +0100] "HEAD /plugins/system/plugin_googlemap2/plugin_googlemap2_proxy.php?url=web3.ekoloko.com HTTP/1.1" 500 224 "-" "Mozilla/5.0"

Was nun fail2ban auf den Plan ruft und ich damit zum eigentlichen Thema des Artikels komme. 

Ich habe mir einen Filter für diese HEAD Aufrufe gebastelt. Obwohl ich mich nach meiner eigenen Beschreibung gerichtet habe, hat es anfangs nicht klappen wollen. 

Das lag daran, dass ich die einfachen Hoch Kommas ( Kommata is ja nich mehr nach der neuen deutschen Rechtschreibung ;-) , die ich beim Testen mit fail2ban-regex logfile 'regexp Ausdruck' verwenden muss, in den Filter übernommen hatte, obwohl ich extra im Artikel vermerkt habe, dass dies nicht geht. Naja, mal wieder nicht richtig gelesen, aber im Debianforum habe ich wieder kompetente Hilfe gefunden! (Danke Heisenberg :-)

Der Erfolg ist schon ermutigend. Wenn man den Screenshot betrachtet, fällt die Penetranz einzelner IPs auf. Ein paar habe ich per Abuse Complaint angeschrieben, aber nur einer von 4 hat geantwortet. Vielleicht reagieren andere auch, melden sich bloß nicht. mal sehen.

# apache-HEAD.conf
[INCLUDES]

[Definition]

failregex =  .*"HEAD.*$

ignoreregex =
Das Jail:
# aus der jail.conf
[apache-HEAD]

enabled = true
port    = http,https
filter  = apache-HEAD
logpath = /var/www/*/log/access.log
bantime = 2880
# Ban attackers that try to use googlemaps insecurity

Ps: Wenn man auch die Fail2ban Nachrichten in seinem Postfach haben möchte, muss man die Action für fail2ban anpassen.

z.B. so:

action = %(action_mwl)s

 Zum Thema Abuse Nachrichten versenden, könnte man einen eigenständigen Beitrag schreiben.

Automatisieren empfinde ich nicht als so sinnvoll, weil automatische Complaints oft im Papierkorb landen und ich die Abuse Zentren, so es denn welche gibt auch nicht zuspammen möchte. 

Aber vorgefertigte Templates in sauber abgefasstem English wären schon schön. Wie machen das andere Admins?

Ich benutze einfach den letzten aus sent und passe ihn immer an.

Ohh, erst heute am 21.2. gefunden.

http://www.the-art-of-web.com/system/fail2ban-log/

Das ist sehr übersichtlich und informativ.

Manche könnens halt :-)

3 Kommentare

Linear

  • Sebastian  

    Du kannst die fail2ban mails direkt an blocklist.de senden, damit fliessen deine reports direkt in deren listen ein.

    Fuer incident handling (wie es die CERTs, CSIRTs etc machen), sind die Daten aber nicht brauchbar, da die zeitlichen Infos verloren gehen. Eine Instanz, die solche Daten annimmt und auch zur gaenze wieder weitergibt, kenne ich leider nicht. Ich nehme derartige Hinweise aber gerne an CERTs sammeln solche infos ein und geben sie an die ISP weiter. Das macht aber nur mit timestamps Sinn.

    • bed  

      Ja, danke für deinen Kommentar, ich werde mir das mal in der kommenden Woche ansehen.

      ps: Kommentieren geht wieder. Bayes hatte sich wohl verschluckt, lief schon Jahrelang ohne Störung... Dann darf er ja mal.

  • bed  

    Nachtrag: im Filter habe ich nun eine verlängerte Bantime von 48 Minuten eingetragen. Es waren mir einfach zu viele emails.

Kommentar schreiben

Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.

Um maschinelle und automatische Übertragung von Spamkommentaren zu verhindern, bitte die Zeichenfolge im dargestellten Bild in der Eingabemaske eintragen. Nur wenn die Zeichenfolge richtig eingegeben wurde, kann der Kommentar angenommen werden. Bitte beachten Sie, dass Ihr Browser Cookies unterstützen muss, um dieses Verfahren anzuwenden.
CAPTCHA

Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
BBCode-Formatierung erlaubt
Markdown-Formatierung erlaubt