Initiative: Mehr Sicherheit für WordPress durch den Schutz von WP-Admin

Artikel vom 11. Mai 2010

Man spricht vom schwächsten Glied der Kette im Sicherheitskonzept der WordPress-Blogs und meint automatisch den Administrationsbereich. Als Entwickler von Sicherheitslösungen darf man bei der Wiederholung des folgenden Satzes nicht müde werden: Schützt eure Backend-Systeme! Dieser Artikel geht nicht erneut die 10 Punkte für die Sicherheit in WordPress, sondern legt den Fokus auf eine bestimmte Abwehrmethode, die rasch eingebunden und äußert effektiv ist: Der Zugriffsschutz via .htaccess.

Anmeldeformular erzwungen in .htaccess

Sinnvoll: Kritische Trennung der Bereiche
Fakt ist: Das Backend eines Blogs darf nicht öffentlich zugänglich sein! Punkt. Der – durch WordPress generierte Zugangsdaten – bereits geschützte Raum hat nicht umsonst den Namen Administrationsbereich. Einen Zugriff auf die dahinter liegenden Seiten haben nur Administratoren und diejenigen, die vom Administrator explizit eingeladen wurden – meist Autoren mit beschränkten Rechten. Der Rest der Menschheit darf den Adminbereich einer WordPress-Instanz nie zu Gesicht bekommen, geschweige das mächtige, dennoch empfindliche Segment von innen zu sehen. Nicht mal die Login-Seite.

Gemeinsame Zugangsdaten für die “Eingangstür”
Die praktikable Lösung der vorgeschlagenen Trennung zwischen Back- und Frontend: Admin-Area durch ein zusätzliches Passwort abgrenzen, um dadurch einen weiteren Passierpunkt auf dem Weg zur Login-Maske zu schaffen. “Doppelt hält besser” ist hier die zutreffende Devise. Zugegeben, auf den ersten Blick ein wenig umständlich wirkender Schritt. Doch ab diesem Punkt übernimmt der Server bzw. Apache die unbürokratische Konfrontation mit Angreifern, die wiederholt versuchen ans Blog-Backend heranzukommen.

Es existieren zwar WordPress-Plugins, die solche Angriffe protokollieren und nach X gescheiterten Loginversuchen den Roboter aussperren. Doch warum Ruhestörer erst auf WordPress (das System und die Datenbank) lassen, wenn fehlerhafte Anmeldungen bereits auf Server-Ebene abgefangen werden können?

Appell: Lieber eine Passwortabfrage zu viel als zu wenig
Daher der dringende Aufruf an die Blogger: Sichert eure Adminbereiche ab! Die Angelegenheit ist schneller und unkomplizierter erledigt als vermutet. Die in den meisten Fällen bereits vorhandene Server-Datei .htaccess (wird meist von WordPress für die Steuerung der Permalinks angelegt) wird um 2 Code-Blöcke mit minimaler Pfadanpassung erweitert. Plus Erstellung einer Datei mit den Zugangsdaten im gleichen Ordner. Mehr ist da nicht zu machen. Investiert jetzt Minuten anstatt nach einem möglichen Angriff Stunden oder gar Tage für das Suchen nach injizierter Malware und für die Wiederherstellung der Daten hineinzustecken.

Anleitung für einen Zugriffsschutz via .htaccess

Leere Datei mit dem Namen .htpasswd (PUNKThtpasswd) im Hauptverzeichnis des Blogs anlegen. (Unsichtbar?)
Erstellte Datei im Texteditor öffnen (Microsoft Word ist keiner), den generierten Inhalt aus dem Htpasswd Generator übernehmen und speichern.
Datei .htaccess (PUNKThtaccess) analog öffnen und um den nachfolgenden Code erweitern. Der Server-Pfad zu .htpasswd gehört angepasst.
Änderungen speichern und das Ergebnis kontrollieren.

Zugriffsschutz + Interner Schutz für Systemdateien

<Files wp-login.php>
  AuthName "Admin-Bereich"
  AuthType Basic
  AuthUserFile /pfad/zu/.htpasswd
  require valid-user
</Files>

<FilesMatch "(\.htaccess|\.htpasswd|wp-config\.php|liesmich\.html|readme\.html)">
  order deny,allow
  deny from all
</FilesMatch>

Zusammenfassung
Natürlich schließt die oben aufgeführte Technik einen eventuellen Einbruch nicht hundertprozentig aus – ein auf dem heimischen Rechner installierter Trojaner würde die Übertragung auch dieser Anmeldewerte heimlich ins Netz übertragen. Dafür ist die Vielfalt und die Hartnäckigkeit der Einbruchsmethoden zu überdimensional und zu brutal. Doch als weiterer Stolperstein auf dem Weg zur Plünderung eignet sich der Ansatz mehr als perfekt und konnte sich in der Vergangenheit mehrmals als zuverlässiger Wächter beweisen und vor Ausnutzung von bekannt gewordenen WordPress-Lücken auf Backend-Seiten schützen.

Wichtig zu beachten ist die Tatsache, dass nicht der komplette Ordner wp-admin mit einem Zugriffsschutz versehen wird (da sind Webhoster schnell dabei, meinen es aber gut), da WordPress auch im Frontend auf diverse Dateien im Backend zugreift.

Unterstützt die Initiative, sagt weiter.

[Der Autor] Sergej Müller ist enthusiastischer Software Engineer mit Schwerpunkten Webentwicklung und WordPress. Seit 2007 programmiert und vertreibt er wpSEO, das weltberühmte und patentierte SEO-Plugin für WordPress-Blogs.

45 Kommentare zum Artikel

115 Tage zuvor | #1 caschy

*Rauskram* Einfach auf den hier verlinken:

http://j.mp/4yvRHo

115 Tage zuvor | #2 Sergej Müller

caschy, einfach verlinken bringt nichts. Habe auf Twitter schon mehrmals gemacht. Man muss erneut thematisieren, Gefahren darstellen, die Lösung noch detaillierter darlegen. Glaub mir, ich würde den Artikel nicht schreiben, wenn ich keine Notwendigkeit dafür sehen würde.

Aber danke natürlich für deinen Kommentar, der gibt mir nachzudenken.

115 Tage zuvor | #3 Michael Oeser

So schön einfach, dass ich es einfach direkt mal umgesetzt habe. Danke für´s Aufwecken Sergej ;-)

115 Tage zuvor | #4 Perun

@Sergej,

leider gibt es immer noch Hoster, die den Zugriff auf die .htaccess nicht erlauben.

115 Tage zuvor | #5 Sergej Müller

Das ist richtig, aber da kann man sonst auch nichts machen. Da bleibt man ungeschützt und da muss man sich als Blogger fragen, ob man dort richtig aufgehoben ist. Viele Hoster erlauben zwar kein Schreiben in die htaccess, haben dafür aber entsprechende Weboberflächen, die dafür ausgelegt sind, bestimmte Ordner oder Dateien zu schützen.

114 Tage zuvor | #6 Perun

Hallo Sergej,

Da bleibt man ungeschützt…

man muss das nicht alles so fatalistisch sehen. Du hast ja selber die Plugins erwähnt, die den Admin-Bereich zusätzlich absichern bzw. die Login-Versuche einschränken. So ungeschützt ist man nicht.

114 Tage zuvor | #7 Stefan

@Perun,

wenn der Hoster solche Optionen nicht bietet, dann würde ich für meine Kunden den Hoster wechseln. Soweit ich weiß haben alle namhaften Hoster in Deutschland Zugriff auf die .htaccess aktiviert – teilweise nicht im kleinsten Paket, aber zumindest ab den gängigen 4,99€/Monat.

Aus meiner Sicht gilt da safety-first. Lieber 2 Euros im Monat mehr ausgeben, dafür aber das Sicherheitsrisiko verringern.

114 Tage zuvor | #8 Robert

kleiner Hinweis:
hat man das Backend in einen anderen (Unter-)Ordner verschoben, muss dort eine extra DOThtaccess erstellt werden mit dem oben angegebenen Inhalt.

114 Tage zuvor | #9 Sergej Müller

@Perun
Genau aus diesem Grund habe ich im Code-Schnippsel nicht nur den Block mit dem Zugriffsschutz aufgezeigt, sondern auch einen weiteren Code zur Absicherung der systemweiten Dateien wie zum Beispiel der wp-config.php.

Richtig, aber ich habe auch gleich auf die Schwächen des Plugins hingewiesen, was in meinen Augen doch nicht unbedeutend sind. Es ist immer eine Frage, welchen Schutz will ich meinem Blog verpassen? Gar keinen, mittleren (mithilfe von Plugins) oder erweiterten. Ich würde das letztere bevorzugen und 3 Euro mehr im Monat investieren, da dabei meine Inhalte – für viele Blogger sogar Existenz – au dem Spiel stehen.

114 Tage zuvor | #10 Sergej Müller

@Robert
Nicht zwingend. Meine WordPress-Installation liegt auch nicht im Hauptverzeichnis. Aber wenn die Möglichkeit und der Aufwand es her geben, dann klar, gerne.

114 Tage zuvor | #11 Sergej Müller

Ich als Entwickler bin lediglich in der Aufklärungspflicht, weil ich tagtäglich berühmte und große Blogs ohne den Zugriffsschutz sehe (viele davon habe ich schon eingebrochen gesehen). Das will ich mit diesem gezielt verfassten Beitrag ändern, in dem ich auf die Möglichkeiten hinweise. Ob jemand über eine fehlende Möglichkeit zur Erstellung einer .htaccess oder nicht über das nötige Kleingeld verfügt, da kann ich nichts dran ändern.

Ich versuche zum Nachdenken zu bewegen, mehr nicht. Wenn es mir nicht gelingt, dann war es umsonst und ich mache es beim nächsten mal, wie caschy es sagt: Keine Initiativen, einfach ein dummes Linken auf bestehende Beiträge.

114 Tage zuvor | #12 Perun

@Stefan,

mein Hoster (all-inkl.com) bietet das schon seit eh und jeh.

Aber ob du es mir glaubst oder nicht, in den letzten Jahren hatte ich mehrere Kunden wo es nicht möglich war die .htacccess anzulegen bzw. anzupassen und ich rede hier nicht von Accounts für 0,99 Euro.

114 Tage zuvor | #13 Sergej Müller

@Perun
Dann kommst du ohne Auswege via Plugins nicht drumherum. In diesem Zustand der Technik ist es die bessere Lösung.

114 Tage zuvor | #14 Tom

Ich zahl 2,49/Monat und hab Zugriff auf htaccess und meine eigene php.ini. Darf ichs sagen? planet-hosting.de ;)
Es geht also auch preiswert. Und mit der htaccess kann man ja noch vieles andere anstellen. Da lohnt sich das allemal.
Danke auch für dich nochmalige Erinnerung! :)

114 Tage zuvor | #15 florian

habe bei mir seit jeher die admin bereiche sämtlicher cms systeme via .htaccess gesichert. bei wordpress kann es unter umständen bei bestimmten templates zu problemen kommen, hier der workaround http://j.mp/d174MO

114 Tage zuvor | #16 Sergej Müller

@florian
Deswegen weise ich im Beitrag explizit darauf hin, nicht den kompletten wp-admin Ordner mit einem Zugriffsschutz zu belegen, da selbst WordPress an diversen Stellen im Frontend auf die Bestandteile des Backends zugreift.

114 Tage zuvor | #17 florian

ok, sorry. hatte den artikel nur überflogen da bei mir wie gesagt sowieso schon umgesetzt.

114 Tage zuvor | #18 Sergej Müller

@florian
Super ;)

114 Tage zuvor | #19 Uwe

Ohne .htaccess ist ja wie ohne Gummi: geht gar nicht, egal wie viel Vertrauen auf allen Seiten herrscht; schon ewig und drei Tage aktiviert. :)

114 Tage zuvor | #20 Sergej Müller

Uwe, feiner Vergleich.

114 Tage zuvor | #21 Bart

So funktioniert der multiuploader aber nicht mehr..
Hier gibts die Lösung: http://j.mp/bSr2v8 (unten bei htaccess Problem)

114 Tage zuvor | #22 Sergej Müller

@Bart
Bitte, lese doch den Beitrag, den Code-Snippet und die Kommentare genau durch. Ich sage doch an zig Stellen: Nicht den kompletten Ordner schützen, nur die Login-Datei.

114 Tage zuvor | #23 Bart

jo.. aber darin seh ich keinen grossen Sinn.. wennschon dann alles Schützen.
oder ist wp-login.php eine Datei die bei jedem File-Aufruf included wird?

114 Tage zuvor | #24 Sergej Müller

Alle nicht autorisierte Requests landen automatisiert auf der wp-login.php. Probier doch einfach aus, hast ja ein WordPress Blog.

114 Tage zuvor | #25 Olaf

dank dir sergej

gleich mal umgesetzt. Jetzt kann ich ruhiger schlafen ;-)

114 Tage zuvor | #26 Luigi

Hallo! Bei mir funktioniert das nicht. Ich habe WP in einem Unterordner (/blog) liegen und die zwei Dateien auch in den Ordner kopiert. Dann hatte ich eine Fehlermeldung “500″ vom Server. Hatte vergessen den Pfad zu der DOThtpasswd anzugleichen. Nachdem ich das gemacht habe sehe ich keinen Unterschied zu vorher. Wo mache ich den Fehler?

114 Tage zuvor | #27 Sergej Müller

Luigi, leg die Dateien außerhalb des Blog-verzeichnisses. Wenn immer noch nicht klappt, schreib mir eine E-Mail, ich helfe gern.

114 Tage zuvor | #28 Ralf

Das “.htpasswd” sollte man auf Wattebäuschchen schreiben und dir um die Ohren hauen bis sie weh tun ;)
.htpasswd ist lediglich ein Dateiname und wurde (und wird es leider immer noch) als recht bezeichnender Dateiname in Anleitungen zum Verzeichnisschutz verwendet.
Will jemand ernsthaft die Webseite hacken, z.B. für Linkspammerei, dann möchte er dies möglichst unbemerkt tun. Bei einen Angriff auf den Server würde man also versuchen an die Passwortliste heran zu kommen, diese lokal zu speichern und dann die Passwörter in aller Ruhe zu knacken. Danach hätte man unbemerkten Zugriff, sogar mit gültigen Benutzernamen und Passwort, auf die Webseiten und könnte weitere Schritte vornehmen um die Webseite zu komprimierten.
Dabei ist es dem Angreifer natürlich eine große Hilfe wenn er weiß wonach er suchen muss: nach “.htpasswd”.

Die Datei in der Benutzernamen und Passwörter gespeichert sind kann fast beliebig benannt werden. Es geht z.B. auch “hullewulle”, “topfsiekriet”, “schwuppdiwupp.lst” oder sonst was. Es muss also weder ein Punkt am Anfang des Dateinamens stehen, noch muss die Datei eine bestimmte Endung haben.
Dies nur als kleine (reflexartige) Anmerkung zu .htpasswd.

Beim Lesen des Artikels und den Kommentaren ist mir eine Idee gekommen: Warum nicht gleich den ganzen Admin-Bereich woanders hin auslagern?
Theoretisch könnte man den Admin-Bereich auf eine geheime Sub-Domain auslagern (z.B. secretadmin.example.com). Auf der Haupt-Webseite (www.example.com) wäre dann nur noch das Frontend untergebracht. So hätte es ein Angreifer unweit schwerer überhaupt erst einmal das Backend zu finden.

Das wäre wahrscheinlich zu viel des Guten, denn der Aufwand alleine für die Pflege wäre enorm. Bei jeden Update müsste man zwei Seiten pflegen und WP ist mit Sicherheit auch nicht so einfach davon zu überzeugen in dieser Konfiguration zu arbeiten. Es wäre aber wahrscheinlich ganz interessant, nur so aus Spaß, zu sehen ob es überhaupt geht und mit welchen Aufwand.

114 Tage zuvor | #29 Sergej Müller

Ralf, WordPress erlaubt eine Auslagerung von wp-config.php und die Umbenennung des wp-content-Verzeichnisses. Der Admin ist ohne einen Megaaufwand im Core nicht verschiebbar.

114 Tage zuvor | #30 Sergej Müller

Mist, habe in Eile vergessen auf den anderen Part deines Kommentars zu reagieren, Ralf. Nu aber…

Das mit dem Namen der .htpasswd hast du mit Sicherheit Recht, doch diesen Aspekt habe ich in meiner Lösung bereits bedacht. Du hast lediglich übersehen, dass Systemdateien im Format .htxxx im von mir vorgeführten Code (oben im Artikel) gleich von unbefugten Zugriffen ausgeschlossen werden. So kommt von außen keiner an die dort gelisteten Files ran.

Man könnte die Datei mit den Zugangsdaten sonst wie benennen, doch das verwirrt die Einsteiger nur unnötig. Wenn ich meine Leser zur Implementierung meiner Lösung überzeugen kann (für die eigene Sicherheit wohlgemerkt), dann ist sie in dieser Konstellation mehr als sicher. Vorausgesetzt natürlich, man nimmt den Code so wie der ist (+ Pfadanpassung), ohne da die Hälfte weg zu lassen.

113 Tage zuvor | #31 Michael Oeser

Nun bin ich doch noch über ein Problem bei der geschichte gestolpert. Setzt man z.B. das Simple Forum Plugin ein, das die Userverwaltung von WP nutzt, bekommt man schwierigkeiten, da jeder, der sich im Forum anmelden will auch die .htaccess Abfrage zu sehen bekommt.

Deshalb musste ich es wieder entfernen (nicht das Forum natürlich ;-))

113 Tage zuvor | #32 Jeffrey

Danke für den Tipp!

Ich hatte mir schon lange mal vorgenommen eine zusätzliche Passwortabfrage für den Admin-Bereich einzubauen, nun ist es gemacht :)

113 Tage zuvor | #33 Ralf

@Sergej: “[...] dass Systemdateien im Format .htxxx im von mir vorgeführten Code (oben im Artikel) gleich von unbefugten Zugriffen ausgeschlossen werden. So kommt von außen keiner an die dort gelisteten Files ran.”
Sicherlich kann man mit FilesMatch".ht~" alle Dateien vor Zugriffen schützen die mit .ht beginnen. Jedoch ist dies kein Schutz vor Zugriffen von Außen, sondern ein Zugriffsschutz über HTTP. Die .htaccess schützt nun einmal (leider) nur vor recht simplen Zugriffsversuchen.

Dein Beitrag ist mit Sicherheit nicht verkehrt. Besser ein paar kleine Schutzmaßnahmen als gar keine. Aber der Schutz über .htaccess hat so seine Haken und Tücken.
Zum Beispiel bietet diese Methode keinen Schutz vor Bruteforce-Angriffen*. Da ist ein Schutz via PHP, z.B. mittels Plugin, doch besser. Denn so kann man zumindest einen Bruteforce-Angriff in weiten Teilen verhindern.

Auch sollte man sich einmal vor Augen halten wie die meisten Angriffe ablaufen. Denn der gezielte Angriff auf eine einzelne Webseite ist eher selten und bedarf ganz individuelle Schutzmaßnahmen.
Viel eher läuft es so ab: Ein Angreifer sucht nach einen Hoster bei dem sehr viele Webseiten mit einer bestimmten Software installiert sind. Nehmen wir mal an Hacker A hat eine Lücke in WordPress gefunden und Hoster XY ist dafür bekannt das dort sehr viele WP-Blogs gehostet sind. Nun sucht Hacker A bei den Servern des Hosters nach einer Sicherheitslücke, z.B. durch eine Fehlkonfiguration. Gehen wir mal weiter davon aus, dass Hacker A es schafft auf jeder beliebigen Webseite des Hosters XY Leserechte zu bekommen. Es ist dann ein einfaches Scripte zu programmieren die automatisiert nach bestimmten Dateien suchen, z.B. .htpasswd, und diese zu stehlen.
Das größte Problem bei heutigen Angriffen ist die Monokultur bei Verzeichnis- und Dateinamen. Niemand muss heutzutage noch tagelang vor dem Computer sitzen und Passwörter von Hand knacken. Dank Monokultur kann dies fast vollständig automatisiert werden.

Dein Script ist demnach in einen Punkt relativ anfällig für automatisierte Angriffe. Besser wäre es mittels FilesMatch ".ht~" alle Dateien zu schützen die mit .ht beginnen. Die Passwortdatei kann dann nach dem Format .htxxx benannt werden, wobei xxx eine beliebige Kombination aus Buchstaben und Zahlen darstellen sollte.
Dies kann man auch Anfängern vermitteln ohne sie zu verwirren. Ich denke das man gerade Anfängern gleich ein paar wichtige Dinge mit auf dem Weg geben sollte bevor sie sich die üblichen Fehler angewöhnen (z.B. Monokultur bei Datei- und Verzeichnisnamen).

Auch sollte man darauf hinweisen das der “Verzeichnisschutz” über .htaccess weniger ein echter Schutz als eine Sammlung von Regeln ist wer auf welche Dateien zugreifen darf. Ansonsten läuft man Gefahr das Anwender sich in einer falschen Sicherheit wiegen und glauben alles nötige getan zu haben. Deswegen sollte man sich nicht alleine auf die .htaccess verlassen, sondern auch Plugins installieren die z.B. die Anzahl der Versuche beim Einloggen begrenzen.

Das WP sich nur durch intensive Eingriffe in den Core davon überzeugen lässt mit den Admin-Bereich zu arbeiten auch wenn dieser woanders installiert ist, wundert mich ein wenig (eigentlich aber auch nicht, ist schließlich WordPress und da darf man sich über nichts wundern ;) ).
Die einzige Änderung die wichtig wäre, wäre die Pfadangabe zum Backend. WP-Content kann man verschieben, ebenso die wp-config.php. Beides ist möglich da die Pfadangabe nicht hart codiert ist. Ist die Pfadangabe zum Backend hart codiert, wäre dies schade, es wäre aber eine gute Idee dies in zukünftigen Versionen zu ändern um ein Installation des Backend an einen anderen Ort zu ermöglichen. Zumindest wäre es der Sicherheit dienlich da es wieder ein Schritt weg von der Monokultur ist.

—
* Es gibt Module für den Apache-Webserver die auch Bruteforce- Angriffe und vergleichbares blockieren, jedoch sind diese eher selten anzufinden.

112 Tage zuvor | #34 Pascal

Danke für deinen hilfreichen Post!

111 Tage zuvor | #35 realloc

Bei der Gelegenheit kann man ja eben noch anmerken, dass die .htpasswd nicht zwingend im DocumentRoot liegen muss. Wenn der Hoster einen Account zur Verfügung stellt, wo das möglich ist, kann man die Datei auch außerhalb anlegen und das Problem vermeiden.

Aus der Apache-Dokumentation:

Because this file contains sensitive information, it should be stored outside of the document directory.

108 Tage zuvor | #36 Jeffrey

Ich habe noch eine kleine Frage bezüglich der .htaccess für den Admin-Bereich:

“….da selbst WordPress an diversen Stellen im Frontend auf die Bestandteile des Backends zugreift…”

Welche Teile des Admin-Bereichs werden denn im Frontend von WordPress benötigt?

Als zusätzlichen Schutz vor Session Hijacking würde ich zusätzlich gerne den ganzen Admin-Bereich per .htaccess schützen.

108 Tage zuvor | #37 Sergej Müller

@Michael Oeser
Ok, das ist natürlich ein Argument. Gibt es Erweiterungen im Blog, die auf Nutzerverwaltung von WordPress zugreifen, darf der Bereich natürlich nicht abgesperrt werden. Die offene Registrierungsmöglichkeit war jedoch mehrmals Ziel der Angreifer, wobei bekannte Sicherheitslücken ausgenutzt wurden.

@realloc
Für noch mehr Sicherheit, absolut.

@Jeffrey
Schau mal hier. Außerdem scheint der Media-Uploader nicht mehr funktionieren, wenn man den kompletten Admin-Ordner via .htaccess sperrt.

108 Tage zuvor | #38 Jeffrey

@Sergej:

Danke für den Link!
Muss mir da mal noch was überlegen :)

93 Tage zuvor | #39 deLtadeep

Sehr schön, direkt eingerichtet. Vielen Dank!

75 Tage zuvor | #40 BMO

Super danke für den Tipp.

63 Tage zuvor | #41 Ritchie

Hi, danke für diesen ausführlichen und ausgesprochen berechtigten Beitrag. Ich bin ebenfalls der Meinung, dass User (=Blogleser) im Backend nichts zu suchen haben. Doch jetzt kommt das “big hairy but”: ich möchte meinen Usern keinesfalls die Möglichkeit nehmen, sich zu registrieren – alleine schon, weil’s für die Stammleser komfortabler ist beim Kommentieren.

Das Problem bei der von dir beschriebenen Methode – so sicher und sinnvoller sie auch ist – liegt darin, dass durch den htacces-Schutz auch die normale Registrierung unmöglich wird. Das mag egal sein für Webmaster, die WP primär als CMS einsetzen und keine registrierten User wollen. Wenn man aber die Registrierung ermöglichen will, dann find ich den Mingle-Ansatz (Mingle ist ein Social Networking Plugin für WordPress; will hier nicht Link-Spammen, aber falls es jemanden interessiert: ich hab’s auf datenschmutz laufen und dort auch ein ausführliches Review geschrieben, den Link poste ich hier auf Nachfrage gerne) besser: Mingle verhindert im Wesentlichen, dass User ins Verzeichnis /wp-admin/ kommen und wickelt Reg sowie “Profilverwaltung” (User-Foto, Info, URL etc.) über Frontside-Pages ab. Gefällt mir gut, weil ins wp-admin mag ich nur Schreiberlinge reinlassen.

Was mir jetzt aber sehr gelegen käme, wär die Möglichkeit, den Ordner wp-admin zu ändern – sprich, für den gesamten Admin-Bereich einen anderen Ordnernamen zu verwenden. Meiner Meinung ist das nämlich genauso sinnvoll wie den Standard-Admin namens “admin” auf einen andern User zu ändern: das ist keine Maßnahmen, die gegen gezielte, menschliche Hack-Versuche hilft, aber eine, die jede Menge Bots, die einfach nur checken, ob das Verz. /wp-admin/ grundsätzlich vorhanden ist, abhalten würde – und meiner Erfahrung nach sind die automatisierten “Hack” respektive Spam-Versuche die häufigsten.

Deine htaccess Methode löst das Problem zwar auch, aber für Blogger, die nicht Mingle verwenden und trotzdem eine Reg bzw. ein Login erlauben wollen, ist die Methode nicht optimal – daher meine Frage: meines Wissens nach ist der /wp-admin/ Pfad keine Variable, sondern “hardgecodet” – gibt’s eine Möglichkeit, diesen Verzeichnisnamen zu ändern, ohne sich Folgeprobleme einzuhandeln?

So, sorry für den Roman – aber das ist nun mal ein Thema, über das ich mir schon häufiger Gedanken gemacht habe.

lG,
Ritchie Blogfried aka datenschmutz

27 Tage zuvor | #42 Thomas

Hallo Sergej,
bei mir tuts nicht ;-(
Sitze seit gestern abend um 22 uhr darn und es will nicht klappen.
Habe per fullpath.php den Pfad ausfindig gemacht, die Verzeichnissperre ist auch aktiv, nur kann ich mich nicht einloggen. Habe x variationen schon ausprobiert.
Frage: Muss der Server eine bestimmte Vorraussetzung haben, damit er das verarbeiten kann, was in der .htpasswd drinnen steht? Es muss doch eigentlich auch kein existierender wp user sein. Obwohl ich einen für wp angelegt habe. Ich wäre dir echt dankbar für nen Tipp was ich zu machen habe, damit das klappt, denn den Verzeichnisschutz seh ich auch als sehr wichtig an.
lg
Thomas

27 Tage zuvor | #43 Sergej Müller

Thomas, für die Abarbeitung der Passwort-Datei sind meines Wissens keine gesonderten Anforderungen seitens Server notwendig.

27 Tage zuvor | #44 Thomas

Hallo Sergej,
vielen Dank für deine prompte Reaktion. Ich war natürlich nicht untätig und hab mal bei meinem Provider recherchiert.
Tja, also der Server muss dafür eine Voraussetzung haben. Er darf nämlich kein Business Server (managed server) bei Strato sein, da klappt das per .htacces nicht. Dort gibt es eine andere Lösung, nämlich über das Kundenservicelogin ein Passwort diversen Ordnern zu vergeben.
(Für alle “Leidensgenossen hier ein Link für das how to: http://j.mp/bWqR96
)
Nun hoffe ich wirklich, dass wp nicht auf den wp-admin zugreifen muss (hab mal gelesen wegen der Kommentare etc tut es das doch) das wäre natürlich sehr, sehr bescheiden. Da ich auf eine Anmeldung für User gänzlich verzichten möchte und nur Newsletter und moderierte Kommentare zulassen werde. Weniger Daten, weniger Verantwortung ;-)
Das Ergebnis seh ich dann in einer Stunde, solang dauert diese Einrichtung…
Hab vielen Dank für deine Antwort! Find ich Klasse und werde deinen Blog im Auge behalten ;-)
Gruß
Thomas
PS, achso, hab gar keine Antwort durch dein System erhalten, fällt mir gerad so auf. War mir sicher den Haken ins Feld gesetzt zu haben, evtl hab ich aber die email falsch geschrieben…

27 Tage zuvor | #45 Thomas

sorry Sergej, dass ich dich gerad zumülle, eben hab ich die Mail erhalten. Kannst diesen Kommentar und mein PS des vorangegangenen also vergessen. War wohl doch kein Haken gesetzt oder die email falsch beim ersten mal