, , ,

WordPress Sicherheit: Ausreichend Schutz vor Hackern

WordPress absicherns

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.

8 comments
Gerald Baeck
Gerald Baeck

@n4n0   >Wie ist HTTPS (also SSL) denn ein Schutz gegen Bruteforce? SSL verschlüsselt lediglich die Übertragung vom Sender zum Empfänger, hält aber keinen Bot davon ab die Passwörter zu erraten. Ich nicht geschrieben, dass https ein Schutz gegen Bruteforce ist, aber es ist der beste Schutz in einem öffentlichem WLAN und eine Verschlüsselung des ganzen Blogs würde auch den Lesern dabei helfen, ein bisschen weniger gläsern zu sein. > Und warum werden PHP und MySQL nie sicher sein? Weil der Nutzer nicht in der Lage ist, seine Systeme gegen buffer over- / underflow angriffe zu schützen, da er davon keine Ahnung hat? Ganz genau. Abgesehen davon, dass die meisten User nichtmal eigene Server betreiben und von den of sehr langsamen Update Zyklen ihrer Provider abhängig sind. Plugins sind tatsächlich die größte Gefahr, es gab auch schon jede Menge Spam Plugins zb.

datadirt
datadirt

@Gerald Baeck  Generierte Blogs sind im Zeitalter der 3rd Party Commenting Systeme wieder eine Option geworden - sozusagen der ultimative Cache :-) Aber WordPress ist für mich persönlich in den letzten Jahren zum Ersatz fürs Legospielen geworden; darauf mag ich nicht verzichten *g* Welche Softwarelösung verwendest du? Lokales WP und Staticize HTML?

n4n0
n4n0

@Gerald Baeck Wie ist HTTPS (also SSL) denn ein Schutz gegen Bruteforce? SSL verschlüsselt lediglich die Übertragung vom Sender zum Empfänger, hält aber keinen Bot davon ab die Passwörter zu erraten. Und warum werden PHP und MySQL nie sicher sein? Weil der Nutzer nicht in der Lage ist, seine Systeme gegen buffer over- / underflow angriffe zu schützen, da er davon keine Ahnung hat? Ich sehe hier vor allem durch die Menge der Plugins in WP eine Gefahr, dass immer mehr Menschen meinen, sie bräuchten dringend eine WP Installation und ziehen sich dann ein paar Plugins die schon alles richten werden.  Server-Sicherheit geht anders. Am einfachsten ist eine .htaccess Datei, die den Zugriff von außerhalb des Servers gleich unterbindet; das erzeugt keinen Traffic und legt keine gigantischen Datenbanken an, wie es einige "Security" Plugins für WP tun.

Gerald Baeck
Gerald Baeck

Das Problem ist, PHP und mysql werden nie besonders sicher sein. Ich habe mich deswegen für den Wechsel zu einem generiertem Blog entschieden. Das heißt die Software läuft nur bei mir und generiert jedes mal, wenn ich etwas veröffentlichen will, statische html Seiten zum Upload auf den Server. Das macht das ganze nicht nur performanter sondern auch ziemlich robust gegenüber allen möglichen Hacks.


Der einzige wirkliche Schutz fürs login via /wp-admin ist https. Wem das verständlicherweise zu kompliziert ist, der sollte sich aber auf keinen Fall in öffentlichen Netzen ins eigene Blog einloggen. Langfristig - auch um der NSA eins auszuwischen - wäre es ratsam die ganze Domain auf https umzustellen.

n4n0
n4n0

@Gerald Baeck Wie ist HTTPS (also SSL) denn ein Schutz gegen Bruteforce? SSL verschlüsselt lediglich die Übertragung vom Sender zum Empfänger, hält aber keinen Bot davon ab die Passwörter zu erraten.

Und warum werden PHP und MySQL nie sicher sein? Weil der Nutzer nicht in der Lage ist, seine Systeme gegen buffer over- / underflow angriffe zu schützen, da er davon keine Ahnung hat?

Ich sehe hier vor allem durch die Menge der Plugins in WP eine Gefahr, dass immer mehr Menschen meinen, sie bräuchten dringend eine WP Installation und ziehen sich dann ein paar Plugins die schon alles richten werden. 

Server-Sicherheit geht anders.


Am einfachsten ist eine .htaccess Datei, die den Zugriff von außerhalb des Servers gleich unterbindet; das erzeugt keinen Traffic und legt keine gigantischen Datenbanken an, wie es einige "Security" Plugins für WP tun.

datadirt
datadirt moderator

@Gerald Baeck  Generierte Blogs sind im Zeitalter der 3rd Party Commenting Systeme wieder eine Option geworden - sozusagen der ultimative Cache :-)


Aber WordPress ist für mich persönlich in den letzten Jahren zum Ersatz fürs Legospielen geworden; darauf mag ich nicht verzichten *g*


Welche Softwarelösung verwendest du? Lokales WP und Staticize HTML?

Gerald Baeck
Gerald Baeck

@n4n0  

>Wie ist HTTPS (also SSL) denn ein Schutz gegen Bruteforce? SSL verschlüsselt lediglich die Übertragung vom Sender zum Empfänger, hält aber keinen Bot davon ab die Passwörter zu erraten.


Ich nicht geschrieben, dass https ein Schutz gegen Bruteforce ist, aber es ist der beste Schutz in einem öffentlichem WLAN und eine Verschlüsselung des ganzen Blogs würde auch den Lesern dabei helfen, ein bisschen weniger gläsern zu sein.


> Und warum werden PHP und MySQL nie sicher sein? Weil der Nutzer nicht in der Lage ist, seine Systeme gegen buffer over- / underflow angriffe zu schützen, da er davon keine Ahnung hat?


Ganz genau. Abgesehen davon, dass die meisten User nichtmal eigene Server betreiben und von den of sehr langsamen Update Zyklen ihrer Provider abhängig sind.


Plugins sind tatsächlich die größte Gefahr, es gab auch schon jede Menge Spam Plugins zb.

Gerald Baeck
Gerald Baeck

Das Problem ist, PHP und mysql werden nie besonders sicher sein. Ich habe mich deswegen für den Wechsel zu einem generiertem Blog entschieden. Das heißt die Software läuft nur bei mir und generiert jedes mal, wenn ich etwas veröffentlichen will, statische html Seiten zum Upload auf den Server. Das macht das ganze nicht nur performanter sondern auch ziemlich robust gegenüber allen möglichen Hacks. Der einzige wirkliche Schutz fürs login via /wp-admin ist https. Wem das verständlicherweise zu kompliziert ist, der sollte sich aber auf keinen Fall in öffentlichen Netzen ins eigene Blog einloggen. Langfristig - auch um der NSA eins auszuwischen - wäre es ratsam die ganze Domain auf https umzustellen.

Trackbacks

  1. […] WordPress Sicherheit: Ausreichend Schutz vor Hackern: Richie Pettauer gibt Tipps zur Sicherung von WordPress-Blogs.  […]

  2. […] man mit dieser Aktion nicht nur die Sichtbarkeit der eignen Domain, sondern macht sie obendrein sicherer gegen Hacker-Angriffe. Gerade der Login-Bereich ist unverschlüsselt ein hervorragendes Ziel für […]

  3. […] So musste ich auf Astricelli ausweichen. Okay, halt mal eine Ausnahme machen. Blöd aber auch, dass Passwörter manchmal aus mindestens sechs Zeichen bestehen müssen, gut, Ausnahme Nummer zwei war geboren. Noch […]