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:
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."
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.
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. ;))
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
5 Kommentare