Das Salz in der Suppe für die WordPress-Sicherheit

SalzstreuerIn (c) Dubravko SorićDamit man sich beim Bearbeiten der WordPress-Seiten nicht jedesmal neu einloggen muss, werden Cookies in den Speicher des Browsers gesetzt. Dadurch wird den aufrufenden Seiten signalisiert, der Benutzer ist eingeloggt und autorisiert.

Cookies sind also per se nichts Schlechtes.

In der Grundinstallation sind diese Cookies durch die Keys in der wp-config.wp nicht besonders gesichert, wie man am nachfolgenden Beispiel sehen kann:

define(‚AUTH_KEY‘, ‚put your unique phrase here‘);
define(‚SECURE_AUTH_KEY‘, ‚put your unique phrase here‘);
define(‚LOGGED_IN_KEY‘, ‚put your unique phrase here‘);
define(‚NONCE_KEY‘, ‚put your unique phrase here‘);
define(‚AUTH_SALT‘, ‚put your unique phrase here‘);
define(‚SECURE_AUTH_SALT‘, ‚put your unique phrase here‘);
define(‚LOGGED_IN_SALT‘, ‚put your unique phrase here‘);
define(‚NONCE_SALT‘, ‚put your unique phrase here‘);

Böse Buben (und auch Mädchen) könnten diese Cookies nutzen, um sich Zugriff auf die Website zu verschaffen.

Unter https://api.wordpress.org/secret-key/1.1/salt/ kann man sich diese Schlüssel generieren lassen und dann sieht es z. B. so aus:

define(‚AUTH_KEY‘, ‚qtj-:G~p?UEy-;9*CJ+5Pj c:o|#@]`_JFc]D=K,*Wsco`o%{feE+ j}n,1|I3)#‘);
define(‚SECURE_AUTH_KEY‘, ‚0w<Lud7hXt&F>|=jp;1g6p*lAp-UB=d]GIn(;@]8yXVKW]NS|II/8/O.b6$?-w G‘);
define(‚LOGGED_IN_KEY‘, ‚,_?G%v@5@v}LH~ZF-,C`p|l5(q_?1@$i?^>Lz63O8 !eAQ_P{l$@:ueqcDzcVQPi‘);
define(‚NONCE_KEY‘, ‚A>{UVihS*74x{:hU:1C{2<4/QOjAzZ-]kGu(q8KqKS{Rme~-:E|b1CZFM-+2|/NQ‘);
define(‚AUTH_SALT‘, ‚K<y0JF,a-|/=KnJZ&i?N|,:3IR/cRbHK|.sCHQw&]OD1d|KX3Fp%;1Rq?+(IwK+}‘);
define(‚SECURE_AUTH_SALT‘, ‚Y.PS1}yv-[&,Yl:y>B$+ttBj2PEwp~oJa4CSr!eswk(Db)}b$d|9$@TVj60|=9N4‘);
define(‚LOGGED_IN_SALT‘, ‚?T.5q`$+3X-_>SAq%==F-sc*>nNrx.2?|–iYvm/2zjMEKA^jN/s+dRbe1+:=s]:‘);
define(‚NONCE_SALT‘, ‚jI(Uy;(W>UI$!)vOUOUvqI-/m[DTts*ZF+ BA6vznZY{;q=op<M10ffC|8~Os2Vf‘);

Diese Werte werden entweder manuell in die wp-config.php eingetragen oder man erledigt das automatisch z. B. mit dem Plugin Sucuri Security.

Salt (englisch für Salz) bezeichnet in der Kryptographie eine zufällig gewählte Zeichenfolge, die an einen gegebenen Klartext vor der Verwendung als Eingabe einer Hashfunktion angehängt wird, um die Entropie der Eingabe zu erhöhen. Es wird häufig für die Speicherung und Übermittlung von Computer-Passwörtern benutzt. Wikipedia

Mehr dazu im Artikel Sicherheit gegen Hackerangriffe bei WordPress

Aufruf einer WordPress-Seite über das Hauptverzeichnis

ProgrammcodeWird eine WordPress-Seite parallel zu einer bestehenden Site aufgebaut, kann es praktisch sein, das CMS in einem Unterverzeichnis zu installieren.

Ein Aufruf würde dann z. B. über http://www.meinedomain.at/wp/ oder http://www.meinedomain.at/wordpress/ oder so ähnlich.

Wenn die bisherige Site dann abgeschaltet wird, ist es natürlich einfacher und kürzer die Seiten über http://www.meinedomain.at zu erreichen.

Folgende Schritte sind dazu notwendig

Adminbereich => Einstellungen => Allgemein => WordPress-Adresse (URL): http://www.meinedomain.at/wordpress/

Da steht, wo WordPress seine Dateien wirklich findet und das bleibt so wie es ist.

Adminbereich => Einstellungen => Allgemein => Seiten-Adresse (URL): http://www.meinedomain.at/

Das steht wo es hingehen soll.

Wenn die beiden EIngabefelder ausgegraut sind und keine Eingabe möglich ist, wurden die Variablen WP_HOME und WP_SITEURL vermutlich in der wp-config.php gesetzt.

Es gibt aber noch einen Pferdefuß.

Die index.php und die .htaccess Dateien müssen ins Stammverzeichnis kopiert werden. Die .htaccess weil sonst mitunter mit Adminbereich => Einstellungen => Permalinks nicht funktioniert.

 

Und in der index.php muss der Pfad auf die wp-blog-header.php richtig gesetzt werden … also  http://www.meinedomain.at/wordpress/wp-blog-header.php oder dgl.

 

Die Zeiten ändern sich … in der Version 4.2.2 (oder auch schon früher) wurde die Zeile require( dirname( __FILE__ ) . ‚/wp-blog-header.php‘ ); verwendet. Dadurch wird schlauerweise immer im gleichen Verzeichnis in dem die index.php liegt gesucht.

Zum Schluss noch die Permalinks neu speichern unter:

Adminbereich => Einstellungen => Permalinks

Sicherheit gegen Hackerangriffe bei WordPress

Warum ist gerade meine Seite Ziel eines Hackerangriffs???

Don't Panic… nun, ich mag niemandes Illusion zerstören, aber es ist in den allermeisten Fällen eben nicht gerade meine Site, die angegriffen wird. WordPress behauptet auf der eigenen Website, dass es über 60 Millionen Nutzer dieses Content Management Systems gibt.

Und da liegt es nahe, dass die „bösen Buben“ (vulgo Hacker) ein System wählen, dass möglichst großflächig angegriffen werden kann. Mittlerweile gibt es ja auch schon Hackerangriffe und Sicherheitslücken auf Apple Computer … etwas, das bei Appleanhängern immer nur bei Windowsrechnern möglich schien 😉

Wer also mit WordPress Ziel eines Hackerangriffs wird, ist in allerbester Gesellschaft.

Frei nach Douglas Adams gilt jedoch: Don’t Panic!.

Das Plugin „Rename wp-login.php“

Damit gehen Brute-Force-Attacken ins Leere, weil es die Datei wp-login.php nicht mehr gibt. Ohne dieses Plugin sind pro Tag 40 Versuche und mehr das Passwort des admin Nutzers zu erraten keine Seltenheit.

wp-config.php etc. schützen

Es besteht in der Regel die Möglichkeit Dateien und Verzeichnisse serverseitig vor Zugriff zu schützen. Somit kann z.B. durch die Anweisung deny from all von außen (durch Eingabe des Dateinamens in der Browseradresszeile) nicht mehr auf die Datei wp-config.php zugegriffen werden.

<files wp-config.php>
order allow,deny
deny from all
</files>

Mit folgender Anweisung kann auch der Inhalt vom Upload- und Content-Ordner vor dem Ausführen von Dateien geschützt werden. Denkbar ist jedoch, dass zukünftige Plugins zugriff auf die PHP-Dateien brauchen. Bei Multisite-Installationen muss im wp-includes Ordner die ms-files.php Datei ausgenommen werden und das Sucuri Plugin nimmt wp-tinymce.php aus.

<Files *.php>
deny from all
</Files>

Standardbenutzer „admin“ entfernen

Standardmäßig gibt es bei einer neuen WordPressinstallation den Benutzer admin.

Wenn dieser durch einen anderen Namen ersetzt wird (nicht vergessen die bereits erstellten Seiten und Beiträge einem bestehenden Benutzer zuzuordnen), muss bei Brute-Force-Attacken neben dem Passwort auch der Benutzername erraten werden.

Dateiberechtigungen

Verzeichnisse sollten die Berechtigung 755, Dateien die Berechtigung 644 haben. Bei manchen Plugins sind besondere Dateiberechtigungen notwendig.

Datenbank-Prefix verwenden

WordPress erlaubt die Verwendung eines Datenbank-Prefix. Diese freiwählbare Bezeichnung wird den Datenbanknamen vorangestellt, wodurch es schwieriger wird, auf die Datenbank selbst zuzugreifen (um z. B. einen eigenen Benutzer anzulegen).

Dateibearbeitung abschalten

Administratoren haben die Möglichkeit Plugin-Programmdateien im Plugin-Editor zu bearbeiten. Damit ist dem Unfug Tür und Tor geöffnet. Die Sicherheits-Plugins Wordfence (selbständige Abschaltung) und Sucuri Security (via Tab „Hardening“) schalten diese Möglichkeit aus.

Alternativ kann folgende Zeile in die wp-config.php eingebaut werden:

define(‚DISALLOW_FILE_EDIT‘, true);

Key und Salt setzen

In der Grundinstallation verschlüsselt WordPress seine Cookies nicht. Mehr darüber im Artikel Das Salz in der Suppe für die WordPress-Sicherheit.

Informationen über die WordPress Version unterbinden

Wenn der Angreifer, weiß, um welche Version von WordPress es sich handelt, kann er gezielt und automatisiert durch Auslesen der readme.html und liesmich.html Schwachstellen nutzen. Wenn diese Informationen durch Entfernen ebendieser Dateien nicht mehr verfügbar sind, wird das Hacken der Seite wieder eine Spur schwieriger.

Sucuri Security entfernt leider nur die readme.html, die liesmich.html sollte manuell entfernt werden.

Mit dem „Broken Link Checker“ die Links in einer WordPress-Seite aktuell halten

Hervorgehoben

Broken Link Checker - AllgemeinJetzt bin ich gerade wieder auf einer Hotelseite auf einen Link gestoßen, der ins Leere zeigte … dumm wenn es sich gerade dabei um die Allgemeinen Geschäftsbedingungen handelt.

Zum Glück gibt es ein Plugin, das ich verwende, das genau dieses Problem verhindert.

Man kann sich unter dem Reiter Allgemein eine E-Mail Benachrichtigung schicken lassen, wenn ein defekter Link entdeckt wurde.

Im „Suchen Sie nach Links in“ Reiter lasse ich veröffentlichte Beiträge, Kommentare und Seiten durchsuchen.

Unter Welche Links überprüfen sind „HTML Links“ und „HTML Bilder“ ausgewählt.

Und bei Protokoll & Schnittstellen ist „Standard HTTP“ eingestellt.

Bei Erweitert kann man einstellen, ob auch Redakteure die ungültigen Links sehen können.

Alles in Allem ein sehr nützliches Plugin.