WordPress und Sicherheit: Ausweitung der automatischen Loginversuche

42 Kommentare

Das Plugin Limit Login Attempts habe ich hier auf perun.net an mind. zwei Stellen genannt (hier und hier). In regelmĂ€ĂŸigen AbstĂ€nden bekomme ich von dem Plugin folgende Meldung:

8 failed login attempts (2 lockout(s)) from IP: xx.xxx.xxx.xx

Last user attempted: admin

IP was blocked for 24 hours

Es wurde mal wieder eine IP geblockt von der mehrere ungĂŒltige Loginversuche in einem bestimmten Zeitraum stattfanden. Das automatische Loginversuche auf den Nutzernamen admin stattfinden ist ein alter Hut.

WordPress: Einstellungen von Limit Login Attempts
Einstellungen von Limit Login Attempts

Deswegen sollte man hier entweder den admin durch einen Administrator-Account mit einem individuellen Namen ersetzen oder eben das Limit Login Attempt oder eine Àhnliche Lösung installieren.

In den letzten Wochen konnte ich allerdings beobachten, dass vermehrt automatische Loginversuche auf andere Nutzernamen stattfanden, wie zum Beispiel: webmaster, test, demo, author und editor. Ich möchte keine Panik machen, aber ich kann mir gut vorstellen, dass es nicht mehr lange dauern wird bis es Loginversuche auf john, michael, chris etc. geben wird.

Daher wĂŒrde ich auf jeden Fall empfehlen, dass man eine Begrenzung der Loginversuche einrichtet.

Diesen Beitrag teilen:

Verwandte BeitrÀge:

Über Vladimir

Vladimir Simović arbeitet seit 2000 mit HTML & CSS und seit Januar 2004 mit WordPress. Im Laufe der Jahre hat er diverse FachbĂŒcher und Fachartikel publiziert.

Schlagwörter: ,

42 Kommentare

  1. So in etwa sah das bei mir in den vergangenen Wochen auch aus. Auch der Blogname wurde schon verwendet aber bisher hats Gott sei dank noch niemand geschafft.

    Wenn das so weitergeht, dĂŒrfte es aber leider wirklich nicht mehr lange dauern… 🙄

  2. Das PhĂ€nomen kann ich schon seit mehreren Wochen beobachten. Da wird – egal auf welchem Blog – mit dem Nutzernamen ein Loginversuch gestartet. Ich dachte das wĂ€re normal, jetzt hast du mich doch in Panik versetzt. 🙂
    Gruß, Max

  3. Es empfiehlt sich eine zusĂ€tzliche Absicherung durch Apache .htpasswd. Dann kommt der Angreifer gar nicht erst zum WordPress-Login bzw. muss eine weitere HĂŒrde ĂŒberwinden. Und natĂŒrlich muss man zwei unterschiedliche Logins und Passwörter nehmen!

    1. @Martin,

      eine zusĂ€tzliche Absicherung durch den Server wĂŒrde ich nicht empfehlen und zwar nicht nur wegen des Einwandes von NetzBlogR. Eine Absicherung durch ein individuellen Loginnamen, eines guten Passworts und durch Limit Login Attempts reicht völlig aus. Eine zusĂ€tzliche (und im Falle von .htaccess) eine unkomfortable Passworteingabe verleitet den Nutzer dazu zu schummeln (z.B. schwaches Passwort zu nehmen) und sich dadurch in eine falsche Sicherheit zu wiegen.

  4. Bei mir gibt es auch vermehrt solche Versuche. Da ich ein sehr langes und sehr “abewechslungsreiches” Passwort verwende, wird man das dank LimitLogin Attempts, das ich ebenfalls verwende, durch Raten nicht herausbekommen, obwohl ich lĂ€ngstens fĂŒr eine Stunde sperre.
    Aber warum ich das hier eigentlich schreibe: bei mir wurde mit dem Namen eines Autoren (der ja öffentlich und auslesbar ist) der Login versucht.
    Eigentlich eine simple Sache, aber bisher hatte es gereicht, wenn der Admin nicht den
    Standard-Namen hat, weil immer nur mit admin probiert wurde. Die Zeiten sind anscheinend vorbei…

  5. @Martin: Das Problem ist, dass mit einer .htaccess-Sperre seit neuestem passwortgeschĂŒtzte Posts nicht mehr aufrufbar sind, da die Abfrage fĂŒr diese auch ĂŒber die wp-login.php abgehandelt wird.

  6. @NetzBlogR: Okay, da ich keine passwortgeschĂŒtzten Posts habe, war mir das nicht bewusst.

    @Vlad: Mich beruhigt das eher. Ich habe einfach ein autogeneriertes Passwort mit ĂŒber 20 Stellen auswendig gelernt. Aber ich glaube das muss jeder selber entscheiden. Und ein Schutz kann immer nur so gut sein, wie das gewĂ€hlte Passwort. Und wie man da schludrig sein kann, verstehe ich persönlich nicht. DafĂŒr ist mir mein Blog zu wichtig! 😀

  7. Kann ich nur bestĂ€tigen, bekomme seit 1,5 Wochen tĂ€glich mehrere solcher E-Mails. Ziehmlich nervig, aber kein Grund zur Panik, admin gibt es bei mir nicht. 😉

  8. Nach der zweiten Mail von Limit Login Attempts war mir die Sache zu dumm und ich habe eine extra HĂŒrde mittels .htaccess aufgebaut (keine passwortgeschĂŒtzten BeitrĂ€ge vorhanden). Seitdem ist Ruhe im Karton. Ich habe mich hierbei fĂŒr ein weiteres Passwort entschieden, theoretisch wĂ€re jedoch auch eine Eingrenzung auf bestimmte IP-Adressen möglich.

    ZusĂ€tzlich verwende ich natĂŒrlich ein sicheres Kennwort, keine Standard-Benutzernamen und verschleiere diese auch noch mittels Edit Author Slug.

    http://brandonallen.org/wordpress/plugins/edit-author-slug/

    Diese Verschleierung dĂŒrfte dann auch die Lösung fĂŒr das Problem sein, welches Marc Haunschild angesprochen hat.

  9. Ich nutze das Plugin auch schon eine Weile. Habe es aber noch verschĂ€ft. Ab dem ersten Fehlversuch wird gesperrt. Da mein PW im Browser gespeichert ist, kann ich es ja nicht falsch eingeben 😉 Und der Rechner ist auch geschĂŒtzt.

    Leider wurde bei mir anfangs nur der admin, inzwischen aber auch mein Benutzername abgefragt. Ich habe nun eine htaccess in den Adminbereich gepackt, wo nur Leute mit Deutscher LĂ€nderkennung Zugang bekommen.
    Das sollte auch die meisten aussperren.

  10. @Sebastian: Könntest Du bitte mal Deine .htaccess vorstellen? Die Variante hört sich interessant an.

  11. Ich habe eben festgestellt, das das nicht klappt. Alle wurden gesperrt, obwohl es mehrfach im Netz so vorgeschlagen wurde 😉
    Dort stand:

    order deny,allow
    Deny from all
    Allow from .de

    Ich habe es aber nun wie folgt verÀndert:

    order deny,allow
    Deny from all
    Allow from 123.456
    Allow from 234.567

    Du musst natĂŒrlich deine IP nehmen bzw die ersten beiden Blöcke.
    Die erste ist vom BĂŒro, die zweite von zu Hause. Da die ersten beiden meist immer gleich bleiben, reicht das. Falls nicht dann nehm nur den ersten Block. Auch wenn das ggf andere LĂ€nder/Provider wieder einschließt. So wird es trotzdem viele Angreifer aussperren.

    Wie gesagt, das kommt in den Ordner wp-admin, sonst sperrst du ja alle aus 😉

  12. Leider ist es schon soweit, dass generierte Namen verwendet werden. Hier eine kleine Liste von Namen, mit denen in den letzten Tagen versucht wurde sich bei meinem WordPress Blog anzumelden:

    dannyz97, miraovers, dickvital, christyma, calebbrow, carrollcr, dominique, edmundobl, katiamccl, abigailka, rochellme, jonathanc, desmondtw, garyklein, mollybrin, alyssa07l, alyssatol, dolliecar, harleyofj, cathleenw, colemgp, sharonivj, kerstinwe, ...

    Außerdem wurde als Benutzername auch der 2nd Level Domain-Name verwendet! FĂŒr diese Seite wĂŒrde das z.B. “perun” sein.

    Das wird wirklich immer schlimmer.

    Gruß,
    Guido

  14. Nachdem ich seit Ende 2012 tĂ€glich rund 600 Angriffe auf wp-login hatte, habe ich per htaccess ein entsprechendes htpasswd vorgeschaltet. Danach war 4 Tage Ruhe und dann kamen sie wieder und kassierten tĂ€glich wieder ca 600 mal ihren verdienten error 401. Mittlerweile hab ich den Login kpl dichtgemacht und erlaube nur noch Zugriff von meiner IP. Alle anderen schicke ich zurĂŒck auf ihren localhost. Meine IP ist zwar dynamisch, ich muss die htaccess also vorm Posten entsprechend editieren, was fĂŒr mich aber das kleinste Problem darstellt. Dazu muss ich sagen, dass ich auf meinen WP-Installationen der Alleinherrscher bin und mir ĂŒber andere User und passwortgeschĂŒtzte Artikel keine Gedanken zu machen brauche. Die Sicherheit meiner Inst. steuere ich kpl ĂŒber htaccess und verzichte auf Plugins, um nicht eine weitere SicherheitslĂŒcke zu riskieren.

    Außerdem gesperrt sind fast 200 User Agents und eine tĂ€glich wachsende Liste von jetzt schon hunderten IP-Adressen und ganzen Ranges.

    WordPress ist ein super Tool aber leider zu interessant fĂŒr Kriminelle und von denen gibt es immer mehr.

    Hier meine login-Sperre, falls es jemanden interessiert:
    (Rewrite engine ist on)
    RewriteCond %{REQUEST_URI} ^/wp-login.*$
    RewriteCond %{REMOTE_ADDR} !^mein\.ip\.adresse$
    RewriteRule ^.* http://localhost [L,R=301]

    Webadminsitration ist Krieg! 😉

    All the best.

    1. @Webmasta,

      Leider ist das genannte Plugin nicht kompatibel zu 3.5.x 🙄

      sagt wer? Es funktioniert einwandfrei mit WP 3.5.1

  16. Eine weitere Möglichkeit die erlaubten Rechner fĂŒr den Zugang zum Login einzuschrĂ€nken ist das Plugin Login Dongle. Nur von Browsern, auf denen der Software-Dongle installiert ist, ist ein Login möglich.

    Es handelt sich dabei um ein Bookmarklet, das die Eingabe eines weiteren Passworts gleichzeitig mit dem normalen Login-Dialog erfordert.

    Eine Änderung der .htaccess ist dafĂŒr nicht nötig.

    1. Die Angabe des Autors bezieht sich deswegen auf WP 3.3.2, weil das Plugin zuletzt Juni 2012 aktualisiert wĂŒrde. Ob ein Plugin funktioniert oder nicht sollte man lieber selber testen und unten rechts auf die Angaben anderer Nutzer schauen:

      6 people say it works. 0 people say it’s broken.

  18. Noch eine Möglichkeit den Zugriff einzuschrĂ€nken: Verwende einen benutzerdefinierten UserAgent (z.B. Firefox AddOn). Über .htaccess den Zugriff nur mit diesem UserAgent erlauben. Diese Methode verwende ich zur Zeit nur wĂ€hrend Wartungsarbeiten an meinen Seiten, aber ich werde das bzgl. Login ebenfalls bedenken.

  19. Das ist inzwischen richtig ĂŒbel. Bei mir wurde es erst heute wieder probiert den Account zu knacken.

    Ich habe meine Einstellungen fĂŒr das “Limit Login Attempts” noch hochgeschraubt und zwar:

    2 erlaubte Anmeldeversuche
    9999 Minuten Sperre nach Überschreiten der Anzahl oben (das Maximum)
    2 Sperrungen erhöhen die Gesamtzahl auf 4320 Stunden
    336 Stunden bis RĂŒcksetzung erfolgt

    Somit hat man ne Weile Ruhe :mrgreen:

  20. @Guido: Auch nicht schlecht die Lösung. Aber ich denke mit meiner und dem IP-Pool werde ich viele auch schon sperren. Werde das beobachten udn notfalls anpassen.

  21. Ich verwende das Plugin auch und bin sehr zufrieden.
    Wenn es mal “Wellen” gab, gingen mir allerdings die vielen Benachrichtigungen auf den Geist, abschalten wollte ich die Nachrichten aber auch nicht.

    Habe dann einfach mal fĂŒr ein paar Wochen die wp-login.php “umbenannt”.
    Vielleicht nicht besonders elegant, aber hat auch funktioniert. 😉

  22. Wir haben pro Tag ca. 800 Loginversuche auf unsere Seite. 95% davon mit dem Namen “Admin”

    Wenn man jedoch wie oben genannt den Admin in der Datenbank Ă€ndert, sollte man auch darauf achten, dass das Theme keine Autoren-Archiv-Funktion unterstĂŒtzt. Wenn doch, dann kann hier ganz leicht die Änderung des Admin-Namens eingesehen werden.

    http://www.deine-blogadresse.de/?author=1

    Daher sollte sicherheitshalber diese Seite z.b. per .htaccess umgeleitet werden.

  24. @Sebastian: Meines Wissens nach wird beim Aufruf von wp-admin die wp-login.php aufgerufen, deswegen schĂŒtze ich die Datei und nicht den Ordner.

  25. Ich habe heute die Login-failed-Tabelle seit langer Zeit angesehen,
    und festgestellt, das seit September 2012 regelmĂ€ĂŸig Logins auf den admin-User durchgefĂŒhrt werden. Nun gibt’s den Admin nicht mehr, mal sehen, wie es weitergeht.

  26. Wenn möglich (leider gibt es ein paar Plugins, die Teile aus /wp-admin laden) setze ich einen .htpasswd-Zusatzschutz ein. Bisher konnte ich den Serverlogs praktisch keine Versuche feststellen, dass jemand versucht hĂ€tte, diese HĂŒrde zu ĂŒberwinden.

    Ansonsten kommt Limit Login Attempts zum Einsatz. RegelmĂ€ĂŸig erreichen mich E-Mails, die Login-Versuche melden. Wird hier eine IP besonders auffĂ€llig, wird diese in der Server-Firewall eingetragen und ist somit fĂŒr sĂ€mtliche Zugriffe auf den Server gesperrt.

    Ich konnte bisher ausschließlich Login-Versuche mit dem Nutzernamen “admin” feststellen, was mich beruhigt …

  27. […] eben hab ich durch Zufall auf Perun.net in dem Artikel „WordPress und Sicherheit: Ausweitung der automatischen Log-in-Versuche“ gelesen, dass es derzeit vermehrte Angriffe auf WordPress Nutzer zu scheinen […]

  28. Hallo,
    dieses Plugin werde ich mir mal installieren. Gut, dass ich vorausschauend war und keinen so offensichtlichen Login-Namen nutze.
    Meiner Meinung nach sollte man als Name aber auch nicht unbedingt den Namen seines Blogs verwenden, denn auf diese Idee kommen Angreifer bestimmt auch schon bald 😉

  29. Kleine ErgÀnzung:
    Ich habe inzwischen meine wp-login.php umbenannt, sodass nur ich den Namen kenne. Vielleicht bringt das eine kleine Verbesserung in der Sicherheit.
    Durch das Umbenennen musste ich allerdings auch einige kleine Änderungen am Inhalt der Datei machen: Alle Vorkommen von wp-login.php mussten durch den neuen Dateinamen ersetzt werden. Das Ganze dĂŒrfte aber auch ohne PHP Kenntnisse kein problem sein, ist ja nur einfaches Suchen&Ersetzen 😉

    Gruß
    Christian von SoftNetBlog.de

  30. Moin Moin,
    seit einigen Tagen verfolge ich diesen Artikel und habe mich natĂŒrlich besorgt auf meine Seite(n) gestĂŒrzt.
    Doch ich kann sagen, ich bemerke nichts von dem was einige von Euch hier so posten.
    Ich kann einfach keinerlei Einbruchsversuche feststellen.
    Limit Login Attempts benutze ich schon seit Monaten, und seit Wochen, genau genommen, seit dem ich eine .htaccess eingerichtet habe, bekomme ich von Limit Login Attempts keinerlei Mails mehr.

    Plugins benutze ich nur ganz wenige. Vielleicht ist meine Seite mit 500 bis 600 Besuchern am Tag, zu Spitzenzeiten 3800 Besucher auch einfach zu uninteressant fĂŒr Angreifer 😉

    Gruß Frank

  32. Hallo Leute,
    interessant zu lesen, aber wirklich ĂŒberraschend ist dies ja nicht! Wer sich dadurch beunruhigt, sollte ja erst gar keine Website ins Netz stellen und wenn, dann auch kein WordPress, da dies durch seine weite Verbreitung natĂŒrlich auch den meisten Angriffen ausgesetzt ist.

    Das wird sich in Zukunft sicher alles noch verschÀrfen!

    Es sollte aber auch dazu beitragen, das WP immer sicherer wird.
    Dnd deshalb sind die Sicherheitstools neben guten Login-Daten sehr wichtig!

    Was ich vermisse hier ist ein Hinweis auf Wordfence. Das begrenzt auch die Loginversuche und kann noch mehr zur Sicherheit beitragen!

    Gibts da evtl. etwas Gegenteiliges zu sagen zu diesem Plugin? Hat jemand schon mehr Erfahrung damit?

    Beste GrĂŒĂŸe

    Andy

  33. Interessant zu sehen, dass mein Kommentar bis heute weder freigeschalten, noch gelöscht wurde. 🙁

    1. @fantasylife,

      Interessant zu sehen, dass mein Kommentar bis heute weder freigeschalten, noch gelöscht wurde. 🙁

      Ja, das fand ich auch interessant. Hier in diesem Weblog passieren auch die verrĂŒckten Sachen. 😉

      HĂ€ttest du mich frĂŒher darauf aufmerksam gemacht, hĂ€tte ich ihn auch frĂŒher freigeschaltet.

  34. Vielen Dank @Vladimir! Ich wollte nicht aufdringlich sein.

    Zum o.g. Problem: Wenn ich ĂŒber Who Is – Abfrage oder Honeypot die IPs der letzten Angriffe teste, dann habe ich oft Bots dabei, was ich sehr seltsam finde.
    Meine Seite ist zwar DoFollow, aber ich denke das ist fĂŒr die doch uninteressant, oder.
    Meine Seite hat eigentlich sehr wenige Besucher, deshalb wundern mich die Angriffe doch sehr.

  35. @Oli: Danke fĂŒr den Tipp mit der author-URL.
    Hab ich gleich in die htaccess eingetragen.
    Ging zwar nicht mit dem ?author=1 aber ich hab es wie folgt eingetragen:

    Redirect /author/mein-author-name/ http://meine-webseite.de

  36. @Sebastian: Anstatt die author-URL fĂŒr den Admin komplett durch eine Umleitung zu deaktivieren, wĂŒrde ich lieber das Plugin aus Kommentar 9 verwenden. So lĂ€sst die URL dann keinerlei RĂŒckschlĂŒsse mehr auf den Loginnamen zu, was eigentlichen reichen sollte.

  38. Was haltet ihr denn von “Google Authenticator Plugin”? Hat jemand mit dem Plugin schon Erfahrungen gemacht? Ich registriere nĂ€mlich auch schon seid Tagen Anmeldeversuche auf mein Blog.

    .htaccess Absicherung wĂ€re fĂŒr mich keine Lösung da mehrere Autore mit dem Blog beschĂ€ftigt sind.

    Da die letzte Kommentare schon ĂŒber ein Jahr alt sind hoffe ich, dass ein oder anderer eine aktuelle Lösung vorschlagen kann.

Kommentare sind geschlossen.