Limit Login Attempts Plugin Alarm im Logfile prüfen

Gestern ging es ja mal wieder richtig los, im Stundentakt trudeln E-Mails von praktisch allen meinen WordPress Seiten ein, das Limit Login Attempts Plugin für WordPress meldet fehlgeschlagene Anmeldeversuche und Sperrungen der IP Adresse. Da versuchen offenbar wieder ein paar böse Jungs, massiv WordPress Domains anzugreifen und sich Zugriff auf das Backend zu verschaffen. Zu welchem Zweck auch immer. Wer schon länger das beliebte CMS nutzt, wird das bereits kennen und seine wp-login.php entsprechend mit einem zusätzlichen Passwort Schutz via htaccess und htpasswd file versehen haben. Ich auch, letztes Jahr im April als es erstmal richtig nervig wurde und die Sperrungen im Minutentakt ankamen. Damit war auch erstmal Ruhe, bis gestern jedenfalls, es ist auch längst nicht so heftig, der Passwort Schutz wirkt also.

Gleichwohl machten mich die E-Mails stutzig, denn im Grunde dürfte es gar nicht so weit kommen, wenn der htaccess Schutz läuft. Um meinen Verdacht zu überprüfen habe ich mir mal die Server Logfiles genauer angeschaut. Darin ist zu sehen, ob es Zugriffe auf die wp-login.php Datei gegeben hat, von wem und wie der Server die Anfragen beantwortet hat. Nun sind diese Dateien unter Umständen ziemlich groß und unübersichtlich und ich habe mir das mit folgender Methode einfach gemacht und kann auf einen Blick sehen, ob wirklich Gefahr droht, weil etwa Login Versuche zugelassen wurden oder das Limit Login Attempts WordPress Plugin nicht funktioniert oder jemand, wenn auch extrem unwahrscheinlich, das Passwort der htaccess knacken konnte. Folgende Schritte sind nötig:

1. Die Datei „access_log“ via FTP vom Webserver downloaden
2. Via Copy/Paste die gesamten Daten in eine leere Excel/Calc Tabelle importieren
3. Mit der „Text in Spalten“ Funktion die Daten trennen und überflüssige Zellen löschen
4. Alphabetisch sortieren lassen und fertig

Die Rohdaten sehen dann wie folgt aus, das ist nun sehr unübersichtlich und bei großen Datenmengen mit vielen hundert oder tausend Zeilen, wäre es unpraktisch und mühsam, die relevanten Zeilen zu finden.

Hier sind die gefährlichen Einträge schon orange markiert, bei vielen Zeilen ist es trotzdem schwer, Angriffe zu identifizieren.

In diesem Auszug habe ich die Angriffe schon orange markiert, bei vielen Zeilen ist es trotzdem schwer, die Angriffe zu identifizieren. Interessant sind hier noch die beiden vorletzten Zeilen, wird doch deutlich, dass versucht wird, die Schwachstelle im Revolution Slider Plugin auszunutzen. Aber dazu ein anderes Mal mehr. Wir wollen weiterhin unsere Logdaten einer genauen Analyse unterziehen.

Hier hilft die Funktion „Text in Spalten“ in MS Excel (dürfte es in allen Office Tools äquivalent geben), denn damit können wir unnütze Informationen leicht beseitigen und alles fein übersichtlich alphabetisch sortieren und anzeigen lassen. Für die Funktion gehst du in Excel auf den Reiter „Daten“ und dann rechts auf den Button „Text in Spalten“. Es erscheint ein Abfragefeld, wir legen fest, durch welches Zeichen die Daten getrennt werden sollen. Dort setzen wir das Häkchen bei „Andere“ und tragen einen „Slash /“ als Trennzeichen ein und klicken auf weiter und fertig stellen. Jetzt können die überflüssigen Zellen gelöscht werden, etwa die IP Adresse, bis wir bei der Zeile mit der wp-login.php Datei ankommen. Dann nur noch alphabetisch sortieren lassen und das Excel File sieht so aus.

Nun ist alles übersichtlich im Logfile dargestellt und wir sehen auf einen Blick, wie mit den Login Versuchen verfahren wurde.

Nun können wir die einzelnen Einträge bequem und übersichtlich analysieren und ich stelle in diesem Beispielfall fest, dass es offenbar mindestens zwei unterschiedliche Versuche gibt. Ich habe also jede Menge Anfragen auf die wp-login.php die vom Server mit dem Response Code 401 „Autorisierung ist fehlerhaft“ abgewiesen wurden. Das sollte grundsätzlich erwartet werden. Nun sperrt aber das Limit Login Attempts Plug-In trotzdem angreifende IP Adressen und die sind in diesem Fall nicht mit den abgewiesenen identisch. Das habe ich nicht erwartet, und es besteht Grund zu der Annahme, dass es vereinzelt gelingt, den htaccess Schutz zu überwinden.

Nun muss ich gestehen, dass mir das einiges Kopfzerbrechen bereitet und ich das mal mit dem Hoster besprechen muss. Also wird es in Kürze ein Update geben, sobald ich hier Klarheit habe und sicher bin, was das bedeutet und wie dem angemessen begegnet werden kann. In der Zwischenzeit, kannst du deine Ideen und Vorschläge posten, ich bin gespannt!

1. Update 19.09.2014 10:35 Uhr:

Also bisher tappen wir alle noch im Dunkeln, was das Problem und seine Lösung angeht. Es ist aber nötig, eine kleine Klarstellung einzufügen, denn eigentlich ging es mir in diesem Beitrag darum, eine einfache Methode zur Logfile Analyse mit Excel zu zeigen, um den nicht erwarteten Meldungen vom Limit Login Attempts Plugin, auf den Grund zu gehen. Nicht erwartet sind diese, weil ich diese Methode der zusätzlichen Passwort Abfrage per htpasswd im Einsatz habe. Das ist nötig zu klären, denn auf Facebook gab es da Verwirrungen bezüglich der „htaccess“ und der „htpasswd“ Datei. Gleichwohl bin ich über sachdienliche Hinweise zur Lösung des Problems dankbar und vermutlich nicht nur ich, sondern jeder WordPress Nutzer.

2. Update 19.09.2014 14:30 Uhr:

Nun denn, bisweilen ist es praktisch, wenn man jemanden fragen kann, der sich auskennt, so kommt man schneller zur Lösung 😉 und die habe ich gefunden, denke ich jedenfalls. Denn die Login Versuche, die vom Limit Login Attempts Plug In gesperrt wurden, sind nicht auf die wp-login.php, sondern auf die xmlrpc.php Schnittstelle erfolgt. Ihr wisst sicher, dass diese seit einiger Zeit per default aktiviert ist und sich im Backend nicht mehr abstellen lässt. Anbei mal ein Auszug aus dem Logfile.

Die vom Plugin blockierten Anmeldeversuche wurden auf die XMLRPC Schnittstelle ausgeführt und wie zu sehen, vom Server mit Status 200 beantwortet.

Daraus ergibt sich nun folgende Lösung, wenngleich die nicht für jeden in Betracht kommt, denn wer etwa mit Trackbacks arbeitet, wird keine mehr empfangen können, denn meine Lösung bezieht die XMLRPC Schnittstelle in den Passwortschutz mit ein. Dazu wird die htaccess um folgendes Snippet erweitert (der Pfad zur htpasswd muss individuell angepasst werden):

# Auth protect wp-login.php
<Files wp-login.php>
  AuthName "Restricted Admin-Area"
  AuthType Basic
  AuthUserFile ~/.htpasswd
  Require valid-user
</Files>

Oder alternativ wer die Schnittstelle aktiv braucht, kann mit diesem Snippet den Zugriff auf erlaubte Anwendungen einschränken.

  
    <IfModule mod_setenvif.c>
 <Files xmlrpc.php>
 BrowserMatch "Poster" allowed
 BrowserMatch "WordPress" allowed
 BrowserMatch "Windows Live Writer" allowed
 BrowserMatch "wp-iphone" allowed
 BrowserMatch "wp-android" allowed

 Order Deny,Allow
 Deny from All
 Allow from env=allowed
 </Files>
</IfModule>

Oder, wie Eazy gefragt hat, IP Adressen oder Blöcke erlauben und den Rest aussperren:

<files wp-login.php>
 order deny,allow
 Deny from all
 Allow from xxx.xxx.xx.xx
 Allow from yyy.yyy.yy.yy
 </files>

Damit ist dann hoffentlich wieder Ruhe. Jetzt muss ich das nur noch auf etlichen Domains erledigen und dann abwarten und schauen, ob sich das Limit Login Plugin noch immer meldet. Danke an Mike Kuketz, dessen Hinweise wie immer sehr hilfreich waren weshalb ich euch seinen Blog aus dem Link oben wärmstens empfehle.