WordPress Sicherheit: Ausreichend Schutz vor Hackern

Zuletzt aktualisiert am 24. Januar 2018 um 13:59

Um eine WordPress-Installation zu hundert Prozent vor Angriffen und Hacks zu schützen, existiert in diesem uns bekannten Teil des Universums nur eine einzige Möglichkeit: man lässt das CMS lokal auf einem Rechner laufen, der völlig vom Internet getrennt ist. Kein Netzwerkkabel, kein WLAN, kein Bluetooth. Da diese Variante aber im Großteil der Anwendungsfälle nicht mit der Intention des Blogbetreibers, Information zu veröffentlichen, kompatibel sein dürfte, muss man ständig mit dem Risiko leben, verwundbar zu sein – und ein paar vergleichsweise simple Ratschläge beherzigen.

Jedes Plugin zu installieren, das im WordPress-Repository mit „Security“ getaggt ist und sich danach sicher zu fühlen, kann man zwar nicht direkt mit Homöopathie vergleichen (immerhin bieten manche Plugins deutlich mehr als puren psychologischen Placebo-Effekt), schießt aber schnell mal übers Ziel hinaus und im schlimmsten Fall sogar noch die Performance des Webservers ab. Außerdem sollen auch schon üble Sicherheitslücken in solchen Erweiterungen gefunden worden sein…

Also machen wir uns nichts vor: wenn weder Sony noch Adobe ihre Server absichern können, wenn der Heartbleed Bug zwei Jahre lange ungesehen im OpenSSL Code vor sich hinschlummern konnte, dann brauchen wir uns gar nicht erst in Sicherheit zu wiegen. Denn schließlich lautet ein altes chinesisches Sprichwort nicht umsonst:

Selbst der vorsichtigste WordPress-Administrator hat einen interessanten Webhoster. Und wenn er einen Rootserver betreibt, dann hat er ein interessantes Betriebssystem.

Soll heißen: ob Shared Space oder Managed Server oder selbst kompilierter Linux Core, Irren ist menschlich. Die wichtigste Vorbeugemaßnahme gegen allfällige feindliche Übernahmen des eigenen Blogs lautet also: regelmäßig Backups anfertigen! Das funktioniert bei kleineren Blogs mit Backup-Plugins ganz okay. Hier auf datenschmutz hab ich mittlerweile ein paar Gigs an Attachments und Fotos rumliegen, deshalb mach ich das ganze händisch über Terminal: zuerst kommt ein Datenbank-Dump dran, dann pack ich das ganze /www/ Verzeichnis in ein gzip-Archiv, das ich mir anschließend via abhole.

Dass der Admin-Nutzer nicht „admin“ heißen sollte, WordPress und Plugins zeitnah upgedatet werden wollen, man sich bei letzteren besser aufs Nötigste beschränkt und dass sich die Passwörter für (s)ftp-Zugang, Datenbank und Admin-User unterscheiden sollten, hat sich mittlerweile hoffentlich herumgesprochen. Ein starkes Passwort ist natürlich ebenfalls ein Muss, ein anderes mySQL-Tabellen-Präfix als das standardmäßig eingestellte wp_ erschwert zumindest Datenbank-Injections. Datenübertragungen von/zum Server sollten nicht via ftp erfolgen, sondern ausschließlich über die sichere Variante sftp verwenden – ganz besonders in öffentlichen WLANs, wo auch das beste Passwort keinen Schutz vor Lauschangriffen bietet, wenn man nicht den WordPress-Admin auf SSL-umstellt. Besonders Vorsichtige empfehlen zusätzlich, Autor- und Admin-Nutzer zu trennen, aber die dauerende Umloggerei wär mir persönlich zu umständlich.

Sensible Daten via SSL verschlüsselt übertragen

Update, 26.4.2014: Martin Leyrer hat mich auf eine weitere grundlegende Maßnahme hingewiesen – SSL Verschlüsselung für den gesamten Admin-Bereich. Verzichtet man auf diese verschlüsselte Datenübertragung, dann hebeln potentiell Lauscher in öffentlichen WLANs nämlich jede Passwortabfrage aus:

Wenn man sein WP nämlich aus dem Kaffehaus, etc. administriert kann JEDER, der das WLAN mitbenutzt, auch das WP-Adminpasswort mitlesen. Und zwar mit trivialem Aufwand. Und da ist es vollkommen egal, ob man nun ein oder zwei Passwörter eingeben muss und ob WP oder der Apache dieses verifiziert.

Wie einfach das in der Praxis funktioniert, zeigt Martin in diesem Video.

Die Einrichtung von SSL ist leider nicht ganz trivial – erstens hängen die konkreten Schritte von der jeweiligen Hostinglösung (eigener Rootserver, Managed Server oder Shared Space), zweitens vom Betriebssystem und drittens vom eigenen Webserver ab. Die Erstellung eines eigenen Zertifikats ist keine Hexerei, in vielen Fällen erleichtert das Plugin WordPress SSL den Prozess. Eine ausführliche englischsprachige Anleitung gibt’s hier.

Sicherheitsschloss für den Admin-Bereich

Den Administrationsbereich, also jenen Teil einer WordPress Installation, der sich im Verzeichnis abspielt, mit einem Extra-Schloss auszurüsten, ist an sich eine ganz hervorragende Idee, sofern sich am Blog sowieso keine Nutzer registrieren dürfen. Muss sich ein Angreifer erstmal mit der serverseitigen Passwortabfrage rumplagen, kommt er an viele Hebel und Einfallstore erstmal gar nicht ran. Gefürchtete Brute-Force-Attacken, bei denen in rascher Folge ein große Anzahl von Usernamen/Passwort-Kombinationen durchprobiert werden, fallen somit schon mal flach – sofern man für diesen sogenannten htaccess-Schutz eine nicht leicht bis unmöglich zu erratende Kombination verwendet.

Damit erspart man sich auch die Installation weitgehende sinnbefreiter Schutz-Plugins á la „Limit Login Attempts“, die nach x-maliger falscher Passworteingabe eine bestimmte IP-Adresse für y Stunden sperren. Sinnbefreit deshalb, weil solche Angriffe in der Regel nicht von Script-Kiddies, sondern Botnetzen kommen, und die wechseln ihre IP-Adressen schneller als Gina Lisa ihre Schönheitschirurgen.

Viele Webhoster ermöglichen einen solchen Verzeichnisschutz über Administrations-Interface – ABER: man sollte keinesfalls das ganze /wp-admin/ Verzeichnis schützen, sondern lediglich die Datei wp-login.php! Das erspart Probleme mit einzenlen Dateien, die auch am Frontend aus /wp-admin/ geladen werden, zum Beispiel Fehlermeldungen bei versehentlich leer gelassenen Kommentarfeldern. Wie das funktioniert, hat Sergej Müller ganz wunderbar erklärt, technisches Vorwissen ist für die Umsetzung seiner 5-Minuten-Anleitung nicht erforderlich: Mehr Sicherheit für WordPress durch den „Admin“ Schutz.

Wer sein WordPress nicht am Apache-Server laufen hat, kennt sich mit Alternativen für nginx und Co. hoffentlich gut genug aus. Sollte jedoch der Webhoster trotz Apache keine .htaccess Funktionalität bieten – dann wird’s höchste Zeit für einen neuen Webhoster.

Nicht übertreiben mit den Security-Plugins!

Mit diesen Tipps (sicheres Passwort, eigenes Tabellen-Präfix, abgesicherter Admin) werden 90% aller potentiellen Attacken von Ihrer WordPress-Installation abprallen wie Schmeißfliegen von einem Nissan NSX auf der Autobahn. Die folgenden Security-Plugins sind nicht gänzlich überflüssig und haben sich bei mir recht gut bewährt.

BBQ – Block Bad Queries: ein simples, kleines Filterscript, das bekannte „malicious requests“ im Hintergrund block – Konfiguration überflüssig.

Wordfence: Firewall, umfangreiche Blocking- und Throttling Optionen und Scanning auf veränderte Core-Dateien bzw. „malicious URLs“ in Kommentaren. Obendrauf gibt’s noch die hauseigene Caching-Engine „Falcon“, die ich gerade ausprobiere. Zahlende Nutzer bekommen zusätzlich 2-Faktor-Authentifizierung via SMS.

Acunetix WordPress Security Plugin: zeigt auf eine Blick die aktuelle Konfiguration an und weist auf potentielle Sicherheitslücken hin. Vor allem bei älteren Installation hilfreich, um schnell mal zu überprüfen, ob die Dateirechte ausreichend restriktiv gesetzt und leere index.php Dateien in /wp-content/ und anderen Verzeichnissen vorhanden sind. Kein Plugin, das dauerend aktiviert sein muss, aber hilfreich, um allfälligen Einfallstoren auf die Schliche zu kommen und diese zu beseitigen. iThemes Security macht den gleichen Job und hilft nötigenfalls auch bei der Umbenennung des Admin-Users.

Felloazit: Kein noch so mächtiges Sicherheitsplugin ersetzt ein wenig Hausverstand und Selbstdisziplin bei der Passwortvergabe. Wer auf Nutzerregistrierungen verzichten kann, schützt sich mit einer Kombination aus serverseitiger Passwort-Abfrage für die wp-login.php Datei und SSL für den WordPress Admin am effizientesten vor einer ganzen Reihe von Angriffen.