Schutz vor Website-DefacementAlarmanlage für die Website

Image-Schaden

Schutz vor Website-Defacement

Jeden Tag meldet das Defacement-Archiv Zone-h.org Hunderte von gehackten Webservern – und das sind nur die, die dort gemeldet werden. Oft wird die Startseite durch eine Botschaft des Crackers ersetzt – Defacement nennt man das. Manche Angreifer setzen ihre Marke aber auch im Geheimen. Sie fügen dem Server an einer unauffälligen Stelle eine Datei mit ihrer Signatur hinzu. Das reicht, um sich in den einschlägigen Foren mit dem Defacement zu brüsten. Zudem bleiben solche versteckten Marken oft über lange Zeit unentdeckt.

Ein Defacement schädigt immer das Image. Werden über eine Webpräsenz Geschäfte angebahnt oder abgewickelt, drohen darüber hinaus handfeste finanzielle Schäden. Noch schlimmer wird es, wenn der Speicherplatz des Webservers für strafbare Zwecke genutzt wird: zum Beispiel zum Tausch von Kinderpornos oder Raubkopien. Der Inhaber des Webspaces kann so ins Visier der Staatsanwaltschaft geraten.

Schutz vom Schreitisch aus

Schutz vor Website-Defacement

Um sich gegen Defacement zu schützen, sollten Sie daher die Integrität der eigenen Webseiten regelmäßig überprüfen. Zum Glück brauchen Sie nicht persönlich nach dem Rechten zu sehen, sondern können diese Zeit raubende Aufgabe bequem an Skripts delegieren. Internet Professionell stellt im Folgenden ein geeignetes Skript vor. Damit das Kind einen Namen hat, soll das Skript Sidep heißen: Simple Defacement Protection.

Skripts, die vom eigenen Schreibtisch aus den Webserver überprüfen, haben den Vorteil, dass sie eine zusätzliche Verteidigungslinie darstellen. Sollte ein Cracker sich Root-Rechte auf einem Webserver verschafft haben, kann er Systeme, die dort installiert sind, manipulieren. Das gilt dann auch für ein IDS-System wie Tripwire. Auf den Defacement-Schutz im Büro des Webmasters hat ein Angreifer aber nur Zugriff, wenn er dessen PC ebenfalls knackt.

Check: Dateigröße und Datum

Schutz vor Website-Defacement

Der Defacement-Schutz prüft, welche Dateien vorhanden sind, welche Größe sie haben und wann sie zuletzt geändert wurden. Damit dürften sich fast alle Defacements zuverlässig erkennen lassen. Bei den meisten Defacements wird eine Datei hinzugefügt oder in ihrer Größe geändert. Diese Angriffe lassen sich leicht erkennen. Etwas kritischer sind Änderungen, bei denen die Dateigröße gleich bleibt. Es reicht dazu schon, in einer Preisliste auf den Webseiten ein paar Zahlen zu vertauschen – Umsatzeinbußen durch irritierte Kunden sind die Folge. Oder der Angreifer setzt als Defacement immer eine Datei ein, die kleiner als das Original ist und füllt den Rest mit beliebigen Bytes auf – das bleibt unerkannt, wenn nur Name und Größe der Datei geprüft werden.

Um solche Angriffe zu erkennen, wird für jede Datei das Datum der letzten Änderung überprüft. Doch das ist nicht hundertprozentig sicher. Denn das Datum einer Datei könnte der Angreifer nach seiner Manipulation wieder auf den ursprünglichen Wert zurücksetzen. Das geht mit dem FTP-Befehl MDTM. Der sollte aber bei einem gut konfigurierten FTP-Server deaktiviert sein. Um zu überprüfen, ob diese Sicherheitslücke in der Praxis geschlossen ist, probiert das Skript sie aus. Damit dürfte die Defacement-Alarmanlage wasserdicht sein.

Und so geht’s

Schutz vor Website-Defacement

Um Manipulationen an den Webseiten erkennen zu können, muss zunächst ein gültiger Soll-Zustand festgehalten werden. Voraussetzung dafür ist ein FTP-Zugang zu den Webseiten, der aber üblicherweise vorhanden ist. Über HTTP lassen sich nämlich nur komplette HTML-Dateien abrufen, aber nicht deren Eigenschaften. Zudem entstünde unnötig viel Traffic, wenn für jede Inspektion alle HTML-Seiten heruntergeladen würden. Ein weiterer Vorteil: Per FTP können Skripts im Quelltext überprüft werden, während der Client per HTTP von PHP- oder CGI-Skripts immer nur den Output zu sehen bekommt.

Statt dessen werden Dateilisten per FTP abgerufen und lokal gespeichert. Um den Sollzustand zu definieren, könnte man das auch manuell machen. Dazu müsste man sich von der Kommandozeile aus auf dem FTP-Server anmelden und die komplette Dateiliste mit folgendem Befehl in eine lokale Datei speichern:


ftp> ls -R dateiliste.soll
output to local-file: dateiliste.soll [anpqy?]? y


Dummerweise kommt es vor, dass der ls-Befehl im FTP-Client unterschiedliche Formate ausgibt, je nachdem, ob er von der Kommandozeile oder aus einem Skript heraus aufgerufen wird. Statt sich lange mit diesem seltsamen Problem herumzuschlagen, kann man es einfach umgehen, indem man auch den Soll-Zustand aus einem kleinen Skript heraus abruft.

Mehrere Server prüfen

Schutz vor Website-Defacement

Vorher sollte das Skript aber die Zugangsdaten aus einer Konfigurationsdatei auslesen, damit Sie es für mehrere Websites verwenden können. In die Datei sidep.config schreiben Sie zeilenweise einen Namen für die jeweilige Website, die Server-Adresse, den Benutzer, das Passwort und die Mail-Adresse für den Alarm. Das sieht dann zum Beispiel so aus:


IT-Journalist.de
achimwagenknecht.de
achimw
B6%9Jkp,_
aw@it-journalist.de


Der nächste Block folgt ohne Leerzeile direkt darunter. Das Skript liest die Zugangsdaten so aus:


#!/bin/sh
cat sidep.config |
while read name
do
read server
read user
read pass
read mailadresse
#Hier kommt der weitere Programmcode hin
done


Danach lädt das Skript die komplette Dateiliste der Website herunter:


ftp ftp://$user:$pass@$server << "EOF"
ls -R $server.soll
y
quit
EOF
exit 0


Speichern Sie diesen Text unter dem Namen sidep-soll.sh und machen Sie die Datei ausführbar. Wenn Sie das Skript starten, haben Sie in kurzer Zeit ein komplettes Dateiverzeichnis Ihrer Website auf der lokalen Festplatte.

Prüfung der Dateien

Schutz vor Website-Defacement

Der Prüflauf funktioniert praktisch genauso, nur dass die Dateiliste mit der Endung ist gespeichert wird, so dass eine soll-Datei mit einer ist-Datei verglichen werden kann. Den Vergleich besorgt der Linux-Befehl diff.

diff -s $server.soll $server.ist

Die Option -s sorgt dafür, dass auch dann eine Meldung ausgegeben wird, wenn die Dateien übereinstimmen:

Dateien IT-Journalist.de.soll und IT-Journalist.de.ist sind identisch.

Sobald ein Angreifer die Webseiten ändert, bemerkt das Skript das und gibt die Unterschiede aus. Um den Webmaster über jeden Prüflauf zu unterrichten, können Sie ihm mit folgendem Befehl die Ausgabe des Skripts per E-Mail schicken:


achim@rechts:~/sidep> ./sidep.sh | mail -s "Hackertest auf servername.de" webmaster@servername.de


Damit das regelmäßig passiert, können Sie das Skript in die Datei /etc/crontab eintragen oder zum Beispiel unter /etc/cron.daily speichern. Letzteres bewirkt unter Suse Linux 9.3, dass der Webmaster täglich per E-Mail erfährt, ob seine Seiten gehackt wurden oder nicht. Die soll– und ist-Dateien dürfen aber nicht in diesem Ordner gespeichert werden, weil Linux sonst auch versucht, sie als Skripts auszuführen. Denken Sie auch daran, die Pfade zu den Dateien anzupassen.

Datum checken

Schutz vor Website-Defacement

Wenn Sie diesem Workshop bis hier gefolgt sind, haben Sie schon eine gute Alarmanlage für Ihre Website. Jetzt fehlt noch die Überprüfung, ob sich das Dateidatum per FTP ändern lässt. Dazu fügen Sie einfach den Befehl unmittelbar vor dem Abruf der Dateiliste in das Skript ein:

MDTM 20041216220424 index.htm

Auf einem gut konfigurierten Server sollte diese Zeile eine Fehlermeldung ergeben:

?Invalid command.

Falls irgendwann durch einen Angriff oder Administrationsfehler die Änderung des Dateidatums möglich wird, stellt das Skript das fest und meldet, dass die Datei index.htm geändert wurde.

Das Skript sidep.sh ist jetzt soweit, dass es Änderungen an den Webseiten zuverlässig erkennt. Jedes Mal, wenn jemand die Website mit Erlaubnis geändert hat, muss nun also erneut der Soll-Zustand mit dem Skript sidep-soll.sh erfasst werden. Trotzdem gibt es noch ein Problem, nämlich Fehlalarme.

Dynamische Seiten

Schutz vor Website-Defacement

Selbst Internet-Seiten, die nur aus statischem HTML bestehen, enthalten meist Dateien, die sich ändern: die Log-Dateien. Und Webseiten, die dynamische Elemente enthalten, erzeugen natürlich massenhaft Fehlalarme mit der hier vorgestellten Website-Alarmanlage. Dateien, die sich ändern dürfen, müssen also von der Überprüfung ausgenommen werden.

Eine sinnvolle Möglichkeit dazu ist, veränderliche Dateien in bestimmten Ordnern zu sammeln und diese Ordner von der Überprüfung auszunehmen. Leider funktioniert das zunächst nicht, denn in der Dateiliste steht nicht in jeder Zeile der Pfad. Statt dessen taucht die Pfadangabe immer nur als Zwischenüberschrift auf:


Augustin:
drwx---r-x 2 1310-250
ftpusers 4096 Dec 19 2003 .
drwx---r-t 22 1310-250
ftpusers 4096 Dec 17 20:56 ..
-rw-r--r-- 1 1310-250
ftpusers 197235 Aug 24 2004 Augustin.pdf
-rw----r-- 1 1310-250
ftpusers 5415 Dec 2 2002 a1einleitung.htm


Um die Pfadangaben für die Website-Überwachung sinnvoll nutzen zu können, müssen sie in jede Zeile eingefügt werden.

Pfade einbauen

Schutz vor Website-Defacement

Die Datei in dieses Format umzuwandeln, erweist sich als schwierigster Akt bei der Programmierung. Hier der Quellcode:


# Variable leeren
ordner=""
# Zieldatei löschen
rm $server.ist
cat $server.ist.temp |
while read zeile
do
# Doppelpunkt am Ende erkennen, Variable Ordner neu belegen
# Wenn Doppelpunkt am Ende der Zeile
if test "$zeile" != "${zeile%:}"
then
#Zeile in der Variablen Ordner
ablegen
ordner="$zeile"
else
#Ansonsten Variable Ordner der Zeile voranstellen
echo $ordner$zeile >> $server.ist
fi
done


Diese Routine muss in beide Versionen des Skripts eingebaut werden, damit sich Soll- und Ist-Zustand vergleichen lassen. Jetzt ist der Pfad in jeder Zeile:


Augustin:drwx---r-x 2 1310-250
ftpusers 4096 Dec 19 2003 .
Augustin:drwx---r-t 22 1310-250
ftpusers 4096 Dec 17 20:56 ..
Augustin:-rw-r--r-- 1 1310-250
ftpusers 197235 Aug 24 2004 Augustin.pdf
Augustin:-rw----r-- 1 1310-250
ftpusers 5415 Dec 2 2002 a1einleitung.htm


Ordner ausschließen

Schutz vor Website-Defacement

Damit kann der logs-Ordner mit folgender Formulierung ignoriert werden:

diff -I "logs:" -s $server.soll $server.ist

Sollen mehrere Ordner übersprungen werden, kann bei der I-Option des diff-Befehls auch ein regulärer Ausdruck verwendet werden.

Mail nur bei Alarm

Schutz vor Website-Defacement

Aktuell bekommt der Webmaster bei jedem Prüflauf eine E-Mail. Paranoiker werden das begrüßen. Entspanntere Naturen werden es bevorzugen, nur bei Alarm benachrichtigt zu werden. Um das zu erreichen, wird der diff-Befehl in eine if-Anweisung eingebettet. Sind Soll- und Ist-Dateilisten gleich, geschieht nichts. Nur wenn Unterschiede gefunden werden, mailt das Skript diese an den Admin.


# Unterschiede ausgeben
rm $server.unterschiede
if diff -I "logs:" $server.ist $server.soll >> $server.unterschiede
then
#Wenn beide Dateien gleich sind, soll nichts weiter passieren
echo "Homepage OK."
else
# Unterschiede gefunden, Admin alarmieren
echo "Unterschiede gefunden."
cat $server.unterschiede | mail -s "Hackeralarm auf" $server $mailadresse
# Gegenmaßnahmen ergreifen
fi


Die Unterschiede werden – sofern vorhanden – zunächst in einer Datei gespeichert. Diese wird dann per E-Mail an den Webmaster geschickt. Damit ist das Alarmanlagen-Skript fertig.

Automatische Reaktion

Schutz vor Website-Defacement

Wer will, kann in den else-Block noch automatische Gegenmaßnahmen einfügen. So können zusätzliche und veränderte Dateien zur Beweissicherung automatisch heruntergeladen werden. Zusätzliche Dateien sollten danach gelöscht werden, geänderte und fehlende durch das Original ersetzt werden. Außerdem bietet es sich an, das Prüfintervall in etc/crontab zu verkürzen, denn die Erfahrung zeigt, dass die Skript-Kiddies nach einem ersten Defacement gern die gleiche Adresse wiederholt aufs Korn nehmen.

Automatische Gegenmaßnahmen sind aber mit Vorsicht zu genießen. Sie werden nur selten gebraucht, müssen sehr sorgfältig programmiert werden und eröffnen neue Fehlerquellen. Außerdem werden die meisten Webmaster wahrscheinlich lieber selbst nach dem Rechten sehen wollen, wenn ein Defacement sie erwischt hat.

Andere Angriffe

Schutz vor Website-Defacement

Hundertprozentige Sicherheit gibt es bekanntlich nicht. Was kann noch passieren, wenn Sidep über Ihre Website wacht? Zunächst einmal verhindert Sidep gar nichts. Es schlägt nur nach dem Defacement Alarm. Zwischen den Prüfläufen bleibt das Defacement bestehen. Das Prüfintervall entscheidet darüber, wie lange man im Ernstfall mit heruntergelassenen Hosen dasteht.

Eine weitere Gefahr sind Defacements, die als Soll-Zustand festgehalten werden. Das kann entweder beim ersten Herunterladen der Dateiliste passieren oder wenn ein Angreifer kurz nach einem Update der Homepage die Seiten verändert. Führt man danach einen Soll-Lauf durch, werden die Fehler mit erfasst.

Noch schlimmer wäre ein gewiefter Angreifer, der mit Root-Zugriff auf dem Server Webspace und FTP-Zugang entkoppelt. Auf dem FTP-Account bleibt die korrekte Website gespeichert, während der Angreifer davon unabhängig auf dem Webspace die Seiten verändert. Da man auf diese Ebene beim Shared Hosting nicht zugreifen kann, muss ein solcher Angriff beim Webspace-Provider erkannt und abgewehrt werden.

Und schließlich kann jemand in den Ordnern für veränderliche Dateien Defacements ablegen. Diese müssen geschützt werden. Es bietet sich an, sie anderen Systembenutzern zuzuordnen und den Zugang mit .htaccess zu beschränken. Alle diese Angriffsszenarien sind unwahrscheinlich. Sie können davon ausgehen, dass Sidep die meisten Defacements zuverlässig erkennt.

Alle Listings zum Workshop finden Sie unter listings.internet-pro.de.

Das vorgestellte Skript veröffentlicht Internet Professionell als Open Source. Die Projekt-Webseite finden Sie unter www.it-journalist.de/iproalarm.