Ein nach wie vor weit verbreiteter Irrtum wenn es um Sicherheitsfragen bei Websites geht ist, dass die eigene Website nicht interessant genug wäre, um gefährdet zu sein. Dabei geht es Nutznießern von Sicherheitslücken selten um die Daten und Dateien einer Website selbst, sondern in erster Linie um die Dienste und Ressourcen vor denen sie läuft. Somit ist jede Website unabhängig von Umfang, Attraktivität und Inhalt ein potentielles Angriffsziel. In den meisten Fällen wird das erst zum Problem, macht man es Angreifern leicht.

Darüber kommen sie rein

Die Hauptschwachstelle eines jeden Systems sind veraltete und damit unsichere Plugins oder Template-Dateien des Themes. Denn gern genutzte Gelegenheiten sind bekannte Sicherheitslücken, um deren Beseitigung sich niemand schert. Nicht zuletzt sind achtlos verbliebene Rückstände vorheriger Website-Installationen Brutstätte trojanischer Pferde die durch solche Hintertüren passen.

Zu offen gesetzte Dateirechte haben auch schon so manches unerwünschte Skript in seiner Ausführung begünstigt. PHP-Versionen zu nutzen die nicht mehr gewartet werden, sind der Sicherheit auch nicht zuträglich.

Ein schlechtes Hostingprodukt mit veralteter Serversoftware und Skripten trägt zur Gefährdung einer Website bei. Restriktive Sicherheitsmaßnahmen vor denen eine Website nur noch eingeschränkt nutzbar ist, sind kein verlässlicher Hinweis auf sicheres Hosting. Es kann sogar einer darauf sein, dass der Anbieter bereits gehacked wurde, und sich nicht anders zu helfen weiß, als Dienste oder Funktionalität einzuschränken, vor der dies geschah.

Quellen die kostenpflichtige Premium-Plugins oder -Themes gratis zum Download anbieten, sind unbedingt zu meiden. Hier wird Schadcode absichtlich eingeschleust. Im harmlosesten Fall wird die eigene Website mit unerwünschten Werbelinks ausgestattet.

Legal käufliche Komponenten sind auch nicht unbedingt sicher. Schlampiger Code aus Quellen jenseits des WordPress-Repositories lässt sicherheitstechnisch oft zu wünschen übrig. Darauf, sich in der erforderlichen Tiefe mit WordPress-Konventionen zu befassten wird gerne mal verzichtet. Inline-Javascript ist nicht nur oft sicherheitstechnische, sondern auch Hürde bei der Performance-Optimierung. Der Verzicht auf Sicherheitsprüfungen usergenerierter Daten und die Datenausgabe ohne Prüfung öffnet Schadcode Tür und Tor.

Was passiert wenn es mich erwischt?

Es gibt zwei Gruppen von Befall die eine Website treffen können. Die eine greift Browser direkt an, die andere manipuliert eine Website soweit, dass sie Besucher auf Websites lotst die schädliche Komponenten enthalten.

Die potentielle Schadwirkung reicht also über die eigenen Belange hinaus. Immer wieder infizieren befallene Sites weitere nicht ausreichend abgesicherte oder sie übertragen Malware auf die Rechner von Besuchern.

Um den Schaden einzugrenzen, werden Websites heute nicht einfach nur von Suchmaschinen indexiert. Derselbe Mechanismus prüft auch gleich auf etwaige Malware. Fällt der Scan positiv aus, landet die betroffene Domain auf Schwarzen Listen, an denen sich unter anderem auch moderne Webbrowser orientieren. Warnhinweise ihrer Browser oder in Sucherergebnislisten halten potentielle Besucher davon ab, gekennzeichnete Gefahrenherde zu besuchen. Nicht nur für Onlineshops bedeutet dies das vorläufige Ende womöglich regelmäßig erwarteter Umsätze.

Wenn erst ab diesem Zeitpunkt der Befall erkannt und etwas dagegen unternommen wird, kann es Tage dauern, bis die Warnungen verschwunden sind, und sich die Statistiken erholen. Besser ist es, Verluste von Vertrauen und Umsatz durch Prävention zu vermeiden. Denn wer länger weg vom Fenster ist der bleibt es auch, zwingt er seine Besucher zum Mitanbieter abzuwandern.

Was kann mich schützen?

• WordPress aktuell halten
• möglichst aktuelle PHP-Version wählen (Server-Einstellungen)
• regelmäßige Backups zu anderem Server oder in die Cloud
• individuelles Tabellenpräfix verwenden
• TLS/SSL aktivieren
• nur so viele Plugins einsetzen wie nötig
• darauf achten, ob alle Komponenten nach wie vor betreut werden
• fehlende Salt Keys eintragen
• individuelle, lange Passwörter wählen

Die regelmäßige Aktualisierung eines CMS und seiner Komponenten ist die wichtigste Sicherheitsmaßnahme überhaupt. Wird eine Sicherheitslücke bekannt, lässt ein Update meist nicht lange auf sich warten. Allerdings kann man sich nur bei WordPress selbst, den Originalthemes und ein paar populären und gut gepflegten Plugins darauf verlassen, dass das zeitnah geschieht.

Eine veraltete PHP-Version die keine Updates mehr bekommt wird nicht nur über kurz oder lang zu einem Kompatibilitätsproblem führen, sie ist meist auch langsamer und unsicher.

Die Einrichtung automatisierter Datensicherungen um sowohl für Angriffe als auch schief gelaufene Updates gewappnet zu sein, sollte in keiner Installation fehlen. Backups auf einen anderen Server oder in die Cloud verhindern Schäden die mit Datenverlusten durch Plattendefekt oder andere Gründe einhergehen.

Ein individuelles Tabellenpräfix legt man am besten gleich bei der Installation fest. Das erweitert den Schutz gegen SQL-Injections.

TLS/SSL (Aufruf von Seiten über https://) schützt vor Man in the Middle Attacken, bei denen nicht nur Daten ausgelesen sondern auch manipuliert werden können (Achtung, manche Virenscanner können hier die Schutzwirkung beeinträchtigen, wenn sie sich in die Browser einklinken).

Je mehr Plugins eine Site verwendet, desto größer die Wahrscheinlichkeit von Sicherheitslücken. Besonders skriptlastige (aufwendige Slider) oder Komponenten die Daten entgegennehmen (Formulare) oder speichern (Statistik-Plugins) sind als Einschleus-Kandidaten geeignet. Bei diesen ist daher auch besonders wichtig, sich immer wieder zu vergewissern, dass sie noch aktualisiert werden.

Selbst wenn man immer alle verfügbaren Updates macht, kann sich dennoch eine Sicherheitslücke in einer nicht mehr aktuellen Drittanbieter-oder individuell entwickelten Komponente verstecken, weil zwischenzeitlich keiner mehr da ist, der sich darum kümmert. Eine gelegentliche Kontrolle der Aktualität installierter Komponenten ist daher zu empfehlen. Ein veraltetes Plugin ist selten der einzige Weg eine erwünschte Funktionalität umzusetzen. Gibt es keine Alternative, ist sie vielleicht (mittlerweile) auch verzichtbar.

Der Einsatz von Salt-Keys wehrt Angriffe ab, die sich der Prüfsummen-Werte (Hash-Keys) von in Wörterbüchern gesammelten Begriffen bedienen, welche z.B. in Passwörtern häufig Verwendung finden. Die dabei kombinierten Werte erschweren einen so initiierten Dateneinbruch, sofern der verwendete Salt-Schlüssel nicht zu schwach ist.

Beispiele für gesalzene Keys:

define('AUTH_KEY',         '/g1wTY[s:SnM=WH-A^+toOx0F6DQCjqbd($}RM$C]&c{`-,&m@q|Jd2X4CH[X kp');
define('SECURE_AUTH_KEY',  'Di{-v;OaAT.F/%QqCsq?%~IM,?*zw;XcMVbc(P],9R>r)tDnVNup|EkKUkbYbqeO');
define('LOGGED_IN_KEY',    'N*vj2iWi/H|k|[V|]IB-?b3yPe<|}o~uG6/|(ph ]6| ~G+28D>V#rtUNOW+`PNn');
define('NONCE_KEY',        'cFvw7+$7*3FH9US}-_7:f&3_lepZzmzNB|+$yn?cn/M>NNVITqL:h+3xc1+$3pvL');
define('AUTH_SALT',        '|E#0[@{{IvaEb504?l-^1xGZu-k&fCu8[sGeIBT~)@)-.!IL+}wS+BCAcJum_u;U');
define('SECURE_AUTH_SALT', 'jwX-FCdRYp9t-eA8<m2YZc>B|Xi@_?~0en+0>j+|L;Uk>Rr.U*Vrq?J+1NBR5iE<');
define('LOGGED_IN_SALT',   '*rYt?z|X<%AZj]|7mD|pc(S%g-&-{SO`k@d|Uj+c>5o(RN6SwbGDL5&|jPSr?9~c');
define('NONCE_SALT',       '$uCa>0s(fwMh$7FEq;i-(cW~&V!}.U*zY=MF_x6 7+1nrTbPXxZ+b_UeEv|-|3+B');

Passwörter wie „geheim123“, thomas1987 oder ähnliche leicht zu erratende Konstruktionen können im Zuge von Wörterbuch-Attacken (automatisiertes Durchprobieren zahlreicher Kombinationen von Benutzernamen und Passwort aus vorhandenen Listen) leichter erraten werden. Bei einem von WordPress vorgebrachten Passwortvorschlag, dessen Zeichenfolge erheblich sicherer zusammensetzt ist, wird das kaum gelingen. Es spricht auch nichts dagegen, ein Passwort zu verwenden das man sich gut merken kann, so lange es individuell und lang genug ist.

Einfach, aber effektiv gegen Wörterbuch-Attacken wirksam ist es beispielsweise, die Login-Seite zu „verschieben“, so dass sie gar nicht erst von Unbefugten aufgesucht wird. Das mag sicherheitstechnisch nicht unbedingt nötig sein, schont allerdings den Server.

Eine Zwei-Faktor-Authentifizierung wehrt Mitleser ab, wenn das System mit dem man sich anmeldet, befallen ist und ausspioniert wird. Wirksam ist der Schutz dann jedoch nur, wenn man dafür auch tatsächlich zwei unterschiedliche Geräte verwendet.

Was ist mit der Beschränkung von Loginversuchen?

Verschieben der Loginseite bringt mehr, vor allem wird damit der Server weniger belastet, da niemand auf ein Formular losgehen kann, das er gar nicht findet.

Was ist mit XML-RPC?

Das war tatsächlich bis Dezember 2015 (WordPress 4.4) ein Thema. Teilweise wurde die Deaktivierung geradezu als Pflichtübung gehandelt. Im Zuge von Aufräum- und Performance-Maßnahmen und wenn die Schnittstelle nicht benötigt wird (z.B. WordPress wird nicht als Blog verwendet, oder Pingbacks und Trackbacks sind nicht erwünscht und Inhalte werden nicht über externe Clients veröffentlicht), spricht nichts dagegen den XML-RPC-Link auszuschalten. Auch wenn Angriffe nichts ausrichten, können sie doch die Performance beeinträchtigen.

Fazit

Auf einer vernachlässigten Website ist ein Befall nur eine Frage der Zeit, da werden auf Dauer auch keine Schutzplugins helfen. Grund zur Panik besteht dennoch nicht. Wer seine Website pflegt und die Daten regelmäßig sichert, hat gute Chancen, dauerhaft verschont zu bleiben. Noch mehr Schutz bieten manuelle Konfigurations-Maßnahmen in der .htaccess und / oder Sicherheitsplugins.

Wem es zu viel ist sich eigenhändig um die Sicherheit seiner Installation zu kümmern, dem hilft Managed WordPress-Hosting, oder er kann sich vertrauensvoll an einen professionellen Dienstleister wenden, der sich nicht nur regelmäßig und um sämtliche Sicherheitsaspekte kümmert, sondern der auch in der Lage ist, im Worstcase zeitnah für die Wiederherstellung der Website zu sorgen.