kollidieren 1. und 3. nicht miteinander?

PS: und der Admin User kann auch nicht gelöscht werden!
>>The current user will not be deleted.
>>There are no valid users selected for deletion.

@Viktor
1. Nein, tun sie nicht. Was spricht dagegen WordPress in einem Unterordner und wp-config.php eine Ebene tiefer zu haben?

2. Wenn du dich als neuer Administrator einloggst, dann kannst du sehr wohl den admin-Nutzer löschen. Ist doch klar, dass du dich nicht selbst (da gerade eingeloggt) entfernen kannst.

Glaubst du wirklich, ich empfehle Dinge, die ich vorher nicht getestet oder nicht selbst einsetze? ;)

hi, danke! 2. geht jetzt — ich war wohl zu dumm, als ich die Frage gestellt hatte :) 5 min später kam es mir dann auch in den Sinn :)

zu 1. (3.)
angenommen, man hat eine Struktur wie:

-root
—WProot-1
—–wp-config.php
—WProot-2
—–wp-config.php

wenn man nun die wp-config eine Ebene tiefer legen würde, hätte man doch zwei in einem Ordner?!

PS: Meine Comments waren als Fragen gedacht… hätte ich besser kennzeichnen sollen, sorry :)

Ja, wenn du mehrere Installationen hast, dann ist es natürlich was anderes ;) Dann kannst du sicherlich nur eine Konfigurationsdatei außerhalb ablegen. Bei den meisten Nutzern ist es sowieso die Ausnahme.

Danke für den Beitrag, ich werde glaube ich mal einige Änderungen bei mir vornehmen :-)

Das ist doch mal ein schönes Tutorial, das einen Versuch wert ist.
Dennoch könnte es bei kommenden Updates etwas aufwendiger werden, jedesmal alles neu anzupassen.

Wenn man nicht wie in 3. beschrieben vorgehen kann/möchte, so gäbe es auch folgende Möglichkeit:

in eine .htaccess die sich auf der selben Ebene wie wie wp-config.php befindet folgendes eintragen:
# protect wpconfig.php
<files wp-config.php>
Order deny,allow
deny from all
</files>

Auch für wichtig halte ich die Anpassung der Fehlermeldung auf der Loginseite.

Damit wird ausgeschlossen das der “Hacker” weiß das ein Benutzername vorhanden ist und er nur noch das Passwort rausfinden muss. ;-)

http://bueltge.de/wordpress-login-sicherheit-plugin/652/

LG Marcel

Marcel, guter Tipp. Werde den Artikel um deinen Vorschlag erweitern.

Netter Artikel der einige Dinge beschreibt, die oftmals vernachlässigt werden von den Nutzern. Jeder der schon einmal Opfer eines Hacks wurde wird das zu würdigen wissen.

Für viele wäre es vielleicht wünschenswert, einzelne Dinge etwas tiefergehend zu erklären, beispielhafter meine ich damit. Manche sind schon froh wenn es Ihnen gelingt WordPress überhaupt zum Laufen zu bringen.

Der obige Artikel wurde von mir komplett überarbeitet: Vorhandene Schritte wurden ausführlicher beschrieben und mit Bildern versehen. 5 neue Tipps für mehr Absicherung des Adminbereichs sind hinzugekommen.

Hallo Sergej,
ein sehr interessanter Bericht. Vorallem auch so erklärt, dass Laien dies in Ihrem WordPress Blog einbauen können!

Vielleicht sollte man beim nächsten Seiten Update dies noch einfügen:
WP Version im Quelltext bieten Angreifern die ideale Basis um Sicherheitslücken zu finden!

//Entferne Header Eintrag: Meta Generator “WordPress 2.x”
remove_action(‘wp_head’, ‘wp_generator’);

//Entferne Header Eintrag: Microsoft Live Writer
remove_action(‘wp_head’, ‘wlwmanifest_link’);

//Entferne Header Eintrag: Really Simple Discovery
remove_action(‘wp_head’, ‘rsd_link’);

Besten Dank
Ivan

Ivan, diese Punkte tragen der Sicherheit des Blogs bei – keine Frage. Doch bei diesem Artikel geht es um die Absicherung des Administrationsbereiches. Also werden hier auch Dinge behandelt, die wirklich dem Schutz des Backends beitragen.

Steht aber auch oben im Titel und im Beitrag ;)

“Verzeichnisschutz für wp-admin” … finde ich sehr interessant, allerdings bekomme ich dann Probleme mit dem Upload von Dateien. D.H. es wird beim “upload” ständig nach dem Passwort gefragt!?

Gruß
Malte

(sorry for reply in english)

Good tips. Thank you for mentioning my plugin.

WordPress was not exactly design to withstand a determined attacker unfortunately:

Remote publishing, or post via e-mail, should of course never be enabled if you value security.

There are a number of other ways to brute-force find usernames: user registration (if enabled), the ‘lost password’ functionality, and ?author_name=xxx if account have made any posts.

You can brute-force attack auth cookies, or the ‘lost password’ functionality, if you are really determined.

Its sort of fun though trying to find possible attack vectors, and how to defend against them.

@Malte
Gute Frage. Ich weiß, das ich in Safari die Zugangsdaten nur einmal eingeben und diese für spätere Abfragen speichern kann. So fragt Safari nie wieder nach, da er sich mit den im Schlüsselbund abgelegten Daten automatisch beim Server authentifiziert.

@Sergej : Bein einloggen funkt. das, wenn es angeschaltet ist, auch prima, nur beim hochladen von Dateien nicht. Nun ja, habe es erstmal wieder rausg. ;;-)

Gruß
M.

Malte, das verstehe ich aber nicht. Eigentlich geschieht das Hochladen der Dateien ebenfalls über den Administrationsbereich. Wenn man sich bereits verifiziert hat, dann sollte die Abfrage zumindest während der Sitzung nicht erneut auftauchen.

Ne ganz interessante Lösung.
Bin da aber noch am überlegen, ob sich das für meine Blogs rentiert (zumindest alle Schritte durchzuführen). Was dann zwar den Komfort einschränkt, aber sicher ist sicher. Danke für die Tips.

Tipp 8 und 9 beissen sich. Wende ich Tipp 8 an dann wird mir nichts von Tipp 9 angezeigt. Soll heißen es wird nicht angezeigt das ich falsche Eingaben gemacht habe und wie lange ich in dem Fall noch warten muss. Was nun ?

@Cyriakus
Die Punkte beissen sich überhaupt nicht. Dass du oder ein Autor/Moderator die Zugangsdaten falsch eingeben hat, das schnellt wohl jeder, wenn man nach der Eingabe der Daten wieder auf der Loginseite landet.

Der Angreifer muss es nicht wissen, aus welchem Grund er nicht reingelassen wurde – ob wegen dem falschen Passwort oder weil das Plugin ihn für eine unbestimmte Zeit rausgeschmissen hat.

Ganz kleine Ergänzung zum Punkt 1: Ein Großteil der Themes besitzen einen Link zur Anmeldung auf der Hauptseite. Das neue WP-Verzeichnis kann hierdurch schnell ermittelt werden. Also besser ebenfalls solch einen Link entfernen.

Das Tabellen-Präfix einer neu aufgesetzten WordPress-Installation soll dem Standard “wp_” auf jedem Fall abweichen.

Sehr guter Ansatz, den ich jedoch modifizieren würde. Besser ist es aus meiner Sicht, den Krypto-Wortbrei auch noch mit einer sinnvollen Ergänzung auszustatten, etwa wp_348734q_XYZ, wobei XYZ für die Erweiterung steht. Anders wird es schwierig, als Entwickler Überblick über in derselben Datenbank abgelegte Blogs zu behalten.

Das Präfix wp_ ist auch nicht wirklich das Problem, sondern eher der Rest. ;)

Rene, stimme dir absolut zu. Das bleibt allerdings dem Nutzer überlassen, wie sinnvoll er das Tabellen-Suffix erweitert. Für Anwender mit einem Blog reicht auch ein einfacher Krypto-String als Zusatz. Für Entwickler und Dienstleister im Bereich WordPress mit mehreren betreuten Installationen ist es sicherlich von Vorteil, da noch eine aussagekräftige Erweiterung dran zu hängen.

@Sergej
Ich habe bei 7. das Problem, dass die Eingabeaufforderung auch dann erscheint, wenn jemand nicht alle Pflichtfelder im Kommentar-Formular ausgefüllt hat und die etwas spartanische Fehlermeldungsseite von WordPress /wp-comments-post.php aufgerufen wird. Nehme ich die Authentifizierung für /wp-admin/ raus, kommt die Eingabeaufforderung nicht.

in der .htacess steht folgendes:
AuthUserFile /pfad-zu-wp-admin//.htpasswd
AuthGroupFile /dev/null
AuthName ByPassword
AuthType Basic
<Limit GET POST>
require user username
</Limit>

Haste einen Tip?

Liegen beide Dateien denn im gleichen Ordner?

Ja beide liegen in /wp-admin

Nun, sehr interessanter Artikel. Wobei ich finde, das ein htaccess Schutz und ein neuer AdminAcc vollkommend ausreichend sind.
htaccess muss man erstmal knacken :-)

Gruß,
solar22 aus dem solardorf

@solar22
Kommt immer auf die Ansprüche, Kenntnisse und die technische Umgebung an. In der Regel würde ein Passwort-Schutz via .htaccess wirklich ausreichen, um den Zugriff auf die Admin-Login-Seite zu eliminieren.

Zur Klarstellung:
htaccess und htpassword liegen in /wp-admin
Die Eingabeaufforderung kommt aber beim Abschicken des Formulars ohne dass man alle Pflichtfelder ausgefüllt hat und dann eben entsprechend /wp-comments-post.php auf der root bzw. im WordPress-Verzeichnis aufgerufen wird.

@André Wegner
OK, hast du Recht. Musste es eben ausprobieren und im WordPress-Core nachschauen, wie es zustande kommt. Es ist in der Tat so, dass WordPress für die Ausgabe der Fehlermeldungen (zum Beispiel bei einer fehlerhafter Übertragung der Daten bei einem Kommentar) auf das Admin-Verzeichnis zugreift. Daher auch die Abfrage der Zugangsdaten für .htaccess an dieser Stelle. Ein wenig unschön ist das schon.

Ich werde den Artikel oben um diesen Hinweis erweitern und mir Gedanken machen, wie man diese Unschönheit bereinigen könnte. Danke dir.

@Sergej
Ich weiß mittlerweile was der Grund ist. Es sind zwei CSS-Dateien die auf der Fehlerseite aus /wp-admin/ eingebunden werden.
Ärgerlich weil man eine Anpassung dort bei jedem Update berücksichtigen muss. Überlege ob ich das per Mod-Rewrite, Source-Code anpassen oder einem AJAX-Comment-Plugin lösen werde.

Genau, wie ich in meinem vorherigen Kommentar schrieb, greift WordPress bei der Ausgabe der Fehlermeldungen auf das Verzeichnis zu. Eigentlich logisch, da sie somit das Aussehen der Fehlermeldungen unabhängig vom verwendeten Theme steuern können.

Mit Sicherheit lässt sich mod_rewrite so erweitern, dass die Abfrage-Maske an solchen Stellen unterbunden wird. Ich such mal, falls du schneller bist als ich, poste bitte.

@André Wegner
Habe mir gestern Abend noch intensiv Gedanken gemacht und eine brauchbare Lösung erarbeitet. Die Idee dahinter ist einfach: Nicht den kompletten Admin-Bereich, sondern nur die Loginseite zum Backend mit einem Passwortschutz belegen. WordPress leitet sowieso jeden nicht angemeldeten Nutzer zum Anmeldescreen, den es auch zu schützen gilt.

Der Punkt im Artikel ist modifiziert.

@Sergej
Coole Idee, bei mir funktioniert es.

@Sergej
Da war ich wohl zu schnell. Generell funktioniert es, aber wenn ich einmal das Passwort falsch eingegeben habe, kommt bei erneutem Aufruf immer ein “Internal Server Error”.
Ist das Server-spezifisch oder kannst Du das bestätigen?

Also bei mir funktioniert das nicht. Die Wp-Login liegt im Root also habe ich die htpasswd erstellt und die bestehende htaccess durch den hier zu lesenden Text erweitert. Bei Aufruf der Login gibts einen internen 500er.

Habt ihr den Pfad zu der .htpasswd notiert? Also in der Zeile

AuthUserFile /www/htdocs/pfad-zu/.htpasswd

Muss man nicht, aber würde – glaube ich – diesen unschönen Nebeneffekt mit 500 Error beheben.

Siehste Sergej, das war der Fehler. Sollte ich vielleicht mal erwähnen und auf dich verweisen.

Auf Sergej verweisen ist immer gut ;)

Is klar ;)

Merci, funktioniert auch bei mir.

Danke für den Tipp. Man kann bei WordPress nur dazulernen.

Vielen Dank für diesen Artikel. Habe sofort einige Punkte umgesetzt.

“create_function” aus Punkt 8 wird vom Antivirus-Plugin als Virus verdächtigt. Ist ein wenig nervig, dass nun jeden Tag eine E-Mail mit dem Fehlalarm versendet wird.

@Matthias Pabst
Das AntiVirus-Plugin wurde trainiert solche Stellen zu erkennen. Außerdem ist der AntiVirus so schlau, dass er die vom Nutzer als “Kein Virus” markierten Bereiche nicht mehr als Gefahr einstuft und entsprechend nicht mehr alarmiert. Einfach die Plugin-Beschreibung durchlesen.

Sehr interessanter Artikel. Den Benutzername kann man aber z.B. mit “Vorname Nachname” im Blog anzeigen lassen. Das stellt man in den Benutzerprofil ein; die Einstellung heißt “Name im Blog”.

sehr interessanter Beitrag zum Schutz des Admin-Verzeichnisses von WordPress. Will demnächst auch einen Blog starten und bin froh diesen Beitrag gefunden und gelesen zu haben.

Eine robots.txt reicht also nicht zum schutz aus, wie ich das entnehme.

Robots.txt ist ja für Suchmaschinen, nicht gegen Angriffe ;)

@Chris:

Nein, die robots.txt hilft ja höchstens Suchmaschinen davon abzuhalten Verzeichnissen und Dateien zu indizieren die sie nicht sollen.

Welche Suchmaschine bzw welcher Spider/Crawler sich jetzt daran dann auch hält ist noch ne ganz andere Geschichte. -.-

LG enochs08

Ich nutze die Plugins WP Security Scan, AntiVirus, Limit Login Attempts, habe den Artikel “Sicherheit in WordPress: 10 Schritte zum Schutz des Admin-Bereichs” gelesen und größenteils befolgt, aber nun funktioniert mein Flashuploader nicht mehr und bringt Firefox zum einfrieren/abstürzen – leider wird mir bei diesem Problem im Forum von WordPress Deutschland nicht weitergeholfen, sondern es einfach damit abgetan, dass es “andere Ursachen hat” jedenfalls soll der Flashuploader selbst angeblich unschuldig sein, überprüft wurde es aber nicht und weiter Hilfe wurde mir auch nicht angeboten. Was soll ich machen?

Kann mir bitte jemand helfen? Bitte!!!

Puh, was hast du denn (wp-admin-Ordner?) in der .htaccess mit einer Passwort ausgesperrt?

@Sergej
Ich dachte ich hätte den Tipp von dir, dabei hab ich den von Caschy.

Du hast doch auch in dem betreffenden Beitrag kommentiert. warum hast Du da nicht geschrieben dass der ganze Beitrag von Caschy blödsinn ist?

Warum ist der Beitrag denn Blödsinn? Der ist doch gut. Verstehe nicht ganz, was das ganze mit deinem Kommentar hier zu tun hat. Frag sonst direkt da, wo du den Tipp auch her hast. *Kopfschüttel*

Nein, nicht dein Beitrag ist Blödsinn, sondern der in dem Caschy empfiehlt den wp-admin-Ordner komplett per .htaccess abzusichern.

http://stadt-bremerhaven.de/2009/01/25/wordpress-sicherer-machen-ohne-plugins/

#menno

Ich hab sehr wohl verstanden, welchen Beitrag du meinst. Und ich finde diesen immer noch kein Blödsinn. Es kommt immer auf die Umgebung und gesetzte Anforderungen an. Ich bin mir sicher, dass der Autor die Empfehlung getestet und weiterhin im Einsatz hat.

ja ich mir auch, solange man den Flashuploader nicht benutzt funktioniert ja auch ansonsten Alles. Leider ist dort (nicht wie hier) kein Hinweis zu finden, dass der Flashuploader nicht funktioniert wenn man den wp-admin per .htaccess abschottet. Da Caschy wahrscheinlich immer noch ausschließlich den Windows Live Writer nutzt, wird ihm selbst der Fehler nie aufgefallen sein, ist mir auch klar. Schade dass sonst Niemandem der Fehler aufgefallen sein scheint. Is ja auch egal. Jedenfalls Danke, ohne Dich hätte ich den Fehler nicht gefunden – selbst im WordPress Forum wußte man keinen Rat.

Und bei jedem Upgrade von WordPress muss man dann wieder händisch eingreifen? Natürlich ist bei Handarbeit mehr Sicherheit geboten. Aber bei den vielen WordPress-Updates macht das für den Admin wohl sehr viel Arbeit…

@BTTV
Nein, keiner der oben genannten Punkte konfrontiert mit dem (automatischen) Update der Blogsoftware.

Hmm, hört sich nicht schlecht an, falls die WordPress-Updates tatsächlich nicht beeinträchtigt werden sollten. Es bleibt dann wohl nichts anderes als es selbst auszuprobieren, um sicherzugehen, aber gut: Wenn´s der Sicherheit “auf die Sprünge hilft”……

Bin froh, dass ich diese Tipps gefunden hab!

Ich würde aber dazu auch mal gern wissen, wie ich am besten meine CDMOD Rechte setz, damit ich mich mehr gegen Malware schützen kann. Wenn ihr da vielleicht ein paar Tipps für mich habt. :)

@Ani
Während der Installation versieht WordPress die Dateien und Ordner mit notwendigen Rechten. Aber schau mal, in diesem Forumsbeitrag stellt jemand identische Frage und da wird aufgelistet, welche Verzeichnisse welche Rechte bekommen müssen, um sicher zu sein.

Hallo,

sehr interessanter Artikel. Ich werde es heute abend gleich mal das ein oder andere ausprobieren. :)

Im Moment versuche ich “boesen Menschen & Bots” das Leben damit schwer zu machen das ich das /wp-admin/ Verzeichnis komplett umbenannt habe, in das /wp-admin/-Verzeichnis die Software Spider Trap installiert habe (ein Schelm der denkt es war absicht :) ) und zusaetzlich schliesse ich IP’s aus bestimmten Laendern aus (nicht optimal, aber was will man machen…).

Gruss
Gordon

Hallo Sergej,
danke für den Tipp!

Noch eine Frage: Habe ein Problem mit Punkt 7. Habe den Generator benutzt und .htaccess sowie .htpasswd erstellt und hochgeladen wie du es beschrieben hast. Alle diese Dateien liegen im wp-admin, genau wie die wp-config.php und die wp-login.php.
Die PW-Abfrage erscheint auch, allerdings sagt der mir dauernd, ich würde das falsche Passwort eingeben bzw. der Benutzername sei falsch.
Woran könnte das nur liegen?

@Ani
Dann ist es wohl tatsächlich so, dass eins von beiden Zugangsdaten falsch ist. Sonst vielleicht einen anderen Generator probieren. Eine andere Idee kommt mir jetzt spontan nicht in den Sinn.

Nein, es war alles richtig. Inzwischen hab ich den Fehler gefunden.
Das Problem war, dass ich den Pfad in der .htaccess nicht richtig angegeben hatte.

Vielen Dank. :)

Achso, davon bin ich aber ausgegangen ;) Super, freut mich.

Zum Glück habe Ich noch diesen Artikel gefunden. Ich denke schon die ganze Zeit darüber nach ob Ich mir ein Buch in Bezug auf Sicherheit in WordPress kaufen soll. Hatte da ein englisches Ebook gesehen und weil man immer und immer wieder von Leuten liest deren Blog gehackt wurde, liess es mir keine Ruhe. Aver das ist jetzt ja wohl nicht mehr nötig.

Hallo zusammen,
nur mal so ne Frage:
wp-admin mit .htaccess schützen finde ich gut.
aber jetzt hätten alle Benutzer ein .htaccess-Passwort und ein WP Passwort, oder?
Gibt es den die Möglichkeit eine .htpasswd mit den Passwörteern aus der Mysql-Datenbank zu erstellen?

Gruß Michi

@Michi
Die Zugangsdaten für die .htaccess sollen schon anders sein, dadurch wird der Schutz ebenfalls erhöht. Wenn, dann richtig.

@Sergej
wohl war – bei ein paar usern kann man das so machen.
stimmt besser ist das!

aber wenn es viele user sind muß ich allen das “firewall”-passwort zukommen lassen.
((ich denke wenn in der htaccess ein andrer username ist als im WP ist doch sicher genug oder?)) sprich 2 usernames 1 Passwort.

zumal denke ich wäre es halt auch praktisch wenn sich user selbst registrieren können… aber das lassen wir mal lieber :) wenn ich daran denke läufts mir kalt den Rücken runter.

nur mal so in den Raum geworfen:
Wieso ist der WP-login nicht sicher genug?
Wie schneidet denn da WordPress mit andren Blogsystemen bzw Drupal ab?
Würde mich mal interessieren. Wenn da jemand einen Vergleich / Tests hat wäre ich dankbar.
Gruß Michi

Michi, ideal ist, wenn registrierte Nutzer über feste IPs verfügen, dann kann man nur diese freischalten. Das ist bequem und sicher zugleich.

Sehr schön und vorallem auch für WordPressneulinge wie mich gut zu verstehen und leicht umsetzbar.
Kann man den “wp_” Präfix eigentlich auch bei einer bestehenden Installation direkt in der wp-config.php ändern?

Wenn man die entsprechende Tabelle in der Datenbank ebenfalls abändert, dann ja. Sonst würden bereits bestehende Daten nicht gefunden.

@Sergej,

mit dem Punkt 7 habe ich einen seltsamen Effekt. Wie vorgeschlagen habe ich die wp-login.php mit einem Passwort geschützt. Sobald aber in WP die Permalinks aktiviert werden, wird bei einem Zugriff auf wp-login.php ein 403 Status zurückgegeben und es ist überhaupt kein Login oder Authentifizierung möglich. Schaltet man die Permalinks auf Standard, funktioniert alles wie gewünscht. WP ist 2.8.3 und sonst steht in der htaccess nur noch dein Punkt 4, der wp-config Schutz. Eine Idee?

Tim, so auf die Schnelle habe ich keine Lösung für dein Phänomen. Eigentlich betreffen Permalinks immer die Ausgabe der Links im Frontend, nicht im Administrationsbereich. Sonst probier den Punkt 4 erstmal aus der htaccess rauszunehmen.

Achso, und schau dir nach der Umstellung auf sprechende Permalinks die htaccess an: Manchmal packt WordPress die entsprechenden Befehle an die falsche Stelle, so dass es zum Fehler kommen könnte.

Hallo Sergej,

vielen Dank für den wunderbar erklärten Artikel. Man merkt das Du auf deinem Gebiet ein absoluter Profi bist. Die Tipps sind sehr hilfreich und helfen mir gut weiter. Danke.

LG Tobi

Tobi, ich hab zu danken für die warmen Worte. Tut meiner Motivation wirklich gut.

Die Ansätze sind gut … allerdings sehe ich ein Problem: bei WordPress tauchen derzeit vermehrt Sicherheitslücken auf, die auch relativ schnell geschlossen werden.

Wenn man 10, 20 und mehr Blogs betreut ist es nicht möglich bei jedem Update/Major-Update diesen Prozeß durchzuziehen.

Einfacher wäre da: htaccess-Datei in den Admin-Ordner packen und fertig ;)

Gruß Tobias

Tobias, einfache zwei Dinge zu deinen Bedenken:

1. Für den Schutz der Login-Seite via .htaccess bedarf es keine Anpassungen (nach den WordPress-Updates, meine ich jetzt): Die .htaccess wird nicht überschrieben, die dort eingetragenen Schutzmechanismen verbleiben an der Stelle bis du sie wieder manuell rausnimmst.

2. Genau das darf man nicht: Eine .htaccess in den Ordner wp-admin werfen und diesen komplett “schützen”. Das ist ein fataler Fehler, der leider auf sehr vielen Seiten a la “100 Tricks für WordPress” verbreitet wird. Warum? Der Admin-Ordner (bzw. Dateien daraus) wird an zahlreichen Stellen auch im Frontend angesprochen und aufgerufen.

Deswegen schreibe ich auch meine Artikel, ihr müsst euch nur die Mühe machen und sie aufmerksam durchlesen, denn auf die Gefahr mit einer .htaccess im Admin-Ordner weise ich oben im Beitrag ebenfalls hin.

Moin Sergej

*hmmmm* … teilweise habe ich das mit der htaccess im Admin-Verzeichniss praktiziert und dabei keine Probleme feststellen können – auch wenn man ausgeloggt ist …

Das WP-Include-Verzeichniss sollte man dagegen nicht so schützen ;)

Ich schau mir das nochmal in Ruhe an, denn wenn man so einige Blogs betreut muss man eine wirtschaftliche Lösung haben, die schnell umsetzbar ist und die man nicht ständig bei jedem Update anpassen muss … by the way, eine Tasse Kaffee “mehr” sollte gerade auch helfen ;)

@Tobias
schau mal Kommentar #35, da gibt es ein Beispiel für Probleme mit einem Passwordschutz im Adminordner

Nabend zusammen

also man lernt ja nie aus ;) Danke für die Infos – werde sie so umsetzen.

Zu Punkt
3. Verschiebung der Datei wp-config.php
noich eine Frage:

Ich habe einige Blogs wie folgt angelegt

root
/logs
/domain.de
/cgi-bin

Die Webseiten-Domain verweist auf den Ordner /domain.de

Wenn ich die wp-config.php nun in das Root verschiebe, dann weiß die Webseite doch nicht, WO sich diese Datei befindet, da die Domain auf den Unterordner verweist. Kann man hier – z.B. in der htaccess angeben, in welchem Ordner die Datei liegt, z.B. /www/htdocs/xyz123/ ????

Tobias, probier doch aus. Wenn es eine höher liegende Ebene ist, dann ist es kein Problem, da WordPress dort automatisch nach dieser Datei sucht.

Der Beitrag hat mir sehr bei meinen Blog geholfen, um den Admin Bereich besser zu schützen. Vielen dank dafür

Hi, ich habe gewisse Probleme mit Punkt 1. Es funktioniert alles soweit, nur ich kann mich nicht mehr ins Backend einloggen.

Zudem springt die Url, wenn ich example.de/wp-admin zum Einloggen eingebe, auf example.de/mein-wp-ordner/wp-login.php?redirect_to=… um.

Somit wäre ja für einen Angreifer sofort ersichtlich, wo sich die Wp-Installation befindet und das Verschieben in einen Unterordner sinnlos.

Die Blog-Adresse und die index.php habe ich entsprechend Deiner Anleitung angepasst, sowie index.php und .htaccess ins Root verschoben.

Habe ich da irgendwo einen Denkfehler?

@fpr
Du kannst dich nicht einloggen, weil deine Zugangsdaten nicht akzeptiert werden? Ein wenig mehr Infos wären schon sinnvoll.

Alle Tipps aus dem obigen Artikel stellen keinen hundertprozentigen Schutz dar, sie dienen alleine der Hinderung eines möglichen Angriffs. Erst im Gesamtpaket ergibt sich ein Schutzkondom, mit dem man seinen Blog zuverlässig abdichten kann.

Hallo Leute,
ich habe mal eine Sicherheitsfrage die sich nicht direkt auf den Adminbereich bezieht.
Das wohl meiste Problem was man so hört ist doch der “Wurm”, der Templatefiles im Header bzw Footer abändert oder?
Sergej hat ja da ein klasse Plugin entwickelt – Danke an dieser Stelle.

Ich frage mich nur immer wieder wer die Funktionen Themeeditor / Plugineditor etc braucht. schließlich sind doch das auch Teile die die Sicherheit nicht gerade erhöhen.
Macht das Sinn diese zu Löschen wenn man sie nicht braucht? oder seid Ihr da anderer Meinung? gruß

Hi Sergej, ich habe den Fehler gefunden:

Ich hatte noch Kopien der WordPress-Ordner im Root belassen, die ich erst nach dem erfolgreichen Verschieben der WP-Installation löschen wollte – da kamen alle in Nr. 112 geschilderten Interferenzen her.

@fpr
Alles klar, freut mich.

@michi

Kann man sicherlich machen. Allerdings, wenn ein Wurm sich einen Administrationszugang verschafft hat, dann geht er nicht den Weg über den Theme-Editor, sondern schreibt direkt in die Template-Datei. Oder halt in mehrere.

ok, dann bringt dass wohl nix, außer wenn sich eine fremde Person sich irgendwie eingelogt hat und Änderungen vornehmen will. oder?

wenn ich aber die Rechte des Themeordners so einstelle, dass ich nur noch per ftp drauf zugreifen kann, bringt das sicherlich mehr oder?
Kann mir evt jemand sagen wie ich die Rechte des Theme-Ordners am besten einstelle?

Michi, mit Sicherheit bringt es was. Allerdings kann ich dir jetzt nicht sagen, wie die Rechte eingestellt werden müssen. Einfach ausprobieren? Sonst ein wenig googeln…

Moin Moin,
danke für die Tipps :)

Aber ich habe da noch eine Frage: Gibt es immer noch keine Möglichkeit den wp-admin Ordner auszulagern?
Hab schon gegoogelt und so, aber find das so gut wie nichts.

Grüße aus Hamburg, Holger

@Holger
Diese Möglichkeit ist mir nicht bekannt. Ich vermute, das geht aus technischen Gründen nicht, da dieser Bereich doch an zahlreichen Stellen mit festen Pfaden arbeitet.

Doch eigentlich, wenn du die Login-Seite mit der .htaccess sperrst, dann kommt auch so keiner an deinen Admin-Bereich ran.

Super Informationen! Werde das Ganze gleich nochmals durchlesen, damit s besser hängen bleibt :-)

Eine weitere Idee ist es noch wp-admin mit einer .htaccess zu versehen, wo alle IP, bis auf die eigene, verweigert werden.

@Mario
Ich habe diesen Art des Schutzes absichtlich nicht in die Liste aufgenommen, da die meisten Nutzer über eine dynamisch zugewiesene IP verfügen. Und diese in die .htaccess einzutragen macht keinen Sinn und sorgt nur für unnötige Nachfragen hier im Blog, sobald sich die IP geändert und der Schutz wie von selbst “aufgehoben” hat.

Ich versteh nicht, warum man die wp-config schützen sollte. Es wird doch eh eine leere Seite zurückgegeben, wenn man sie aufruft und (zum Glück) nicht die Konstanten!

@Markus
Idealerweise schützt man alle Systemdateien – nicht vor Aufrufen, sondern von gezielten Angriffen (wenn man weiß, wo sie ungeschützt liegt).

Bin froh, dass ich diese Tipps gefunden hab! Man lernt echt nie aus…Danke für die Infos und weiter so!

Hallo – wenn ich wie unter Pkt. 1 beschrieben die WP-Installation in ein Unterverzeichnis lege, kann ich doch den Pkt. 3 anwenden und neben der geänderten index.php die wp-config in die Domain-Root legen. (für eine WP-Installation). Diese erhält dann den Schutz aus Pkt. 4 und fertig.

Mit fertig war ich zu voreilig. Wie geht das dann mit den Permalinks?! Wie werden in einem solchen Fall die Pfadangaben in der .htaccess?! Oder fehlt etwas in den von WP vorgeschlagenen Zeilen gänzlich?

Peter, deine “Lösung” hab ich sowieso nicht ganz verstanden, daher kann ich dir auch keinen Tipp zu der .htaccess geben. Alternativ im Web suchen.

Hallo,

vielen Dank für die vielen guten Tipps, ich habe den größten Teil der Einstellungen schnell und unkompliziert realisiert. Ich werde diesen Post auf meinem Blog verlinken.

Thx
Christian

Christian, herzlichen Dank für die Empfehlung in deinem Blog.

hallo sergej!
habe gerade mal deinen tipp probiert, mit “define(‘FORCE_SSL_ADMIN’, true);” den admin bereich auf SSl umzulenken.

auf meinem webserver habe ich aber nun einen “httpdocs” und einen “httpsdocs” ordner. er versucht natürlich nun auf den ordner “wp-admin” in “httpsdocs” zuzugreifen. der is aber weiterhin im standard-httpdocs verzeichnis…

kann ich selber da noch was beeinflussen oder is das ne webserver-konfig geschichte?

hast du eine idee oder tipp? danke

Marco, dazu kann ich dir leider nichts sagen, da ich mit der Server-Struktur auf SSL-Basis überhaupt nicht auskenne. Eventuell eine Anfragen in diesem Kontext im WordPress Deutschland Forum stellen, da wird schnell geholfen.

Hi,

besten Dank für die sehr hilfreichen Tipps. Hab schon angefangen gewisse Teile umzusetzten. Ist vor allem für Kunden wichtig, dass mit Ihrer Seite kein Unsinn getrieben werden kann.

Thanks a lot

Hallo Sergej,

danke für diesen wirlich lehrreichen Artikel. werde es schnellstmöglich umsetzen! Leider hab ich irgendwie Probleme mit der Rechte-Vergabe! Viell. krieg ich es ja irgendwie hin. Wenn nicht, hoffe ich, dass Du mir Rede und Antwort stehst! ;)

Beste Grüße

Christoph, schreib mir notfalls eine E-Mail, helfe gern.

Hallo Sergej,

ich habe gestern Deinen Artikel entdeckt, da ich selbst über das Thema WP als CMS für Affiliate-Starter schreiben wollte. Das Thema Sicherheit ist natürlich super wichtig, gerade auch für Beginner, die sich noch nicht so recht mit WP auskennen. Ich hab im Blogpost auf Deinen Artikel verlinkt! Super geschrieben!

Hi,

danke für diesen tollen Artikel. Ich fange gerade ganz neu an mit WP. Leider unterstützt mein Hoster nur SSL-Proxy. Die anderen Lösungen sind aber top!

VG
Daniel

Vielen Dank für die guten Tipps und ich habe mir diesen Blog gleich einmal abgespeichert.

Hallo Sergey,

vielen Dank für diesen tollen Beitrag. Ich denke es wird viel zuwenig über die Sicherheit bzw. sichere Passwörter nachgedacht wird.