Wenn IPS allein nicht mehr hilft
Firewalls für Webapplikationen
Netzwerk-Firewall-, Intrusion-Prevention- und Webapplication-Firewall-Systeme stellen heute die grundlegenden Komponenten einer dreifach gestaffelten Sicherheitsstrategie in Rechenzentren dar, die den bestmöglichen Schutz für webbasierte Anwendungen sicherstellen sollen. Dieser Artikel beschreibt jede dieser Techniken und ihre Rolle beim Schutz von Webapplikationen.
Der Schutz von Webanwendungen in Unternehmen und damit assoziierten Datenbanken vor Angriffen
aus dem Internet gewinnt zunehmend an Bedeutung. Während in den frühen Tagen der Internetsicherheit
bereits eine gut konfigurierte Netzwerk-Firewall zufriedenstellenden Schutz bot, verbreiteten sich
schon bald darauf "Würmer" auf der Applikationsebene – und erforderten den Einsatz von
leistungsfähigen Intrusion-Prevention-Systemen (IPS). Nun sind neue Bedrohungen aufgetaucht, die
die IPS mit auf Webapplikationen abzielenden Angriffsstrategien umgehen. Um diesen neuen
Bedrohungen zu begegnen, setzen viele große Rechenzentren Webapplication-Firewalls ein.
Netzwerk-Firewalls - die erste Verteidigungslinie
Netzwerk-Firewalls zählen seit über 15 Jahren zur Standardausrüstung einer
Netzwerkinfrastruktur. Sie stellen darin die erste Verteidigungslinie dar. Läuft beispielsweise
eine Webanwendung auf einem in einer "demilitarisierten Zone" (DMZ) stehenden Server oder
Datenzentrum – also außerhalb des eigentlichen internen LANs, stellt die Firewall sicher, dass
lediglich über HTTP-Port 80 und HTTPS-Port 443 eingehende Anfragen an diesen Webserver
weitergeleitet werden. Ohne eine Netzwerk-Firewall könnten die Ressourcen des Webservers leicht von
externen Hackern missbraucht werden, etwa durch den Einsatz von Port-Scannern und
Remote-Access-Protokollen wie Telnet.
Doch Netzwerk-Firewalls bieten meist keine Funktionen, die Anwendungsschicht (Layer 7, auch Data
Payload) der Pakete in den Datenströmen zu untersuchen. Angreifer haben gelernt, diese Schwäche zu
ihrem Vorteil auszunutzen, indem sie auf der Anwendungsschicht ablaufende Attacken in unverdächtige
Webanfragen einbetten. Im Zusammenhang mit Webanwendungen zählen webbasierte Würmer zu den frühen
Beispielen dieser Art von Bedrohung auf Anwendungsebene. Code Red, Nimda und Slapper sind
Internetwürmer, die weltweit erhebliche Schäden angerichtet haben.
Intrusion-Prevention-Systeme (IPS) stoppen Würmer und andere Angriffe, die bekannte
Schwachstellen in kommerzieller und freier Software wie etwa Webservern (IIS, Apache und so weiter)
und Datenbankservern (Oracle, MS-SQL etc.) ausnutzen. Ein IPS inspiziert die Paketinhalte auf der
Anwendungsschicht und vergleicht sie mit einer Liste bekannter Datenmuster (Signaturen).
Intrusion-Prevention-Systeme - die Wurm-Killer
Doch auch IPS haben nur einen beschränkten Wirkungskreis: Aufgrund ihrer Abhängigkeit von
Signaturen sind die Systeme machtlos gegen Angriffe, die Schwachstellen in kommerziellen
Webapplikationen (SAP, Oracle, Peoplesoft und so weiter) und in selbst geschriebenen Webanwendungen
(etwa .asp- und .php-Applikationen) ausnutzen. "SQL Injection" ist ein verbreitetes Beispiel für
eine solche Bedrohung. Dabei sucht der Angreifer nach einer Sicherheitslücke im Eingabemodul der
Anwendung ("Input Validation"), die es ihm ermöglicht, korrekte Anwendungseingaben durch angepasste
Datenbankbefehle zu ersetzen. Diese Kommandos werden dann zur Backend-Datenbank durchgereicht und
hier mit den Berechtigungen des Programms ausgeführt.
Gefahr durch SQL-Injection
Mithilfe der "SQL Injection" kann ein Hacker zum Beispiel Kreditkartennummern, Benutzernamen und
Passwörter stehlen oder sogar unbeschränkten Zugang zu einer ganzen Datenbank erlangen.
Genau wie Wurm-Attacken sehen Webapplication-Angriffe aus Sicht der Protokolle wie legitime
HTTP-Datenströme aus, daher sind sie für Netzwerk-Firewalls nicht zu erkennen. Doch sie basieren –
anders als die Würmer – nicht auf einer bekannten Schwachstelle und können daher nicht anhand einer
Signatur dingfest gemacht werden. Einige IPS-Anbieter werben damit, dass ihre Systeme einige
Webapplication-Attacken abwehren können, indem sie Signaturen auswerten, die häufig bei
Webangriffen verwendete Zeichenfolgen enthalten – etwa "union", "select" oder "script".
Doch diese Wörter tauchen mittlerweile auch häufig in ganz normalen Websites auf, die dann
fälschlicherweise als gefährlich eingestuft werden. Die Folge: In den meisten Fällen ist die
Signaturenfunktion deaktiviert. Doch selbst, wenn sie genutzt wird, lässt sie sich mit bekannten
Techniken leicht umgehen.
Webapplication-Firewalls - die dritte Verteidigungslinie
Webapplication-Firewalls (WAF) richten sich gegen die zunehmende Zahl von Angreifern, die
verstärkt nach Schwachstellen in Webanwendungen suchen. Eine WAF baut ein Vergleichsmodell auf (oft
als "Positive Security Model" bezeichnet), das zeigt, wie eine Webanwendung unter normalen
Bedingungen arbeitet. Dann vergleicht es den aktuellen Datenstrom mit dem Modell und kann so ein
ungewöhnliches Verhalten identifizieren.
Ein effektives WAF-Anwendungsmodell umfasst dynamische URLs (.asp, .php und so weiter),
Parameter, HTTP-Methoden, Cookies, Session-IDs, XML/SOAP-Schemata und vieles mehr. Bei einigen
WAF-Produkten der ersten Generation müssen die Modelle noch von Hand erstellt werden – eine äußerst
komplizierte und zeitaufwändige Aufgabe, die im Falle von Änderungen an Webapplikationen oft fast
täglich erledigt werden muss. Daher automatisieren WAF-Systeme der zweiten Generation diesen
Prozess, indem sie den Datenverkehr einer Applikation live überwachen und mithilfe statistischer
Lernalgorithmen automatisch ein vollständiges Verhaltensmodell unter Normalbedingungen
erstellen.
Wenn nun ein Angreifer die Kommunikation der Applikation stört, greift die WAF ein. Wenn ein
Hacker etwa auf einer E-Commerce-Website einen numerischen Parameter des Einkaufskorbs mit einem "
UPDATE"-SQL-String ersetzt – zum Beispiel, um den Preis zu ändern – erkennt die WAF die
ungewöhnliche Aktion, die dem gewöhnlichen Verhalten der Applikation widerspricht.
Obwohl "UPDATE" Teil eines zulässigen SQL-Strings ist, hat die WAF gelernt, den unzulässigen
Gebrauch des Parameters zu identifizieren. Dadurch werden Fehlalarme drastisch reduziert. Die
Folgerung lautet in diesem Fall: Beim Einsatz moderner WAF-Systeme sollte kein manuelles "Tuning"
nötig sein.
Rechenzentren vereinfachen und skalieren
Die Implementierung von WAF-Systemen stellt eine Herausforderung an die Applikationen, Netzwerk-
und Hochverfügbarkeitslösungen dar. Aus Sicht der Anwendung basieren die WAF-Architekturen der
ersten Generation auf reversiven Proxy-Techniken für die Inspektion der Anwendungsschicht. Doch
Proxies bringen eine Vielzahl von Risiken bei der Implementierung mit sich:
Performance-Einbußen – Seit den ersten Netzwerk-Firewalls waren
Proxy-Architekturen verantwortlich für die Verschlechterung des Netzwerksdurchsatzes und die
Erhöhung der Antwortzeiten (Latenz).
Änderungen am Rechenzentrum – Proxies modifizieren den Datenverkehr im
Netzwerk. Dadurch ist die Anpassung von IP-Adressierung, IP-Routing, Anwendungs-URLs, eingebetteten
Applikationsaufrufen und so weiter im Datenzentrum nötig.
Einzelfehlerpunkt/Hochverfügbarkeit – Reversive Proxy-Lösungen stellen einen
Einzelfehlerpunkt dar (Single Point of Failure) – daher müssen sie besonders sorgsam entwickelt
werden, um eine möglichst hohe Verfügbarkeit zu gewährleisten.
Neuere WAF-Systeme setzen Datenverarbeitungstechniken auf Kernel-Ebene ein, die die Nachteile
von Proxy-Lösungen vermeiden. Sie ermöglichen einen Multi-Gigabit-Durchsatz, Latenzen im
Mikrosekundenbereich und kommen ohne Änderungen an der Infrastruktur des Rechenzentrums aus. Auf
Kernel-Ebene arbeitende Produkte erlauben zudem mehrere Anwendungsszenarien für
Hochverfügbarkeit.
Im Netzwerkpfad eingesetzt ("inline") unterstützen sie transparentes Failover. Sessions werden
im Fehlerfall nicht unterbrochen. Außerdem lassen sich die Produkte auch offline als
Netzwerkmonitor einsetzen. Angriffe wehren sie dann über TCP-Resets ab.
Schutz über jede Schnittstelle
Aus Sicht des Netzwerks müssen sich WAF-Systeme transparent in bestehende Layer-2-Architekturen
einfügen lassen, damit sie Verfahren wie Link-Aggregation und komplexe VLAN-Topologien unterstützen
können. Appliances der ersten Generation erfüllten diesen Anspruch nicht, was bisweilen zu
ernsthaften Problemen für Netzwerkverantwortliche in Rechenzentren führte.
Die aktuelle Generation der Security-Plattformen verfügt über die nötigen Leistungsmerkmale, die
die Applikationstransparenz neuer WAF-Systeme sicherstellen. Das ermöglicht es einer WAF, über jede
Schnittstelle einfließenden Datenverkehr zu schützen. Zusätzlich sind diese neuen
Security-Plattformen in der Lage, VLANs gegenüber der Applikation entweder als nativ oder als
standardisiertes Ethernet-Interface darzustellen.
Ein weiterer nicht zu unterschätzender Aspekt: Zu guter Letzt bietet die modulare Architektur
neuerer Security-Plattformen volle Redundanz auf Port-, Hardware- und Anwendungsebene. Damit
unterstützen sie die Hochverfügbarkeitsanforderung von WAF-Systemen der zweiten Generation. Eben
diese Modularität bietet einen weiteren wichtigen Vorteil: Die Leistung des Systems lässt sich
durch das Hinzufügen neuer Module oder Schnittstellenkarten linear skalieren.
Fazit: Schutz durch dreischichtigen Ansatz
Webapplication-Security ist in jedem Fall ein komplexes Aufgabengebiet. Diese Aussage klingt
zwar zunächst banal, weil sie auf so viele Spielarten der Sicherheitsproblematik zutrifft, zieht
jedoch wichtige Konsequenzen nach sich: Security-Verantwortliche müssen sich darüber bewusst sein,
dass Bedrohungen ein breites Spektrum von einfachen Netzwerkattacken über Würmer bis hin zu
Angriffen auf Webanwendungen umfassen. Ein höchstmöglicher Schutz von Webapplikationen erfordert
aus diesem Grund einen dreischichtigen Ansatz, der auf Netzwerk-Firewall-, IPS- und
Webapplication-Firewall-Techniken basiert.
Lesen Sie mehr zum Thema
