Wie naiv kann man sein?!

Seit einigen Monaten nutzen wir WordPress für unsere Site. Das ist nun wirklich nichts besonderes und eigentlich keiner Rede wert. WordPress hat sich in den letzten Jahren vom reinen Tool für Blogger zu einer weit verbreiteten Plattform für Web-Sites entwickelt. Sehr beliebt bei allen, die ihre Site nicht mit Code-basierten Mitteln herstellen wollen. Das gilt – mit gewissen Einschränkungen – auch für uns. Vorbei die Zeiten von Dreamweaver oder gar Frontpage, mit denen wir früher gearbeitet haben. Und die meisten Web-Hoster bieten WordPress schon seit längerem standardmäßig als App auf ihren Servern an. Kostenlos – unkompliziert – prima!

Soweit, so gut. So sind wir auch vorgegangen. Durch Zufall (YouTube sei Dank) sind wir dann auf einige Informationen gestoßen, die sich mit der Sicherheit von WordPress-Sites beschäftigen. Aber was betrifft uns das? Unsere mittelprächtige Site von einem nicht wirklich riesigen Unternehmen – wo sollte da das Interesse für Hacker sein? Die greifen doch nur die großen und interessanten Ziele an.

To make a long story short, haben wir ein Plugin (iThemes Security – dazu später mehr) installiert – und nicht schlecht gestaunt. Innerhalb kürzester Zeit summierten sich die Meldungen über Brute-Force-Angriffe auf unsere Site zu einer beachtlichen Zahl. Wir kommen am Tag auf durchschnittlich 20 bis 30 eher unfreundliche Versuche uns einen Besuch abzustatten. Ungebetene Gäste aus aller Herren Ländern klopfen bei uns an. Das mag wenig sein (keine Ahnung) und der IT-Admin eines großen Unternehmens wird sich über diese Marginalie vermutlich eher amüsiert zeigen. Aber…

ehrlich gesagt haben wir uns mächtig geärgert. Nicht über die Tatsache dass solche Angriffe stattfinden, sondern vielmehr über unsere gnadenlose Naivität. Wie naiv kann man sein, um davon auszugehen, dass „bei mir schon nichts passiert“?

Was passiert da?

Vorausschicken möchten wir, dass wir keine Experten für IT-Security sind und auch nicht den Anspruch erheben, dies zu sein. Wenn es also um eine spezielle Beratung beim Schutz der eigenen Web-Site geht, sollte man sich an die einschlägigen Fachleute bzw. Fachfirmen wenden.

Festzuhalten ist, dass die WordPress-Plattform aufgrund ihrer hohen Verbreitung ein äußerst beliebtes Angriffsziel darstellt. Die Brute-Force-Methode ist eine gerne genommene Angriffsmethode, um Passwörter herauszufinden oder Daten zu entschlüsseln. Sie nutzt „rohe Gewalt“ (brute force), indem sie wahllos verschiedene Buchstabenfolgen oder Zeichenketten automatisiert ausprobiert. Je mehr Kombinationen getestet werden, desto höher ist die Erfolgsaussicht. Prinzipiell lässt sich jedes Geheimnis durch Ausprobieren lösen. Allerdings steigt die hierfür benötigte Zeit mit der Komplexität des Geheimnisses. Moderne, leistungsfähige Rechnersysteme sind in der Lage, binnen kurzer Zeit viele mögliche Kombinationen durchzurechnen. Mit Hilfe komplexer Passwörter, langer Schlüssel und der Begrenzung von möglichen Fehlversuchen bei Logins lassen sich die Erfolgsaussichten von Brute-Force-Angriffen senken.

Ist der Angreifer aber erst einmal „drin“, lassen sich in den Skripten der Site problemlos Schadcodes (Malware, Schadprogramme, Trojaner) unterbringen. Der Eigentümer (Admin) der Site bemerkt davon meist absolut nichts. Denn es ist ja der Charme von WordPress, dass man sich nicht mit dem Code beschäftigen muss. Der Eigentümer/Admin sieht nur die Oberfläche und die Site, nicht den Code. Da die WordPress Dateien in den meisten Fällen nicht lokal gespeichert sind, sondern sich auf dem Server des Web-Hosts befinden, kann man auch keine lokalen Viren- bzw. Malware-Scanner zur Prüfung der eigene Site-Dateien nutzen.

Das Ergebnis solcher Angriffe machst sich meist erst beim Besucher der Site bemerkbar – und dies unangenehm.

Die Auswertung unserer Protokolle hat jedenfalls ergeben, dass sich diese Angriffe in etwa 10% der Fälle direkt auf die wp-admin.php, also den direkten Zugang zum WordPress Backend richten. In 80% der Fälle wird die XMLRPC-Schnittstelle (xmlrpc.php) angegriffen. Diese Schnittstelle wird von WordPress vor allem als mehr oder minder offener Eingang für Blog-Kommentare genutzt und dient gleichzeitig als Schnittstelle, um WordPress über externe Programme verwalten zu können. Diese Schnittstelle ist bei WordPress seit der Version 3.5 standardmäßig offen und lässt sich ohne zusätzliches PlugIn nicht beeinflussen.

Die Vorgehensweise bei den Angriffen ist dabei meist die gleiche. An die beiden Eingangstüren (wp-admin.php alternativ xmlrps.php) wird erst einmal eine Anfrage nach dem Muster

.../?action=lostpassword">Passwort vergessen?</a>

gesendet, um über die „Passwort vergessen“-Funktion eine Reaktion hervorzurufen. Dann wird eine geballte Ladung von möglichen Passworten ausprobiert. Geeignete Tools sind in der Lage bei so einer Anfrage bis zu 500 Passwörter in einer Anfrage unterzubringen und reduzieren den zeitlichen Aufwand damit erheblich, irgendwann auf die korrekten Login-Daten zu stoßen. Selbst aktuelle WordPress-Versionen (5.03) sind davor nicht geschützt.

Die nächste Methode die es Angreifern ermöglicht in die Site einzudringen, ist über Funktionsaufrufe direkt an die XMLRPC-Schnittstelle mit wp.getUsersBlogs oder wp.getComments Kombinationen von Benutzernamen und Passwort zu erproben. Sobald ein Angreifer Benutzername und Passwort sendet, wird die xmlrpc.php entsprechend Rückmeldung geben, ob die Kombination korrekt ist oder nicht.

Was tun?

Schritt 1 – Passwort für den Zugang zum Backend

Es ist fast peinlich, soll aber nicht unerwähnt sein. Wer als Zugangspasswort zum WordPress-Backend (also der wp-admin.php) immer noch „Admin“ verwendet, dem ist wirklich nicht zu helfen. Das Passwort sollte möglichst komplex sein und eher 15 als 8 Zeichen enthalten. Passwort Generatoren und Passwort Manager gibt es wie Sand am Meer.

Schritt 2 – Backup

Es soll ja immer noch Menschen geben, die mit  Thema Datensicherung auf dem Kriegsfuß stehen. Hm… nicht wirklich smart. Aber sei es drum. Spätestens vor den nächsten Schritten ist ein Backup der externen Datenbank via ftp fällig. Die verbreitetste Software zur FTP und SFTP Datenübertragung dürfte FileZilla sein. Diese Software ist erprobt, zickt nicht rum und ist kostenlos.

Zunächst muss beim Provider geklärt werden, wo der ftp-Zugang zur Datenbank ist. Bei jedem Provider (zumindest nach unserer Kenntnis) befinden sich im Kundenmenü entsprechende Informationen über die ftp-Serveradresse und die erforderlichen Passworte.

Dann den Zugang herstellen und die Datenbank-Dateien lokal speichern. Dies ist für den nächsten Schritt zwingend!

Man sollte hierbei bedenken, welches Backup da hergestellt wird. Bei der Erstinstallation von WordPress (beim Provider/WEB-Host) wird mehr oder minder automatisch auch eine MySQL-Datenbank erzeugt. „Mehr oder minder“ bedeutet, dass bei diesem Vorgang nur die Auswahl bleibt, welche PHP-Version verwendet wird. Auf diese MySQL-Datenbank setzt WordPress dann auf. Die vorgenannte Methode via ftp bezieht sich ausschließlich auf das Backup der WordPress-Files. Die eigentliche MySQL-Datenbank ist auf diesem Weg nicht zu erreichen. Ein Backup der MySQL-Datenbank kann nur über die „Backup“-Funktion im Kundenmenü des Hosts erfolgen, nicht via ftp. Für die weiteren Schritte genügt aber ein Backup der WordPress-Files mittels ftp-Zugang.

Schritt 3 – Den Zugang zum Backend verschleiern

Normaler Weise liegt der Admin-Zugang zum WordPress-Backend im Root-Directory der Site. Die Adresse lautet dann beispielsweise „www.domainname.de/wp-admin/“. Diese Tatsache ist jedem Nutzer von WordPress und definitiv jedem Hacker bekannt. Da wäre es doch hilfreich, wenn man diesen Zugang verschleiern könnte. Okay, man kann und hierzu gibt es 2 Möglichkeiten, die man auch kombiniert einsetzen kann.

Möglichkeit 1 ist die Umbenennung des Admin Zugangs mit dem PlugIn „Rename wp-login.php“. Dieses PlugIn ist schon etwas älter, funktioniert aber einwandfrei. Nach Aktivierung des PlugIns und Eingabe der erforderlichen Änderung lautet die Anmelde-URL dann entsprechend der Änderungen in diesem Plugin und nicht mehr „wp-admin“. Es wäre natürlich hilfreich, wenn man sich diese neue URL sicher (z.B. im Passwort-Manager) notiert hat. Andernfalls ist der Zugang zum Admin-Bereich versperrt (was ja das eigentliche Ziel war) und es hilt nur noch das vorher hergestellte Backup via ftp-Programm zurück auf den Server zu spielen.

Möglichkeit 2 ist die Verlegung des gesamten WordPress Zugangs in ein anderes Directory. Danach befindet er sich nicht mehr im Root, also in dem oben bereits erwähnten „www.domainname.de/…“, sondern in einem neuen Unterverzeichnis mit beliebigem Namen. Hierzu ist wieder ein Plugin erforderlich. Dieses Mal ist es „WPS Hide Login“. (Hierzu gibt es ausführliche Tutorials bei YouTube, was wir dringend empfehlen!) Nach der Installation sollte man das PlugIn keinesfalls sofort aktivieren, sondern zuerst genauestens einrichten. Denn nach der Aktivierung wird das Backend geschlossen und man muss sich unter der neuen URL neu anmelden. Wenn man die erforderlichen Zugangsdaten nicht genau notiert hat, ist wieder das vorher hergestellte Backup am Zug.

Schritt 4 – Zugang zur XMLRPC-Schnittstelle schließen

Auch hierzu gibt es wieder zwei Möglichkeiten. Eine, die sich nur um die seit WordPress Version 3.5 ständig offene Schnittstelle kümmert und die rabiate Variante, die generell versucht Brute-Force Angriffe abzuwehren.

Man sollte sich aber vorher klar machen, dass diese Schnittstelle nicht grundlos existiert. Sie ist das Tor zur Außenwelt der Site und kümmert sich beispielsweise um Pingbacks, also ein- und ausgehende Mitteilungen von anderen Webseiten. Außerdem greifen verschiedene Plugins (wie beispielsweise Jetpack) oder Apps darauf zu. Wer diese Funktionen zwingend benötigt, muss sich andere Wege zu deren Schutz suchen.

Möglichkeit 1 ist die Installation des PlugIns „Disable XML-RPC“ von Philip Erb. Dieses PlugIn macht nur eins, es schließt ganz stumpf die XMLRPC-Schnittstelle, sonst nichts. Genügt aber meistens.

Möglichkeit 2 ist da etwas umfangreicher und auch deutlich rabiater. Das PlugIn „iThemes Security (formerly Better WP Security)“ schließt nur unter Anderem die XMLRPC-Schnittstelle. Es lässt sich mit diversesten Einstellungen auch die gesamte Datenbank überwachen. Jede Änderung in allen Dateien wird kontrolliert und dokumentiert (was manchmal nervig sein kann, wenn man die Site häufiger verändert oder z.B. Beiträge, wie diesen schreibt). Außerdem wird (hoffentlich) jeder externe Zugriffsversuch erkannt und nach einstellbaren Kriterien (wieder hoffentlich) abgeblockt. Empfohlen wird beim dritten Versuch. Das läßt sich aber auch noch strammer einstellen. Zur Abwehr der ganz unerfreulichen Besucher kann man auch, wenn gewünscht, eine externe Blacklist heranziehen, die einschlägig bekannte URLs sofort abblockt.

Eine weitere, höchst charmante Einstellung ist die Überwachung der 404-Funktion. Der „404 not found“ Statuscode wird immer dann gezeigt, wenn defekte oder nicht vorhandene Links oder Web-Seiten aufgerufen werden. Hat jeder schon einmal gesehen. Dies machen sich „neugierige“ Menschen gerne zu nutze um mal zu sehen, was da sonst auf der Site noch so los ist und ob man nicht über Entwürfe, offline gestellte Seiten oder andere Türchen in die Site gelangen kann. Anfragen an die Site, die mit „404“ beantwortet werden, werden ebenfalls überwacht. Frequenz und Zeitraum können eingestellt werden. Ist jemand zu häufig allzu neugierig, wird er ausgesperrt.

Die Bedienung und Einstellung dieses PlugIns zu erläutern, übersteigt allerdings die Möglichkeiten dieses Beitrags bei weitem. Hier hilft wieder YouTube mit etlichen Tutorials.
Der guten Ordnung halber sei erwähnt, dass die Existenz der von diesem PlugIn erzeugten Security-Log-Files in der Datenschutzerklärung erwähnt werden sollte.

Zum guten Schluss noch drei Anmerkungen.

Alle hier genannten Programme und PlugIns sind kostenlos. Insoweit ist das hier keine Werbung für irgend etwas oder irgend jemand. Alle genannten PlugIns lassen sich innerhalb des WordPress Backends über die hinlänglich bekannte „PlugIns installieren“-Seite installieren.

Nehmen Sie die hier erwähnten Einstellungen nicht „einfach mal so“ vor. Die meisten Einstellungen bedürften vorher genauer Information und es sollte unter allen Umständen vorher ein Backup der WordPress-Datenbank erfolgen. (Man kann es nicht oft genug erwähnen.)

Und… was auch immer wir tun und installieren – PlugIns hin und Verschleierung her – vor Hackern können wir uns nie zu 100% schützen. Nur völlig naiv sollten man nicht sein und es den ungebetenen Besuchern so schwer machen, wie es möglich ist.

🖖🏼