Diesen Artikel wollte ich schon sehr lange schreiben, denn ich denke es wird von vielen WordPress-Nutzern immer wieder unterschätzt, wie wichtig die Absicherung des eigenen WP-Logins ist. Durch sogenannte Brute Force Angriffe (mehr Info über Brute Force-Angriffe) kommt es immer wieder vor, dass die Logins von WordPress-Seiten gezielt angegriffen werden.
Dadurch kann die Erreichbarkeit der Webseite massiv eingeschränkt werden, weil der Server durch die zahlreichen Angriffe überlastet wird und wenn der Login nicht ausreichend gesichert ist, kann es im schlimmsten Fall sogar passieren, dass die eigene WordPress-Seite gehackt wird. Doch es gibt glücklicherweise hilfreiche WordPress-Plugins und Vorsichtsmaßnahmen, um dies erfolgreich zu verhindern.
1. Ein sicheres Passwort wählen
Der erste und einfachste Schritt ist, einen sicheren Benutzernamen und ein sicheres Passwort für den WordPress-Login zu wählen. Auf keinen Fall sollte der Benutzername „admin“ sein. Da dies sehr lange der Standard-Benutzername für WordPress-Seiten war, ist dieser Benutzername besonders unsicher.
Für ein sicheres Passwort kannst du entweder einen Passwort-Manager nutzen oder ein Password aus einer zufälligen Anordnung von Wörtern erstellen. Im Artikel über sichere WordPress-Passwörter auf WordPress.com findest du jede Menge hilfreiche Tipps und Tools.
2. Die Anzahl der Login-Versuche einschränken
Standardmäßig ist die Anzahl der Login-Versuche bei WordPress uneingeschränkt. Das ist natürlich ein weiteres Sicherheitsrisiko, dass du mit Hilfe des Plugins „Limited Login Attempts“ leicht in den Griff bekommen kannst. Das Plugin erlaubt es dir, die Login-Versuche pro IP-Adresse auf z.B. 3 mögliche Versuche zu begrenzen. Wird diese Anzahl überschritten, wird die IP-Adresse für eine bestimmte Zeit (der Zeitraum kann in den Plugin-Einstellungen selbst gewählt werden) vom Zugriff auf deine WordPress-Seite gesperrt.
3. 2-Fach Authentifizierung mit dem Google Authenticator
Noch weitere Sicherheit bietet die zusätzliche Authentifizierung in zwei Schritten, die du mit Hilfe der Google Authenticator-App und des Google Authenticator WordPress-Plugins leicht einrichten kannst. Das ganze funktioniert so, dass du bei jedem Login nicht nur dein WordPress-Benutzernamen und dein Passwort, sondern auch einen zusätzlichen Google Authenticator Code eingeben musst, der immer wieder neu über die Google Authenticator-App generiert wird.
Diese Methode setzt also voraus, dass Du dein mobiles Device (Smartphone oder Tablet) immer zur Hand hast, wenn du im WordPress-Admin arbeiten möchtest. Das ist zwar etwas aufwendiger, bietet aber einen sehr sicheren zusätzlichen Schutz vor Login-Angriffen.
Die Einrichtung ist mit dem WordPress-Plugin „Google Authenticator“ ganz einfach. Nach der Plugin-Installation und dem Download der Google Authenticator-App (Android-App, iOS App) kannst du einfach den Barcode in den WordPress Plugin-Einstellungen nutzen, um das Plugin mit deiner App zu verknüpfen. Wenn du jetzt die Google Authenticator-App öffnest, wird dir der Login-Code für deine WordPress-Seite in zeitlichen Abständen immer wieder neu generiert und du kannst den Code in deinem WordPress-Loginscreen eintragen.
Du kannst über die App natürlich auch für mehrere Webseiten und Dienste die 2-Fach Authentifizierung einrichten.
4. Ein extra Passwort über die .htaccess Datei einrichten
Für alle, die über den Zugang zur .htaccess Datei verfügen, gibt es auch noch die Möglichkeit ein zusätzliches Passwort über die .htaccess Datei einzurichten. Das hat den Vorteil, dass der eigentliche WP-Login erst gar nicht aufgerufen werden kann, Brute Force-Angriffe also bereits vor dem eigentlichen Angriffsversuch abgeblockt werden können. Das schont die Aufrufe auf deine WordPress-Seite natürlich massiv und die Erreichbarkeit der Webseite bleibt auf jeden Fall immer gewährleistet.
Die Einrichtung eines .htaccess Logins ist auch gar nicht so kompliziert. Du benötigst lediglich Zugang zu deiner .htaccess Datei über deinen FTP-Zugriff (das ist leider nicht bei allen Hosting-Angeboten möglich) und einen Code-Editor, um die .htaccess zu bearbeiten und eine neue .htpasswd Datei (diese Datei enthält dein Passwort) zu erstellen.
.htaccess Passwort- So funktioniert’s
Als erstes musst du und über deinen FTP-Zugriff eine neue, leere Datei mit dem Namen .htpasswd im Hauptverzeichnis deiner Webseite (also da, wo sich auch bereits die .htaccess Datei befinden sollte) erstellen.
Die neue, noch leere Datei lädst du dir dann lokal auf deinem Computer herunter und öffnest sie in einem Code-Editor. Mit Hilfe des Online htpasswd Generators kannst du jetzt ein Benutzername und Passwort eingeben und den Inhalt für die .htpasswd Datei erstellen.
Jetzt musst du noch den Code für die .htaccess Datei erstellen. Dazu kannst du diesen Code kopieren, du musst allerdings noch deinen eigenen AuthUserFile-Pfad zu deiner .htpasswd Datei ermitteln und im Code ersetzen. Um den Pfad herauszufinden, kannst du die Anleitung „How to find the full path to a file using PHP“ und den Code auf der .htaccess Tools-Webseite nutzen.
[code]
<Files wp-login.php>
AuthType Basic
AuthName "My Protected Area"
AuthUserFile /path/to/.htpasswd
Require valid-user
</Files>
[/code]
Wenn du den Code in die .htaccess Datei eingefügt hast und auch die neue .htpasswd Datei mit deinem Code in das Hauptverzeichnis deine Webseite hochgeladen hast, sollte jetzt die Passwort-Abfrage im Browser erscheinen und deinen Login so zusätzlich schützen.
Eine ausführliche Beschreibung der Einrichtung eines .htaccess Passwortes für deine WordPress-Seite findest du außerdem im Artikel „Initiative: Mehr Sicherheit für WordPress durch den Admin-Schutz“ auf dem ebiene Playground-Blog.
Fazit
Wie du siehst, gibt es also wirklich einiges was man tun kann, um den eigenen WordPress-Login vor unerlaubten Zugriffen zu schützen. Welche Tipps, Tools und Anleitungen kennst du noch, die hilfreich bei der Absicherung von WordPress-Seiten sind? Über dein Feedback und deine Tipps freue ich mich sehr!
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…
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
Danke für den Artikel. :-)
Diesen werde ich direkt zum Anlass nehmen, endlich mal die .htaccess-Lösung umzusetzen.
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”.
Bin momentan nur mir Nr.1 und 2. unterwegs. Sicher ist das schon nur sind die größten Lücken in unsauberen Plugins vorhanden.
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.
Oder besser als das, per Einsicht in die Datenbank schlicht umbenennen. :-)
die einfachsten schutz-maßnahmen sind ein sicheres passwort, regelmäßiges updaten und ein secure-login-plugin, habe erst gestern auch einen kleinen artikel darüber gepostet…
http://siegmargebele.com/2014/01/11/tipps-zu-wordpress-und-sicherheit
deinen post werde ich gleich noch da verlinken, v.a. das mit dem .htaccess-passwort scheint mir eine gute, zusätzliche maßnahme… ;)
best°siggi
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 ;-)
Super Link. Danke Michel :)
Macht das die .htaccess. eigentlich „schwer“? Also lädt die Site dann langsamer?
Ja!
2-FACH AUTHENTIFIZIERUNG hätte ich auch gerne im Einsatz. Jedoch funktioniert dann die WordPress App nicht mehr.
Danke für deinen Beitrag !
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. :)
@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
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.
Ich verwende immer das Plugin Better WP Security in Kombination mit BackWPUp. Super Backups für den Notfall und Better WP Security bietet neben Login Limits noch viele viele weitere Optionen
http://wordpress.org/extend/plugins/better-wp-security/
http://wordpress.org/plugins/backwpup/
Ich nutze auch diese beiden Plugins und kann sie sehr empfehlen!
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.
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.
+ t
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
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.
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.
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?
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. ;-)
Danke für den hilfreichen Beitrag, den Google Authenticator werd ich mir wohl gleich mal zulegen.
Vielen Dank! Habe umgehend den Google Authenticator installiert.
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 :-)
Also ich finde die Variante mit der .htpasswd recht interessant und werde das mal auf ein paar Seiten testen.
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
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
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?
#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.
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!
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.
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!
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!
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
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?
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. :-)
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?
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. ;-)
Habe einen Internal Server Error, wenn ich versuche mich einzuloggen.. Jemand eine Idee woran es liegen kann?
Sorry, jetzt funktionierts! Danke für die Anleitung!
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
wäre super, wenn jemand hier eine Lösung hätte. Finde leider keine Möglichkeit, die dauerhaft funktioniert.
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
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.
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
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?
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.
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?
Super, genau danach habe ich gesucht. Ich hatte mir die Zähne ausgebissen, um den richtigen Pfad zu finden.
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.
@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?
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?
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
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ß!
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.
Einfach Danke für den Artikel und den Erklärungen.
Das hilft bei den Überarbeitungen extrem.
Viele Grüße,
M.Werner
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
Hi,
dein hinterlegter Link http://playground.ebiene.de/initiative-wordpress-sicherheit/ zum Punkt „Initiative: Mehr Sicherheit für WordPress durch den Admin-Schutz“ führt zu einer 404. Nur als kleine Info. ;)
Liebe Grüße
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 =)
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
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 .
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
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… ;-)
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