WordPress – Botnetz und Brute-Force-Attacken zur Ermittlung von Logins abwehren

Angriffsszenario

Zum Knacken von WordPress-Seiten (zunächst zum Verschaffen von Zugängen) werden massenhafte Login-Versuche auf bestimmte Seiten einer WordPress-Installation gesendet. Einfallstore: Wenn man eine Site www.xyz.de betreibt

  • ergibt sich bei WordPress der Admin- bzw. User-Zugriff via www.xyz.de/wp-login.php und
  • die Konfigurationsdaten liegen auf in einer Datei namens www.xyz.de/wp-login.php.

Auf die Datei bzw. den Link www.xyz.de/wp-login.php muss ein Angreifer nun nur noch ein Lexikon mit gängigen Login/Passwort-Kombinationen loslassen um mit hoher Wahrscheinlichkeit einen Zugriff zu erhalten.

Nach aktuellen Untersuchungen nutzen rund 99% der erfolgreichen Angriffe Lücken und Schwächen, die relativ leicht zu schließen gewesen wären. Die Angreifer/Hacker sind also weniger – wie in Film und Literatur oft skizziert (etwa in Stirb Langsam 4) – brilliante Genies, die hinter Pizzaburgen versteckt für Normalsterbliche unabdingbar jedes Ziel spielend überwinden. Es handelt sich eher um Leute mit Ingenieurs-Mentalität, die Ihre Hausaufgaben machen und nach sauberer Analyse bekannte Schwachstellen gekonnt nutzen. Auf den Alltag abgebildet: Hier agieren Leute, die weniger mit verrückten selbstgebastelten Infrarotscannern durch Wände gucken, sondern wissen, dass Bargeld bis heute oft in Dosen mit der Aufschrift Zucker liegt und daher dann eben – nachdem sie auch den Trick mit dem Schlüssel unter der Matte befolgen – in Zuckerdosen nachgucken.

Schwache Passworte oder schwache User/Passwort-Kombinationen sind nach denselben Untersuchungen bis heute ein riesiges Einfallstor in fremde Systeme.

  • Simpel-Passworte – rund 10% aller Nutzer wählen ihren Vornamen als Passwort oder behalten unveränderte Standardeinstellungen bei
  • Standard-Nutzer wie z.B. adminunter WordPress werden nicht entfernt und auch deren Standardpassworte nicht verändert
  • Passworte werden für mehrere Websites und Dienste in nahezu gleicher Form verwendet. Im Laufe einer digitalen Existenz landet dann eine User-ID/Passwort-Kombination bei einem erfolgreichen Angriff auf irgendeinen dieser Services in einem Angreifer-Lexikon. Wo immer solche ein Lexikon dann angewendet wird, ist ein solcher Account dann natürlich leicht aus dem Weg zu schießen.

  • Ein Webserver wie Apache macht eigentlich nichts als Dateien, die auf einem Rechnerlaufwerk liegen, im Falle von Anfragen (z.B. via http) über den vorgesehenen Weg auszuliefern. Ohne einen solchen „Übergang“ kommen Dateien nicht von einem lokalen Rechnerlaufwerk in den Browser. Allerdings sollen z.B. im World Wide Web nicht gleich für jedermann die dieselben Rechte gelten wie für den Autor der Dateien auf seinem lokalen Rechner. Diese Modalitäten können über Dateien mit dem Namen .htaccess (Konvention) gesteuert werden.
  • In diesen Dateien kann über Kommandos beschrieben werden, ob, wie oder unter welchen Bedingungen der Apacher-Server Dateien im betreffenden Ordner über den Webserver ausliefert.

Beispiele

  • Dateien können z.B. mit ZIP o.ä. komprimiert werden ehe sie an den Browser geschickte werden
  • Dateien, die bestimmte Informationen wie die Datenbank-Passworte erhalten sollen natürlich in aller Regel überhaupt nicht geöffnet werden können, wenn man deren Dateinamen weiß und sie daher direkt in die Browserzeile eingeben kann. Daher kann man Apache anweisen bei bestimmten Dateinamen so zu tun, als wenn es diese Dateien nicht gäbe.
  • Schon in alten nur-HTML-Zeiten wollte man häufig unterbinden, dass Besucher einer Website die Ordnerstuktur direkt ansehen und Dateien, die absichtlich nicht verlinkt sind, auf diesem Wege finden und herunterladen können.
  • Im Falle eines Angriffs via Botnetz hilft ein IP-basierter Zähler-Schutz (Blocken der IP-Adresse nach n Angriffen in einem bestimmten Zeitintervall o.ä.) wie ihn einige Security-Tools anbieten wenig, da der ausführende Rechner nach jedem Login wechselt
  • Eine einfache Sicherheit bietet hier eine vorgeschaltete Zugriffsprüfung, die den Angreifer gar nicht erst zur PHP-Ebene vorlässt

Apache mit .htaccess-Datei scharfmachen

  • Der Apache-Webserver macht eigentlich nichts als Dateien, die auf einem Rechnerlaufwerk liegen, im Falle von Anfragen (z.B. via http) auszuliefern. Das kann über Dateien mit dem Namen .htaccess (Konvention) gesteuert werden.
  • In diesen Dateien kann über Kommandos beschrieben werden, ob, wie oder unter welchen Bedingungen der Apacher-Server Dateien im betreffenden Ordner über den Webserver ausliefert.

Schritt 1 – Account anlegen

Für den hier angestrebten Schutz muss zunächst ein technischer Account (nur für den Webserver, kein voller Unix-Account) angelegt werden, auf den die .htaccess-Datei später zugreift.

  • Per SCP/FTP im Ordner /usr/share/ einen Unterordner namens WordPress anlegen
  • Dann via putty/SSH/Linux-Shell folgenden Befehl eingeben:
htpasswd -c /usr/share/wordpress/.htpasswd
  • Für einen eigenen Accountnamen frei wählen
  • Nach Eingabe des Befehl erfolgt normalerweise die Abfrage des gewünschten Passworts in zwei Schritten (Eingabe + Verifikation, wie üblich bei Passworten)

Wenn alles funktioniert hat, sieht das wie folgt aus:

htpasswd-Ablauf

Schritt 2 – Inhalt der .htaccess-Datei

  • Im WordPress-Verzeichnis muss nun eine Datei namens .htaccess (ja – mit dem Punkt am Anfang) auf dem Servers angelegt werden und der unten stehende Code eingetragen werden
  • Falls so eine Datei schon vorhanden ist, dann den unten stehenden Code in die vorhandene Datei eintragen
# .htaccess-Border
<FilesMatch "(wp-config.php|wp-login.php)">
  AuthName "HTAccess"
  AuthType Basic
  AuthUserFile /usr/share/wordpress/.htpasswd
  require valid-user
<FilesMatch>

Ergebnis: ein Apache-Login vor dem WordPress-Login. Das genügt häufig, um einfachen Gelegenheits-Angreifern – auch via Botnetz – die Lust zu nehmen. Natürlich wirkt auch diese Hürde nur, wenn keine allzu simplen User-ID/Passwort-Kombinationen wie demo/demo etc. verwendet werden.

Apache-Login