Beteilige dich an der Diskussion

  1. Was ich mal in Benutzung hatte hieß „Login Lockdown“, fanden die Mitautoren eher nervig, weil ein Login generell erst beim zweiten Versuch funktionierte.
    Google Authenticator finde ich persönlich zu umständlich, wenn man sich mal schnell von unterwegs einloggen möchte…

  2. Hi,
    Wie bei allem muss auch hier ein guter Mittelweg zwischen Sicherheit und Usability gefunden werden.
    Als zufriedenstellende Lösung hat sich meiner Erfahrung nach eine Kombination aus sicherem Benutzername & Passwort und limitierung der Loginversuche etabliert. Lösungen mit .htaccess o.ä. fanden fast all meine Kunden zu umständlich.

    Grüße
    Jens Hetke

  3. ich hatte als das mit den Bruteforce Attacken losging auch zunächst die Login Versuche limitiert. War aber eher um zusehen, wieviele Attacken so protokolliert werden. Die Bots wechseln nämlich die IP – was das ganze dann umgeht. Aber so auf 1700 Einlog Versuche kam ich dann pro Tag.
    Wirkliche Abhilfe schafte nur die htaccess – lösung die sehr einfach zu realisieren ist.
    Danach gab es keinerlei LogEinträge mehr via “Limited Login Attempts”.

  4. Bin momentan nur mir Nr.1 und 2. unterwegs. Sicher ist das schon nur sind die größten Lücken in unsauberen Plugins vorhanden.

  5. Mit „Lockdown WP“ kann man auch die Login-URL ändern. Unter /wp-login.php kommt dann eine „404 not found“. So kann man sich nur einloggen, wenn man auch die geheime URL kennt. Außerdem sollte man auf jeden Fall den admin Account löschen. Alle Angriffe, die ich bisher gesehen habe, gingen immer auf den admin Account.

  6. Manchmal sind Login-Erschwernisse aber auch nicht möglich oder sogar kontraproduktiv (zB Community-Sites, etc.). Dann kann man natürlich dem Problem mit IP-Sperren begegnen und Bösewichte auf Serverebene bereits abweisen. Das erfordert allerdings sehr viel Arbeit und Mühsal. Wer sich beides nicht antun will, kann gerne auf meine immer wieder aktualisierte Liste, die ich aus Brute-Force-Loginversuchen auf mehreren WP-Installationen erstelle, zugreifen.

    Ich nenne diese Liste passenderweise die WordPress Brute Force Hall of Shame ;-)

    1. E.

      Super Link. Danke Michel :)
      Macht das die .htaccess. eigentlich „schwer“? Also lädt die Site dann langsamer?

  7. Guter Artikel, habe mir schon länger sorgen um die Sicherheit meiner Blogs gemacht.
    Ich habe allerdings den Fehler gemacht den Hauptuser Admin zu nennen, bekomm ich den noch weg? Und wenn ja, wie ? Ich denke eher das es nicht geht, DEN USER überhaupt, so einfach zu löschen.

    Danke für den Beitrag. Wenn jemand ne idee hat, was ich machen könnte, einfach kontaktieren. :)

    1. @Lukasz Piasecki: Es gibt 2 Möglichkeiten, den Benutzernamen nachträglich zu ändern. Entweder kannst du den Login direkt in der Datenbank (über phpMyAdmin) anpassen, hier eine Anleitung dazu: „Benutzername in WordPress nachträglich ändern“ oder du legst einen neuen Account mit Admin-Rechten in WordPress an und überträgst dann alle Artikel und Seiten beim Löschen des alten „admin“-Accounts an den neu angelegten Nutzer.

      Hier im WordPress Deutschland Forum findest du auch noch einmal einen Thread dazu.

      Grüße, Ellen

    2. ich würde Ellens zweite Variante favorisieren. Die Erste mit den Datenbank Eingriffen finde ich nicht fehlertollerant genug. Einen weiteren Admin anlegen als dieser dann anmelden und den anderen „admin“ dann löschen.

  8. Ich las letztens was von einer schönen Methode, die ich jetzt zusätzlich zu einem starken Passwort und der Limitierung der Versuche einsetze: Mein Admin-Account hat einen anderen Namen und es gibt einen „gefälschten“ Admin-Account unter dem „admin“, dieser hat aber nur Abo-Rechte.

  9. Mac

    Eine .haccess sollte einem die Sicherheit wert sein. Einen guten Hoster (ich bin seit über 12 Jahren bei dF), der die DB und die Webpräsenz mehrmals sichert und man hat weniger Probleme.

  10. Volker

    Weitere Maßnahmen:

    1. nie unter dem Admin-Account schreiben oder diesen auf der Seite erwähnen, damit unbekannt ist, wie der Login des Admin ist.

    2. bei kleinen Blogs, mit nur einem oder zwei eingerichteten Usern (die man ja mit der Domain + angehängtem „/?author=x – also z.B. musterdomain_de/?author=1 – auslesen kann), ist einem Angreifer klar, dass nur einer davon der Admin sein kann.

    Man könnte viele „Fake-Accounts“ mit minimalen Rechten anlegen um das zu erschweren.
    Und man könnte den Admin-Namen aus einer Mischung aus Groß- und Kleinbuchstaben aufbauen, um einen Angreifer einen zusätzlichen Stolperstein einzubauen. Also statt alessandro eher aLessAnDRo

    Habe ich gefunden auf:
    http://www.123-blog.de/allgemein/tipps-fur-sichere-usernamen-in-wordpress

    1. Eine Idee dazu:
      User 1 – als admin benennen, lediglich Leserechte
      User 2 – irgendeinen Namen, Leserechte
      User 3 – benennen, Leserechte und löschen
      User 4 – benennen, Leserechte und löschen
      User 5 – benennen, Leserechte und löschen
      User 6 – benennen, Leserechte
      User 7 – benennen, Leserechte
      User 8 – benennen, Leserechte
      User 9 – benennen, Redakteuer
      User 10 – benennen, Leserechte und löschen
      User 11 – benennen, Leserechte und löschen
      User 12 – benennen, Admin
      Wer nun mit Deinem Trick den Admin sucht, und bei 3,4,5,10 und 11 nichts findet, hat schnell die Schnauze voll.

  11. stimmt – das ist natürlich auch noch von Vornhinein zu beachten.
    Der Tabellenprefix in der Datenbank sollte auch von dem üblichen „wp_“ geändert sein.

  12. Moin,

    leider wurde das Limit Login Plug-in schon lange nicht mehr aktuallisiert.
    Die Version wird immer noch für WordPress 3.3.2 gelistet.
    Worauf man auch achten sollte, sind die Autorenarchive. Bei mir ist es einmal passiert, dass die Archive bei Google gelistet wurden und man den Usernamen schön deutlich und einfach auslesen konnte.
    Bei der nächsten Attacke, hat der Bot dann auch schön artig den richtigen Usernamen eingetragen. ;)
    Das lockdown wp Plug-in muss ich auch einmal ausprobieren. Gibt es dann keine Probleme mit dem Blog, wenn die wp-admin URL geändert wird?

    1. Andi

      Zum Plugin Limit Login Attempts: Normalerweise sollte man keine Plugins evrwenden, die so lange nicht aktualisiert wurden. In diesem Fall ist das aber egal, da es sich um eine ganz simple Funktion und ein ganz simples Plugin handelt, das nicht aktualisiert werden muss und kein Sicherheitsrisiko darstellt.
      Diesen Hinweis habe ich vom WordPress-Guru Morten Rand-Hendriksen (der laut eigener Aussage dieses Plugin auf all seinen WP-Installationen verwendet) und der sollte es eigentlich wissen. ;-)

  13. Sehr schöner und hilfreicher Beitrag! Neben dem extra Passwort via .htaccess , verändere ich auch immer die Standardrückmeldung vom WP-Login-Fenster, also ob der Name oder das Passwort falsch ist. Bei mir heißt es immer, das war wohl nix :-)

  14. So komprimiert habe ich dieses wichtige Thema noch nirgends dargestellt gesehen -Toll!!

    Eine weitere Möglichkeit besteht darin (so man einen VPS- oder Rootserver hat) WordPress direkt an fail2ban anzubinden.
    Dafür gibt es ein Plugin das Loginversuche direkt in das Serverlog schreibt und die IP dann gleich vom Server über IPtables blockiert wird, was den Vorteil hat das WordPress damit dann nicht mehr behelligt wird = die Severlast zurück geht

    Beste Grüsse, Christian

  15. Danke für die zahlreichen Tipps! Ich verwende zur zeit zusätzlich das Tool Better WP Security, damit kann man auch zb die Login versuche limitieren oder aber auch die Login Seite verstecken – finde ich sehr nützlich, kann man in Artikel vielleicht noch ergänzen. Auch macht das Plugin autmatisierte Database Backups

    1. Das Tool heißt ja mittlerweile iThemes Security. Ich habe den User admin komplett gelöscht und einen neuen Admin, mit ID 12 eingefügt. Nun habe ich iThemes Security installiert, und es sendet Updates an die E-Mailadresse vom längst gelöschten admin. Wie kommt so etwas?

  16. #4 ist m.E. die einzige wirklich sichere Lösung. Alle anderen sind auch nicht schlecht, haben aber den Nachteil, dass die Login-Maske erstmal für Login-Versuche offen im Web steht.

    m.E. sollte eine Login-Maske zu einem CMS-Backend nicht offen im Web erreichbar sein.

  17. Mist, schade das die WordPress App nicht mehr funktioniert, sobald man den Google Authenticator verwendet. Aber die Lösung mit der „Limit Login Attempts“ bringt ja auch schon einiges. Danke!

  18. Danke für den Artikel. :-)
    Diesen werde ich direkt zum Anlass nehmen, und mal die .htaccess-Lösung umzusetzen, denn das scheint für mich die doch die Lösung zu sein die für mich persönlich am besten ist.

  19. Martin

    Danke für die tollen Tipps :-)
    Hatte die Tage wieder einmal einige Attacken auf meinen Blog. Mit den entsprechenden Tools und diversen Sicherheitsmaßnahmen, wie z.B. das Ändern des „admin“ fühlte ich mich eigentlich bis jetzt ganz sicher. Zu meinem Erstaunen musste ich bei den fehlerhaften Login-Versuchen feststellen, dass diese mit dem richtigen Benutzernamen durchgeführt wurden!? Wie hat der Angreifer diesen herausgefunden? Nach etwas suchen im generierten Quellcode der Seite, habe auch den Hinweis bekommen…dieser steht dort drin und zwar beide, der öffentliche Name, sowie der richtige Benutzername :-(

    Gibt es eine Möglichkeit oder ein Plugin um diesen aus dem generierten Quellcode zu entfernen? Denn so hat es doch jeder Angreifer leicht, wenn die Seite nicht, bzw. keine weitere Autoren hat, den BN des Admins herauszufinden!

    1. Du hast recht und ich bin entsetzt! Was bringt der ganze Aufwand, wenn man die Umgehung geradezu auf dem Silbertablett präsentiert bekommt.
      Google ist ein guter Kumpel von mir, den frage ich mal, ob er ne Lösung hat.
      Dank Dir!

  20. Kann mich einfach nicht in meinen Blog ohne Authenticator einloggen.
    Von einem Tag auf den anderen, ging nichts mehr.
    Meines wissens hab das Tool auch nicht als Google Plugin heruntergeladen, kann aber sein, da ich ein gmail Account hatte mein Blog sich Google vernetzte?
    Versuch seit Stunden mit den Zwei.Scritten Anleitung das wieder in alte Bahnen zu lenken.
    Hier mein ProtesstPosting an Google das auch auf Facebook gesendet wird.

    Ihre Eklärungen sind wie eine Ratte die sich selber versucht Ihren Schwanz abzubeißen, denn Google ist die Partei und die Partei hat immer recht!
    So hiess das Lied der EX-SED aus der DDR!

    In meinem Fall kann ich durch den nicht funktionierenden Authenticator, mich nicht mehr auf meinen WordPress-Blog einloggen, es wurden mir auch keine SMS mit Code gesendet, aber sowohl für mein Ex-Email Konto Raddatz.Fritz@googlemail.com

    Was Sagen Sie nun dazu?

    ZUm Glück für Sie ist http://www.freddys-corner.com noch nicht im verdienen.

    Sonst würde das für Google verdammt Teuer werden.

    Sie haben schon genug Trouble durch Ihre BIG BROWSER Watching You Allyren

    erzeugt.

    Versuch schon seit etlichen Stunden, Ihr angeblich so leicht umzusetzende Zwei-Schritte-Deaktivierung, in die Tat um zu setzen.

    Darüber sollten Ihre am Markt, vorbei programmierenden Software Entwickler mal nachdenken.

    Hoffe das ist jetzt klar und unmissverständlich bei Ihnen angekommem???

    Fritz Raddatz/Freddysblog

  21. Dave

    Interessant und gute Tipps. Wenn ich aber die Variante mit .htaccess mache, kommt ja diese Abfrage auch bei einer WordPress Seite mit Passwortschutz. Also ich muss erst das Passwort eingeben und dann kommt das Fenster mit der .htaccess Abfrage. Das ist ja dann eher unpraktisch. Was könnte man da machen?

  22. Moin Ellen,
    vielen Dank für die zahlreichen Hinweise. Ich habe den wp-admin Bereich jetzt per .htaccess geschützt. Das PHP-Script zum feststellen des Pfads zur .htpasswd Datei ist super. Daran ist es bei mir zuvor nämlich immer gescheitert. :-)

  23. Auch ich habe über die htpasswd meinen Login-Bereich doppelt abgesichert. Auch wenn es mir etwas schwer gefallen ist, bis ich den korrekten Pfad herausgefunden habe. Die Login-Versuche zusätzlich mit dem Plugin „Limit Login Attempts“ abzusichern, wäre sicher sinnvoll. Allerdings scheint mir dieses Plugin nicht mehr gepflegt zu werden. Das letzt Update war im Sommer 2012. Hat jemand eine bessere Idee für ein leichtgewichtiges Plugin, um die Login-Versuche zu begrenzen?

    1. Andi

      Normalerweise empfehle ich keine Plugins, die mit der Warnung „This plugin hasn’t been updated in over 2 years. It may no longer be maintained or supported and may have compatibility issues when used with more recent versions of WordPress.“ versehen sind.
      In diesem Fall ist das aber egal, da es sich um eine ganz simple Funktion und ein ganz simples Plugin handelt, das nicht upgedated (hübsches neudeutsches Wort, oder? ;-) werden muss und kein Sicherheitsrisiko darstellt.
      Diesen Hinweis habe ich vom WordPress-Guru Morten Rand-Hendriksen (der laut eigener Aussage dieses Plugin auf all seinen WP-Installationen verwendet) und der sollte es eigentlich wissen. ;-)

  24. Adam

    Habe einen Internal Server Error, wenn ich versuche mich einzuloggen.. Jemand eine Idee woran es liegen kann?

  25. Super Artikel, Ellen!
    Habe die httaccess-Lösung eingebaut, denn das erscheint mir die sinnvollste gegen diese Angriffe, die von wechselnden IPs kommen.

    Hier habe ich nur ein Problem festgestellt:
    Wir betreiben einen woocommerce-Shop. Der Login funktioniert gut. Nur, wenn der Kunde den Logout möchte, wird er auch nach dem Security-Login gefragt. Da er diesen nicht hat, wird er nicht ausgeloggt.
    Was macht man denn da?

    Danke,
    Konstantin

  26. Vielen Dank für die vielen Tipps.

    Doch was bringen Begrenzung der maximalen Login-Versuche und – was man auch überall und immer wieder liest – das Sperren von IPs über die .htaccess wirklich? Wenn ich mir einige dubiosen Zugriffe am meiner Seite so ansehe, erkenne ich mehrmals im Monat etwa 20-60 Zugriffe zur selben Zeit, jedoch über 20-60 Städte weltweit verteilt. Das sieht doch ziemlich eindeutig nach Hackern aus, welche sich über Bot-Netzwerke Zugriff zu verschaffen versuchen. Die Master dahinter bedienen sich dann doch eh immer wieder anderer PC aus anderen Städten, über welche dann die eigentlichen Loginversuche gestartet werden. Man korrigiere mich bitte, sollte ich das falsch interpretieren.

    Da bringt die Begrenzung der maximalen Login-Versuche rein gar nichts, und die IP-Sperren via .htaccess machen die Seite leider nur lahm. Vor allem dann, wenn man diese Methode aktuell zu halten pflegt. Ich habe es bereits versucht, die .htaccess stiegt auf eine beachtliche Größe an und der Start der Seite rutschte sogleich auf fast 10 Sekunden. Das geht gar nicht.

    Aktuell nutze ich Methode 1 und zugegeben auch 2 (gegen Bots keine Chance, aber sicherlich effizient gegen „Skrip-Kiddies“. Die hier empfohlenen Methoden 3 und 4 halte ich für sehr sinnvoll und werde diese umsetzen. Der Umweg über das Smartphone stört mich nicht. Ich muss nicht so oft in den Admin-Bereich.

    Viele Grüße
    Remo

  27. Moin,

    für mich gibts da nur die Sicherung mit .htaccess und/oder mit dem GooglePlugIn.
    Wie schon oben erwähnt stinkt der Fisch vom Kopf ab nach unten. Es ist schon merkwürdig dass eine so wichtige Datei (wp-login.php) im RootVerzeichnis zu finden ist und nicht etwa in einem extra dafür vorgesehenen Ordner, welchen man mit einem Verzeichnisschutz durch den Server bereits absichern könnte. LoginAttemp=nutzlos und nicht mehr aktualliesiert, der Admin kann – gerade auch in Blogs ausgelesen werden – da bleibt wies gesagt nicht mehr viel.

  28. Hallo Ellen,

    Klasse Anleitung.

    Allerdings komme ich an einem Punkt nicht weiter und ich weiss mir auch nicht mehr zu helfen.
    Ich hab gegooglet und trotzdem nichts befriedigendes gefunden.

    Folgendes Szenario:
    Ich habe die .htpasswd und .htaccess genauso angelegt wie beschrieben, mit dem (hoffentlich) richtigen Pfad (der wurde mir jedenfalls über „how to find the full path…) angezeigt.
    Habe beide Dateien in das Verzeichnis gelegt, wo sich die „wp-login“ befindet und der Admin-Login Bereich ist nun abgesichert aber meine Seite ebenso ;-) und nicht mehr zugänglich. Zumindest funktioniert kein Link oder Unterseite mehr ohne 404 Fehler anzuzeigen, dass die Seite nicht gefunden wurden.

    Die home kann man aufrufen, ansonsten ist alles tot. So bringt mir die Absicherung natürlich nichts.

    Ich hatte heute wieder Attacken. Ich hatte schon mal welche. Dann hab ich so für 1-2 Tage die .htaccess und .htpassw auf dem Server gelassen und dann wieder gelöscht, damit Besucher sich die Seite überhaupt anschauen können.

    Ich weiss nicht mehr weiter. Irgendjemand ne Idee. Vielen Dank schon mal im voraus.

    LG Richard

  29. Johannes

    Ich habe htaccess-Schutz aktiviert und einen einigermaßen komplizierten Benutzer und ein kryptisches Passwort dafür gesetzt. Trotzdem laufen weiterhin Angriffe auf meine Anmeldeseite. Woran kann das liegen?

    1. ja es werde natürlich weiter angriffe auf die Seite gemacht. Aber diese werden immer bei der htaccess ab gewiesen. und so schonst du deinen Server.

      1. Johannes

        Die Anmeldeseite kann ich selbst nur erreichen, wenn ich mich per htaccess anmelde. Wie kann es dann sein, dass (zwar nicht mehr so häufig wie davor) immer wieder Hacker auf der Loginseite landen und versuchen sich mit dem Benutzer admin (den es nicht gibt) am System anzumelden?

  30. Nachdem heute mehrere tausend logins hatte, bin ich auf der Suche nach Abwehr hier gelandet, und möchte schon mal danke sagen. Das Plug-In limited kannte ich bisher nicht.

  31. Tim

    @johannes
    Bei mir war auch einige Tage Ruhe und jetzt kommen die ersten schon wieder durch. Zudem hab ich auch noch die wp-login.php mit einem Plugin umgebogen. So langsam verstehe ich es nicht mehr, wie die es reinschaffen. WP auch neuste Version. Weis jemand woran das liegen könnte?

    1. Johannes

      Hallo Tim

      Ja, es kommt bei mir immer wieder vor, dass ich ungewünschte Login-Versuche habe. Ich selbst muss mich immer authentifizieren. Die Hacker müssen das aus unerfindlichen Gründen nicht. Wozu ist dann dieser Schutz gut, wenn er mir nur die Arbeit erschwert und Hacker nicht hindert. Hat hier noch jemand einen Tipp, wie man den Zugang über htaccess noch sicherer machen kann?

  32. Thomas

    Hallo, ich habe ein Problem mit der zusätzlichen Passwortabfrage per .htpasswd und hoffe auf hilfreiche Tipps zur Lösung dessen. Vielen lieben dank bereits im Voraus.
    Was kann ich machen, wenn ich die zusätzliche Passwortabfrage vor dem Wp-login eingerichtet habe, aber meinen Benutzernamen und das Passwort verloren habe? Wie komme ich als Seitenbetreiber an dieser Abfrage vorbei?

    Vielen Dank und Grüße
    Thomas

    1. Hallo Thomas!
      Log Dich per FTP in das Konto ein, lösch die htaccess, und gut ist. Die Abfrage ist verschwunden.
      Solltest Du die FTP-Zugangsdaten verloren haben, kontaktiere den Provider.
      Gruß!

  33. R

    Sehr guter Artikel, danke. Ein Problem habe ich noch, leider funktioniert die „fullpath.php“ bei mir nicht. Das hat irgendwas mit den Permalinks zu tun. Hat jemand eine Idee, wie ich den Pfad auslesen kann? Ich kann die Datei nicht direkt aufrufen und bekomme von WordPress immer gesagt, die Datei würde nicht existieren.
    Danke und Gruß R.

  34. M.Werner

    Einfach Danke für den Artikel und den Erklärungen.
    Das hilft bei den Überarbeitungen extrem.
    Viele Grüße,
    M.Werner

  35. Danke für die genialen Tipps. Ich habe den vierten Punkt bei mir umgestellt, nun frage ich mich aber, wie ich auf die .htaccess komme, um zu überprüfen, ob ich nun auch wirklich ein Passwort eingeben muss?
    Bin über jede Antwort dankbar.
    Viele Grüße

  36. Nachdem ich es echt satt habe, mich jeden Tag mit Hacker-Angriffen auseinanderzusetzen und die IPs zu blockieren, habe ich mich auf die Suche gmacht und diesen Beitrag gefunden.. ich werde es jetzt mal mit dem Google Authenticator Code probieren, da ich das Smartphone immer am Mann habe =)

  37. Danke für die Übersicht.
    Ich finde es aber wichtig, nochmal zu betonen, dass der Einsatz von allen Methoden gleichzeitig die Usability massiv einschränkt. Wenn ich für jeden Login 5 Passwörter, Captchas und Apps auf dem Smartphone aufmachen muss, ist das natürlich nicht mehr Benutzerfreundlich.
    Ich glaube auch, dass eine bis maximal drei deiner Vorschläge ausreichen.
    Aber um so besser, so kann sich jeder einen passenden Mix zusammenstellen.

    Ich nutze übrigens gerne die Google Authentifizierung. Geht schneller als man meint.

    Viele Grüße

  38. Super Anleitung , haben das mit dem Plugin und der Google Authenticator jetzt drin und funktioniert einwandfrei . Hatten zu sehr viele Attacken bis zu 1500 pro Tag . Was ich jeden raten kann die Vorschläge von WP Passwort anzunehmen . Die Passwörter sind zwar super lang aber auch sehr Stark .

  39. Hallo,

    super Artikel!

    Ich habe eigentlich fast alles was geht installiert. Google reCaptcha, Securi Sicherheit, Limit Login Attempts, immer alles auf dem neusten Stand. Und jetzt auch noch die zwei Wege Authentifizierung. Htaccess kommt leider nicht in Frage, da ich damit die User aussperre. Mein Passwort ist ziemlich lang und relativ sicher würde ich behaupten. (Zahlen / Sonderzeichen / immer ein anderes bei meinen Projekten) Der Admin heißt nicht admin. Dennoch versucht Jemand Zugriff zu bekommen seit Gestern.

    Aber was mache ich jetzt gegen die BruteForce Attacken? Ich hab ca. 3.000-4.000 Zugriffe auf die wp-login am Tag. Hat Jemand eine Idee?

    Meint ihr es hilft etwas per htaccess nur bestimmte Länder auf die wp-login zu lassen?

    Wie lange hält das ein Webserver aus ohne Performance einzubußen? Wie hartnäckig bleiben die Betreiber solcher Attacken?

    Ich habe kurz vor dem Angriff das Plugin Social Login aktiviert (Da ich vermehrt über Social Media geworben habe und die Hemmschwelle für Registrierungen senken wollte), wo man aber ganz umfangreich über die Facebook und Google API über die Firma AllOne geht. Könnte das die Eingangstür gewesen sein?

    Was würdet Ihr jetzt noch machen?

    LG
    Ronny

  40. Inzwischen ist eine Menge Zeit vergangen… Die Probleme bleiben dieselben. Ich setze das aktuelle Plugin „Limit Login Attempts Reloaded“ ein, was gegen manuelle Hackversuche zuverlässig ist. Die Bot-Skripte wechseln bei ihren Serien-Attacken allerdings nach Belieben die IP-Adressen, so dass man da immer nur für wenige Augenblicke etwas blockieren kann. Ich beobachte fast immer Attacken-Sitzungen, die mehrere Stunden dauern, aber nicht permanent bei meinem Blog anklopfen, sondern immer wieder zu pausieren scheinen. Ich vermute, dass diese Skripte ganze Serverschränke rotierend nach zugänglichen WordPress-Installationen durchsuchen. Die meisten Blogs werden ja auf großen Providerservern „massengehostet“.

    Das Zweite ist, und das erstaunt mich tatsächlich, dass diese Skripte sich offensichtlich überhaupt nicht für meinen .htaccess-Schutz vor der wp-login.php interessieren. Der funktioniert zuverlässig, wie ich immer wieder manuell ausprobiere. Die Botskripte gelangen trotzdem zum WordPress-Login und werden erst vom Plugin abgefangen. (Und sie schaffen mit Sicherheit nicht die Überwindung der Usernamen/Passwort-Abfrage de .htaccess-Lösung)

    Ich frage mich also, wie diese Skripte diesen Schutz unterlaufen oder umgehen?

    Beim Versuch, das herauszufinden, bin ich übrigens hier auf diesem Artikel gelandet. Ich forsche weiter… ;-)

    1. Johannes

      Hallo Boris

      Mit diesen Ergänzungen in der .htaccess konnte ich bei mir die Vielzahl an Angriffversuchen trotz Verzeichnisschutz beenden:

      AuthType Basic
      AuthName „Sicherheitsbereich“
      AuthUserFile /dein-serverpfad/html/.htpasswd
      Require valid-user

      # Zugriff verweigern

      Order deny,allow
      Deny from all

      # Konfigurationsdatei schützen

      Order allow,deny
      Deny from all

      # Schnittstelle abstellen

      Order Deny,Allow
      Deny from all

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.