WordPress Sicherheit | 10 Schritte zum Schutz des Admin-Bereichs! (2024)

Der Administrationsbereich einer Webanwendung ist das beliebteste Ziel der Angreifer und gehört somit besonders gut und wirksam geschützt. Nicht anders ist es in WordPress.

Beim Initialisieren eines neuen Blog legt das System einen Administrationsnutzer mit einem durchaus sicheren Passwort an und sperrt den öffentlichen Zugang zum Bereich mit sämtlichen Einstellungen durch eine Login-Seite ab. Der Grundstein der Absicherung ist gelegt. Wir graben tiefer!

Dem Missbrauch aktiv vorbeugen

Dieser Artikel beschäftigt sich ausschließlich mit der Verteidigung des Administrationsbereichs in WordPress – gemeint sind also all die Seiten im Ordner wp-admin bzw. http://www.domain.de/wp-admin/, die nach der Verifizierung des Nutzers im Browser angesteuert werden.

Die Wortgruppe “Verifizierung des Nutzers” im vorigen Satz ist absichtlich hervorgehoben: Sie soll klar und deutlich machen, dass zwischen böswilligem Friedensstörer und mächtigem Admin-Bereich eines ganzen Blog nur eine simple Abfrage für Zugangsdaten geschaltet ist. Und die Letztere ist so dumm, wie die generierten Passwörter.

Damit ein Provokateur es beim Eindringen ins Blog-Innere nicht unbedingt einfach hat, gehören nachfolgende Maßnahmen manuell ausgeführt. Eine hundertprozentige Sicherheit können auch diese Lösungen nicht gewährleisten, effektive Stolpersteine werden jedoch auf dem Weg zum Administrationsbereich gestreut.

1. Umbenennung und Upload des WordPress-Ordners

Seit der Version 2.6 erlaubt WordPress die Auslagerung des wp-content-Verzeichnisses – fatalerweise aber nicht des wp-admin. Mit dieser Tatsache muss sich der sicherheitsbewusste Blogger abfinden und hoffen, dass auch diese für den Schutz eines Blog relevante Möglichkeit bald zum Lieferumfang der machbaren Systemanpassungen gehört.

Bis dahin stellt folgendes Patentrezept eine beinahe äquivalente Alternative dar: Nach dem Extrahieren der heruntergeladenen ZIP-Datei mit komprimierten WordPress-Dateien, erhält man einen Ordner mit wordpress als Namen. Dieser Ordner soll nun nach Wünschen (bestenfalls kryptisch) umbenannt und zum späteren Zeitpunkt, sprich nach den Anpassungen der wp-config.php, ins Hauptverzeichnis der Domain hochgeladen werden.

Was bringt die Änderung mit sich?

• Erstens: Dadurch dass die Dateien nicht mehr lose im Hauptverzeichnis liegen, steigt die Übersichtlichkeit der Root-Ebene. Andere Files und Ordner werden prompter gefunden.
• Zweitens: Beliebig viele WordPress-Instanzen können nach diesem Muster parallel zueinander aufgesetzt werden, ohne dass Systemdateien miteinander kollidieren oder Einstellungen durcheinander kommen. Perfekt für Tests und Entwicklungen.
• Der dritte Vorteil geht aber tatsächlich in Richtung Sicherheit: Der Administrationsbereich (ebenfalls der Blog selbst) liegt nicht mehr im Root der Domain und muss von los geschickten Robotern erst ausfindig gemacht werden. Aller Voraussicht nach lässt sich der Pfad der durch die Lösung durch eine verschobenen Login-Seite wieder aufs Neue herausfinden – spätestens mit Hilfe eines Menschen. Bis dahin stellt der dargestellte Kompromiss eine standhafte Barriere mit vielversprechenden Resultaten dar.

Tipp:

Liegen Systemdateien eines WordPress-Blog nicht mehr im Hauptverzeichnis und auch der Hauptordner der Installation wurde – wie oben empfohlen – im Namen verändert, so kann der Blog dennoch unter meinblog.de erreichbar sein. Wie? Ins Feld WordPress-Adresse (URL) in den Allgemeinen Einstellungen gehört der Pfad des umbenannten Ordners eingefügt.

Ein Beispiel zum Verständnis: Wurde der entpackte wordpress-Ordner in wordpress_live_Ts6K editiert, so lautet der einzutragende Pfad meinblog.de/wordpress_live_Ts6K. Dazu die index.php aus dem Verzeichnis wordpress_XXX in die Root-Ebene verschieben, folgend im Texteditor öffnen und die Codezeile mit dem Pfad zu wp-blog-header.php um den Ordnernamen erweitern.

2. Erweiterung der Datei wp-config.php

Die WordPress-Konfigurationsdatei wp-config.php beinhaltet Einstellungen und Zugangsdaten für die verwendete Datenbank. Aber auch sicherheitsrelevante Werte finden in der Datei den verdienten Platz.

Folgende Definitionen gehören in die Config (können aber auch bereits ihre Existenz vorweisen) und müssen vervollständigt oder modifiziert werden:

• Sicherheitskeys: Seit WordPress 2.7 sind es 4 von der Sorte und müssen mit entsprechenden Werten versehen werden. WordPress denkt auch hier mit und erspart einem das Ausdenken der Zeichenfolgen und generiert die Zeilen mit Sicherheitsschlüsseln automatisch. Die Ausgabe muss lediglich in die Konfigurationsdatei eingesetzt werden. Diese Schlüssel tragen aktiv der Sicherheit des installierten Blog bei.
• Das Tabellen-Präfix einer neu aufgesetzten WordPress-Installation soll dem Standard “wp_” auf jedem Fall abweichen. Je kryptischer die Wortbildung, desto unwahrscheinlicher ist ein Einbruch in die Tabellen der mySQL-Datenbank. Schlecht: $table_prefix = ‚wp_‘;. Perfekt: $table_prefix = ‚wp4FZ52Y_‘;. Dieser Wert wird nur einmalig zugewiesen und muss nicht gemerkt bzw. notiert werden, da die Variable einen internen Charakter besitzt.
• Falls der Server mit aufgesetztem Blog über eine SSL-Verschlüsselung verfügt, so empfiehlt es sich, den Administrationsbereich von der Maschine verschlüsseln zu lassen. Dafür ist nachfolgender Befehl in der wp-config.php zuständig: define(‚FORCE_SSL_ADMIN‘, true);
• Ergänzend lassen sich weitere Systemeinstellungen in der Konfigurationsdatei justieren. Eine übersichtliche und verständliche Auflistung der möglichen Schalter für mehr Sicherheit und Performance befindet sich im WordPress Codex.

3. Verschiebung der Datei wp-config.php

Ebenfalls seit WordPress 2.6 ist es zugelassen, das File wp-config.php zu bewegen und zwar um eine Ebene höher. Da in dieser Datei systemweit die empfindlichsten Informationen gelagert werden, macht es definitiv Sinn diese an einem Ort außerhalb der eigentlichen Installation aufzubewahren, da man nicht ohne Mühen auf das Dateisystem der übergeordneten Serverebene zugreifen kann.

Übrigens schaut WordPress vollkommen automatisch im höher liegenden Verzeichnis nach der Datei mit Konfigurationseinstellungen. Die Bekanntgabe des neuen Pfades wird somit obsolet.

4. Nachhaltiger Schutz der Datei wp-config.php

Allerdings erlauben nicht alle Provider eine Verschiebung der Daten auf die höhere Ebene vom Hauptverzeichnis aus gesehen. So kann es schnell passieren, dass der 3. Schritt gar nicht ausgeführt werden kann, da nicht ausreichend Rechte vorhanden.

In solcher Situation können externe Zugriffe auf wp-config.php leicht und erprobt mittels .htaccess ausgesperrt werden. Dafür zuständiger Code:

Es ist darauf zu achten, dass die .htaccess mit eingebautem Schutzschild sich das Verzeichnis mit der wp-config.php teilt, sprich beide befinden sich im gleichen Ordner. Übrigens kommt diese Technik auch dann zum produktiven Einsatz, wenn mehrere WordPress-Installationen zugleich in Verwendung sind und Auslagerungen der jeweiligen Konfigurationsdateien nicht in Frage kommen.

5. Löschung des Admin-Nutzeraccounts

Ein Administrator mit dem Benutzernamen admin wird bereits während der Installation des Blog automatisch und optionslos angelegt (seit WordPress 3.0 kann der Name des Default-Accounts beim Anlegen des Blogs geändert werden).

Gut gemeinte Geste seitens WordPress, doch vom Standardnutzer mit Administrationsrechten und ihm zugewiesener ID #1 gehen auch die Roboter der Ganoven aus. Beim eventuellen Überfall müsste nur noch das hinterlegte Passwort des Benutzers enträtselt werden. Daher der Ratschlag:

• Im Admin-Bereich einen zusätzlichen Administrator hinzufügen.
• Logout aus dem Backend.
• Sich mit den Zugangsdaten des eben angelegten Administrators anmelden.
• Den alten Bekannten admin aus der Benutzerliste streichen.

Noch mehr Vertrauen und Sicherheit schafft ein zusätzlich angelegter Autor: in seinem Namen werden alle künftigen Artikel veröffentlicht und kommentiert, so dass die Namenbezeichnung des Administrators nie auf Blogseiten erwähnt und somit nimmer nach Außen kommuniziert wird.

6. Wahl starker Passwörter

Die Wahrscheinlichkeit und Frequenz der Angriffe auf einen Blog steigt proportional zur Popularität der jeweiligen Website. Ausgerechnet dann, wenn das Backend einer WordPress-Instanz absichtlich und gekonnt angegriffen wird, darf es keine schwachen Glieder in der Kette der zusammengehörigen Schutzmechanismen geben.

Nicht selten, dafür aber gerne repräsentieren Passwörter in den Zugangsdaten zum Administrationsbereich das schwächste Glied. Der Grund: Der Umgang mit dem Passwort oder die Wahl der erforderlichen Zeichenkette geht viel zu leichtsinnig von statten. Zahlreiche Studien belegen kläglich, die überwiegende Anzahl der Kennwörter besteht zweifellos aus zu wenigen, zu einfachen Zeichen. Das Ergebnis: Die gewählte Kombination kann mühelos erraten werden.

WordPress reagiert auf die akute Problematik mit zu simplen Passwörtern und bringt einen intuitiven Indikator für die Anzeige der aktuellen Passwortstärke nach dem Ampelprinzip mit. Aus unerklärlichen Gründen stellt der Indikator seine Dienste ausschließlich bei der Bearbeitung des gegenwärtigen Profils zur Verfügung (zu finden unter Einstellungen -> Benutzer -> Ihr Profil). Werden vom Administrator neue Nutzer angelegt, so wird die Stärke des Kennwortes optisch nicht kommuniziert.

Folgende Empfehlung für ein sicheres und stabiles Passwort gibt WordPress ab: Das Passwort sollte mindestens 7 Zeichen lang sein. Um es sicherer zu machen, verwenden Sie Groß-/Kleinschreibung, Ziffern und Symbole wie ! ” ? $ % ^ & ).

7. Verzeichnisschutz für wp-login.php

Ganz dem Motto “Doppelt hält besser” entspricht folgender Ansatz: Die Loginseite des Administrationsbereichs wird mit einem zusätzlichen Passwortschutz ausgestattet. Warum allein die Anmeldeseite, wäre die Abgrenzung des kompletten Adminbereichs nicht effektiver gewesen?

Die Erfahrung hat gezeigt, dass WordPress auch außerhalb des Backends an diversen Stellen auf die Dateien aus dem wp-admin-Verzeichnis zugreift, z. B. im Flash-Uploader oder bei der Ausgabe der Fehlermeldungen nach dem Absenden eines unvollständigen Kommentars. Außerdem leitet WordPress automatisch jede ans Backend gerichtete und unautorisierte Anfrage zum Login zurück.

Die Abfrageroutine übernimmt die – in WordPress sonst für Permalinks zuständige – Datei .htaccess, welche zusammen mit der .htpasswd im selben Ordner wie die Datei wp-login.php abgelegt wird. Nach der Inbetriebnahme der Lösung und beim Aufruf des Admin-Bereichs fragt der Browser die in der .htaccess gespeicherten Zugangsdaten ab – diese können für jeden Blogautor unterschiedlich oder für das gesamte Team einheitlich sein.

Gehört in die .htaccess:

# protect wp-login.php
<files wp-login.php>
AuthName „Admin-Bereich“
AuthType Basic
AuthUserFile /lokaler-pfad-zu/.htpasswd
require valid-user
</files>

Tipp: Der Htpasswd Generator unterstützt bei der Dateierstellung mit gewünschten Werten.

8. Unterdrückung von Fehlerhinweisen auf der Login-Seite

Die Login-Seite einer WordPress-Installation ist die Eingangstür zum Steuerungspult eines Blog: Der Administrationsbereich ist erst nach einer fehlerfreien Verifizierung begeh- und bedienbar. Bis zum erfolgreichen Login hat der Besucher – ob gut oder böse – unzählige Versuche, korrekte Zugangsdaten in die Eingabefelder der Abfrage einzugeben. Im Fehlerfall kommuniziert WordPress netterweise den entsprechenden Hinweis.

Bei der Fehlerbehandlung ist WordPress wirklich penibel und hält für jedes Fehlverhalten eine eigenständige, aussagekräftige Meldung parat. Wird also der Benutzername falsch eingetippt, wird es geäußert. Ist im Kennwort ein Vertipper, so wird auch das zum Ausdruck gebracht.

Bequem für den Nutzer, komfortabel für den Dieb. Aus dem Buch “Blog-Einbruch für Dummies”: Unbewusst versorgt WordPress den Langfinger beim Ausprobieren der Zugangsdaten mit wertvollem Feedback. Es ist nur eine Frage der Zeit bis der Gauner sich den Zugang zum Backend verschafft hat.

Ein Einzeiler verspricht Hilfe und löst das Problem auf die schlaue Weise: Die Ausgabe der Fehlermeldungen auf der Login-Seite wird schlicht und einfach unterbunden, um Plünderer im Dunkelt tappen zu lassen. Dieser Code gehört in die functions.php des verwendeten Theme:

9. Beschränkung der fehlerhaften Login-Versuche

Unbehandelt führt WordPress keinerlei Protokoll über Misserfolge der Anmeldungen auf der Login-Seite – sehr zum Nachteil des Blog-Administrators, der die hinterhältige Gefahr nicht kommen sieht und entsprechend keine Schritte zur Bekämpfung unternehmen bzw. einleiten kann. Gibt es einen Ausweg aus dem Dilemma?

Mit Login LockDown und Limit Login Attempts existieren zwei Lösungen auf dem Markt, die nach der Aktivierung alle gestarteten Login-Anfragen aufzeichnen. Ferner sind die beiden WordPress-Erweiterungen in der Lage, Besucher nach einer bestimmten Anzahl an Fehlversuchen für eine in den Einstellungen festgelegte Sperrzeit vom Login auszuschließen. So werden Roboter und Hacker in ihrem Handwerk aktiv gehindert.

10. Software Up-to-Date halten

Zum Schluss sei noch Folgendes gesagt: WordPress-Entwickler sind sehr fleißig und reagieren unverzüglich auf bekanntgewordene Sicherheitslücken innerhalb der Blog-Software. Halte die Installationen also auf dem aktuellsten Stand, seit WordPress 2.7 ist das verfügbare Update nur einen Klick entfernt. Dito für verwendete Plugins!

Weniger ist mehr: Als Verantwortlicher des Projekts dafür Sorge tragen, dass in der Pluginverwaltung nur die nötigsten Erweiterungen im aktiven Zustand sind. Jedes Plugin stellt ein potentielles Risiko dar und sollte bei Nichtnutzung auf inaktiv gesetzt oder gar entfernt werden.

Loading...