Wie man Kunden ausgesperrt und anschwärzt

Heute lag eine seltsame Abuse-Mail im Posteingang: Ein Kunde habe einen Angriff vorgenommen und sei deswegen von fail2ban geblockt worden. Als Beleg wurden gesperrte HTTP-Zugriffe auf den Webserver angegeben. Das Verhalten ist reproduzierbar.

Dear Sir/Madam,

We have detected abuse from the IP address ( 217.17.197.14 ), which according to a whois lookup is on your network. We would appreciate if you would investigate and take action as appropriate. Any feedback is welcome but not mandatory.

Log lines are given below, but please ask if you require any further information.

(If you are not the correct person to contact about this please accept our apologies - your e-mail address was extracted from the whois record by an automated process. This mail was generated by Fail2Ban.)

IP of the attacker:  217.17.197.14 

You can contact us by using: abuse-reply@<protect-the-hoster>.de

Addresses to send to:
abuse@iks-jena.de

==================== Excerpt from log for 217.17.197.14 ====================
Note: Local timezone is +0200 (CEST)
/home/users/hwburgk/logs/error.log:[Mon Aug 07 10:32:18.498758 2017] [evasive20:error] [pid 11057:tid 139621224589056] [client 217.17.197.14:60994] client denied by server configuration: /home/users/hwburgk/www/j15/templates/rt_terrantribune_j15/images/bottom-menu-bg.png, referer: http://www.<protect-the-customer>.de/templates/rt_terrantribune_j15/css/template_css.css
/home/users/hwburgk/logs/error.log:[Mon Aug 07 10:32:18.499515 2017] [evasive20:error] [pid 11057:tid 139621300123392] [client 217.17.197.14:60988] client denied by server configuration: /home/users/hwburgk/www/j15/templates/rt_terrantribune_j15/images/footer-bl.png, referer: http://<protect-the-customer>/templates/rt_terrantribune_j15/css/template_css.css
/home/users/hwburgk/logs/error.log:[Mon Aug 07 10:32:18.499542 2017] [evasive20:error] [pid 11057:tid 139621241374464] [client 217.17.197.14:60986] client denied by server configuration: /home/users/hwburgk/www/j15/templates/rt_terrantribune_j15/images/footer-bg.png, referer: http://<protect-the-customer>/templates/rt_terrantribune_j15/css/template_css.css
/home/users/hwburgk/logs/error.log:[Mon Aug 07 10:32:18.500119 2017] [evasive20:error] [pid 11057:tid 139621266552576] [client 217.17.197.14:60990] client denied by server configuration: /home/users/hwburgk/www/j15/templates/rt_terrantribune_j15/images/footer-br.png, referer: http://<protect-the-customer>/templates/rt_terrantribune_j15/css/template_css.css
/home/users/hwburgk/logs/error.log:[Mon Aug 07 10:32:25.007673 2017] [evasive20:error] [pid 11057:tid 139621350479616] [client 217.17.197.14:60998] client denied by server configuration: /home/users/hwburgk/www/j15/
/home/users/hwburgk/logs/error.log:[Mon Aug 07 10:32:25.220530 2017] [evasive20:error] [pid 11057:tid 139621350479616] [client 217.17.197.14:60998] client denied by server configuration: /home/users/hwburgk/www/j15/favicon.ico
/home/users/hwburgk/logs/error.log:[Mon Aug 07 10:32:25.260728 2017] [evasive20:error] [pid 11057:tid 139621350479616] [client 217.17.197.14:60998] client denied by server configuration: /home/users/hwburgk/www/j15/favicon.ico

Zunächst ist auffällig, dass als Begründung für die Sperre die letzten Einträge des Logfiles verwendet werden. Dies ist eine gute Idee, denn so weiß der betroffene Abuse-Bearbeiter, was vorgefallen ist.

Allerdings werden die Logs erst nach der Installation der Sperre bei der Erzeugung der Beschwerde-Mail ausgelesen. Sie enthalten also nur noch die Einträge, die aufgrund der Sperre geblockt wurden. Eine Ursachenermittlung ist so nicht möglich.

Beim schnellen Test am Arbeitsplatz wird die Webseite angezeigt. Soweit so gut.

Drückt man aber F5-neu laden einige Male, so erscheint nur noch das folgende Bild:

2017-08-07-121848_881x287_scrot

Tests von verschiedenen anderen Systemen aus zeigten immer das gleiche Verhalten. Sobald man die CSS-Dateien schnell neu läd, erfolgt die Sperre. Es genügt offenbar auch, die /favicon.ico mehrfach schnell neu zu laden. Diese Datei existiert nicht und liefert einen 404.

Bei jedem dieser Versuche geht eine E-Mail an den Abuse-Kontakt des Internet-Providers, den man nutzt. Also Vorsicht!

Zur Klärung des Problems habe ich den Hoster angerufen und mit der Hotline gesprochen. Nach einigen Erklärungen hatte man das Problem verstanden (und vermutlich den Hotline-Rechner gesperrt). Eine Verbindung in die Abuse-Abteilung war aber nicht möglich, da "Die Kollegen Tag und Nacht im Einsatz sind, so dass sie heute erst nach 15 Uhr wieder rein kommen."

Avatar
Lutz Donnerhacke 08/08/2017 10:11 am
@th-h: Mist. Den Screenshot habe ich übersehen.

Ich verstehe allerdings nicht, warum die Einträge "vor der Sperre" existiert haben sollen, denn jede einzelne der URLs kann ich manuell sauber (200, 302 oder 404) abrufen. Da steht ja sogar die Hauptseite (/) dabei.
Avatar
-thh 07/08/2017 7:53 pm
@Uwe: Naja, es ist ja eigentlich in eurem Interesse (bzw. vielmehr dem des Kunden), wenn auf das Defacement aufmerksam gemacht wird, zumal, weil dieselbe Lücke durchaus auch andere, relevantere Fremdzugriffe ermöglichen kann. Sich da auf "falsche Sprache, falscher Empfänger und wer weiß, ob das nicht Absicht ist" zurückzuziehen, finde ich weder netz- noch kundenfreundlich. YMMV.
Avatar
-thh 07/08/2017 7:51 pm
Fail2ban ist halt ein ganz sinnvoller Automatismus, wenn man ihn (a) vernünftig aufsetzt und (b) Beschwerden manuell erzeugt oder wenigstens prüft. Hier hapert es an beidem ... Es gibt ein fail2ban-Modul, das auf "Herumstöbern" auf dem Webserver triggert. Es ist aber keine gute Idee, das zu verwenden, denn ein 403 kommt ganz schnell, wenn die Konfiguration nicht stimmt oder ein Link fehlgeht, wie ja auch hier; ein 404 kommt noch schneller. Fürs Blocken ist das nichts, und für automatisierte (!) Beschwerden schon dreimal nicht.

An den Logzeilen gibt es übrigens nicht zu meckern; das sind nämlich die Zeilen, die den Filter getriggert haben, also zeitlich vor (!) der Sperre liegen. Nach der Sperre erscheint üblicherweise gar nichts mehr im Log, weil fail2ban den "Angreifer" per Firewall blockt. Dass da ein "client denied by server configuration" steht, hat nichts mit der Sperre zu tun, sondern ist AFAIS vielmehr deren Ursache: da sind irgendwelche Verzeichnisrechte falsch, das führt zu 403ern, und die wiederum triggern dann fälschlich den Filter. Du hast das ja selbst (unfreiwillig) ausprobiert: die Sperre erfolgt dann über Firewallrules.

(Übrigens zeigt Dein Screenshot den Anbieter, um des es geht. ;))
Avatar
Uwe 07/08/2017 6:54 pm
bei uns kommt seit einigen Wochen mehr oder weniger regelmäßig Mail von einem Spanier wegen eines defacements der Seite einer unserer Kunden an noc@ rein, obwohl im whois unmissverständlich steht, dass man doch bitte abuse@ benutzen möge - komplett auf Spanisch und gaaaaaaaaaaaanz unten dann eine Version in gebrochenem Englisch. ich seh nicht ein, das an die Abuse Kollegen weiterzuleiten
1. was juckt es uns als Provider, wenn auf einer Kundenseite "hacked by xy" steht? vielleicht ist das ja Absicht und irgendein Gag
2. Wer sich nicht einmal minimal Mühe gibt und an den falschen Empfänger schreibt( auf Spanisch, an eine .de Domain) dem kann es ja wohl nicht so wichtig sein
Fazit: ordentliche Abuse reports sind rar
Avatar
Lutz Donnerhacke 07/08/2017 5:28 pm
Anruf am Nachmittag endete in "Bitte schreiben Sie eine E-Mail".

Total 5 comments

Post a comment

Related content