Home » Webdesign » Website wurde gehackt
- Anzeige -
Software Asset Management beim Fachmann

Meine Webseite wurde gehackt, was nun?

Schadsoftware auf der eigenen Website

Leider musste ich auch schon erleben, dass Websites gehackt wurden. Um dem vernünftig zu begegnen, gilt es einiges zu beachten. In diesem Artikel fasse ich mal das wichtigste zusammen. Manches ist recht rudimentär angeschnitten, es sollte aber hoffentlich in die richtige Richtung für weitere Recherchen weissen. Besten Dank an Manuel von SLYNET, bei denen unter anderem auch Websites gehostet werden können, der mir einige entscheidende Hinweise gab.

Die gängigsten Infektionswege von Webapplikationen

Naheliegend ist hier zwar eine Infektion via geknacktem FTP-Account, wesentlich häufiger sind aber sog. Injection Flaws. Computerwoche hat hierzu einen interessanten Artikel online. Er ist zwar schon etwas älter, dürfte aber nach wie vor Gültigkeit besitzen.

Cross-Site-Scripting

Hier wird einer Web-Anwendung falscher Code übergeben. Ohne entsprechende Absicherung wird dieser dann ausgeführt. Beispielsweise könnte man einem Suchformular Javascript-Code übergeben.

Weitere Infos hierzu finden Sie unter dem Artikel Cross-Site Scripting auf Webmasterpro.

Auf Youtube findet sich ein Vielzahl an Tutorials zu dem Thema. Die Zeiten, in denen kleine Seiten von Hack-Angriffen verschont bleiben, sind also entgültig vorbei.

Injection Flaws

Injecton Flaws sind ebenfalls ein weit verbreitetes Problem. Sie entstehen immer dann, wenn z.B. Formulare übermittelten Programmcode ungeprüft ausgeben. Bei SQL-Injections wird z.B. SQL-Code übergeben, um an Datenbankinhalte zu kommen, die ein 'normaler User' nicht sehen sollte. Bei Webscript Injection versucht ein Angreifer dem Webserver Schadcode (z.B. PHP) zur Ausführung unterzujubeln.

Man-in-the-Middle-Attacke

Hier versucht der Angreifer die Kommunikation zweier Partner abzuhören oder gg. zu manipulieren.

Einen Hack feststellen

Renommierte Webprovider scannen ihre Server regelmässig. Insofern sollte man von seinem Provider hoffentlich rechtzeitig gewarnt werden. Allerdings ist es auch schon vorgekommen, dass der Scanner eines Providers nicht den ganzen Schadcode feststellen konnte. Insofern sollte man sich nicht blindlings auf eine vom Provider übergebene Dateiliste verlassen.

Andere Anzeichen können sein.

Hat man seine Seite bei den Google Webmastertools aufgenommen, so erhält man unter Umständen auch von dort eine entsprechende Warnmeldung. Nach meiner bisherigen Erfahrung kommt diese aber eher spät.

Was tun?

Wurde die eigene Website gehackt, dann heisst es zum einen einen kühlen Kopf bewahren, aber auch recht zügig handeln. Fangen sich User über die eigene Website Schadcode ein, kann dies sonst zu einem massiven Trafficabfall führen.

Zugriff auf betroffene Dateien sperren

Falls vom Provider nicht bereits erfolgt, sollte man den Zugriff auf die befallenen Dateien via Änderung der Berechtigungen entsprechend verhindern.

Passwörter ändern

Passwörter sollten alle geändert werden. Das betrifft insbesondere:

Falls es der Provider anbietet, sollte auf SFTP umgestellt werden. So kann der FTP-Verkehr nicht mehr abgehört werden.

Applikationen aktualisieren

Sind alle Applikationen auf der Website aktuell? Dies betrifft insbesondere das CMS.

Tante Google fragen

Gibt es andere Betroffene? Dank Google habe ich in einem Fall z.B. Hinweise gefunden, dass auch in der aktuellsten Version eines CMS ein Plugin Sicherheitsrisiken beinhaltet.

Clients prüfen

Auch über einen Ihrer Clients könnte die Website geknackt worden sein. Überprüfung der verwendeten Clients mit FTP- bzw. CMS-Zugriff auf Viren, Trojaner

Analyse der Logfiles

Anhand der vom Provider übergebenen Daten und der Logfiles, sollte man versuchen näheres über den Infektionsweg festzustellen. Leider sind die Logfiles bei jedem Provider anders aufgebaut. I. d. R. sind Sie aber via FTP downloadbar. Beispiele:

xferlog_regular.processed 

enthält das Logfile von archiviertem FTP-Verkehr

error.log 

enthält Log der Zugriffsfehler.

access_log.stat

enthält Log der Zugriffe auf den Webspace. Die letztere ist eigentlich mit die interessanteste, da hier recht gut auf seltsame Zugriffe geprüft werden kann. Auffällig sind z.B. Post von anderen IPs als der eigenen, aber auch HEAD. Mit der Post-Methode wird der Webserver angewiesen Daten zur Speicherung entgegenzunehmen. Aber auch andere Zugriffe sollte man kritisch prüfen, wenn z.B. auf eine Pluginverzeichnis sehr häufig zugegriffen wurde. Als Einstiger hat man es hier leider nicht gerade leicht. Seltsame Einträge können einfach auch nur Log-SPAM sein. Kommt ein Zugriff sehr häufig vor, wird er in den Logs, die man per Web aufrufen kann, mit einem Link aufgeführt. So kommt man also gg. zu einem Backlink, der die eigene Seite in den Suchdiensten weiter nach oben bringt.

Beispiele

nnn.nnn.nnn.nnn - - [03/Sep/2014:01:22:08 +0200] "POST /golf/Vuissens/Fotogallerie/zoom/Vuissens/a6db048d41.php 
HTTP/1.1" 200 435 "-" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; 
Trident/5.0)"
nnn.nnn.nnn.nnn - - [10/Nov/2014:03:07:56 +0100] "HEAD /admin/fckeditor/editor/filemanager/connectors/asp/upload.asp 
HTTP/1.1" 401 346 "-" "-"

Geziehlt suchen sollte man nach POST-Aufrufen. Alle Zeilen mit einem 200 nach dem Dateinamen wurden extern ohne Fehler aufgerufen. Also sind diese Skripte attackierbar oder infiziert.

Vorkehrungen für die Zukunft

Sofortmassnahmen

Abweichung von Standards

Sehen Sie zu, dass Sie keine Passwörter auf Defaults setzen. Wo möglich sollten sie nicht den Standard-Admin-User verwenden, sondern einen eigenen User (z.B. MySecUser - nein den verwende ich selbst nirgends) verwenden.

Internetpräsenz auf veraltete Systeme prüfen

Aktualisieren Sie alles, was sie aktualisieren können. In der Regel ist das CMS hier der erste Ansatzpunkt. Prüfen Sie, ob es eine neue Version gibt und installieren Sie diese. Überprüfen Sie das regelmässig, auch ohne Befall der Webpräsenz!

.htaccess Magic

Über die .htacces-Datei kann man einige tolle Dinge anstellen, die zur weiteren Absicherung dienen.

Mit...

  order allow,deny 
  deny from nnn.nnn.nnn.nnn 
  allow from all

...wird die IP-Adresse nnn.nnn.nnn.nnn vom Zugriff ausgeschlossen.

Mit

order allow,deny
deny from 192.168
allow from all 

...wird ein ganze IP-Bereich gesperrt.

Mit

<FilesMatch "\.php$">
Order Allow,Deny
Deny from all
</FilesMatch>
<FilesMatch "index[0-9]?\.php$">
Order Allow,Deny
Allow from all
</FilesMatch>
<FilesMatch "veriword[0-9]?\.php$">
Order Allow,Deny
Allow from all
</FilesMatch>

...wird der Zugriff auf alle php-Dateien ausser index.php und veriword.php gesperrt.

Für das CMS MODX braucht es noch die Freischaltung der login.processor.php, daher noch folgendes ergänzen:

<FilesMatch "login\.processor[0-9]?\.php$">
Order Allow,Deny
Allow from all
</FilesMatch>

Berechtigungen

In der Regel liegen Webpräsenzen auf einem Unix-artigen Betriebssystem, wie z.B: Linux, Solars, FreeBSD. Die Berechtigungen werden hier über 3 oktale Zahlen definiert. In Filezilla sieht man die Berechtigung, wenn man mit der rechten Taste auf eine Datei klickt und "Dateiberechtigungen..." wählt.

Bei den meisten Hostern läuft das Web unter dem FTP-Account. Auf solchen Systemen kann man für Dateien 644 und Verzeichnisse 755 als Berechtigungen setzen. Auf keinen Falls sollte 777 als Berechtigungen gesetzt werden, da sonst über ein gehackten Account auf dem gleichen Server (der gar nichts mit Ihrer Webpräsenz zu tun haben muss), Dateien verändert werden können.

Und sonst?

Bei einigen Providern kann man einstellen, dass per http von PHP-Skripts aus keine Dateien hochgeladen werden dürfen, was die Sicherheit ebenfalls vergrössert.

Quellen, weitere Infos:



War der Artikel hilfreich? Bitte liken und sharen. Danke!

it-zeugs.de ist auch auf Facebook...

Schreibe einen Kommentar - aber kein SPAM - der wird zuverlässig gefiltert!

  • Erforderliche Felder sind markiert mit *.

If you have trouble reading the code, click on the code itself to generate a new random code.