Auf allen Blogs, Webseiten und überhaupt allem, was http spricht, tummeln sich Bots. Die meisten davon sind Bots der Suchmaschinenbetreiber. Daneben gibt es solche, die für die Webseite keinerlei Nutzen bringen, ja sogar gegen die Webseitenbetreiber arbeiten. So z.B. der Pixray-Bot, der Webseiten nach urheberechtlich geschützen Bildern durchsucht. Bei einem Fund kann man sich anschließend offensichtlich auf Post vom Anwalt freuen.
Da meiner Meinung nach das Verhalten des Pixray-Bots einer digitalen Hausdurchsuchung entspricht, ich ihm das nicht erlaubt habe und ich den durch den Bot generierten Traffic bezahlen muss, habe ich nach einer Lösung gesucht, den Bot von meinen Webseiten fernzuhalten.
Meine erste Idee war, die IP-Adressen des Bots aus den Apache-Logfiles zu fischen und diese dann direkt mit iptables zu sperren. Natürlich nur mit einem deny und nicht mit reject, man will es den Betreibern von Pixray ja nicht zu einfach machen. Allerdings ist das Festlegen auf IP-Adressen wohl keine gute Idee, denn diese können sich im Laufe der Zeit ändern. Auch die Sperre eines Subnetzes ist nicht möglich, da (derzeit) die Pixray-Bots auf verschiedenen einzelnen Servern aus unterschiedlichen Subnetzen beim Hostingprovider Hetzner gehostet werden. Vielleicht ist das auch Absicht.
Die zweite Idee war erfolgversprechender: mit Hilfe des bereits hier eingesetzen fail2ban Zugriffe durch den Pixray-Bot feststellen und dann automatisch die IP-Adresse mit iptables aussperren. Das garantiert zwar keinen 100%igen Erfolg, da immer erst mindestens ein erfolgreicher Zugriff protokolliert worden sein muss. Auch identifiziert sich der Pixray-Bot selbst durch seinen User-Agent, was evtl. in Zukunft nicht mehr der Fall sein kann. Mit diesem Kompromiss kann ich aber im Moment leben.
In der fail2ban-Konfiguration unter Ubuntu (mitgeliefert wird aktuell die fail2ban-Version 0.8.4) ist bereits ein Filter zum Erkennen von unliebsamen User-Agents enthalten, aber nicht aktiviert. In der Datei /etc/fail2ban/filter.d/apache-badbots.conf sind bereits ein paar User-Agents eingetragen. Ich habe dort Pixray bei der Einstellung badbotscustom hinzugefügt:
badbotscustom = EmailCollector|WebEMailExtrac|TrackBack/1\.02|sogou music spider|Pixray
Bei mir musste ausserdem das Muster zum Suchen angepasst werden, da in meinen Apache-Logs als erstes der virtuelle Hostname protokolliert wird. Das Suchmuster sieht bei mir dann so aus:
failregex = ^(blog|www|piwik|thinkup)\.tausys\.de <HOST> -.*"(GET|POST).*HTTP.*"(?:%(badbots)s|%(badbotscustom)s).*"$
Besonders auf das hinzugefügte .* am Ende des Muster muss geachtet werden. Falls nicht schon vorhanden muss anschließend in der Datei /etc/fail2ban/jail.conf ein neues "Gefängnis" definiert werden:
[apache-badbots] enabled = true port = http,https filter = apache-badbots logpath = /var/log/apache*/*access.log maxretry = 0 bantime = 2592000
Die bantime entspricht in dieser Einstellung 30 Tagen. Den Wert für maxretry habe ich auf 0 gesetzt, damit schon nach einem einzigen Versuch Aktionen durch fail2ban ausgelöst werden.
Nach einem Neustart von fail2ban kann die korrekte Konfiguration durch die Anzeige der iptables-Chains mit
iptables -L -v
kontrolliert werden. Dort muss dann ein Chain fail2ban-apache-badbots angelegt worden sein. Nach kurzer Laufzeit (der Pixray-Bot kam hier im Minutentakt vorbei) hat man schon die ersten Bots ausgesperrt.
Chain fail2ban-apache-badbots (1 references) pkts bytes target prot opt in out source destination 3 180 DROP all -- any any node-176-9-19-103.cluster.eu.webcrawler.pixray.com anywhere 6 360 DROP all -- any any node-176-9-31-203.cluster.eu.webcrawler.pixray.com anywhere 6 360 DROP all -- any any node-46-4-121-154.cluster.eu.webcrawler.pixray.com anywhere 20 1136 DROP all -- any any node-46-4-116-100.cluster.eu.webcrawler.pixray.com anywhere 3878 718K RETURN all -- any any anywhere anywhere
Nun ist Ruhe.
Guter Artikel,
"Besonders auf das hinzugefügte .* am Ende des Muster muss geachtet werden"
Was hat es genau damit auf sich? Muss das rein, warum? Funktioniert dann noch alles wie zuvor?
-Dieter
Der Teil des regulären Ausdrucks würde ohne das .* am Ende die gesuchten Zeilen im Apache-Log nicht finden. Durch .* werden null oder mehrere beliebige Zeichen gesucht, danach ein doppeltes Hochkomma und danach wiederrum folgt das Zeilenende (durch $ dargestellt).
Selbst gebaute reguläre Ausdrücke kann man mit dem Fail2ban-Tool "fail2ban-regex" vor dem Einsatz testen. So z.B. für das Apache-Log mit: "fail2ban-regex /var/log/apache/access.log 'TestRegEx'".
Hallo,
ein super Artikel. Vielen Dank. Mir haben die Kandidaten alle Logs meiner Domains unendlich aufgeplustert. Kaum hatte ich den Filter eingestellt, hatte ich innerhalb 1 Minute 5 Bots gefangen. Vielen Dank :)
Beste Grüße
Prinzipiell - sofern man Zugriff hat - empfehle ich jedem die Installation von "logrotate". Es werden bei den meisten Distris Regeln für Apache & Co. mitgeliefert, aber man kann einiges konfigurieren. So kann man z.B. ein Log auch bei einer gewissen Größe rotieren und verhindert so das Aufblähen des Logordners. Uns sein wir mal ehrlich, mehr als 2-3 Tage Logs braucht kaum einer von uns.
Ich bin sogar dazu übergegangen alle Logs zu anonymisieren und nach einem Tag zu entfernen...
Man kann auch Apache2 etwas anpassen bezüglich der Logfiles.
LogFormat "%v:%p %h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combined
Wenn man hier %v:%p entfernt kann man die Blockregel für alle Domains des Servers benutzen, und muss nicht zu jeder Domain eine Regel failregex = erstellen. (aber Achtung: Jetzt wird die Domain über welche zugegriffen wurde nicht mehr geloggt!)
Die failregex würde dann nur noch so aussehen:
^ -.*"(GET|POST).*HTTP.*"(?:%(badbots)s|%(badbotscustom)s).*"$
Die Konfig wie hier beschreiben lief bei mir nicht aber mit der geänderten Apache2 Logconfig schon. Vieleicht liegt es aber auch an der Fail2ban version ggf. ändert sich hier auch immer etwas.
Aber das nutzt nix mehr.
Mittlerweile tarnt der sich als:
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; Trident/4.0; BTRS124307; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618; InfoPath.2; .NET4.0C; eMusic DLM/4; .NET CLR 1.1.4322; .NET4.0E
Das macht dann obige Lösung leider obsolet :-(
Ich überlege gerade, ob es nicht eine Lösung währe, wenn man Zugriffe auf die robots.txt (die der Pixray-Seeker wohl macht) mit unbekannten UserAgents, also keinen erwünschten Bots, gleich für alle weiteren Zugriffe sperrt. Wenn Bot, dann soll der sich auch anständig identifizieren, so dass ich selber entscheiden kann, ob ich den Zugriff zulasse oder nicht. Besucher mit "normalen" Browsern rufen die robots.txt ja nicht ab. Es ist dann allerdings erst einmal eine Positivliste erforderlich.