Heute will ich mich einmal dem leidigen Thema des Webserver-Hackens widmen. Indem ich aus meiner Erfahrung spreche, hoffe ich, dem sehr zeitintensiven und potentiell rufschädigenden Leidwesen ein stückweit einen Riegel schieben zu können. Drei Fragen tauchen auf: Erstens, weshalb werden Webserver gehackt. Zweitens, was tut man, wenn eine Website oder ein Server befallen ist? Und zweitens, mit welchen Vorkehrungen kann man einen Server derart härten, dass zukünftige Angriffsversuche zum Scheitern verurteilt sind?
Seit Junk-Email-Filter und Antiviren-Programme immer effizienter unerwünschte Spam-Emails unterbinden, muss sich die kriminelle Energie im Internet nach alternativen Wegen umschauen. Immer häufiger werden daher Webserver das Ziel von Attacken. Dabei geht es im harmloseren Fall darum, mittels eines sogenannten „Google-Pharmacy-Hacks“ eine Online-Apotheke auf einer anderen Website wiederzugeben, wo Mann Viagra und andere potenzsteigernde Produkte erstehen soll. Das perfide daran ist, dass man bei einem direkten Aufruf der Website die gewohnten Inhalte sieht. Nur wenn man über Google die Website gefunden hat, so wird in der Voransicht und beim Aufrufen des Links aus den Suchresultaten die Apotheken-Seite angezeigt. Klar dürfte sein, dass die Hacker besonders scharf sind auf gut vernetzte Websites mit hoher Vertrauenswürdigkeit und entsprechend gutem Google Pagerank. Wie z.B. die von Pragmas betreuten Websites mit wissenschaftlichen Inhalten und einer internationalen Online-Community wie wocat.net oder biodiversitymonitoring.ch. Bei üblerem Befall können dann über Sicherheitslücken im Browser Virenprogramme auf den Computer eines Webseiten-Besuchers übertragen werden. Hier steckt die Absicht dahinter, fremde Computer zu überwachen und fernzusteuern.
Eine befallene Website ist in jedem Fall ein sehr ernster Fall. Die Hacker haben eine sogenannte „Webshell“ auf den Server geladen, mit der sie Dateien auf dem Server einsehen und manipulieren können, sie haben meistens Zugriff auf die Datenbanken und im schlechten Fall können sie sogar auf Betriebssystem-Ebene Befehle ausführen. Die wirksame Bekämpfung eines befallenen Servers sieht so aus, dass man ihn zuerst vom Web nehmen muss, so dass ausser einem selbst niemand anders mehr auf den Server zugreifen kann. Wo dies unmöglich ist, sollte mit einem Klon des Servers gearbeitet werden, der anschliessend die Live-Site ersetzt. Dann muss man die potentiell befallenen Softwareteile wie Betriebssystem, Web- und Datenbankserver, Content-Management-System und dessen Erweiterungen komplett neu installieren. Hierbei sollten auch sämtliche Passwörter neu vergeben werden. Dann folgt die Suche nach verseuchten Dateien in den restlichen Verzeichnissen, welche im Bereich des Web-Wurzelverzeichnisses liegen. Das Schlüsselwort dazu lautet die Suche nach „obfuscated“ Code, nach getarnten, schwer verständlichen Befehlen. Das sieht bei php so aus, dass mittels eval(), call_user_func_array(), base64_decode(), gzinflate() usw. unverständlicher Code in ausführbaren Code umgewandelt und interpretiert wird. Der eigentliche ausgeführte Code muss aber nicht direkt in einer Datei auf dem Server liegen, sondern könnte auch per Formular-Post oder via ein Fake-Cookie übermittelt werden. Grundsätzlich sollte man kritisch nach php-Dateien suchen, wo diese nichts verloren haben. Neben Upload-Verzeichnissen werden bei einem CMS häufig auch Code-Bestandteile in Konfigurations-Dateien geschmuggelt. Erst wenn man 100% sicher ist, den Server von sämtlichen unerwünschten Dateien und Codebestandteilen gereinigt zu haben, sollte man wieder online gehen. Es reicht eine Datei auf einem manchmal mit hunderten verseuchten Server und nach einigen Tagen beginnt die ganze Handarbeit von vorne.
Zudem muss man vorgängig als zweiten Schritt verhindern, dass die Angreifer durch dieselbe Eintrittspforte nochmals auf den Server gelangen können. Dazu gibt es bei den gängigen CMS in immer kürzeren Abständen Sicherheitsupdates für das System und die Erweiterungen. Falls man hier einigermassen à jour bleiben kann, so hat man wenigstens die Garantie, dass bekannte Schwachstellen abgedeckt sind. Auch hilfreich kann die Installation eines Virenscanners wie z.B. „rkhunter“ auf dem Server sein. Das Problem bleibt jedoch, dass die Einfallsmethoden immer raffinierter ausfallen. Mittels „SQL-Injection“ können per Datenbank-Server Files auf den Server geladen werden, mittels „Tamper Data“ (Datenverfälschung) kann Programmcode in Bilddateien versteckt hochgeladen und anschliessend ausführbar hinterlegt werden, und mittels „Dorking“ (Idiotensuche) werden gezielt Webseiten mit Schwachstellen gesucht. Da die Exposition eines Webservers weltweit und 24h am Tag ist und die Schwachstellen insbesondere in Open Source Code immer noch schwer voraussehbar sind, sollte man nicht darauf vertrauen, dass die Einfallspforten von freiwilligen arbeitenden Entwicklern in dem Umfang geschlossen werden, wie neue auftauchen.
Als Konsequenz hier noch mein persönlicher Tipp und Brachialmethode, wie man effizient und bei mir bisher dauert verhindert, dass etwas Unvorhergesehenes auf einem Webserver geschieht: Man entziehe dem Webserver auf allen Verzeichnissen die Schreibrechte, in denen Programmier-Code ausgeführt werden soll. Dazu kann man je nach Konfiguration die Befehle chmod oder chown verwenden. In allen Verzeichnissen, in welche temporäre Dateien und Upload-Files abgelegt werden, entziehe man dem Webserver die Ausführungsrechte. Das kann man z.B. in der .htaccess-Datei mittels RemoveHandler, RemoveType oder der php_flag erledigen. Diese Methode tönt ein bisschen restriktiv und verhindert automatische Updates, dafür ist sie ein simpler und logischer Weg, eine Website mit Content-Management-Systemen wie Joomla, Drupal, Typo3 oder WordPress effektiv angreifsicher zu härten. Für weitere Auskünfte oder auch in dem Zusammenhang gesammeltes Material stehe ich gerne zur Verfügung.
Und jetzt wünsche ich Ihnen hackersicheres Surfen und freie Rede für alle.