Zurzeit häufen sich wieder die Angriffe auf WordPress Installationen. Dabei gibt es ganz unterschiedliche Gründe, für einen Angriff. Zu den 5 häufigsten Gründen gehören wohl:
- Angriffe auf den Sitebetreiber (um tatsächlich Schaden anzurichten, Daten zu zerstören)
- Angriffe zur Verbreitung von Schadcode (meist Javascript, Flash oder Java-Applets)
- Angriffe zur Übernahme des Servers in ein Zombie-Netzwerk
- Page-Rank Diebstahl (Link-Building)
- Hacker-Kids (die es aus Spaß machen, aber möglicherweise trotzdem Schaden anrichten)
Aber es gibt auch unterschiedliche Angriffsarten:
- Brute Force auf das WordPress Login Formular
- Ausnutzen von Sicherheitslücken im WordPress Core-Code
- Ausnutzen von Sicherheitslücken im Theme (in den Themes)
- Ausnutzen von Sicherheitslücken im Plugin (in den Plugins)
- Angriffe auf den Server selber (z.B. FTP oder SSH Login)
- Ausnutzen von Sicherheitslücken des Servers/der Serversoftware
Wie bei vielen anderen Themen, muss auch bei der WordPress Security jedes Angriffs-Szenario einzeln betrachtet, aber im Gesamten angegangen werden.
Es hilft überhaupt nicht, wenn man ein sicheres Passwort wählt, aber die Plugins unbeachtet veralten lässt. Auch muss unterschieden werden zwischen Präventivmaßnahmen und Sofort-Notfall-Maßnahmen.
Im Klartext:
„Will ich mich davor schützen, dass ich angegriffen werde“
oder
„Ich wurde bereits angegriffen und muss den Schaden minimieren“.
Dieser Beitrag handelt nun davon, wie man sich vor Brute-Force Angriffen auf das WordPress Login Formular schützen kann. Dabei gilt aber der Grundsatz: „Es gibt keine 100%ige Sicherheit“. Mann kann es dem Angreifer nur so schwer wie möglich machen mich anzugreifen.
Brute Force auf das WordPress Login Formular
An vielen Stellen liest man, dass es wichtig ist einen sicheren Benutzernamen und einen sicheres Passwort zu wählen. Grundsätzlich stimmt das natürlich, ist aber an vielen Stellen auf WordPress nicht übertragbar.
Sicherer Benutzername in WordPress
In der Standardinstallation erlaubt WordPress keine echten sicheren Benutzernamen. Tatsächlich sind nur Buchstaben, Zahlen, das AT-Zeichen (@), der Punkt, der Bindestrich und der Unterstrich im Benutzernamen erlaubt. Aber auch damit sind bereits einigermaßen sichere Benutzernamen möglich.
@chriss-2015@admin.amenotec@_@ liest sich für den Menschen zwar ganz normal, ist aber für ein Angreifer (Script, Bot) deutlich schwieriger zu erraten wie „admin“, „chriss.gebbing“ oder „chriss-gebbing“.
Aber was ist mit bestehenden unsicheren Benutzernamen?
Wordpress erlaubt es nicht den Benutzernamen zu ändern!
Entweder man nimmt ein Tool wie phpMyAdmin und ändert den Benutzernamen direkt in der Datenbank oder man erstellt erst den neuen „sicheren“ Benutzer, löscht den alten und während des Löschvorgangs fragt WordPress nach, wer den Content des alten Benutzers übernehmen soll.
Sicheres Passwort in WordPress
Natürlich ist es einfach sich ein sicheres Passwort für WordPress zu vergeben. Aber es hilft der WordPress Security nicht, wenn man sich das Passwort nicht merken kann und irgendwo aufschreibt. Die meisten User wissen gar nicht was ein sicheres Passwort ist. Die Frage ist auch gar nicht so leicht zu beantworten. Wikipedia geht davon aus, dass ein Passwort mit 8 Zeichen das nur aus Groß- und Kleinbuchstaben besteht innerhalb von 15 Stunden gehackt werden kann. Das ist aber eine rein theoretische Zahl die darauf basiert, dass eine Software 1 Milliarde Schlüssel pro Sekunde ausprobieren kann. Haben Sie keine Angst, das lässt Ihr Webserver nicht zu. Es würde viele Tage und Wochen brauchen ein 8 Zeichen langes sicheres Passwort zu knacken. Das Problem an dieser Stelle ist tatsächlich die Menschlichkeit. Die User versuchen sich das Passwort zu merken und nehmen deshalb ein leichtes. Vielleicht den Namen der Frau oder Freundin, der Name des Haustiers oder das Geburtsdatum. Zeichenfolgen auf der Tastatur „qwertz“ (Und für alle die es besser meinen, „qayxsw“ ist genauso) in wenigen Sekunden geknackt.
Nun gut, nehmen wir im Besten Fall an, der Admin nutzt ein sicheres Passwort. Steigert das die WordPress Security? Was ist wenn Sie im Team arbeiten? Wie wollen Sie als Sitebetreiber garantieren, dass jeder ein sicheres Passwort benutzt?
Klar, ein Plugin muss her: Password Policy Manager ist so ein Plugin. Man kann selber Regeln festlegen wie ein Passwort aufgebaut werden muss. So haben auch Team-Mitglieder keine Chance sich „einfache“ Passwörter zu merken. Sie müssen sich dann aber mit Ihren Team-Mitgliedern auseinandersetzen. Wenn der Unmut wächst, werden irgendwann die Regeln wieder gelockert und dann hat alles vorher gemachte keinen Sinn.
Logins limitieren
Die Logins zu limitieren kann auf unterschiedliche Weise erreicht werden.
- Limit der Login-Versuche
- Limit der Login-IP’s
- zusätzliche Limitierung
Limit der Login Versuche
Wenn sich nun einige den Wikipedia-Eintrag zum Thema Passwort angesehen haben, so wird mancher erschreckt denken:
„Was ist denn mit meinem Bank-Pin. 4 Stellig, nur Zahlen, also in unter 1ms zu knacken?“
Ja, das wäre theoretisch möglich. Es gibt ja eben nur 10.000 Kombinationen (eigentlich noch weniger, weil einige Kombinationen herausfallen). Das ist relativ schnell ausprobiert. Aber der potentielle Angreifer hat keine 10.000 Versuche. Die Karte wird nach drei fehlerhaften Versuchen einbehalten oder gesperrt. Genau hier setzen derlei Plugins wie Limit Login Attempts an. Sie erlauben nur wenige Versuche das Passwort zu erraten und sperren den Account, die IP-Adresse oder ähnliches.
Aber Vorsicht: Mann sollte immer mehrere User anlegen und im Zweifel einen Admin-User unbenutzt in der Ecke liegen lassen. Wenn ein Robot Ihren Admin-Account errät und sperrt, so kommen Sie selber auch nicht mehr ohne FTP- oder Datenbankzugriff in Ihre WordPress Installation.
Limit der Login-IP’s
Sie haben eine feste IP bei Ihrem Provider? Schön, dann verbieten Sie doch einfach allen anderen IP-Adressen das WordPress Backend. Der Vorteil liegt klar auf der Hand: Nur Ihr Anschluss darf ins Backend. Der Nachteil ist aber auch gravierend: Nur Ihr Anschluss darf ins Backend. Sie können also nicht von unterwegs „mal eben“ etwas posten.
Nur eine einzige IP im Backend zu erlauben ist recht einfach. Tragen Sie folgende drei Zeilen in Ihre .htaccess-Datei im WordPress Root-Path ein.
RewriteCond %{REQUEST_URI} !^/wp-admin/admin-ajax.php.*
RewriteCond %{REMOTE_ADDR} !=1.2.3.4
RewriteRule ^wp-admin/.* - [F]
1.2.3.4 ist dabei natürlich ein Platzhalter für Ihre feste IP-Adresse. Die erste Zeile schließt übrigens die Datei admin-ajax.php aus, da diese auch aus dem Frontend heraus benötigt wird.
Aber Achtung: Manche Provider erlauben das einschalten der RewriteEngine nicht. Da es aber hier eh spätestens bei den SEO- oder den Cache-Plugins Probleme gibt, sollten Sie hier über einen Providerwechsel nachdenken.
Zusätzliche Limitierungen
Wir selber nutzen ein Plugin, dass dem User bei jedem Login-Versuch per Request erst einen Security-Code auf sein SMS schickt. Erst durch zusätzliche Eingabe dieses Codes kann man sich am Backend von WordPress anmelden. Das Plugin befindet sich gerade in der Testphase und wird voraussichtlich im Sommer veröffentlicht. Es verbindet drei Sicherheitsmechanismen
- Single Passwort (Ein Passwort ist nur einmal gültig),
- Zwei-Faktor-Authentifizierung (Authentifizierung über zwei getrennte Kanäle)
- Disallow Account Sharing
Der letzte Punkt „Disallow Account Sharing“ wird oft vernachlässigt. Es gibt einen Admin-Account und 10 Personen kennen und nutzen den Account und dessen Passwort. Das wird durch dieses Plugin unterbunden, weil in der Regel nicht alle zehn Personen sich das gleiche Handy teilen, auf dem der Security-Code gesendet wird.
Wir halten dies aktuell für das sicherste Verfahren um das WordPress Backend abzusichern, dass mobil von unterschiedlichen Rechnern aus einsetzbar ist.
Die Sicherung des Backends durch HTTPS und selber ausgestellten Zertifikaten ist technisch möglich) bedingt aber, dass ich mein Zertifikat immer dabei habe und dies womöglich auf einem PC in einem Internet-Caffee installiere, womit es wieder „unsicher“ wird.
Der nächste Beitrag wird davon handeln, wie man das Ausnutzen von Sicherheitslücken im WordPress Core-Code verhindert.
