Aufgeschreckt durch Meldungen bei heise.de oder spiegel.de versuchen der Tage alle WordPress-Administratoren ihr WordPress-CMS abzusichern. Aus diesem Grund möchte ich hier meinen Leitfaden veröffentlichen, den ich bei einer Neuinstallation einer WP-Instanz anwende. Ich versuche aus aktuellem Anlass auch darauf einzugehen, eine bestehende WordPress-Installation nachträglich abzusichern. Beachten Sie bitte, dass die aktuelle Problematik „wp-admin“ per htaccess abzusichern erst im Punkt 8 ausführlich erläutert wird.
1. Kein Administrator namens „admin“
Zuerst sollte jeder WP-Admin sich in WordPress einloggen und unter Benutzer die Konten prüfen. Viele Administratoren gibt es? Sind es plötzlich mehr? Wenn ja, dürfte ein Angriff bereits stattgefunden haben. Wenn nein, sind nach Möglichkeit die Anzahl der Administratoren auf ein Minimum zu reduzieren. Auch zu prüfen: Gibt es einen Administrator namens „admin“? Wenn ja, ist dieser unbedingt zu ändern! Genau darauf bau der aktuelle Angriff: Wenn bekannt ist, dass das Administrationskonto „admin“ lautet, ist dies schon die halbe Miete. Nun muss nur noch das Passwort per Brute Force ermittelt werden.
Also unbedingt den Benutzernamen des „admin“ in einen individuellen Benutzer-Namen ändern. Dass alle Passwörter auch entsprechend lang und kryptisch sein sollen, ist hoffentlich selbstverständlich.
2. Ein Administrator veröffentlicht keine Artikel. NIE!
Warum? WordPress hinterlässt bei jedem Artikel den Namen des Autors. Dies ist sehr sinnvoll aus vielerlei Gründen. Aus Sicherheitsgründen ist dies jedoch eine Katastrophe, da darüber in den meisten Fällen auch der Benutzername bekannt ist. Somit muss nur noch dem passenden Passwort gesucht werden. Hat dieser Benutzer auch noch Admin-Rechte, ist der Blog schnell in fremder Hand.
3. Die ID des Administrators ändern
Bei der Installation des Blogs wird automatisch das Administrationskonto angelegt und erhält in der Datenbank die User-ID 1. Dies ist ein weiterer Ansatzpunkt beim Hacken einer WordPress Installation. Die ID ist nachträglich mit nachfolgenden SQL-Statements änderbar:
UPDATE wp_users SET ID = '[NEUE ID]' WHERE wp_users.ID = 1; UPDATE wp_usermeta SET user_id = '[NEUE ID]' WHERE wp_usermeta.user_id = 1; UPDATE wp_posts SET post_author = '[NEUE ID]' WHERE wp_posts.post_author = 1; UPDATE wp_links SET link_owner = '[NEUE ID]' WHERE wp_links.link_owner = 1;
Nachdem so die Sicherheit für das Administrations-Konto erhöht wurde, sollte man sich nun an die „wp-config.php“ machen. Diese Datei liegt gewöhnlich im Root der Installation.
4. Prüfen, ob die Sicherheitsschlüssel in der „wp-config.php“ gesetzt sind
Mit wenig Aufwand kann hier die Sicherheit ein gutes Stück erhöht werden. In den Abschnitt „Sicherheitsschlüssel“ gehören zu jedem Define-Block ein „gehörig gesalzener Key“. WordPress macht es sehr einfach. Der Aufruf unter https://api.wordpress.org/secret-key/1.1/salt/ über den Browser erlaubt die Generierung der Keys. Diese Ausgabe im Broser kann einfach via Copy & Paste in die wp-config.php übernommen (bzw. überschieben) werden.
define('AUTH_KEY', '%Sc#(H|Zo5p+wn=>i.yM*!k%w8[zh9K{d5-v2>`:^>M%B:(tr{2;VkGMxTE+NFD)');
define('SECURE_AUTH_KEY', 'ZXsorW!Z_6qi/PC^tDUUftZo*sQ6Ej!MzW9,Ze3z6>W?H+G}*$<iddH/a#Z7+&EO');
define('LOGGED_IN_KEY', 's@X$cZ(*.wCI1tU.Lw$|Ion<Os5+~^F<u,+zo,!|}u#n e6+aJG|dn/u!x`;8k,k');
define('NONCE_KEY', 'aM3~ZibX) Jz4IB+RW%m4M4cY*LHtOwN|Z1kQ/-GVyWOD. RD,n<>:,_GF)A`p:>');
define('AUTH_SALT', ']-tLB^g{c$+NL$%=Npsn,-P~t%9jH0h-t-e-A=-m@!Wh7y-6f1D|;LvU5qG');
define('SECURE_AUTH_SALT', '4p mo_GfknF1>zk$PY[_V_e#f9@![wsE9?head7ZJkMJ..^]S|fZ6+3Zw+ZoV/bq');
define('LOGGED_IN_SALT', 'ACKwio1l@N8P#H|T:$NC-9- 6;geaT2CPp+b[acWxI;Gona}eKl2w5wZZ2KA5I;B');
define('NONCE_SALT', 'Gbl4l,Eu%;|F4/9EMq7%$D-xzuNuc[[+Xn.#dk#|CR:6iu*l{7B62Mzq17!vPO8T');
5. Datenbank-Präfix ändern
Immer wieder ist zu lesen, dass dies die Sicherheit extrem erhöhen sollte. Ich persönlich habe den Fokus auf andere Punkte. Doch wenn ein neuer Blog angelegt wird, schadet es auf keinen Fall, die Variable $table_prefix = ‚wp_‘; in der wp-config.php beispielsweise in ‚wp3h3r6_’ zu ändern. Warum das ganze? Wenn das Datenbank-Prefix „wp_“ nicht geändert wird, ist bekannt, wie die Tabellen in der MySQL-Datenbank lauten. Somit kann speziell nach diesen Tabellen gesucht werden bzw. Datenbank-Sicherheitslücken, die nur beschränkten Zugriff auf eine Datenbank erlauben, sind gegebenenfalls von größerer Gefahr.
Wer nachträglich die Datenbanknamen ändern möchte, kann dies in der wp-config.php erledigen und muss dann zusätzlich auf der Datenbank die Tabellen umbenennen (alle!)
-- Beispiel für die Tabelle wp_posts. Beispiel-Prefix: ‚wpSic#er_’ RENAME TABLE wp_posts to wpSic#er_posts;
Hier geht es weiter zu den Tipps 6 – 10 >>