Meine Website wurde gehackt – was ist zu tun?

Hier finden Sie einige Tipps, wie Sie Ihre Website sicher halten. Dieser Text entstand vor allem als Reaktion auf gehackte Websites:

1. Prüfen Sie zunächst auf den Websites aller Hersteller bzw. Entwickler, ob für ALLE in Ihrem Konto verwendeten Web-Skripte und -Anwendungen Updates vorliegen, einschließlich aller Mods, die Sie in einer Webanwendung einsetzen. Wenn Sie eine Open-Source-Webanwendung verwenden, ist diese möglicherweise der Hauptverdächtige. Sie müssen jedoch alle Anwendungen prüfen und auf dem aktuellen Stand halten. Durchsuchen Sie außerdem die Datenbank auf www.secunia.com nach öffentlich bekannten Exploits.

2. Sobald Sie sichergestellt haben, dass 100 % der installierten Skripte in der neuesten stabilen Version vorliegen, müssen Sie alle Dateien Ihres Kontos durchgehen und sicherstellen, dass keine davon vor Ihrer Prüfung von Hackern hochgeladen oder von Ihnen nach der Installation einer älteren Anwendung zurückgelassen wurde. Verdächtige Dateien können sich in Ordnern befinden, mit denen Sie nie gerechnet hätten, auch mehrere Ebenen tiefer. Sie können per FTP oder mit dem cPanel-Dateimanager alle Dateien unter public_html durchgehen und mit Ihrer lokalen Kopie vergleichen. [Sie sollten für diesen Vergleich sowie als Backup stets eine lokale Kopie vorhalten.]

3. Achten Sie darauf, dass alle Passwörter aus einer Mischung von Buchstaben und Ziffern bestehen und kein Wort aus dem Wörterbuch sind. Nur weil Sie sich ein schwieriges Wort aus dem Wörterbuch ausgedacht haben, sind Sie nicht sicher. Verwenden Sie bitte außerdem Groß- und Kleinbuchstaben sowie mindestens 8 Zeichen.

4. Der MySQL-Datenbankzugriff aller Webanwendungen sollte über separate Datenbankbenutzer erfolgen. Verwenden Sie dafür niemals Benutzername und Passwort Ihres Hauptkontos. Ihre Hauptzugangsdaten sollten in keiner Datei Ihres Kontos gespeichert sein.

5. Aktivieren Sie in Ihrem Kontrollpanel im Raw Log Manager die Archivierungsoption für Ihre Web-Logs. So können Sie später nachvollziehen, wie ein Angreifer eines der Skripte ausgenutzt hat. Andernfalls werden alle Rohprotokolle nach der Erstellung der Statistiken gelöscht. Wenn Sie bereits gehackt wurden, ist es dafür jetzt zu spät, Sie können die Logs aber für künftige Angriffe archivieren.

6. Wenn Sie eine Webanwendung mit einem Mod angepasst haben, stellen Sie sicher, dass auch dieser in der neuesten stabilen Version vorliegt. Viele beliebte Webanwendungen sind stabil, aber eines der Zusatzmodule kann angreifbar sein und wird möglicherweise nicht mehr gepflegt.

7. Wenn Sie selbst Code geschrieben haben, stellen Sie sicher, dass alle Eingabevariablen bereinigt werden (sogenanntes Sanitizing, d. h. Prüfung auf gültige Daten, bevor sie verwendet werden). Andernfalls kann eine einzige fehlerhafte Codezeile Zugriff auf Ihr gesamtes Konto ermöglichen. Der übliche Fehler besteht darin, eine Datei auf Grundlage von Benutzereingaben einzubinden. Achten Sie also nochmals darauf, dass sämtliche Eingaben an ein Skript auf gültige Daten geprüft werden. Alle Exploits beruhen auf Eingabedaten. Wenn Ihre Website keinerlei Eingaben entgegennimmt, sind Sie zu 100% vor Web-Exploits sicher, also wenn Sie eine zu 100% statische HTML-Website betreiben, in der sich nirgendwo in Ihrem Konto ein Skript befindet.

8. Bei PHP sind Anwendungen, die aktiviertes register_globals voraussetzen, anfälliger für Angriffe. Vermeiden Sie solche Anwendungen.

9. Wenn Sie ein Mailskript verwenden, stellen Sie sicher, dass es vor Header-Injection geschützt ist. Achten Sie vor allem darauf, dass die E-Mail-Adresse, der Betreff und andere vom Benutzer übermittelte Daten keine Zeilenumbrüche enthalten. Hilfestellung zur Programmierung finden Sie in unseren Foren.

10. Kostenlose Open-Source-Webanwendungen sind eine gute Sache, Sie müssen sie jedoch durch regelmäßige Updates pflegen, sonst können Sie alle Ihre Daten und Ihre Website verlieren, sobald ein neuer Exploit bekannt wird. Als Inhaber eines Hosting-Kontos sind Sie dafür verantwortlich, dass in Ihrem Konto nur stabile Anwendungen installiert sind.

11. Wenn Ihre Website jahrelang problemlos lief, bedeutet das nicht, dass es dort keine Sicherheitslücken gab. Es bedeutet vielmehr, dass der Exploit unbekannt war oder dass Sie Glück hatten und ihn bislang niemand ausgenutzt hat.

12. Für zusätzliche Sicherheit ändern Sie die Dateiberechtigungen Ihrer Konfigurationsdateien (die z. B. Datenbank-Zugangsdaten enthalten) auf 660. Dies ist per FTP oder über den Dateimanager möglich. Diese Funktion steht auf Shared-Hosting-Servern zur Verfügung oder wenn Ihr VPS bzw. dedizierter Server über cPanel mit phpsuexec arbeitet.

13. Für zusätzliche Sicherheit sollten Sie, sofern möglich, den Zugriff auf bestimmte Administrationsbereiche Ihrer Website einschränken, indem Sie nur autorisierten IP-Adressen den Zugang gewähren und ihn für alle anderen sperren, oder diese Bereiche per Passwort schützen.

14. Falls in Ihrem Konto eine Datei-Upload-Funktion vorhanden ist, stellen Sie sicher, dass nur autorisierte Mitglieder sie nutzen können.

Außerdem sollten hochgeladene Dateien nicht direkt über eine Web-URL erreichbar sein (d. h. sie sollten außerhalb von public_html gespeichert werden), es sei denn,

a) sie werden ausschließlich von einem Website-Administrator (verantwortliche Person) hochgeladen
b) sie wurden geprüft und als nicht ausnutzbar validiert

15. Falls es für Ihre Website-Mitglieder eine URL-Weiterleitung oder eine Webmail-Funktion gibt, stellen Sie sicher, dass diese nicht ohne ordnungsgemäße Autorisierung für alle freigegeben wird, da sie sonst für Spam missbraucht werden könnte.

16. Wenn Sie nur etwas testen oder ausprobieren, das ausschließlich Sie benötigen und das Sie voraussichtlich nicht aktiv auf dem neuesten Stand halten, schützen Sie es sofort mit einem Passwort.

17. Da Shared-, sdx- und Reseller-Server mit suPHP ausgeliefert werden, benötigen Sie keine Dateien oder Ordner mit Schreibrechten für alle Benutzer. Die normalen Ordnerberechtigungen sollten 755 nicht überschreiten. PHP-/HTML-Dateien können 644 haben (oder per SSH niedrigere Werte). CGI-/Perl-Skripte sollten 755 haben.

18. Jeder, der Code für Webanwendungen schreibt, sollte mit dem Thema Sicherheit vertraut sein. Ich habe in meiner örtlichen Bibliothek dieses Buch speziell zu PHP gefunden: http://www.oreilly.com/catalog/phpsec/ Ich empfehle es jedem. Es behandelt alle Aspekte der heute in Webanwendungen vorkommenden Schwachstellen. Aus dem Buch stammt auch diese Website: http://phpsec.org