WordPress Brute Force Hall of Shame

Hier gab es noch vor einiger Zeit eine Liste mit tausenden IP-Adressen. Diese Liste existiert hier nicht mehr und ich empfehle auch nicht, sie einzusetzen. Es macht, aber dazu unten, deutlich mehr Sinn, einige wenige IP-Adressen freizuschalten (und alle anderen zu sperren) oder überhaupt auf automatisierte Schutzmethoden zurückzugreifen.

Wer Websites mit WordPress betreibt und die Loginversuche in den Administrationsbereich mit einem Plugin wie Limit Login Attempts einschränkt, kennt die ewig gleichen IPs, die mit einfach gestrickten Brute Force-Attacken auf die User “admin”, “user”, “test”, usw. ihr Glück versuchen. Ganz anders diejenigen, die sich auf das Jetpack-Modul “Brute Protect” verlassen: Sie haben keine Ahnung über die IPs, die Attacken auf ihre Websites durchführen. Sie kennen lediglich die Zahl der “blockierten, bösartigen Anmeldeversuche”.

Wie Plugins zur Abwehr von Brute-Force-Angriffen funktionieren

Auf Plugins wie Limit Login Attempts und Jetpack BruteProtect basierende Methoden, sich vor Angreifern zu schützen, sind äußerst bequem, weil sie die Attacken automatisch protokollieren und die daraufhin folgenden weiteren Anmeldeversuche nach diversen Kriterien abwehren. Diese Methode ist jedoch aus dreierlei Gründen verhältnismäßig langsam. Die Verarbeitung erfolgt auf einem hohen Abstraktionsniveau, also “weit weg” vom eigentlichen System. Die Verarbeitung eines Angriffs sieht in etwa so aus:

Angreifer → HTTP-Server → PHP → WordPress → Plugin → SQL → Blockade

Der Angreifer stellt eine Anfrage an den Server, der Server aktiviert die PHP-Verarbeitung, WordPress übernimmt die Anfrage, das Plugin schaltet sich dazwischen und macht eine Datenbankabfrage (SQL), vergleicht die angreifende IP mit denen, die es bereits in der Datenbank gespeichert hat, und blockiert gegebenenfalls den Angriff. Die Verarbeitung erfolgt unter Zuhilfenahme externer Services: Jetpack BruteProtect erhöht die eben genannte Verarbeitungskette um einige Ebenen mehr: Zusätzlich zu den Ausführungsebenen vor der endgültigen Blockade wird bei servicebasierten Abwehrmethoden noch eine weitere Ebene eingezogen, in der das Plugin einen zentralen Server kontaktiert, der seinerseits wiederum Anfragen verarbeiten und Befehle zum Blockieren aussenden muss, bevor es zur endgültigen Abwehr des Angriffs kommt. Die Verarbeitung erfolgt am betroffenen System: Bei einigen wenigen Angriffen ist die gleichzeitige Verarbeitung und die Blockade von Angriffen kein Problem. Wenn es aber ernst wird, dann hat der Angriff Ausmaße, mit denen selbst leistungsfähige Server nicht mehr problemlos fertig werden. Die zusätzliche Verarbeitung des Angriffs ist damit nur zusätzliche Belastung.

Listenbasierte Abwehr von Brute-Force-Angriffen

Deutlich schneller, weil unmittelbarer am System, funktionieren auf Listen basierende Maßnahmen zur Abwehr von Brute-Force-Angriffen. Sieht man sich allein die Ausführungskette bis zur Blockade an, sieht man schnell, um wievieles kürzer sie ist:

Angreifer → HTTP-Server → Blockade

Natürlich haben solche listenbasierenden Abwehrmaßnahmen auch Nachteile: Den Komfort einer schönen Oberfläche, in der man die Anzahl der versuchten Logins vor der IP-Sperre definiert, gibt es nicht. Den Komfort, aggregierte Daten unmittelbar zur Verfügung zu haben, ohne sich überhaupt mit Angriffsversuchen auseinandersetzen zu müssen, gibt es auch nicht. Vor allem der Punkt “aggregierte Daten” ist bei der listenbasierenden Methode ein Problem. Es gibt zwar Dienste wie den Fail2Ban Reporting Service, der beispielsweise eine Liste von bei Brute Force-Angriffen erwischten IPs bereitstellt, doch kommt mir vor, dass dort immer nur eine sehr geringe Auswahl von IPs gelistet wird. Aus diesem Grund habe ich mir eine eigene Liste zusammengestellt, die ich hier nicht nur regelmäßig aktualisiere, sondern gerne auch hier zur Verfügung stelle.

Brute Force IP-Liste

Die hier angeführte Liste enthält ein paar Tausend IPs mehr als die Fail2Ban-Brute-Force-Sammlung und wird immer wieder aktualisiert. Alle hier angeführten IPs haben auf mehreren WordPress-Installationen mehrfach versucht über die login.php oder über die XMLRPC-Schnittstelle in das System einzudringen. Perfekte Kandidaten also für die Hall of Shame der abgefangenen Loginversuche. Um die Liste (und damit die Ausschlussregel) für den WordPress-Login anzuwenden, kopiert man die gesamte Liste in die .htaccess. Die Liste sollte vor allen anderen htaccess-Anweisungen eingefügt werden. Keep calm and block all the IPs!

Wichtiger Hinweis zum Schluss

Der Einsatz einer Blacklist dieser Größe macht nur Sinn, wenn man mit einer Whitelist nicht auskommen kann. Man kann aber auf jeden Fall, wenn nur einer oder wenige Autoren Zugang zur wp-login.php haben müssen. Anstelle der obigen Blacklist fügt man in so einem Fall nur diese Whitelist in die .htaccess ein:

<files wp-login.php>
  order deny,allow
  deny from all
  allow from 123.456.789.10
</files>

Die 123.456.789.10 muss natürlich mit der eigenen IP ersetzt werden. Sollten mehrere IPs nötig sein, wird die Zeile “allow from” wiederholt. Erledigt.