Security-Probleme im Web-Hosting-Umfeld
Gehostet ist nicht gleich sicher
Webserver und webbasierte Applikationen sind das beliebteste Ziel von Hackern. Deshalb lassen manche Unternehmen den Webserver bei einem externen Hosting-Anbieter betreiben und hoffen, sich des Problems entledigt zu haben. Nicht immer ist dieser Weg jedoch gangbar oder sinnvoll, und in einigen Fällen kann das Outsourcing des Webservers sogar zu einer Verschlechterung der Gesamtsicherheit führen.
Es gibt viele Gründe, die Web-Hosting interessant machen können. Aber auch wenn es um die
Sicherheit des Webservers geht, gibt es gerade bei kleineren Firmen häufig die Motivation, dass man
mit der Sicherheit oder Angreifbarkeit des eigenen Webservers am liebsten nichts zu tun hätte.
Jedoch kann ein extern gehosteter Webserver auch neue Bedrohungen mit sich bringen. Die
Entscheidung, ob im Einzelfall der Aufbau eines neuen Webservers in einer eigenen Firewall-DMZ des
Unternehmens oder bei einem externen Anbieter die bessere Lösung ist, hängt von vielen Faktoren ab.
Deshalb sollte man zunächst überlegen, welchen Bedrohungen der Webserver unabhängig von seiner
späteren Positionierung ausgesetzt ist.
Die erste und offensichtlichste Bedrohung ist immer der direkte Einbruch in den Webserver durch
einen Angreifer. Die Ursachen für einen solchen Einbruch können auf verschiedenen Ebenen liegen.
Während das Ziel früher meist Verwundbarkeiten im Betriebssystem oder im Webserverprozess waren,
die sich durch das rechtzeitige Einspielen von Patches oder Service-Packs beheben ließen, sind es
heute vor allem Probleme auf der Applikationsebene in Form von Programmierfehlern in den CGI- und
PHP-Skripten oder Java-Servlets. Die eigenen Programmierer oder die Entwickler eines
Dienstleisters, die für die Interaktivität des Webauftritts sorgen, vernachlässigen zu häufig, dass
es nicht nur brave Anwender gibt, sondern auch Angreifer, die gezielt versuchen, jeden Aspekt und
jede Funktion einer Webanwendung zu missbrauchen, um in den Server einzubrechen, ihn zum Spam-Relay
zu machen oder einfach um die Homepage zu verunstalten.
Moderne Angriffe auf Applikationsebene nutzen vor allem Fehler in der individuellen Applikation
aus, um beispielsweise Befehle in Backend-Datenbanken zu injizieren (SQL-Injection), URL-Parameter
oder Session-IDs zu manipulieren oder um per Cross-Site-Scripting Javascript-Befehle in dynamisch
aufgebaute Seiten zu platzieren, die andere Anwender täuschen oder ihre Session-Informationen
stehlen.
Ein Web-Hosting-Anbieter kümmert sich in der Regel um das ständige Einspielen von Service-Packs
und Patches. Dies minimiert klassische Angriffspunkte auf der Ebene des Betriebssystems und der
Webserverplattform, ohne den Auftraggeber damit zu belasten. Je höher die Verwundbarkeiten und
Angriffe jedoch im ISO/OSI-Referenzmodell einzuordnen sind, desto weniger kann ein Hosting-Anbieter
die Probleme beheben, ohne dass der Besitzer der Inhalte davon betroffen ist. Liegt zum Beispiel im
Extremfall eine Verwundbarkeit in einem anwendungsspezifischen PHP-Skript des Servers vor, wird der
Hoster kaum die von seinem Kunden gelieferten Programme verändern wollen oder können. Ein Grenzfall
sind Verwundbarkeiten in Plattformelementen, die nach dem Patching anders funktionieren und deshalb
die Skripte oder Programme des Anwenderunternehmens beeinflussen.
Das Unternehmen kann bei interaktiven Inhalten seines Webservers gerade nicht davon ausgehen,
dass ein Hoster sich um die Sicherheit des gesamten Servers kümmert. Sobald es um Verwundbarkeiten
in den Inhalten oder bei der Eingabeverarbeitung auf dem Webserver geht, ist das Unternehmen
involviert, und der Programmierer der Webseiten und Verarbeitungen muss selbst bei der
Problemlösung mitarbeiten.
Angriffe auf einen Webserver müssen nicht unbedingt so aussehen, dass der Angreifer den Server
sofort vollständig auf Betriebssystemebene unter seine Kontrolle bringt. Ein ganz anderes Beispiel
sind Webapplikationen, die für eine geschlossene Benutzergruppe gedacht sind und deshalb zunächst
eine Benutzeranmeldung mit Name und Passwort oder sogar mit starker Authentisierung erfordern. In
einer solchen Umgebung besteht das erste Ziel des Angreifers darin, die Zugriffskontrolle und
Benutzeranmeldung zu umgehen. Derartige Angriffe finden heute fast immer auf Applikationsebene
statt und haben ihre Ursachen in Fehlern bei der kundenspezifischen Programmierung. Hier leisten
Hoster derzeit kaum einen Beitrag zur Sicherheit.
Wer die Leistungen eines Hosting-Anbieters in Bezug auf die Sicherheit der von ihm zu hostenden
Webserver hinterfragt, erhält meist Informationen zu physischer RZ-Sicherheit, Überwachung oder
Brandschutz. Diese Themen sind ein wichtiger Teil der gesamten Sicherheit, haben aber mit einem
typischen Angriff auf Webserver wenig zu tun. In diesen Bereichen beschränken sich die Anbieter
meist auf SSL-Verschlüsselung, regelmäßiges Patchen der Systeme, gelegentlich noch auf regelmäßiges
Scannen der Server nach bekannten Verwundbarkeiten und in manchen Fällen auf opti-onale
vorgeschaltete Firewalls. Alle diese Maßnahmen sind wichtig und sinnvoll, behindern aber heute
keinen Hacker mehr, da die Angriffe bevorzugt über die Applikationsebene erfolgen und damit nicht
vom Patch-Stand des Betriebssystems oder Webservers und nicht von bekannten Verwundbarkeiten
abhängen. Auch Netzwerk-Firewalls, die Zugriffe auf den Port 80 oder 443 beschränken, haben keine
Auswirkungen auf das Prob-lem der Applikationssicherheit, da derartige Angriffe über den erlaubten
Zugriff auf den Server erfolgen.
Nachbars Server als Risikofaktor
Erschwerend kommt hinzu, dass ein Web-Hosting-Anbieter in der Regel sehr viele Webserver
betreibt. Selbst wenn ein Unternehmen davon ausgeht, dass seine eigene Webanwendung kaum angreifbar
ist und die vom Hoster vorgeschaltete Firewall als Schutz ausreicht, so ist zu bedenken, dass
hinter derselben Firewall viele weitere und potenziell unsichere Webserver angeschlossen sind. Der
erfolgreiche Einbruch in den eventuell unsicheren Nachbarserver eines anderen Unternehmens eröffnet
dem Angreifer womöglich einen direkten Weg zu einem vermeintlich sichereren Server. Eine Firewall,
die vor allen gehosteten Servern steht und diese gemeinsam schützen soll, lässt in der Praxis meist
beliebige Angriffe zwischen den einzelnen Servern zu.
Besonders kritisch wird die Situation bei einem extern gehosteten Webserver, wenn dieser nicht
autark funktioniert, sondern auf Daten aus dem internen Unternehmensnetz angewiesen ist: zum
Beispiel ein Webserver, der einen Produktkatalog mit aktuellen Preisen und Verfügbarkeiten anbietet
und die benötigten Daten per SQL-Verbindung vom Datenbankserver aus dem Unternehmensnetz abruft.
Eine solche Struktur macht das Hosting oft unsinnig: Neben der direkten Gefahr für den Webserver
selbst besteht jetzt ein zusätzliches Risiko des Zugriffs aus dem Netz des Hosters in das
Unternehmensnetz. Da der Hoster typischerweise sehr viele verschiedene Webserver mit
unterschiedlichem Sicherheitsniveau in einem gemeinsamen Netz betreibt, kann es sein, dass nicht
der eigene Server Abfragen schickt, sondern ein anderer gehackter Server im selben Netz mit
gefälschter IP-Quelladresse versucht, die Kommunikationsverbindung auszunutzen. Sogar in der
jüngeren Vergangenheit gab es immer wieder Beispiele, in denen nicht nur einzelne Server bei einem
bekannten Hoster gehackt wurden, sondern in denen die Administrationswerkzeuge des Anbieters
generelle Schwachstellen hatten, sodass ein Angreifer jeden dort betriebenen Server relativ einfach
manipulieren konnte.
Um das Problem des Zugriffs vom Hoster in das eigene Netz zu umgehen, kommen manche Unternehmen
auf die Idee, die benötigten Daten regelmäßig aktiv aus dem Unternehmensnetz zum externen Server zu
replizieren und eventuell auf dem Server zwischengespeicherte Anfragen abzuholen und intern zu
verarbeiten. Solche Mechanismen erwecken häufig spontan ein Gefühl stark erhöhter Sicherheit,
erweisen sich jedoch bei näherer Betrachtung oft als noch größeres Sicherheitsproblem: Zu den schon
existierenden Risiken gesellen sich nun Verwundbarkeiten auf dem Kommunikationsgegenstück im
Unternehmensnetz. Der Aufwand, der jetzt zur Absicherung dieses Gegenstücks zu betreiben ist, wiegt
oft die Hosting-Vorteile wieder auf. Wenn ein Unternehmen ohnehin eine schnelle Leitung für die
Kommunikation zwischen internen Datenbanken und dem externen Webserver beim Hoster benötigt und
dazu noch aufwändige Sicherheitsmechanismen zum Schutz der Kommunikationsbeziehung aufbauen muss,
kann der Webserver auch gleich in einer demilitarisierten Zone (DMZ) der Firewall beim Kunden
stehen. So kann man sich das Hosting sparen.
WAFs zu selten im Einsatz
Technisch gesehen wäre es für Web-Hosting-Anbieter kein größeres Problem, neben dem typischen
Angebot bezüglich Patchen und Firewalls gegen Aufpreis auch spezielle Sicherheitsmechanismen für
den Schutz auf Applikationsebene anzubieten. Allenfalls würde einigen Anbietern das dazu nötige
Personal fehlen. Entsprechende Lösungen sind jedenfalls seit mehreren Jahren am Markt und kommen
bei großen Unternehmen, die die Sicherheit ihrer Web-applikationen selbst in die Hand genommen
haben, zum Einsatz: So genannte Webapplikationsfilter (WAFs) arbeiten meist auf Reverse-Proxy-Basis
und kont-rollieren alle URLs, Cookies und Formulareingaben gegen zuvor definierte oder gelernte
Wertebereiche und maximale Längen. So verhindern sie im Gegensatz zu klassischen Firewalls nahezu
alle Angriffe auf Webserver. Der Aufwand, um solche Mechanismen aufzubauen, beschränkt sich in der
Praxis durch intelligente Lernmechanismen der Lösungen auf wenige Tage bei der Inbetriebnahme und
auf wenige Stunden bei typischen Änderungen an Webapplikationen.
Leider bieten Hoster entsprechende Mechanismen bisher viel zu selten an, was vermutlich an
fehlender Nachfrage und fehlendem Verständnis der Problematik auf Seite der Unternehmen liegt. Die
bevorzugten Verkaufsargumente beim Hosting sind eher der Preis und die Performanz als die
Sicherheit. Unternehmen, die großen Wert auf Sicherheit legen, fragen oft erst gar keine Hoster an:
Wer hier angemessene Sicherheit wünscht, muss dies selbst in die Hand nehmen und sich
beispielsweise aus dem Angebot der kommerziell verfügbaren Webapplikationsfilter bedienen.
Lesen Sie mehr zum Thema
