WordPress Sicherheit: auf keinen Fall den Admin löschen [großes Update]

[Updates weiter unten!]

Aufschrei in Klein-Bloggersdorf. Land auf, Land ab raten WordPress’ler dazu aus Sicherheitsgründen gleich nach der Installation der Blog-Software den Benutzer “Admin” zu löschen, um so den Hackern und Bots keine Angriffsfläche zu bieten. Wie sich jedoch gezeigt hat, kann gerade dies ein Sicherheitsrisiko darstellen.

Admin als Sicherheitsrisiko
Der erster Rat vieler Experten bei der Verwendung von WordPress ist die Löschung des Benutzers “Admin” respektive die Verwendungen eines neuen Benutzernamens mit den gleichen Admin-Rechten. Das Hauptargument hinter dieser Empfehlung ist die Angriffsfläche, welche der Admin für Hacker und Bots bietet. Mit denen durch einen erfolgreichen Hackerangriff gewonnen Zugangsdaten könnte dann der Blog als SPAM-Schleuder benutzt werden, unbrauchbar gemacht werden oder im schlimmsten Fall der Besitzer erpresst werden. Und nach über einem Jahr Erfahrung mit dem Plugin “Limit Login Attempts”, bei dem eine IP bei drei mal falsch eingegebenem Passwort für 24h (oder mehr; je nach Einstellung) gesperrt wird, hat sich gezeigt, dass ein Großteil von geschätzten 95% der Angriffe immer auf den Benutzer “Admin” erfolgen. Der Verdacht kann damit als bestätigt angenommen werden. Doch das ist nur die halbe Wahrheit.

Die Frage ist, was passiert, wenn der Benutzer “Admin” wirklich komplett gelöscht wird? Die Hacker und Bots sind heute vermutlich nicht mehr so blöd und brechen ihren Angriff ab, wenn diese keinen Admin finden, sondern suchen sich einen “Ersatz-Nutzer” respektive ein “Ersatz-Ziel” und beginnen ihr Spiel von vorne. Gewonnen wäre mit der Löschung des Admins also kaum etwas.

Admin als Honeypot
Dreht man die Überlegung aber um, wird aus dem Admin ein schöner Honeypot. Das einzige was man machen muss, ist dem Admin alle Rechte zu entziehen (natürlich vorher einen neuen Benutzer mit vollen Admin Rechten anlegen) und diesen dann auf “nur lesen” Status setzen.
Als zweiter Schritt erhält der Admin dann ein extrem (extrem extrem) sicheres und kompliziertes Passwort, welches man sich auch nicht merken muss, da der Admin ja kein operativer Benutzer mehr ist und auch keine Veränderungen mehr am Blog vornehmen muss und kann.
Danach können die Bots sich genüsslich am Admin abarbeiten bis sie schwarz werden. Und sollten sie das Passwort doch knacken, können sie bzw. der Hacker nur lesen und nichts schreiben oder Einstellungen ändern. So kommen sie, dies zeigen zumindest die Erfahrungen auf diesem Blog, gar nicht erst oder nur sehr selten auf die Idee nach anderen Nutzer für ihren Angriff zu suchen.

Last but not least kann man als Reserve einen Benutzer mit Admin-Rechten anlegen, der als Hintertür fungiert falls der eigene Benutzername wirklich mal gehackt wird. Da dieser Nutzer keine Artikel schreibt, erscheint dieser auch nicht auf der Website und sollte somit nicht von Bots ausgelesen bzw. als Ziel markiert werden können.

Plugins schützen
Als dritter Punkt – zum einen zur Sicherheit und zum anderen zur Kontrolle – sollte zudem auch immer das Plugin “Limit Login Attempts” oder ein vergleichbares Plugin installiert werden (siehe weiter unten). Das Plugin sperrt nicht nur Bots und Hacker (oder auch richtige Nutzer) nach einer gewissen Anzahl an falsch eingegebene Zugangsdaten anhand der IP-Adresse aus, sondern kann auch per e-Mail darüber informieren, welcher Benutzer angegriffen wurde. So kann für jeden Blog ein Controlling aufgebaut werden, welcher Benutzer angegriffen wird. In Notfall kann dieser Benutzer dann nochmals durch ein noch “sichereres” Passwort geschützt werden.

Habt ihr euren Admin gelöscht?

Update 12. Juli 2015
Ein paar Tage nach dem Erstellen dieses Blogbeitrags bin ich noch zusätzlich auf das Plugin “Rename wp-login.php” gestossen. Dieses Plugin ändert die URL der WordPress-Login-Seite auf einen frei wählbaren Namen ab – aus www.domain.de/wp-login wird also www.domain.de/wasauchimmer.
Folge dieser URL-Änderung war in meinem Fall ein kompletter Stopp aller durch “Limit Login Attempts” gemeldeter Angriffe respektive böswilliger Login-Versuche. Die Bots, so die erste Erkenntnis, finden damit erst gar nicht die richtige Login-Seite. Sollten sich die Bots irgendwann wieder auf die neue URL einschiessen, wird sich zeigen, ob eine weitere Namensänderung helfen wird. Seit der URL-Änderung gab es zumindest keine unerlaubten Login-Versuche mehr.

Update 12. Juli 2015
Da ich in der Xing-Gruppe sehr viel Kritik auf diesen Artikel erhalten hab, möchte ich die Chance nutzen ein paar Gegenargumente hier aufzugreifen. Ich hoffe ich fasse die Gegenargumente hier richtig zusammen.

1. Unerfahrene Nutzer könnten damit überfordert sein, also lieber keine Spielchen und komplett weg mit dem Admin.
Das ist meiner Meinung nach eine Gradwanderung. Ab wann ist ein Nutzer noch unerfahren und ab wann erfahren? Im Gegenargument ging es darum, dass der Nutzer lieber den Admin komplett löschen und gegen einen neuen Nutzer-Namen ersetzen soll. Ich halte dagegen, dass dieser Nutzer dann sowieso bereits so erfahren sein muss, den Admin eigenhändig zu löschen und einen neuen Nutzer mit entsprechenden Rechten zu erstellen. Dieser Nutzer, so meine Meinung, sollte dann auch in der Lage sein ein oder zwei Plugins zu installieren und dem Original-Admin die Nutzer-Rechte (nur) zu entziehen, da mit dem Tipp aus dem Gegenargument ja bereits ein Großteil der Arbeit erledigt ist/wäre. Es würden dann nur noch wenige weiterführende Schritte fehlen. Aber das ist Ansichtssache.

2. Argument “Sicherheitlücken in Plugins”
Dieses Gegenargument halte ich an dieser Stelle für zu allgemein, da jedes Plugin theoretisch Sicherheitlücken aufweisen kann. Demnach darf nie ein Plugin installiert werden. Dem zur Folge unterscheidet sich das/die von mir erwähnten Plugins nicht von anderen Plugins bzw. eröffnet genau gleich viele oder gleich wenig Sicherheitslücken. Außerdem geht dieses Argument davon aus, dass der Hacker Zugriff auf den Nutzer admin hat. In meinem Szenario wird aber bereits vorher versucht, diesen Angriff durch mehrere aufeinander folgende Schritte abzuwehren. Erhält der Angreifer dann doch Zugang, findet er zuerst einen unbrauchbaren Nutzer mit “nur lesen”-Status und müsste dann diese wiederum auf Admin-Level hacken. Es sind also mehrere Sicherheitinstanzen vorgeschaltet.

3. Serverlast bei Angriffen
Das Gegenargument besagt, dass durch die Angriffe der Server stark belasst wird. Diese Aussage ist natürlich richtig. Allerdings kann ich als “Ziel” des Angriff, den Angriffsversuch bzw. die Intervalle/Dauer ja nicht kontrollieren. Ich kann nur versuchen durch Sicherheitsmaßnahmen meinen Blog zu schützen. Ob ich angegriffen werden respektive ob mein Sicherheitsmaßnahmen durch Angreifer herausgefordert werden, kann ich nicht beeinflussen. Mit diesem Argument könnte man auch seine Haustür offen lassen, damit niemand das teure Küchenfenster einschlägt. Und sollte ich den Benutzer “Admin” löschen – wie oft gefordert wird – würden sich nach meine Erfahrung die Bots & Hacker ein neues Ziel suchen. Der Angriff würde also leider nicht, wie vermutet, abgebrochen, sondern nur auf einen anderen Nutzer verlagert. Und dieser würde dann ja genauso viel Serverlast beanspruchen.

4. Den Administrator bei der Installation (oder später) nicht Admin nennen
Meine Erfahrungen zeigen, dass die Bots zwar vermehrt auf den Login “admin” anspringen, aber auch versuchen über andere Nutzernamen in den Blog einzudringen. Meine Erfahrung ist also, dass die Bots durchaus auch darauf trainiert sind andere Nutzer aus dem Blog auszulesen und diese dann in der Login-Maske zu versuchen. Eine reine Änderung des Namens würde – und darum meine Empfehlung den Nutzer-Namen “admin” als rudimentären Nutzer ohne Rechte als Honeypot zu behalten – also sehr wenig bringen.

Zusammenfassung:
Abschließen ist es mir wichtig das Zusammenspiel meiner “Tipps” nochmals herauszuarbeiten, da ich aus den Gegenargumenten herauslese, dass es immer um Einzelaspekte geht.

Die “Bots-Journey”
Der Bot sucht sich die Login-Seite. Findet er diese auf Grund der Namensänderung nicht, bricht er hoffentlich seinen Angriff ab. Findet er diese trotz geänderter URL doch, versucht er zuerst den Nutzer “admin”. Findet er diesen nicht, bricht er – so meine Erfahrung – den Angriff leider nicht ab, sondern sucht sich ein neues Ziel. Findet er den Nutzer admin jedoch, versucht der Bot verschiedene Passwörter. Durch das Plugin “Limit Login Attempts” sind diese Versuche aber begrenzt. Damit sperrt sich der Bot dann hoffentlich schnell aus dem Blog aus. Schafft der Bot es aber doch an diesen Hindernissen vorbei, hat er nur Zugriff auf einen nutzlosen Nutzer genannt “admin”. Natürlich kann er dann versuchen diesen “nur lesen”-Nutzer in einen richtigen Administrator umzuwandeln. Allerdings hätte der Bot – so meine Meinung – durch das Weglassen dieser vorgelagerten “Tipps” bereits viel früher die Chance gehabt auf einen Nutzer mit Admin-Rechten zuzugreifen. Die Kette der “Tipps” ist natürlich irgendwann zu Ende, so wie in jeder Bank die Türen und Schlösser zu Ende sind und der Einbrecher im Trasorraum steht. Wenn es ein Hacker oder Bot an allen Sicherheitsschranken vorbei schafft, dann ist er logischerweise am Ziel. Ich als Besitzer eines Blogs kann dem Angreifer nur so viele Steine in den Weg legen wie möglich.

Last but not least “Sicherheitslücken in Plugin”
Meine Beschreibung funktioniert natürlich nur, wenn der Angriff über die Login-Maske erfolgt.
Sollte ein Angreifer über die Sicherheitslücke eines Plugins, sozusagen über einen Nebeneingang kommen, funktioniert das alles nicht mehr. Aber auch hier muss erwähnt werden, dass meine “Tipps” dies nie suggeriert haben und auch nie sollten. Genausowenig können meine Tipps einen Blog-Besitzer davor schützen was passiert, wenn sich ein Angreifer direkt auf den Server des Hosters einhackt, oder man vergisst sich aus seinem Bog auszuloggen und der nachfolgende Computer-Nutzer durch das Cookie einen offenen Blog vorfindet. Die von mir beschriebenen Tipps können nur eine von vielen Ebenen abdecken.

UPDATE 4.10.2015
Folgende Plugins wurden ebenfalls vorgeschlagen, wurde aber von mir bis dato nicht getestet. Beide Plugins sollen Ersatz für das veraltet Plugin „Limit Login Attempts“ sein, welches leider seit mehreren Jahren nicht mehr aktualisiert wird.
Wordfence
Login LockDown

UPDATE Dezember 2015
Das allerwichtigste sind natürlich sehr sichere Passwörter. Diese bilden – man verzeihe mir die Formulierung – die wichtigste Verteidigungslinie vor Angriffen.

UPDATE Januar 2016:
Es erscheinen wieder die ersten Angriff respektive fehlerhafte Login-Versuche auf die WordPress-Login Seite. Das heisst, dass die Bots (und Hacker?) ziemlich genau sechs Monate (Anfang Juli bis Anfang Januar) gebraucht haben, die durch das Plugin “Rename wp-login.php” geänderte URL der WordPress-Login Seite herauszufinden. Es wird sich nun in einem zweiten Schritt zeigen, ob eine erneute Änderung der URL eine gleichlange Pause vor Angriffen ergibt, oder ob die Bots nun schlauer geworden sind. Stay tuned 😉

UPDATE – Mai 2018

WP-Admin verstecken: Beliebt, aufwändig und nicht sonderlich effektiv

Ralf Bachmann

Content Marketing Manager

Generalist: Projektmanager mit Faible Content Marketing & Social Media, ausgebildeter Journalist & PR-Berater, Erfahrung in Unternehmenskommunikation, Digitalisierung und Collaboration-Tools.