Seit etwa Februar 2013 finden im diesmal extrem großen Stil Angriffe per Botnetz auf WordPress-Blogs statt. Darüber ist viel geschrieben worden, aber ein paar eigene Erkenntnisse möchte ich noch beisteuern.
IP-Adressen der Angreifer per .htaccess-Datei (im Falle eines Apache-HTTP-Servers) zu sperren hat keinen Sinn, es wurden schon über 90.000 verschiedene mit weltweiter Herkunft gezählt. Oft wird das Plugin »Limit Login Attempts« empfohlen. Diese Erweiterung verhindert Brute-Force-Attacken. Sie ist leicht zu konfigurieren und gehört für mich inzwischen als Muss zu jeder WordPress-Installation.
An vielen anderen Schwachstellen setzt »Better WP Security« an. Was mir besonders gut gefällt, ist eine Verschleierung des Login-Bereiches: über die gewohnten Dateinamen ist das Login nach entsprechender Einstellung nicht mehr erreichbar. Ferner kann man zum Beispiel die Anmelde-Möglichkeit auf bestimmte Tageszeiten begrenzen, das Tabellenpräfix ändern, die Benutzer-ID »1« (= standardmäßige ID des Administrator-Accounts) in eine andere Zahl umschreiben, die wichtigsten Dateien und Verzeichnisse per .htaccess-Einträge gegen Zugriff abriegeln und so weiter. Die Optionen sind wirklich beachtlich, aber man sollte auf jeden Fall vor irgendwelchen Änderungen ein Datenbank-Backup machen. Außerdem kann man sich im schlimmsten Fall selbst vom Blog aussperren. Man muss dann die .htaccess-Datei bearbeiten. Also bitte ein wenig Vorsicht walten lassen!
Es wird von den Angreifern übrigens nicht nur der Benutzername »admin« verwendet, wie man in manchen Blogartikeln lesen kann, sondern auch »Admin«, »administrator«, »Administrator«, »adminadmin« und womöglich noch weitere Variationen. Das Wichtigste ist also, keinen Benutzernamen zu verwenden, in welchem »admin« in irgendeiner Form vorkommt.
Um aber Angreifer gar nicht bis zum Anmeldebereich kommen zu lassen, habe ich mich entschieden, die Datei wp-login.php in Hauptverzeichnis des Blogs nur für meine eigene IP-Adresse freizugeben – genauer gesagt: für den IP-Bereich meines Internet-Service-Providers. Dazu sind nur ein paar Zeilen in die .htacess-Datei einzutragen:
# Adminbereich absichern
<Files wp-login.php>
Order Deny,Allow
Deny from all
Allow from xx.xxx.
</Files>
Anstelle von »xx.xxx.« trägt man natürlich die ersten zwei Bytes des IP-Bereiches seines Providers ein. Hier kann man seine IP-Adresse ermitteln:
www.torstenkelsch.de/deine-ip.php
Weitere Informationen:
t3n.de/news/massive-angriffswelle-[…]
www.heise.de/security/meldung/Botnet-attackiert-Wordpress-[…]
www.golem.de/news/security-angriff-gegen-admin-konten-[…]
2013-05-25 um 20:42
Limit Login Attempts ist genauso sinnvoll, wie IP-Adressen in der .htaccess zu sperren, nämlich gar nicht. Bei 90.000 Angreifern verhindert das auch keine Brut-Force-Attacken. Am sinnvollsten ist ein sicheres Passwort. Sehr hilfreich ist auch ein zusätzlicher Login via .htpasswd. Sinnvoll ist auch, in der Datenbank den login_name in der Tabelle präfix_users anders zu setzen als den user_nicename, weil die Angreifer mittlerweile auch den user_nicename auselesen.
2013-05-25 um 21:53
Na, ich halte Limit Login Attempts trotzdem für sinnvoll, weil Traffic und Serverlast verringert werden, indem beispielsweise nach drei Login-Fehlversuchen die IP für 72 Stunden oder so gesperrt wird. Richtig Ruhe habe ich, seitdem ich die wp-login.php nur noch für die IP-Range meines eigenen ISP zugänglich gemacht habe. Ein vorgeschaltetes .htaccess-/.htpasswd-Passwort ist natürlich auch eine gute und ziemlich sichere Maßnahme, die man ja noch zusätzlich treffen kann.
Deinen Tipp mit dem in der Datenbank zu ändernden Login-Namen kannte ich noch nicht. Allerdings denke ich, dass WordPress ganz gut gegen SQL-Injections geschützt ist, sonst würden die Angreifer es ja nicht immer nur mit admin etc. versuchen, sondern mit dem echten Admin-Namen. Was ich allerdings gelesen habe ist, dass Angreifer womöglich den Namen der Artikel-Autoren auslesen. Daher wurde empfohlen, diese Namen gar nicht ausgeben zu lassen. Bei Blogs mit mehreren Autor(inn)en ist das natürlich unschön. Und hier sehe ich in deinem Trick, Login- und Nice-Name unterschiedlich zu benennen, eine gute Alternative.
2016-06-13 um 21:30
Limit Login Attempts hat mich zwar schon von reichlich unerwünschten Anmeldeversuchen bewahrt, allerdings wurde diese Erweiterung seit inzwischen vier (!) Jahren nicht mehr aktualisiert!
Autoren-/Nutzernamen auszulesen, ist in der Tat einfach, hat man aber ein starkes Passwort, ist diese Gefahr relativ unbedeutend.
2016-06-13 um 22:43
Ich sage mal so: So lange eine Software funktioniert und keine Sicherheitslücken hat, ist es ja einigermaßen egal, wie alt sie ist. Allerdings gibt es Sicherheits-Plugins, die wesentlich umfangreicher und leistungsfähiger sind als Limit Login Attempts.
Ein starkes Passwort ist natürlich das A und O, und zum Glück verlangen die meisten aktuellen Content-Management-Systeme auch starke Passwörter. Aber ich denke, heutzutage wird eher über andere Schwachstellen versucht, einzudringen. Man liest nämlich ab und zu von Webhostern oder Web-Dienstleistern, dass Benutzer ihre Systeme nicht aktuell halten, sei es aus Unwissenheit oder aus Bequemlichkeit. Da ist es für Angreifer dann leicht einzudringen, also über Schwachstellen, die mit den Benutzerdaten und Passwörtern gar nichts zu tun haben. Und für WordPress gibt es offensichtlich zahlreiche Plugins, die Sicherheitslücken haben. Ich stelle fest, dass ständig WordPress-Blogs von Bots nach solchen unsicheren Erweiterungen gescannt werden. Fazit: So wenige Plugins einsetzen wie möglich. Viele Dinge lassen sich über die Date functions.php regeln.
Was mir aber auch wichtig ist: Ich möchte Angreifer möglichst schnell und möglichst schon vor WordPress abwehren; genauso, wie man Einbrecher ja auch am besten schon an der Haustür und nicht erst an der Wohnungstür blockiert. Und da bietet sich im Falle von Apache-Servern die .htaccess-Datei an (mit Nginx-Servern kenne ich mich nicht aus). Wenn man es schafft, hier schon Angreifer abzuwehren, kommen sie erst gar nicht bis zur „Wohnungstür“ von WordPress. Allerdings ist es mir noch nicht gelungen, Anfragen per GET-Parameter abzublocken – ich weiß einfach nicht, wie man es bewerkstelligen kann, dass der Server bestimmte Anfragen ablehnt (so was wie …/wp-admin/tools.php?page=backup_manager&download_backup_file=../wp-config.php). Wäre schön, wenn da mal ein Kenner/Könner eine Lösung hier vorschlagen könnte.