WordPress sicherer machen – ohne Plugins
Letztens schrieben einige Blogger (darunter auch ich) über das Plugin namens Limit Logins Attempts. Der Beitrag in Kurzform: die Möglichkeit den Administrationsbereich von WordPress gegen zu häufige falsche Eingaben von Benutzernamen und Kennwort absichern. In den Kommentaren hieß es unter anderem, dass es einfacher wäre den Administrationsbereich durch eine .htaccess-Authentifizierung abzusichern. Klingt kompliziert sofern man das erste Mal davon liest – und auch die Möglichkeiten sind vielfältig. Wie einfach das allerdings im Falle eines Blogs sein kann, werde ich hier einmal versuchen zu erklären. Zum Mitmachen quasi.
Ich fange jetzt nicht beim Urschleim an und werde jede Kleinigkeit der .htaccess-Datei erzählen – zumal ich eh nicht alles weiß. Der geneigte Freund des gepflegten Verzeichnisschutzes kann sich ja gerne hier schlau lesen.
Ziel dieser Aktion: Absichern des Administrationsbereich von WordPress durch einen zusätzlichen Schutz. Statt des WordPress-Logins erscheint eine vom Server gestellte Abfrage, bei der man sich authentifizieren muss bevor man zur Loginmöglichkeit gelangt.
Wie funktioniert es? Quasi ganz einfach – denn im Netz gibt es eine Vielzahl von Generatoren, die es euch ermöglichen automatisiert eine .htaccess-Datei zu erstellen. Zwei Dateien sind zur Absicherung nötig – einmal die Datei .htacess für den Sicherungsaufruf als solches und die Datei .htpasswd, die euren Benutzernamen und das Passwort enthält. Logischerweise sollte dieses Passwort ungleich zu eurem WordPress-Passwort sein 
Benutzer von Windows sollten sich nicht wundern wenn sie diese Dateien nicht erstellen können – Windows erlaubt diese Dateinamen nicht. Ihr müsst also erst die Dateien ohne den Punkt am Wortanfang erstellen – das Umbenennen könnt ihr mit eurem FTP-Programm auf eurem Server machen.
Was ist noch wichtig zu wissen? Ihr müsst den absoluten Pfad des WP-Admin-Ordners auf eurem Webserver herausbekommen. Dies ist aber in keinster Weise kompliziert. Erstellt im Rootverzeichnis eures Blogs einfach eine PHP-Datei (zum Beispiel Serverinfo.php) mit folgende Inhalt:
<?
PHPINFO();
?>
Ruft ihr nun diese Datei im Webbrowser auf, so verrät dieser euch einige Infos. Auch eben den absoluten Pfad von wo das Script ausgeführt wurde. Sofern es sich um einen Apache-Server handelt wird euch der Pfad unter SCRIPT_FILENAME verraten:
Diesen Pfad erweitert ihr nun um /wp-admin – das wäre dann der absolute Pfad zu eurem WP-Admin-Ordner. Kopieren und merken 
Begebt euch nun auf diese Seite, gebt den gewünschten Benutzernamen nebst Passwort ein – dazu den eben herausgefundenen absoluten Pfad.
Mit einem Klick auf “Generate .htaccess” werden die Inhalte für die beiden Dateien erstellt.
Übernehmt die Inhalte in eure Dateien und speichert die Änderungen ab. Die Dateien .htaccess und .htpasswd müssen nun ins WP-Admin-Verzeichnis eures Servers.
In Zukunft werdet ihr nach einem Benutzernamen und einem Passwort gefragt (siehe erster Screenshot) – sofern ihr in euer WordPress-Dashboard wollt. Ob ihr dieses in eurem Browser speichert bleibt euch überlassen. Beachtet bitte dass die .htaccess den chmod 0644 hat.
Dieser Beitrag ist übrigens nur ein kleiner Anriss dessen, was mit mit .htaccess machen kann. Ich erhebe hier keinen Anspruch auf Vollständigkeit. Wer mehr wissen will der darf sich gerne schlau machen =)
Nachtrag: Michael meint, dass man zwei Verzeichnisse ausklammern sollte, da aus diesen Ordnern Dateien bei fehlerhaften Kommentaren nachgeladen werden. Erstellt eine .htaccess mit folgendem Inhalt:
Order Deny,Allow
Allow From All
Satisfy Any
Diese .htaccess kommt dann jeweils in wp-admin/images und wp-admin/css.
Nachtrag 2: Alternativ kann man auch in obige .htaccess diesen Code einsetzen :
<Files ~ "\.(png|gif|css)$">
Order allow,deny
Allow from all
</Files>
Somit erlaubt man den Zugriff auf die benötigten Dateien. Auch hat man den Vorteil, dass nur eine .htaccess benötigt wird. Danke lordfiSh.
Artikel per RSS-Feed
Caschy bei Google+
Caschy bei Twitter
Caschy bei Facebook
Caschy bei XING
Caschy bei YouTube
49 Kommentare zu “WordPress sicherer machen – ohne Plugins”
lordfiSh sagt
Problem an der Sache: Es können sich keine normalen Nutzer (Subscriber) mehr einloggen
Kommentar am 25. Januar 2009 um 20:21 geschrieben.
LuNeX sagt
Ich erlaube mir mal 2 Hinweise:
Vor einiger Zeit habe ich mal eine Anleitung geschrieben zu “Erstellen eines geschützten Verzeichnisses mit htaccess” link text. Auch wenn es nicht, wie bei Caschy üblich eine keine Freeware ist (ich kenne keine) kann man mit DA-HtAccessManager (€14,99EUR)link textseine Benutzernamen und Passwörter im Überblick behalten und verwalten.
@Caschy bitte den/die Links löschen falls nicht akzeptabel hier.
Kommentar am 25. Januar 2009 um 20:33 geschrieben.
Roman sagt
Sehr wichtig: Die htpasswd sollte in einem von außen nicht-zugänglichen Ordner liegen, sonst lassen sich auch diese Kennwörter entschlüsseln.
Kommentar am 25. Januar 2009 um 20:33 geschrieben.
Michael sagt
@ Lordfish: Die haben ja auch nix im Admin-Bereich verloren.
Den Admin-Bereich per HTTP-Authentifizierung zu schützen, sollte bei jedem frisch aufgesetzten CMS zu den ersten Schritten gehören. Gerade auch unter dem gern gehackten Joomla erste Adminpflicht.
Kommentar am 25. Januar 2009 um 20:35 geschrieben.
caschy sagt
@Michael, ich denke lordfiSh will darauf aufmerksam machen, dass ich keine Leute mehr in ein Blog einloggen können. Naja, in einem “normalen” Blog meiner Meinung nach eh Humbug – und bei einem Multi Autor Blog haut man die Autoren mit rein =)
Kommentar am 25. Januar 2009 um 20:41 geschrieben.
Sebastian sagt
Ohne Spaß: Ich hab wirklich gelacht, als ich “ohne den Punk am Wortanfang erstellen” gelesen hab. Dachte, das muss so.
Kommentar am 25. Januar 2009 um 21:23 geschrieben.
caschy sagt
Joa, sowas passiert mir Anarchisten schon manchmal
Kommentar am 25. Januar 2009 um 21:27 geschrieben.
Michael sagt
Caschy, gib mal einen fehlerhaften Kommentar bei dir ab! Ups.
Lösung: Eine Ausnahme in wp-admin/images und wp-admin/css a la
Order Deny,Allow
Allow From All
Satisfy Any
in Form einer eigenen .htaccess
Kommentar am 25. Januar 2009 um 21:49 geschrieben.
caschy sagt
@Michael: ich nehme das mal mit Verweis auf dich auf.
Kommentar am 25. Januar 2009 um 21:51 geschrieben.
Michael sagt
Aber gerne doch!
Kommentar am 25. Januar 2009 um 21:56 geschrieben.
caschy sagt
(x) Done =)
Kommentar am 25. Januar 2009 um 21:58 geschrieben.
Filzo sagt
Vielleicht sollte man noch erwähnen, dass die Lösung nur für den Apache funktioniert
Kommentar am 25. Januar 2009 um 22:36 geschrieben.
lordfiSh sagt
dann lieber so
Order allow,deny
Deny from all
dann brauch man nur eine .htaccess
/edit: zeigt nicht alles an: http://nopaste.biz/63472
Kommentar am 25. Januar 2009 um 22:41 geschrieben.
Michael sagt
Stimmt, das geht natürlich auch und ist noch nen Tick eleganter!
Kommentar am 25. Januar 2009 um 22:45 geschrieben.
caschy sagt
Tatsache.
Kann ja einfach in die einzelne htaccess rein =)
Kommentar am 25. Januar 2009 um 22:47 geschrieben.
Puh (
@Puh) sagt
Herzlichen Dank!
Ich habe schon länger einen Verzeichnisschutz per .htaccess auf meinem Adminbereich, aber mir war bislang nicht bewusst, dass ich die zwei Verzeichnisse wp-admin/images und wp-admin/css vom Schutz ausnehmen muss.
Kommentar am 26. Januar 2009 um 01:41 geschrieben.
Puh (
@Puh) sagt
@lordfish
Wenn ich das in meine /wo-admin/.htacces schreibe, dann wird mein Adminbereich nicht richtig angezeigt. Ich mach das lieber mit dem Code von Michael in 2 weiteren .htaccess-Dateien
Kommentar am 26. Januar 2009 um 01:48 geschrieben.
caschy sagt
@Puh:
Liegt an dem DENY.
Kommentar am 26. Januar 2009 um 07:18 geschrieben.
Enrico sagt
Ich möchte dann auch noch einmal einen Punkt erwähnen, der gegen die Authentifizierung spricht: es ist für Bots immer noch ein leichtes, via Bruteforce Benutzername und Passwort beliebig oft zu erraten, da htaccess keine Beschränkung der Fehlversuche vorgibt.
Beim Login muss lediglich eine Base64 verschlüsselte Zeichenfolge mit an den Server gesendet werden. Die htpasswd sollte übrigens besonders geschützt werden (wurde ja schon erwähnt), da die anscheinend kryptischen Informationen sehr leicht auch wieder entschlüsselt werden können. – Kann ja eben nicht alles MD5 sein ^^
Kommentar am 26. Januar 2009 um 08:09 geschrieben.
caschy sagt
@Enrico:
Es handelt sich ja hierbei nicht um den einzigen Schutz – sondern um einen Zusatz =)
Kommentar am 26. Januar 2009 um 08:10 geschrieben.
Havoc sagt
Alternativ:
Die Anleitung ist zwar für Joomla aber man kann es auch für andere Sachen benutzen.
http://www.schroeder-frank.net.....#038;id=42
Kommentar am 26. Januar 2009 um 09:34 geschrieben.
Dirk Paehl (
@dpaehl) sagt
Nachtrag 2 Klappt bei mit mit dem Login auch nicht. Das Problem ist das die beiden CSS
link rel=’stylesheet’ href=
Stehen an Zeile 5 und 6
Diese müßte man anderweitig verlagern. Habe aber noch nicht gefunden wo man das wieder ändern müßte das es klappt.
Aber so klappt es eben nicht
Kommentar am 26. Januar 2009 um 09:43 geschrieben.
Sergej Müller (
@wpSEO) sagt
Vielleicht auch meine 10 Schritte zum Schutz des Admin-Bereichs in WordPress interessant…
Kommentar am 26. Januar 2009 um 10:30 geschrieben.
Puh (
@Puh) sagt
Danke Sergej, deine Tipps sind wirklich klasse, nur mit Dateien verschieben und Ordner umbenennen wird man doch sicher beim nächsten Update Probleme bekommen, oder?
Kommentar am 26. Januar 2009 um 13:19 geschrieben.
Knollo sagt
Wie soll man bitte schön eine htacces auslesen können, wenn die Inhalte per MD5 verschlüsselt ist???
Wie lange soll das dauern? 2 Jahre?
Kommentar am 26. Januar 2009 um 13:23 geschrieben.
Enrico sagt
@Knollo: Genau das sind sie ja eben nicht. Das ist eine reine Textdatei, die auf dem Server liegt. Die Passwörter in der htpasswd sind Base64 verschlüsselt und leicht knackbar, wenn man sie hat, die User stehen im Klartext drin (siehe Artikel)
Kommentar am 26. Januar 2009 um 13:34 geschrieben.
Knollo sagt
User ja, das ist klar. Na dann viel Spaß:
$1$OTtaBbYh$S7X/Y5yXk6ijknPeScmlg0
Ist NICHT Base64 sondern MD5! Ich geb noch ne Hilfe: Alles Kleinbuchstaben, damit es schneller geht.
Kommentar am 26. Januar 2009 um 13:44 geschrieben.
Ick sagt
Für diesen Sachverhalt gibt es auch ein Plugin für WP, AskApache Password Protect.
Gruß
Ick
Kommentar am 26. Januar 2009 um 13:48 geschrieben.
Sergej Müller (
@wpSEO) sagt
Puh, meinst du das Verschieben der wp-config.php? Ja, da müsste man beim automatischen Update beobachten, ob WordPress genau so schlau wie beim Einlesen der Datei ist und von alleine im höherliegenden Verzeichnis sucht und updatet. Habe damit noch keine Erfahrungen sammeln können.
Kommentar am 26. Januar 2009 um 17:21 geschrieben.
Andi sagt
Wie ist das aber wenn du dein adminmenu per htaccess schützt kannst du dann immer noch Artikel ganz normal mit dem Windows Live Writer online stellen?
Kommentar am 26. Januar 2009 um 21:29 geschrieben.
caschy sagt
@Andi:
Wie man sieht funktioniert das einwandfrei =) Die xmlrpc.php liegt ja auch in der Blog-Root.
Kommentar am 26. Januar 2009 um 21:31 geschrieben.
Ich (
@amoklauf_dot_ch) sagt
Ich würde evtl dem Beitrag noch den Hinweis hinzufügen die phpinfo anschliessend wieder zu entfernen, schliesslich dreht sich der Beitrag um Sicherheit
Kommentar am 27. Januar 2009 um 09:18 geschrieben.
Andi sagt
Ah stimmt da hab ich ned dran gedacht das die xmlrpc.php ja ned im adminbereich liegt.
Wie ist es auch mit der Admin Bar? Die klappt auch immer noch? Ohne das man auch auf der Hauptseite die htaccess daten eingeben muss.
Kommentar am 27. Januar 2009 um 17:39 geschrieben.
caschy sagt
Probiere es einfach aus.
Kommentar am 27. Januar 2009 um 17:56 geschrieben.
René (
@mobiFlip) sagt
Hey, an sich ein guter Tipp. Ich nutze seit einiger Zeit das Plugin “Login LockDown“. Leider kann ich bei Nutzung der .htacess keine Bilder mehr ins Medienarchiv von WordPress laden. Zumindest in Chrome mit aktiviertem Google Gears kommt beim Uploadversuch nochmals eine Loginaufforderung. Nach Eingabe der Nutzerdaten hängt sich der Browser auf. Ist das ein Chrome spezifisches Problem oder gibt es dafür eine allgemeine Lösung?
mfg René
Kommentar am 28. Januar 2009 um 12:53 geschrieben.
Ick sagt
Habe gerade selbst meine htaccess-Files überarbeitet, gute Hilfe hierbei gibt die Seite von AskApache, wer das Plugin für WP nicht installieren will findet die verwendeten Codes hier.
Kommentar am 5. Februar 2009 um 03:55 geschrieben.
Puh (
@Puh) sagt
Dann mal herzlichen Dank für den Tipp, seit Monaten habe ich Probleme dass der Flashuploader Firefox einfrieren/abstürzen lässt und erst jetzt kam ich dank Sergej dahinter, dass dein Tipp daran schuld ist.
Kommentar am 25. April 2009 um 15:27 geschrieben.
Michael sagt
@Puh Du hast nen Feingefühl wie ein Presslufthammer. g
Kommentar am 26. April 2009 um 10:13 geschrieben.
caschy sagt
Wenn eine .htaccess deinen Fuchs abstürzen lässt, dann hast du ganz andere Probleme.
Kommentar am 26. April 2009 um 10:16 geschrieben.
Michael sagt
Ich würde da auch eher auf eine veraltete Flash-Version tippen, da es damit sowieso schon immer Probleme in Kombination mit dem WP-Uploader gab.
Kommentar am 26. April 2009 um 10:18 geschrieben.
Puh (
@Puh) sagt
Nein, ich habe keinen veraltete Flash-Version.
Firefox 3.0.9
Flash Player 10,0,22,87
WordPress 2.7.1
Wieso glaubst du mir nicht dass es daran lag, dass ich das wp-admin-Verzeichnis per .htaccess dicht gemacht habe wie hier beschrieben?
Probier es doch aus?
@caschy
Wieso sollte ich denn ganz andere Probleme haben? Du benutzt ja nicht mal das Backend von WordPress da du ja den Windows Live Writer benutzt. Wieso testest du es nicht einfach mal?
Kommentar am 26. April 2009 um 13:26 geschrieben.
caschy sagt
@Puh:
Ich blogge nicht immer per Live Writer, sondern auch gelegentlich via Backend. Ich hätte meine Aussage auch nicht getroffen wenn ich es nicht selber vorher ausprobiert habe. Ich kann also kein Problem feststellen. Ist aber auch egal – bei dir löste das einen Fehler aus den du ja nun beheben konntest. Alles gut.
Kommentar am 26. April 2009 um 15:41 geschrieben.
Michael sagt
Ich glaub deswegen nicht dran, weil ich es selber genauso “schütze” und die gleiche Software verwende.
Kommentar am 26. April 2009 um 15:50 geschrieben.
Mikka sagt
Naja, sehr schön!Die Tipps von Sergej sind ja echt toll.Danke;) Die Seite finde ich sehr schön.Danke.Weiter so!
Kommentar am 29. Juni 2009 um 10:53 geschrieben.
xyt sagt
Und wie wäre es hiermit? Kann mal jemand prüfen ob es auch bei euch funktioniert?
1. Schutz der login.php – die liegt im Root der Domain (wäre bei mir unter /html). Da ich aber gelesen habe es wäre besser unter /html (root) einen wordpress Ordner anzulegen, habe ich es getan und ihn mal gleich umbenannt:
/html/wordpress_denk_dir_was_aus
in diesem Ordner befindet sich nun die ganze wordpress installation, also auch login.php
Dort lege ich die .htaccess an:
# protect wp-login.php
AuthName “Admin-Bereich”
AuthType Basic
AuthUserFile /lokaler-pfad-zu/.htpasswd (muss noch angepasst werden!!!)
require valid-user
Mehrfach habe ich gelesen es wäre nicht sicher genug in GENAU DIESEM ORDNER die .htpasswd zu speichern und schon gar nicht mit eben diesen Namen.
Also bin ich aus dem Ordner wordpress_denk_dir_was_aus
raus und eine Ebene höher. Und Habe unter /html einen ganz neuen Ordner angelegt, mit einem beliebigen Namen.
z.B. bierbauch in diesem habe ich nun die vorgefertigte .htpasswd rein getan (und nur dort); diese eigentlich dort liegen sollte wo die .htaccess liegt.
Dann habe ich es mir noch gewagt die .htpasswd einfach umzubenennen z.b. dass_kommt_davon_wenn_man_zuviel_bier_trinkt
Dann bin ich wieder in meinen wordpress_denk_dir_was_aus und habe den Pfad in der .htaccess angepasst:
# protect wp-login.php
AuthName “Admin-Bereich”
AuthType Basic
AuthUserFile /home/www/webXYZ/html/bierbauch/dass_kommt_davon_wenn_man_zuviel_bier_trinkt
require valid-user
Dann habe ich mich versucht einzuloggen und es klappt bei mir auch alles wunderbar.
Einloggen muss ich mich aber nun mit der Ergänzung des wordpress ordners, also so:
http://meinedomain.de/wordpres.....-login.php
Hat jemand von euch Erfahrung damit? Ist es sicher genug?
2. Weiter habe ich aus dem wp ordner die index.php in /html KOPIERT und in auch einer dort liegenden .htaccess den Pfad angepasst
require(‘./wordpress_denk_dir_was_aus/wp-blog-header.php’);
3. Habe ich dann noch die config.php aus dem wp Ordner auch unter /html VERSCHOBEN. Auch wenn es vielleicht nicht notwendig ist, habe ich die config.php nochmal abgesichert. In die dort schon liegende .htaccess habe ich noch den Schutz für die config.php dazu getan.:
# protect wpconfig.php
Order deny,allow
deny from all
Angeblich sucht wp automatisch in höheren Ebenen nach der config.php und wenn es so ist, dürfte auch die Einspielung einer neueren Version keine Probleme bereiten.? Oder habe ich was falsch verstanden?
Als nächstes wage ich mich mal daran wp-content aus dem wp Ordner auch unter /html zu verbannen und umzubenennen. Mal schauen ob es mit den Anpassungen auch problemlos funktioniert.
Habe gelesen im wp-admin ordner kann man install.php und upgrade.php auch mal löschen. Hat jemand andere Erfahrungen?
Freue mich auf Feedback…
Kommentar am 23. Oktober 2010 um 16:24 geschrieben.
4 Trackback(s)