Das WordPress-Plugin Limit Login Attempts wird häufig empfohlen, um die Anzahl der möglichen Loginversuche einer IP in die WordPress-Administrationsoberfläche zu begrenzen. Das macht Sinn, denn besonders Brute-Force-Attacken sind auf die rasche Abfolge vieler Loginversuche angewiesen, um überhaupt rentabel zu sein. Doch leider hält Limit Login Attempts nicht, was es verspricht. Es blockiert nicht zuverlässig bis gar nicht.
Dass Limit Login Attempts nicht hält, was es verspricht, kann man niemandem vorwerfen. Erstens wird jedes Plugin auf wordpress.org mit einer Lizenz ausgestattet, die es jedem und jeder ermöglicht, Verbesserungen durchzuführen; zweitens wurde das Plugin vor mehr als einem dreiviertel Jahr das letzte Mal aktualisiert. Und drittens hatte der Plugin-Autor offenbar nicht an die Möglichkeit von Botnetz-Attacken gedacht. Warum es jedoch so oft empfohlen wird, vor allem in Zusammenhang mit dem aktuellen Botnetz-Angriff, ist mir ein Rätsel. Matt Mullenweg hält nichts davon und Leute wie Mike Kuketz versuchen in ganzen Artikelserien zu erklären, warum bestimmte Plugins und Erweiterungen, die angeblich dem Sicherheitsgewinn dienen sollen, eigentlich nur das Sicherheitsgefühl der diese Erweiterungen benutzenden Personen steigern. Und genau da setzt mein Problem an.
Auch ich dachte, dass meine Limit Login Attempts-Konfiguration ausreichend war. Zum Zeitpunkt der Attacke sah sie folgendermaßen aus:
- 3 erlaubte Anmeldeversuche
- 1440 Minuten Sperrung nach Überschreiten der zulässigen Anmeldeversuche
- 2 Sperrungen erhöhen die insgesamte Sperrzeit um 168 Stunden
- 378 Stunden bis fehlgeschlagene Anmeldeversuche zurückgesetzt werden
Oder anders:
- Nach 3 Anmeldeversuchen wird eine IP für 24 Stunden (= 1440 Minuten) gesperrt.
- Nach 24 Stunden geht es von vorne wieder los. Erreicht die IP allerdings im zweiten Durchgang abermals 3 fehlgeschlagene Anmeldeversuche, dann wird sie für 1 Woche (= 168 Stunden) gesperrt.
- Das bedeutet, dass eine IP an einem Tag maximal 3 Anmeldeversuche durchführen kann, bevor sie für 24 Stunden gesperrt wird.
Wie viele andere auch, habe ich aufs Funktionieren des Loginlimiters vertraut. Vertrauen ist gut, Kontrolle bekanntlich besser, und so habe ich Activity Monitor installiert. Das Plugin protokolliert alle Zugriffe, auch fehlgeschlagene, sowie Modifikationen innerhalb der WordPress-Administrationsoberfläche. Und so sieht die Brute Force-Attacke im Protokoll aus:
| Datum/Zeit | IP-Adresse | Username | Passwort |
|---|---|---|---|
| 20. Mai 2013, 16:22:55 Uhr | 195.128.126.91 | admin | 1 |
| 20. Mai 2013, 16:22:56 Uhr | 195.128.126.91 | admin | 2 |
| 20. Mai 2013, 16:22:56 Uhr | 195.128.126.91 | admin | 3 |
Bisher sind 3 fehlgeschlagene Anmeldeversuche erfolgt. Spätestens jetzt hätte Limit Login Attempts den Zugang für 24 Stunden sperren müssen. Aber nein, die Attacke wurde ohne Verzögerung fortgesetzt.
| Datum/Zeit | IP-Adresse | Username | Passwort |
|---|---|---|---|
| 20. Mai 2013, 16:22:57 Uhr | 195.128.126.91 | admin | 4 |
| 20. Mai 2013, 16:22:57 Uhr | 195.128.126.91 | admin | 5 |
| 20. Mai 2013, 16:22:58 Uhr | 195.128.126.91 | admin | 6 |
Limit Login Attempts hat die Brute-Force-Attacke nicht gesperrt, die Loginversuche wurden ohne Verzögerung fortgesetzt. Spätestens nach 3 weiteren Versuchen (es sind gerade mal 3 Sekunden seit Beginn der Attacke vergangen) müsste Regel Nr. 2 greifen: 2 x 3 misslungene Anmeldeversuche bedeuten eigentlich eine Sperre für 1 Woche.
| Datum/Zeit | IP-Adresse | Username | Passwort |
|---|---|---|---|
| 20. Mai 2013, 16:22:59 Uhr | 195.128.126.91 | admin | 7 |
| 20. Mai 2013, 16:22:59 Uhr | 195.128.126.91 | admin | 8 |
| … | … | … | … |
| 22. Mai 2013, 06:27:11 Uhr | 195.128.126.91 | admin | zzzzzz |
| 22. Mai 2013, 06:27:11 Uhr | 195.128.126.91 | admin | zzzzzzz |
| 22. Mai 2013, 06:27:12 Uhr | 195.128.126.91 | admin | zzzzzzzz |
Am 22. Mai, also etwas mehr als eineinhalb Tage (!) nach Beginn der Attacke (!!) habe ich dann doch ein mit 22. Mai 2013, 5:30 Uhr datiertes E-Mail von Limit Login Attempts bekommen:
6 ungültige Anmeldeversuche (2 Sperrung(en)) von IP: 195.128.126.91
Letzter Anmeldeversuch erfolgte mit dem Benutzernamen: admin
IP wurde gesperrt für 168 Stunden.
Das große Problem: Zu dem Zeitpunkt waren es nicht 6, sondern 6424 ungültige Anmeldeversuche von der gleichen IP (mit dem User agent Mozilla/5.0 (Windows NT 6.1; rv:21.0) Gecko/20100101 Firefox/21.0 [xUSAx]). Die 6424 Anmeldeversuche stehen in keiner Relation zu den maximal 6 Anmeldeversuchen, die im genannten Zeitraum hätten stattfinden dürfen.
Was mich ein wenig skeptisch stimmte, war jedoch das Absendedatum des E-Mails. Die letzten Brute-Force-Attacken erfolgten um 6:27 Uhr, das E-Mail wurde aber etwa eine Stunde vorher, nämlich um 5:30 Uhr abgeschickt. Das bedeutete, dass trotz dieses E-Mails der damit angekündigten Sperre weiterhin Login-Versuche von der gleichen IP möglich waren. Ein Blick ins Protokoll verschafft Klarheit und Staunen. Nicht einmal 24 Stunden nach der letzten Attacke begann die gleiche IP abermals – diesmal mit anderem User agent (Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1) – ihre Brute-Force-Attacke.
| Datum/Zeit | IP-Adresse | Username | Passwort |
|---|---|---|---|
| 23. Mai 2013, 16:16:07 Uhr | 195.128.126.91 | admin | 1 |
| 23. Mai 2013, 16:16:08 Uhr | 195.128.126.91 | admin | 2 |
| 23. Mai 2013, 16:16:08 Uhr | 195.128.126.91 | admin | 3 |
Wir wissen, was spätestens jetzt hätte geschehen sollen.
| Datum/Zeit | IP-Adresse | Username | Passwort |
|---|---|---|---|
| 23. Mai 2013, 16:16:09 Uhr | 195.128.126.91 | admin | 4 |
| 23. Mai 2013, 16:16:09 Uhr | 195.128.126.91 | admin | 5 |
| 23. Mai 2013, 16:16:10 Uhr | 195.128.126.91 | admin | 6 |
Und wir wissen, was hier hätte passieren müssen.
Die Attacke mit dem neuen User agent war weniger aggressiv als die vorherige, obwohl die eingesetzten Passwörter etwas komplexer waren. Nach insgesamt 843 Loginversuchen hörte sie auf.
Limit Login Attempts hat insgesamt 7262 Login-Versuche durchgelassen, obwohl es in dem Zeitraum maximal 6 hätte durchlassen dürfen.
Wer also ausschließlich aufs zuverlässige Funktionieren des Plugins vertraut, sollte sich vielleicht doch davon überzeugen, dass alles so läuft, wie es Limit Login Attempts verspricht.