Am vergangenen Mittwoch freute ich mich darauf, den Tag endlich mal bei einem netten Film auf der Couch ausklingen zu lassen. Eine halbe Stunde bevor ich den Computer für den Rest des Tages ausschalten wollte, kam aus dem Nebenzimmer ein Hilferuf. Der Blog meiner Lebensgefährtin war nicht mehr aufrufbar. Eine rote Meldung im Firefox warnte vor der Gefährlichkeit ihrer Seite.
Auf meinem Rechner dauerte es noch ein paar Minuten, bis dieser Warnhinweis ebenfalls zu sehen war. Schnell war klar, dass der Fernsehabend später beginnen würde. Unsere ersten Überlegungen, was zu tun sei, wurden von zwei Dingen unterbrochen. Einerseits von der Feststellung, dass wir gerade etwas hilflos vor einem Problem stehen und andererseits von der Tatsache, dass es nur wenige Minuten brauchte, bis auch meine Webseite nicht mehr erreichbar war. Shutdown – Ende – Aus – rien ne va plus.
Wir wussten, irgendwann wird es auch uns mal treffen, denn Hackerangriffe sind ja furchtbar in Mode gekommen. Nun ja, da war er, der Tag X vor dem wir uns fürchteten. Ein Tag X, vor dem wir nicht wussten, wie wir damit umzugehen haben. Zunächst schmissen wir den Plan für unseren Abend über Bord: Die Couch blieb leer und der Fernseher kalt, denn jetzt begann das große Googeln. Der erste Schritt bestand darin herauszufinden, was überhaupt geschehen war.
Da der Blog meiner Lebensgefährtin über WordPress läuft und auf einem eigenen Webspace gelagert wird und ich auch WordPress für meinen Blog benutze, ging der erste Verdacht natürlich schnell in diese Richtung. Entweder das CMS oder eines der Plug-Ins dürfte es wohl gewesen sein. So googelten wir gezielt danach, ob an dem Tag auch andere Personen betroffen waren und fanden – ohne Erfolg. Als nächstes rief ich bei unserem Provider an, der mir auch gleich sagen konnte, dass einige der php-Dateien mit einem iframe-Code infiziert seien.
Auch bei den Webmaster-Tools von Google, wo sich übrigens auch eine Hilfeanleitung verbirgt, wurde mir das bestätigt. Ein Klick auf den entsprechenden Link führt mich zu diesem iframe, den ich natürlich auch googelte. Und so kam ich wiederum zu dem Blog einer Person, die vor einiger Zeit ebenfalls in dieser Form betroffen war. Dort wurde ich auf die Idee gebracht, in den Log-Files nachzuschauen, was da so geschehen sein könnte. Und tatsächlich: Im ftp-Log konnte ich erkennen, dass um 15:52 Uhr Datein von meinem Webspace herunter- und wieder heraufgeladen wurden – unter einer ip-Adresse, die auf London verweist. Aber das heißt ja heutzutage nichts.
Ein Blick auf die log-Dateien meiner Freundin führte zu dem selben Ergebnis. WordPress war also aus dem Schneider. Fakt ist, der Angreifer kam über unser ftp-Passwort auf unseren Webspace. Dummerweise haben wir beim Laden von Dateien nie sftp genutzt, sondern immer nur ftp. Und hinzu kam noch, dass wir den Vorgang mit Filezilla durchführten. Dieses achso tolle und einfache Programm, mit dem man schnell mal Daten auf den Server schieben kann. Blöd nur, dass Filezilla das Kennwort in Klartext speichert, was gut sichtbar für jeden ist, der Zugriff auf den Rechner hat. Die Fehlerquelle war also lokalisiert, der genaue Vorgang unklar. Wurden die Passwörter nun beim ungesicherten Upload abgefangen oder hatten wir unerwünschten Besuch auf unserem Rechner?
Wie auch immer. Nach der Schadensanalyse folgte die Beseitigung und damit auch die Anleitung, was im Fall der Fälle zu tun ist:
1. Den Provider kontaktieren. Einerseits sollte ihm daran gelegen sein, dass seine Server sauber bleiben und andererseits kann er auch unter Umständen Hilfestellung geben oder weitere Gefahren eindämmen.
2. Die Seite vom Netz nehmen. Eine nicht besonders elegante, aber zweckmäßige Lösung ist das Verschieben sämtlicher Dateien in ein neu erstelltes Verzeichnis und eine neue htaccess-Datei, die auf eine simple HTML-Seite weiterleitet. Die in Notepad++ geschrieben htaccess-Datei sieht wie folgt aus:
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/tmp.html$
RewriteRule .* /tmp.html [L]
Die dazugehörige HTML-Datei:
<!Doctype html> <title>Police Line do not cross</title> <meta name="robots" content="noindex"> <p> Bitte gehen Sie weiter. Dies ist keine Übung.</p>
Die HTML-Datei wird unter dem Namen tmp gespeichert und die .htaccess natürlich mit dem obligatorischen Punkt. Somit sollten sich im Wurzelverzeichnis auf dem Server nur noch drei Dinge befinden:
Das neue Verzeichnis mit allen Dateien
Die Datei tmp.html
Die Datei .htaccess
Damit kann nun kein Außenstehender mehr gefährdet werden. Unser nächster Schritt an dem Abend war die Änderung des Passworts für den Webspace und das Zubettgehen, denn mittlerweile war es schon spät geworden.
3. Nun sollte geprüft werden, ob das eigene Betriebssystem in Ordnung ist. Siehe da, auf einem unserer Rechner fanden wir zwei exe-Dateien, die dort nicht hingehörten. Ob das nun im selben Zusammenhang steht, ist zwar offen aber eine gute Erklärung für den Vorfall.
4. Die ip-Adresse des Täters wird natürlich per .htaccess komplett ausgesperrt und hat nichts mehr auf dem Server zu suchen.
5. Schließlich spielt man ein Backup auf, das man natürlich vorher gemacht haben sollte. Das haben wir zum Glück sowieso aber auch unser Provider bietet jeweils Backups der letzten sechs Tage an. Den erstellten Ordner, die tmp-Datei und die provisorische htaccess können nun gelöscht werden.
6. Bei den Webmaster-Tools von Google teilt man mit, dass man den Schädling bzw. die Malware beseitigt hat und bittet per Mausklick um erneute Überprüfung der Webseite. Es heißt, dass dies bis zu 48 Stunden dauern kann. In unserem Fall waren es 8-9 Stunden, bis wir von der Blacklist verschwanden und die Seiten wieder wie gewohnt aufgerufen werden können.
7. Anschließend haben wir sämtliche Passwörter geändert. Und mit sämtliche meine ich auch sämtliche. Vom Router bis zum CMS-Adminportal, von ebay bis E-Mail – eben alles. Dabei wird einem erstmal bewusst, wie viele Passwörter und Accounts man mittlerweile so angesammelt hat. Dauerte auch eine halbe Ewigkeit.
8. Zum Schluss bleibt dann jetzt nur noch zu hoffen, dass wir alles richtig gemacht haben und auf dem Server nicht irgendwo eine Hintertür eingebaut wurde. Denn dann hätten wir in wenigen Wochen vermutlich das selbe Problem.
Diese Hilfestellung erhebt natürlich keinen Anspruch auf Vollständigkeit und Richtigkeit, sondern zeigt nur, wie ich dabei vorgegangen bin, den Angriff auf meinen Webspace abzuwehren. Übrigens: Filezilla nutze ich fortan nicht mehr.