WordPress-Sicherheit – WP Security meldet „Your table prefix is wp_“

Das WordPress-Plugin WP Security und der Befund „Your table prefix is wp_“

Hinweis: jede der folgenden Handlungen geschieht auf eigene Gefahr. Der Autor beschreibt nur allgemein seine Erfahrung und schließt jede Haftung für Schäden aus. Die individuellen Gegebenheiten oder auch vorhandene Fehlerzustände fremder Systeme sind nicht vorhersehbar. Wie bei jedem Eingriff dieser Art kann ein System dabei auch zerstört werden und Daten verloren gehen. Sichern Sie vor solchen Operationen ihr System und ihre Daten.

Hintergrund – was ist der Tabellenpräfix?

WordPress speichert die meisten Content-Daten in einer Datenbank. Datenbanken enthalten Tabellen mit Datensätzen. Im Prinzip können in einer Datenbank auch mehrere Systeme ihre Daten ablegen. Praxisnah: Der Vertrag mit dem Provider erlaubt nur eine Datenbank – man möchte aber mehrere äußerlich unabhängige kleine Domains betreiben.

Hier kommen nun die Tabellenpräfixe ins Spiel: Anstatt die Tabellen für Artikel (engl.: Posts), Seiten (engl.: Pages), Kommentare (engl.: comments) etc. flach posts, pages, comments etc. zu benennen, haben die WordPress-Entwickler jeder Tabelle noch einen „Vornamen“ mitgegeben. Die Tabellen heißen also im Standard z.B. wp_posts, wp_pages, wp_comments etc. Und noch besser: Diese in Fachkreisen Präfixe genannten Zeichenketten können je Blog vergeben werden. So kann man z.B. die Daten zweier Blogs in nur einer Datenbank halten: einfach verschiedene Präfixe wie etwa „wpfotoladen_“ und „wpimmobilien_“ vergeben, und schon können alle benötigten Tabellen in einer Datenbank parallel gespeichert werden. Aus Sicht der Datenbank sind die Tabellennamen wpfotoladen_posts und wpimmobilien_posts unterschiedlich. Das Zusammensetzen von Präfix und benötigter Tabelle zum Zugriff regelt WordPress. So weit so gut.

WordPress Datenbank-Tabellen: Jeder Angreifer weiß um diesen Aufbau natürlich auch

Das Problem mit den Standardpräfixen

Standardgemäß – also ohne Eingriff eines Admininstrators – ist der Präfix immer „wp_“. Wenn man weiß, dass eine Website auf WordPress läuft, weiß man somit auch, dass eine Datenbank dahinterhängt und sogar welche Tabellennamen es sehr wahrscheinlich gibt. In der Vergangenheit haben diese Wissensfragmente leider oft ausgereicht, um Einbrüche in WordPress-Systeme ermöglichen. Einbrecher können …

… Daten über alle Benutzer ausspähen. Da man WordPress so gestalten kann, dass Kommentare etc. nur nach Anmeldung möglich sind, kann ein solches System relativ viele Benutzerdaten haben. Wenn der Blog dann noch ein Hobbythema beinhaltet, wo einfache Nutzer auch einfache Passwörter – und vor allem überall dieselben Passwörter verwenden – kann das schon ärgerlich sein.
… Code zur Infiltration von Besuchern installieren. Das WordPress-System wird dann als Viren- oder Trojaner-Schleuder missbraucht. So bleiben professionelle Betrüger und Hacker selbst im Dunkeln. Für diesen Zweck eignen sich auch echte Randthemen. Die Hacker legen hierbei gar nicht immer großen Wert auf irgendwelche „Big Sites“. Dort fällt sowas nämlich auch schneller auf, es gibt Admins, die das sofort tilgen. Kurzum: der Gedanke „ich bin doch so ein kleines Licht …“ ist hier nicht hilfreich sondern könnte Hacker sogar gerade anziehen.

Lösung – Ändern der Tabellenpräfixe – wie geht das?

Die Sicherheit eines WordPress-Systems kann somit erhöht werden, wenn man den oder die Tabellenpräfixe umbenennt. Dabei geht es gar nicht darum, weitere Blogs und Tabellen zuzulassen. Sondern: das Ziel ist einfach nur darfür zu sorgen, dass Angreifer möglichst nicht auf die bekannten Tabellennamen zielen können. Schon durch die Wahl eines andere Präfixes ist das bereits erreicht.

Damit stellt sich die Frage: Wo überall muss man diese Anpassung vornehmen?

Achtung: Diese Daten gelten aktuell (Oktober 2011, WordPress-Version 3.2.1). Schon beim nächsten Update kann dieses Zusammenspiel völlig anders sein. Dieser Erfahrungsbericht wird nicht regelmäßig nachgepflegt.

1. Backup von Datenbank und System durchführen

Mit einem FTP-Programm oder WinSCP alle Dateien unterhalb des Wurzel-Ordners des jeweiligen WordPress-Systems an einen sicheren Ort kopieren.
Mit phpMyAdmin, cPanel oder einem Plugin wie WP Backup die Daten der Datenbank sichern. Eine Anleitung für phpMyAdmin befindet sich z.B. unter http://doku.wordpress-deutschland.org/Backup_der_Datenbank/phpMyAdmin.

2. Präfix-Einstellung in WordPress-Datei wpconfig.php vornehmen

Die Datei wpconfig.php liegt im Wurzel-Ordner der WordPress-Installation.
Hierin befindest sich eine Zeile

$table_prefix  = 'wp_';

Der Ausdruck auf der rechten Seite in den Hochkommata muss ersetzt werden.

Daher: die Datei in einem Editor laden
Den Ausdruck wp_ auf der rechten Seite gegen einen möglichst kryptischen Term (zufällige Zeichenkombinationen wie p3rk5ttze, m5n5p2r5uao) ersetzen. Achtung: die Hochkommata müssen erhalten bleiben und der Semikolon am Ende der Zeile ebenfalls. Der Präfix ist nur die Zeichenkette in den Hochkommata – jedoch ohne die Hochkommata selbst.
Kryptisch soll heißen: Keine Namen, die man vielleicht aus dem Zusammenhang des Blogs schon erraten kann (etwa „schmidt“, vor allem dann nicht, wenn der Blog „Schmidts Blog“ heißt). Die Kreativität sollte sich auf Buchstaben und Ziffern beschränken – keine Umlaute, Sonderzeichen oder auch Programmier-Begriffe – das kann Seiteneffekte haben (siehe Legal Names in mySQL und Reservierte Wörter in mySQL)! „Konsonantengewirre“, durchsetzt mit Ziffern sind eigentlich das Beste.

Achtung: ab jetzt ist der Blog erstmal tot – solange, bis die Namen der Datenbank-Tabellen wieder zum Präfix in der Datei wpconfig.php passen.

3. Datensätze der Datei wp_options anpassen

Steuert das Login. Der Präfix wp_ taucht auch hier in einem Datensatz auf.

In phpMyAdmin einloggen.
Im linken Teil unter Datenbank die betreffende Datenbank auswählen (falls es überhaupt mehrere gibt). Das hat geklappt, wenn links unter dem Datenbanknamen die Namen der enthaltenen Tabellen wie in der folgenden Abbildung aufgelistet werden
Dieselben Tabellennamen müssen zudem in der Tabelle im Inhaltsbereich zu sehen sein.

Mit der linken Maustaste auf den Tabellennamen wp_options klicken. Im Inhaltsteil sollte nun anstelle der Tabelle mit Tabellennamen eine Tabelle mit Überschriften wie option_id, blog_id etc. geladen sein. Das sind die Datensätze der Tabelle wp_options. Hier muss im Feld option_name nach dem Wert wp_user_roles gesucht werden. Eine einfache Möglichkeit:

im Tabellenkopf das Wort option_name anklicken – das sortiert die Tabellen nach den Werten in dieser Spalte.
Dann blättern, bis der Datensatz zu sehen ist. Das kann einige Seiten weit sein. Finden! Denn ohne die Anpassung klappt kein Login in das WordPress-System mehr!

Durch Klick auf das Stiftsymbol in der Tabelle links bei diesem Datensatz in den Edit-Modus gehen, in der Maske die Zeichenkette wp_ (vor user_roles) gegen den neuen Term austauschen und speichern.

3. Datensätze der Datei wp_usermeta anpassen

Steuert die Zuordnung von Daten zu eingelogten Nutzern.

Mit der linken Maustaste auf den Tabellennamen wp_usermeta klicken. Im Inhaltsteil sollte nun eine Tabelle mit Überschriften wie umeta_id, user_id, meta_key etc. geladen sein. Hier muss in der Spalte meta_key nach allen Werten gesucht werden, die mit der Präfixzeichenkette „wp_“ beginnen. Die genaue Anzahl kann von System zu System variieren. Daher macht eine Aufzählung nur begrenzt Sinn – es könnten je nach Plugin-Stand noch mehr Datensätze existieren. Eine einfache Möglichkeit:
im Tabellenkopf das Wort meta_key zwei Mal anklicken – das sortiert die Tabellen nach den Werten in dieser Spalte in umgekehrter Reihenfolge (also beginnend mit Z – da ist es zum Buchstaben w nicht so weit).
Durch Klick auf das Stiftsymbol in der Tabelle links diesen Datensätzen in den Edit-Modus gehen, in der Maske die Zeichenkette wp_ gegen den neuen Term austauschen und speichern.
Kandidaten (die geben kann aber nicht muss – und die zudem nicht alle sein müssen, siehe oben):

wp_autosave_draft_ids
wp_capabilities
wp_dashboard_quick_press_last_post_id
wp_user-settings
wp_user-settings-time
wp_user_level

5. Namen der Datenbank-Tabellen in phpMyAdmin umstellen

Wenn in der Datei wp_config.php unter prefix ein anderer Wert als „wp_“ eingestellt ist, sucht WordPress fortan in den Datenbanktabellen mit diesem Präfix nicht mehr. Daher müssen nun die Datenbanktabellen umbenannt werden.

Im linken Teil unter Datenbank wieder die betreffende Datenbank anklicken. Wie oben: das hat geklappt, wenn links unter dem Datenbanknamen die Namen der enthaltenen Tabellen wie in der folgenden Abbildung aufgelistet werden.
Dieselben Tabellennamen müssen wieder in der Tabelle im Inhaltsbereich zu sehen sein.
Mit der linken Maustaste auf den ersten Tabellennamen (derzeit wp_commentmeta) klicken. Die Tabelle ist nun hervorgehoben und anstelle der Tabellennamen auf der rechten Seite sind nun andere Inhalte (die Datensätze der jeweiligen Tabelle) zu sehen.

: Eine aktive Tabelle der WordPress-Datenbank in phpMyAdmin

nun im oberen Bereich bei den Karteikartenreitern den Reiter Operationen mit der linken Maustaste anklicken
im Feld Tabelle umbenennen in den Präfix erstetzen
die Änderung mit Klick auf den OK-Knopf unten speichern.

Umbenennen einer Tabelle der WordPress-Datenbank

Nach diesem Schema ALLE Tabellen umbenennen, die mit „wp_“ beginnen.
Die genaue Anzahl der Tabellen variiert leider von System zu System – eine Aufzählung der Tabellen hier würde daher nichts bringen. Sind schon viele Plugins installiert (die auch alle Datenbank-Tabellen angelegt haben), kann die Anzahl der Tabellen gut drei-stellig sein. Frische/leere Systeme haben aktuell um die 20 Tabellen.
Wenn man diese Änderungen relativ früh nach dem Aufsetzten eines Systems vorgenommen wird, erhalten alle neuen Tabellen – etwa bei der Installation von Plugins – den neuen Präfix. Das muss also nicht andauernd manuell nachgepflegt werden. Schiebt man das auf die lange Bank, kann die Umbenennung relativ viele Klicks erfordern.

Fertig.

Einloggen und Testen – das System sollte sich nicht anders verhalten als vor den Umbenennungen. Falls doch ist etwas schief gegangen. Dann das Backup zurückspielen und erneut versuchen oder kleinschrittig alles noch einmal durchgehen, bis der Fehler/Schreibfehler oder die übersehene Stelle gefunden ist.