Vor ein paar Tagen bekam ich mit, dass mein Server die Webseiten nur noch zögerlich bis gar nicht mehr ausliefert. Was eigentlich verwunderlich ist, steht dieser doch im Hause eines absoluten Expertenteams die sich schnell und unkompliziert über jeden kleinen Husten des Servers kümmern, wenn sie gebeten werden. Grund dafür war, ein massiver Versuch sich bei meinen WordPress-Installationen einzuloggen. Man kann in diesem Falle durchaus schon ein einem Angriff sprechen, denn es waren tausende Versuche innerhalb von nur Sekunden.
Froh war ich, dass ich direkten Zugriff auf den Server hatte in diesem Moment und nicht nur Kunde bei einem 0815 Webhoster bin, denn so fand ich schnell heraus, was die Auslieferung der Seiten so stark verzögerte. Ein Blick in das das access.log meiner Seiten verriet es mir. Massive anfragen auf die wp-login.php blockierten den Server. Und wenn ich massiv sage, dann meine ich nicht nur die üblichen 5 – 6 am Tag, sondern die Anfragen rauschten in einer Geschwindigkeit an mir vorüber, dass ich nicht mal in der Lage war auch nur eine IP zu erkennen. Es waren also tausende.
Im ersten Moment wird man da schon etwas nervös. Ist das der Versuch gehacked zu werden? Hat man sich irgendwo eine Sicherheitslücke eingesammelt, ist der Angreifer eventuell schon auf der Seite? Ok, die letzte Frage konnte ich mit NEIN beantworten, denn dann würde der Versuch sich einzuloggen nicht mehr stattfinden.
Doch was tut man nun dagegen?
Als erstes, Ruhe bewaren!
Nun hat man mehrere Möglichkeiten. Wenn man Zugriff auf den Server selbst hat, wie in meinem Fall, direkt erst mal den Apache beenden. Damit hat der Angreifer keinen Zugriff mehr auf die Datei und bekommt auch sonst erst mal keinen Zugang mehr zu irgendwas, was via Web ausgeliefert werden sollte. Somit sind die Webseiten erst mal offline und außer Gefahr.
Nun gilt es, den Angriff abzuwehren, wenn man den Apache wieder einschaltet. Dazu kann man nun jede einzelne IP die im access.log als Angreifer identifiziert wurde in eine deny from xxx.xxx.xxx.xxx Regel in die .htaccess eintragen, was jedoch bei dieser Menge absolut nicht zielführend ist. Denn dann wäre die .htaccess schnell einige Megabyte groß, also totaler Unsinn. Besser ist es, die wp-login.php direkt zu schützen und den Zugriff auf diese Datei via Nutzeridentifizierung zu gestalten. Auch hier hilft die .htaccess weiter.
Eine solche Authentifizierung – also eine Abfrage von Nutzername und Passwort – ist schnell eingerichtet. Die .htaccess hat man ja als anständiger WordPress-Nutzer eh schon im Hauptverzeichnis seiner Installation liegen, also muss nur noch eine .htpasswd angelegt werden. Die .htaccess wird dann um folgenden Eintrag erweitert.
1 2 3 4 5 6 | <files wp-login.php> AuthName "Admin-Bereich" AuthType Basic AuthUserFile /pfad/zu/deiner/.htpasswd require valid-user </files> |
In die .htpasswd kommen dann die Nutzerdaten rein. Eine Kombination kann folgendermaßen aussehen.
1 | Testuser:$1$YYYSWQNG$8BpaylFSwfqTq82GLiMR/0 |
Diese Daten kann man sich online generieren lassen, es gibt da einen sehr schönen .htpasswd Generator im Netz.
Wer es noch etwas sicherer mag, kann stat dem AuthType Basic den AuthType Digest nutzen. Dafür muss aber ein spezielles Apache-Modul installiert sein – mod_auth_digest. Welche Module geladen sind, finded ihr in eurer PHP-Info unter „Loaded Modules“. Bei Nutzung von AuthType Digest muss natürlich die Modifikation der .htaccess ein wenig anders aussehen.
1 2 3 4 5 6 | <files wp-login.php> AuthName "Admin-Bereich" AuthType Digest AuthUserFile /pfad/zu/deiner/.htdigest require valid-user </files> |
Auch die .htdigest hat einen etwas anderen Inhalt und kann auf dieser Seite erzeugt werden.
Ich hoffe einigen damit geholfen zu haben, bei mir ist nun auf jeden Fall wieder Ruhe eingekehrt. Auch dank der guten Mitarbeiter des Boreus Rechenzentrums, in dem mein Server steht. Denn die haben da auch noch etwas ihre Magie spielen lassen :-)
