Foto: olly/Fotolia

Im Jahr 2011 war das Thema Sicherheit im Internet medial präsenter denn je. Nicht nur in den einschlägigen Kreisen, sondern auch in den klassischen Massenmedien Radio, Fernsehen und Zeitung wurde viel darüber berichtet. Hacker-Gruppierungen wie „LulzSec“ oder „Anonymous“ haben anhand prominenter Beispiele gezeigt, dass sogar die „großen“ Firmen offensichtlich nicht genug in die Absicherung ihrer eigenen Systeme investieren. Ob nun die GEMA, Sony oder gar die CIA – Hacker sind in ihre Systeme eingedrungen und haben sich entweder geheime Informationen angeeignet oder aber die Websites lahmgelegt. Das zeigt auch, dass auf diesem Gebiet aktuell sowohl Wissensmangel als auch Handlungsbedarf besteht.

Dem Kompromittieren (Hacken) einer Website liegen unterschiedliche Motivationen zugrunde. Es können Freizeit-Spaß, Ruhm und (Hacker-)Ehre oder aber schlicht finanzielle Interessen sein. Denn dem finanziell motivierten Hacker kommt die Kaninchenzüchter-Website gerade recht, wenn er dort ohne viel Aufwand ein paar Links zu dubiosen pharmazeutischen Händlern unterbringen kann. Wer eine Internetseite betreibt, sollte deshalb grundsätzlich damit rechnen, Angriffsversuchen ausgesetzt zu sein. Dabei ist es egal, ob für die Website WordPress, Drupal, TYPO3 oder einfache HTML-Seiten im Einsatz sind. Im Folgenden wird generell auf die Problematik eingegangen, wobei TYPO3 an einigen Stellen als Beispiel dient.

Allgemein gesprochen gilt etwas als sicher, wenn die Integrität, Erreichbarkeit und Vertraulichkeit gewährleistet ist. Eine Website ist unsicher, wenn unerwünschte Inhalte untergebracht werden können, sie gar keine Inhalte mehr liefert oder der Zugriff auf vertrauliche Informationen möglich ist. Eine Internetseite sicher zu betreiben bedeutet also, eben dies zu verhindern. Was einfach klingt, kann aber durchaus eine komplexe und aufwändige Angelegenheit sein. Grundsätzlich gilt: Je größer der Schaden sein kann, desto mehr Aufwand muss man in die Absicherung investieren. Die CIA wird hier zwar sicher mehr Budget haben als die Kaninchenzüchter, trotzdem können beide Seiten ausreichend abgesichert werden. Handlungsbedarf besteht aber nicht nur, nachdem eine Website kompromittiert wurde, sondern schon vorher. Und dafür gibt es vier überlebenswichtige Grundregeln.

Es ist unerlässlich, die eingesetzte Software auf dem Server (bspw. TYPO3), aber auch den eigenen PC, der ja zur Administration der Website verwendet wird, aktuell zu halten. Dadurch werden zumindest bekannt gewordene Sicherheitslücken geschlossen. Für Software auf dem PC wird man in den meisten Fällen benachrichtigt, sobald Updates vorhanden sind. Für Benachrichtigungen über Aktualisierungen der eingesetzten Software auf Server-Seite abonniert man am besten die entsprechenden Newsletter, Mailinglisten oder RSS-Feeds. Im Falle von TYPO3 ist das etwa die Mailing-Liste [1]. Ebenfalls eine gute Anlaufstelle ist Heise Security [2], die über alle bekannt gewordenen Sicherheitsprobleme berichten.

Die wichtigsten Kriterien für Sicherheit.

Die Nützlichkeit und Notwendigkeit, ein regelmäßiges Backup anzufertigen, liegt auf der Hand. Allein um das Sicherheits-Kriterium der Erreichbarkeit gewährleisten zu können, wenn es zu Datenverlust durch Fehlbedienung oder Fehlfunktion kommt. Ebenso unabdingbar ist die Verfügbarkeit eines Backups, wenn eine Website nach einem erfolgreichen Agriff kompromittiert und verändert wurde.

Sämtliche Zugriffe auf die Website und eventuell auftretende Fehler zu protokollieren, sollte selbstverständlich sein. Zugriffs-Protokolle wie etwa das Apache-Access-Log sind nicht nur nützlich zur Anfertigung von Besucher-Statistiken, sondern auch unerlässlich für die Analyse nach einem Angriff. Darüber hinaus sollte in den PHP-Einstellungen das Schreiben von Fehlern in eine Datei aktiviert werden.

log_errors = On
error_log = /absoluter/pfad/zur/datei/php-error.log

Zu guter Letzt ist es ratsam, in TYPO3 das Protokollieren von Fehlern einzuschalten. Bestenfalls lässt man TYPO3-Fehler direkt in das PHP-Fehler-Protokoll schreiben, um auftretende Fehler einerseits leichter eingrenzen und sie andererseits auch frühzeitig erkennen und beheben zu können.

$TYPO3_CONF_VARS['SYS']['systemLog'] = 'error_log';
$TYPO3_CONF_VARS['SYS']['systemLogLevel'] = '2';

Denn die (Fehler-) Protokolle können noch so gut sein – sie nützen nichts, wenn sie nur aktiviert, aber hinterher nie wieder angesehen oder ausgewertet werden. Daher ist es wichtig, diese stetig zu überwachen, um dann entsprechende Aktionen einleiten zu können.

Regelmäßig in die Protokolle zu sehen und nach Ungereimtheiten Ausschau zu halten, ist für kleine private Websites sicher außreichend. Solche Routine-Aufgaben sind aber langweilig und geraten insbesondere in stressigen Situationen schnell in Vergessenheit. Selten ruft jemand regelmäßig die eigene Seite im Browser auf, um manuell zu prüfen, ob sie noch erreichbar und funktionstüchtig ist. Wer eine große Website betreibt, kommt daher um eine ständige und automatisierte Überwachung nicht herum.

Anwendungen wie Nagios [3] oder Icinga [4] sind auf solche Aufgaben spezialisiert. Man kann mit ihnen hunderte Installationen und Server detailliert überwachen, um bei auftretenden Fehlern einen odere mehrere Personenkreise zu benachrichtigen. Die Einrichtung dieser Anwendungen ist verhältnismäßig komplex und setzt einen eigenen Server voraus. Einige Hoster bieten jedoch zumindest eine einfache Überwachung der Erreichbarkeit an, die in der jeweiligen Verwaltungsoberfläche aktiviert werden kann. Des Weiteren können dafür auch (zum Teil kostenlose) Online-Dienste eingesetzt werden, etwa Mon.itor.us [5].

Leider sind selbst die besten Vorbereitungen und das beständigste Monitoring manchmal nicht genug und die eigene Website wird trotzdem angegriffen und kompromittiert. Angriffe auf die Erreichbarkeit eines Internet-Auftritts (Denial of Service, „DoS“) passieren recht häufig. Wenn man die Last des Servers überwacht und bei der Überschreitung eines Schwellen-Werts benachrichtigt wird, kann man hier eingreifen und in den meisten Fällen schnell Abhilfe schaffen. Dazu schaut man im Zugriffs-Protokoll nach, von welchen IP-Adressen übermäßig viele Anfragen kommen und blockiert diese, indem man sie etwa in eine .htaccess-Datei einträgt, welche im Wurzelverzeichnis des Auftritts liegt.

Deny from 222.47.234.123 222.47.234.203

Ist der Server ein eigener Linux-Rechner, ist es noch besser, auf der Kommandozeile die IP-Adresse oder ganze IP-Bereiche mit einer oder mehreren Firewall-Regeln zu sperren.

Mittels Firewall blockieren

# Verbindungen von einer IP-Adresse verbieten
iptables -I INPUT -s 222.47.234.123 -j DROP
# Verbindungen eines IP-Adress-Bereichs verbieten
iptables -I INPUT -m iprange --src-range 222.47.234.123-222.47.234.203 -j DROP

Doch was tun, wenn ein Angreifer es geschafft hat, die Website zu manipulieren? Auch hier gibt es vier wichtige Punkte, die den Angreifer abschütteln und die eigene Seite wieder auf die Beine bringen sollen.

Eine Site-spezifische Google-Suche nach Begriffen wie „Viagra“ gibt Aufschluss darüber, ob ein Website manipuliert wurde.

Das Erkennen eines Angriffs ist manchmal nicht ganz einfach, weil, je nach Intention, die Angreifer häufig Verschleierungsmethoden einsetzen. Ist das Ziel des Angriffs beispielsweise das Unterbringen von Links auf den Zielsystemen zur „Suchmaschinenoptimierung“ von Pharmazie-Seiten, so wird dies häufig nicht auf der standardmäßig im Browser aufgerufenen Seite angezeigt. Stattdessen hinterlässt der Angreifer PHP-Code, der den eingesetzten Browser auswertet und nur bei Erkennen des Google-Crawlers entsprechende Links unterbringt [6].

An dieser Stelle hilft ein automatisches Monitoring ungemein, weil vor einer erfolreichen Kompromittierung immer zahlreiche Fehlversuche stehen, die mit hoher Wahrscheinlichkeit in den Fehler-Protokollen auftauchen. Zudem machen auch Angreifer Fehler. Verhält sich eine bislang funktionierende Web-Anwendung plötzlich anders oder fehlerhaft, ist erhöhte Aufmerksamkeit geboten und es ist zu analysieren, ob es sich um einen „normalen“ Fehler oder einen Angriff handelt.

Ist eine Manipulation erkannt, ist schnelles Handeln Pflicht. An erster Stelle steht das Abschalten der Website. Entweder leitet man auf eine Wartungsseite um, erlaubt den Zugriff nur mit Passwort oder von bestimmten IP-Adressen, oder man verbietet gar den gesamten öffentlichen Zugriff auf den Server.

# Zugriff nur von der IP-Adresse 10.10.10.10
Order deny,allow
Deny from all
Allow from 10.10.10.10

Einen eigenen Server könnte man natürlich komplett ausschalten und die Festplatte zur weiteren Analyse ausbauen. Das ist aufwändig, in vielen Fällen gar nicht möglich und daher nur für besonders heikle Situationen anzuraten. Kümmert sich ein Dienstleister um das Hosting, ist es zudem wichtig, ihn zu informieren, damit auch dieser entsprechende Maßnahmen einleiten kann. Erst danach sollte mit der Analyse der Ursachen begonnen werden.

Ziel der Analyse muss es sein, jenes Einfallstor zu finden, das die Angreifer genutzt haben. Dabei sollte die Möglichkeit in Betracht gezogen werden, dass Passwörter gestohlen wurden, etwa durch Schadsoftware auf PCs, die zur Verwaltung der Website verwendet werden. Es schadet also nicht, diese einer gründlichen Virenprüfung zu unterziehen.

Häufig ist jedoch das Einfallstor eine Sicherheitslücke in einer Anwendung auf dem Server. Um diese zu finden ist ein genauer Blick in die Zugriffs-Protokolle notwendig. Je exakter man den Zeitpunkt der Kompromittierung eingrenzen kann, desto besser, da diese Protokolle meist mehrere zehntausend Zeilen umfassen. Ohne die nötige Erfahrung und das Wissen über genaue Angriffs-Methoden hier die richtigen Stellen zu finden und das Problem genau zu identifizieren, ist trotzdem schwierig. Wer auf diesem Gebiet keine Erfahrungen hat, sollte unbedingt Experten zu Rate ziehen.

Wenn die Vermutung nahe liegt, dass für den Angriff eine Schwachstelle in TYPO3 oder einer öffentlichen TYPO3-Extension ausgenutzt wurde, hilft das TYPO3-Security-Team weiter. In eine E-Mail an das Team gehören Auszüge aus dem Protokoll, eine möglichst genaue Problembeschreibung und der vermutete Zeitpunkt des Hacks.

Das Apache-Access-Log gibt Aufschluss über augenutzte SQL-Injection-Lücken.

Ist das Einfallstor erst einmal indentifiziert, muss dieses natürlich geschlossen werden. Noch wichtiger ist es, allen eingeschleusten Schad-Code zu finden und zu entfernen. Auch dies ist leider alles andere als trivial. Wenn ein Backup des Internet-Auftritts vom Zeitpunk vor dem Hack vorhanden ist, sollte dieses unbedingt eingespielt werden. Ist das aus irgendwelchen Gründen nicht möglich, sollten in jedem Fall Experten beauftragt werden, welche die Dateien des Auftritts prüfen und bereinigen.

Weder Mensch noch Software ist perfekt. Soll heißen, dass es keine absolut sichere Internetseite gibt. Es bedeutet aber auch, dass man aus Fehlern lernen soll. Dass die eigene Website gehackt wurde, muss einem nicht peinlich sein – es sei denn, es passiert ein zweites Mal aus demselben Grund. Nachdem die Website wieder online geschaltet wurde, gilt es deshalb zu prüfen, welche Fehler im eigenen Einflussbereich lagen (alte Versionen, zu einfache Passwörter etc.), um diese zukünftig abzustellen.

Welche konkreten Maßnahmen im Einzelnen helfen, um eine TYPO3-Website sicherer zu betreiben, kann im TYPO3 Security Cookbook [7] nachgelesen werden. Ein neuer und ausführlicherer Bericht soll noch in diesem Jahr veröffentlicht werden [8].

Der Autor

Helmut Hummel ist angestellt als TYPO3-Entwickler bei naw.info in Hannover. Er engagiert sich seit mehreren Jahren im TYPO3-Projekt, ist Mitglied des TYPO3-Entwickler-Teams und Leiter des TYPO3-Security-Teams.