Der Administrator ist bei einer WordPress-Installation das Konto, mit dem man im Ernstfall praktisch alles darf: Plugins installieren, Benutzer verwalten, Einstellungen verändern und im Zweifel auch eine ganze Website gründlich zerlegen.
Genau deshalb lohnt es sich unbedingt, dieses Konto deutlich sorgfältiger zu behandeln als den Zugang zu irgendeinem Newsletter.
Früher gehörte zu den üblichen WordPress-Sicherheitstipps fast schon automatisch die Empfehlung, die Benutzer-ID des Administrators zu ändern. Bei einer normalen frischen WordPress-Installation wird der erste Benutzer sofort angelegt und erhält aufgrund der fortlaufenden Nummerierung ganz üblich ID 1 zugewiesen.
Das klingt zunächst nach einem schwierigen Problem. Der Angreifer kennt damit schon eine erste Information über das Administratorkonto.
Nur: So eine Benutzer-ID ist noch lange kein Passwort. Und sie ist ganz klar auch kein Sicherheitsmerkmal, auf dessen Geheimhaltung ich mich verlassen würde.
Die Administrator-ID 1 ist nicht die eigentliche Schwachstelle
Wenn mein Sicherheitskonzept davon abhängt, dass niemand weiß, dass mein Administrator möglicherweise die Nummer 1 trägt, habe ich kein Sicherheitskonzept. Ich habe Hoffnung mit Datenbankanschluss.
Eine andere Benutzer-ID kann einen automatisierten Angriff an einzelnen Stellen etwas unbequemer machen. Mehr sollte man daraus aber nicht machen. WordPress verwendet Benutzer-IDs intern an vielen Stellen und behandelt sie nicht grundsätzlich als geheime Information.
Deshalb würde ich heute andere Maßnahmen deutlich weiter oben auf die Liste setzen:
- einen nicht leicht erratbaren Benutzernamen verwenden
- ein langes, einzigartiges und möglichst zufällig erzeugtes Passwort verwenden
- Zwei-Faktor-Authentifizierung für das Administratorkonto aktivieren
- WordPress, Plugins und Themes aktuell halten
- nicht benötigte Benutzerkonten entfernen
- dem Administrator nur dann verwenden, wenn tatsächlich Administratorrechte benötigt werden
- regelmäßige und überprüfte Backups vorhalten
Die ID zu verändern kann zusätzlich erfolgen. Sie ersetzt aber keinen dieser Punkte.
Admin, Administrator und Webmaster sind keine besonders kreativen Benutzernamen
Beim Benutzernamen sieht die Sache schon interessanter aus.
Bezeichnungen wie admin, administrator oder webmaster sind unnötig leicht zu erraten. Damit nimmt man einem Angreifer zumindest einen Teil der Arbeit ab. Genau das muss nun wirklich nicht sein.
Der Benutzername sollte deshalb nicht unmittelbar verraten, welche Aufgabe dieses Konto hat. Auch der Domainname oder der Firmenname sind für ein Administratorkonto nicht unbedingt die erste Wahl.
Man muss daraus allerdings ebenfalls kein Geheimdienstprojekt machen. Ein unauffälliger Benutzername hilft. Die eigentliche Verteidigung übernehmen anschließend Passwort, zweiter Faktor und eine vernünftige Rechteverteilung.
Das Passwort ist wesentlich wichtiger als die Benutzer-ID
Passwörter wie 123456, Passwort, admin123 oder der eigene Domainname scheiden aus offensichtlichen Gründen aus.
Ich würde ein langes, einzigartiges und zufällig erzeugtes Passwort verwenden und es in einem Passwortmanager speichern. Dann muss ich mir keine vermeintlich clevere Konstruktion überlegen, die aus dem Namen des Hundes, dem Geburtsjahr und einem Ausrufezeichen besteht und nach fünf Minuten doch wieder erraten werden kann.
Zusätzlich gehört für mich beim Administratorkonto eine Zwei-Faktor-Authentifizierung dazu. Selbst wenn das Passwort irgendwann abgegriffen wird, reicht es dann allein noch nicht für die Anmeldung.
Das ist ein erheblich wertvollerer Sicherheitsbaustein als die Frage, ob mein Administrator die ID 1, 73 oder 546872 besitzt.
Für Beiträge brauche ich meistens keinen Administrator
Eine Maßnahme gefällt mir besonders, weil sie einfach ist und tatsächlich das mögliche Schadensausmaß begrenzt: Ich verwende das Administratorkonto nicht für die tägliche Veröffentlichung von Inhalten.
Wer hauptsächlich eigene Beiträge schreibt und veröffentlicht, kann dafür ein separates Autorenkonto verwenden. Müssen zusätzlich Seiten oder Inhalte anderer Benutzer bearbeitet werden, kommt je nach Arbeitsweise ein Redakteurkonto infrage.
Der Administrator bleibt für administrative Arbeiten reserviert.
Das hat mehrere Vorteile. Wenn ich an verschiedenen Rechnern arbeite, muss ich dort nicht überall die Zugangsdaten meines wichtigsten Kontos verwenden oder speichern. Wird mein Autorenkonto kompromittiert, besitzt der Angreifer außerdem nicht automatisch die vollständigen Administratorrechte über WordPress.
Das entspricht einem ziemlich einfachen Prinzip: Ein Konto bekommt nur die Rechte, die es für seine Aufgabe tatsächlich benötigt.
Ich gehe schließlich auch nicht mit dem Generalschlüssel des gesamten Gebäudes einkaufen, nur weil ich anschließend wieder hineinmöchte.
Und was ist nun mit der Benutzer-ID 1?
Wer eine neue WordPress-Installation gerade vorbereitet und die Administrator-ID trotzdem ändern möchte, kann das tun. Ich betrachte das als zusätzliche kleine Härtungsmaßnahme, nicht als tragende Wand des Sicherheitskonzepts.
Und an dieser Stelle kommt der wichtigste Hinweis:
Ich würde eine Benutzer-ID nicht ohne guten Grund nachträglich in einer bereits länger laufenden Website verändern.
WordPress verbindet Benutzer-IDs nicht nur mit der eigentlichen Benutzertabelle. Beiträge speichern beispielsweise die ID ihres Autors, Benutzermetadaten hängen ebenfalls an dieser Nummer und weitere WordPress-Bereiche oder Plugins können eigene Verknüpfungen zur Benutzer-ID angelegt haben.
Wer nur einen einzigen Datenbankeintrag ändert und anschließend zufrieden den Laptop zuklappt, kann deshalb am nächsten Morgen feststellen, dass seine Vorbereitung hauptsächlich darin bestand, sich selbst ein Problem zu bauen.
Wenn überhaupt, dann bei einer frischen Installation
Wenn ich die Administrator-ID ändern möchte, mache ich das möglichst früh: bevor die Website mit Inhalten gefüllt wurde und bevor zahlreiche Plugins Daten zum Benutzer gespeichert haben.
Vorher erstelle ich trotzdem ein vollständiges Backup der Datenbank und der WordPress-Dateien. Bei direkter Arbeit an einer Datenbank gibt es für mich keine Kategorie „Das dauert nur zehn Sekunden, da kann nichts passieren“.
Anschließend öffne ich über meinen Webhoster die zur WordPress-Installation gehörende Datenbank, beispielsweise mit phpMyAdmin.
Die Tabellen beginnen bei einer Standardinstallation häufig mit wp_. Wurde ein anderer Tabellenpräfix festgelegt, muss dieser selbstverständlich auch in den folgenden Befehlen verwendet werden.
Die ID in der Datenbank ändern
Angenommen, der bisherige Administrator besitzt die Benutzer-ID 1 und soll die neue ID 546872 erhalten.
In der Benutzertabelle wird zunächst die eigentliche ID geändert:
UPDATE wp_users
SET ID = 546872
WHERE ID = 1;Danach müssen mindestens die dazugehörigen Benutzermetadaten angepasst werden:
UPDATE wp_usermeta
SET user_id = 546872
WHERE user_id = 1;Damit ist bei einer bereits verwendeten Installation aber noch längst nicht garantiert, dass alle Beziehungen korrigiert wurden.
WordPress speichert beispielsweise den Autor eines Beitrags separat. Deshalb müsste bei vorhandenen Inhalten auch diese Zuordnung berücksichtigt werden:
UPDATE wp_posts
SET post_author = 546872
WHERE post_author = 1;Auch angemeldete Benutzer können mit Kommentaren verknüpft sein:
UPDATE wp_comments
SET user_id = 546872
WHERE user_id = 1;In der WordPress-Kerndatenbank existiert außerdem bei den Linkdaten eine Eigentümer-ID:
UPDATE wp_links
SET link_owner = 546872
WHERE link_owner = 1;Und jetzt kommt der Grund, weshalb ich diese Aktion bei einem gewachsenen System nicht leichtfertig durchführen würde: Plugins können zusätzliche Tabellen besitzen und dort ebenfalls Benutzer-IDs speichern.
Die fünf Abfragen oben können deshalb die WordPress-Kerntabellen berücksichtigen. Sie garantieren nicht, dass irgendein Plugin nicht noch eine sechste oder siebte Stelle kennt, von der wir gerade nichts wissen.
Bei einer laufenden Website gibt es eine sauberere Alternative
Bei einer bestehenden Website würde ich deshalb eher ein neues Administratorkonto mit einem unauffälligen Benutzernamen, einem starken eigenen Passwort und Zwei-Faktor-Authentifizierung anlegen.
Dann melde ich mich mit diesem Konto an und überprüfe zunächst, ob wirklich alle benötigten administrativen Funktionen vorhanden sind.
Erst danach kann das alte Administratorkonto stillgelegt beziehungsweise entfernt werden. Falls diesem alten Konto Inhalte gehören, müssen diese vorher einem anderen Benutzer zugeordnet werden.
Damit erhält man automatisch eine andere Benutzer-ID, ohne die Primär-ID eines bestehenden Kontos quer durch eine gewachsene Datenbank umzuschreiben.
Das ist weniger spektakulär. Dafür ist die Wahrscheinlichkeit geringer, dass anschließend irgendein Plugin beleidigt in der Ecke sitzt.
Keine Scheinbenutzer zur Tarnung anlegen
Früher habe ich zusätzlich mehrere fiktive Benutzerkonten mit unterschiedlichen IDs angelegt, damit aus der Reihenfolge der Benutzerkonten möglichst wenig abzulesen war.
Das würde ich heute nicht mehr empfehlen.
Zusätzliche Konten nur zur Verschleierung erzeugen keinen nennenswerten Sicherheitsgewinn. Stattdessen habe ich anschließend mehr Benutzerkonten, die gepflegt, abgesichert und irgendwann wieder überprüft werden müssen.
Redundanz ist sinnvoll, wenn sie eine Funktion erfüllt. Fünf Attrappen im Benutzerverzeichnis sind keine Redundanz. Das ist Dekoration.
Auch der Tabellenpräfix ist nur eine zusätzliche Schicht
Bei einer Neuinstallation kann man außerdem den Standardpräfix wp_ durch einen anderen Tabellenpräfix ersetzen.
Das kann automatisierte Angriffe erschweren, die blind von den Standardtabellennamen ausgehen. Auch hier gilt aber dasselbe Prinzip wie bei der Benutzer-ID: Das ist eine zusätzliche kleine Hürde und kein Ersatz für echte Sicherheitsmaßnahmen.
Wenn eine ungepatchte Erweiterung eine ernsthafte Sicherheitslücke besitzt, wird der kreativste Tabellenpräfix der Welt daraus nicht plötzlich sichere Software machen.
Meine Reihenfolge für das Administratorkonto
Wenn ich eine neue WordPress-Installation absichere, würde ich meine Zeit deshalb ungefähr in dieser Reihenfolge investieren:
- unauffälligen Administrator-Benutzernamen wählen
- langes und einzigartiges Passwort erzeugen
- Zwei-Faktor-Authentifizierung einrichten
- Administrator nur für administrative Aufgaben verwenden
- separates Autoren- oder Redakteurkonto für die tägliche Arbeit anlegen
- Backups einrichten und eine Wiederherstellung zumindest grundsätzlich prüfen
- WordPress, Themes und Plugins aktuell halten
- unnötige Konten, Themes und Plugins entfernen
- bei einer Neuinstallation optional Tabellenpräfix und Benutzer-ID vom Standard abweichend wählen
Die ID steht dabei absichtlich ziemlich weit unten.
Man kann sie verändern. Ich mache daraus aber keine magische Schutznummer.
Sicherheit funktioniert besser, wenn mehrere brauchbare Maßnahmen zusammenarbeiten. Ein schwer erratbarer Benutzername, ein starkes Passwort, ein zweiter Faktor und ein separates Konto mit geringeren Rechten bringen mir mehr als die Hoffnung, dass ein Angreifer an einer sechsstelligen Benutzer-ID verzweifelt.
Plan B ist wichtig. Aber zuerst sollte Plan A funktionieren.