Ratgeber Security: Alles über Web Application Firewalls

Von: Computerwoche / Dr. Bruce Sams

Projekte zu Web Application Firewalls sind äußerst komplex. Was Sie über Funktionen und Betrieb einer WAF unbedingt wissen sollten.

Mit der Verbreitung von Web-Anwendungen in kritischen Bereichen ist die Zahl und Schwere der Angriffe auf diese Anwendungen dramatisch gestiegen. In der Vergangenheit haben sich Unternehmen vor Angriffen durch die Schaffung eines sicheren Raums auf der Grundlage von Netzwerk-Firewalls geschützt. Doch Studien zeigen, dass sich die meisten Angriffe inzwischen von der Netz- auf die Anwendungsebene verlagert haben. Leider sind diese Attacken oft erfolgreich, weil viele Web-Anwendungen schwerwiegende Schwachstellen aufweisen. Nach Untersuchungen von WhiteHat Security haben 82 Prozent von 687 Anwendungen mindestens eine Schwachstelle wie Cross Site Scripting, SQL-Injection oder Privilege Escalation. Traditionelle Abwehrmechanismen wie Netz-Firewalls schützen hier nicht. Sie konzentrieren sich komplett auf die Netz- und Transportschicht und ignorieren Angriffe, die auf dem Hypertext Transfer Protocol (HTTP), Schicht 7 und höher, basieren.

Vor diesem Hintergrund gibt es eine Reihe von Strategien zur Verringerung der Sicherheitslücken, darunter eine neue Klasse von Produkten, die danach streben, einen umfassenden Schutz auf der Anwendungsebene zu gewährleisten: die Web Application Firewall (WAF). Eine WAF ist im Grunde eine Art Filter zwischen Client und Server, der auf der Anwendungsebene operiert, um schädliche oder gefährliche Requests zu blockieren, bevor sie die Anwendungen erreichen.

Richtig ausgewählt, installiert und konfiguriert kann eine WAF die Sicherheit von Web-Applikationen erheblich verbessern. Die Mehrzahl der WAFs schützen Anwendungen (zumindest auf dem Papier) gegen die meisten Bedrohungen, die in der "Owasp Top-10 Vulnerability List" des Open Web Application Security Project beschrieben sind. Allerdings kann dieser Schutz hohe Kosten und großen Aufwand nach sich ziehen. Deshalb sollten Sie im ersten und wichtigsten Schritt bei der Entscheidung für eine WAF definieren, was Sie mit der Technik erreichen möchten und warum Sie sie überhaupt haben wollen.

Brauchen Sie überhaupt eine WAF?

Die effektivsten und bewährtesten Sicherheitslösungen basieren auf dem Prinzip "Defense in Depth", wonach Sicherheit in Schichten aufgebaut sein und es keinen einzelnen Versagenspunkt geben sollte. Eine WAF kann die Sicherheit von Web-Anwendungen erheblich erhöhen, aber sie kann weder auf magische Art und Weise mit einem Knopfdruck unsichere Software in sichere verwandeln, noch ist sie ein Ersatz für die Erstellung sicherer Software. Eine WAF zu installieren, um keine sichere Software produzieren zu müssen, ist demnach keine gute Idee. Vielmehr sollte eine WAF Teil einer umfassenden Strategie zur Sicherung von Web-Anwendungen sein, die auch sichere Entwicklungsverfahren, Verwaltung und Überwachung einschließt.

Auf der anderen Seite haben Sie möglicherweise ein klar definiertes Ziel, etwa das Befolgen von Compliance-Vorschriften wie dem Payment Card Industry Data Security Standard (PCI-DSS). Auch in diesem Fall müssen Sie darauf achten, eine Entscheidung nicht vorschnell zu treffen. Ist das Erfüllen einer gesetzlichen Vorschrift anstelle einer betrieblichen Gesamtstrategie für Sicherheit das einzige Ziel, kann die WAF-Einführung zu einer finanziellen und technischen Katastrophe führen. Unter dem Druck, schnell handeln zu müssen, stützen Systemadministratoren ihre Entscheidung auf das Verkaufsargument eines einzelnen Anbieters beziehungsweise auf eine bestimmte Anforderung oder Funktion, auf die sie sich fixiert haben. Das Ergebnis wird mit hoher Wahrscheinlichkeit eine unangemessene oder nicht optimale Sicherheit sein. Auch eine knappe Frist entbindet Sie nicht von einer fundierten Analyse der Situation.

Ihre Wahl sollte mit Ihren betrieblichen Sicherheitsrichtlinien vereinbar sein, die (hoffentlich) Ihre Ziele und Anforderungen für die Sicherung von Daten und Diensten definieren. Wenn Sie nicht über solche Richtlinien verfügen, dann sind Sie auch nicht in der Lage, über eine WAF zu entscheiden. Die Wahl eines Produkts muss sich auf eine realistische Einschätzung stützen, welche Arten von WAF zur Verfügung stehen, welche Einschränkungen sie haben, und - ganz besonders - wie Sie diese neue Komponente betreiben und verwalten werden.

Zwei WAF-Architekturen

Es gibt zwei grundlegende Architekturen für WAFs. Da wäre zunächst der stark zentralisierte Ansatz von Appliance-WAFs, die in der Regel direkt hinter einer Netzwerk-Firewall und vor Web-Servern positioniert sind und durch die der gesamte Verkehr geleitet wird. Der zweite Ansatz besteht in der Verwendung einer Host-basierenden WAF, die direkt auf den Web-Servern installiert ist.

Als allgemeine Regel gilt: Die reine Leistung der zentralen Geräte ist höher als die von Host-gestützten Produkten, da sie häufig Hardware nutzen, die für den Netzverkehr optimiert ist. Der zentralisierte Ansatz erfordert allerdings auch eine höhere Leistung, da solche WAFs im Vergleich zum verteilten Konzept meist mehr Anwendungen schützen müssen.

In den meisten Fällen ist es leichter, eine einzelne Komponente zu verwalten, was als Vorteil für die Appliances erscheinen mag. Doch viele der Host-basierenden WAFs können über eine zentrale Management-Konsole verwaltet werden, die transparent mehrere Instanzen kontrolliert. Also ist in diesem Fall der vermeintliche Vorteil der Appliances kleiner, als es auf den ersten Blick scheinen mag.

Wenn die WAF versagt oder Probleme hat, kann dies katastrophale Folgen für die Anwendungen hinter ihr haben. Bei einem Fail-Open-Versagen der WAF sind die Anwendungen dahinter ungeschützt. Bei einem Fail-Closed-Versagen dagegen, bei dem kein Verkehr mehr durchgelassen wird, sind alle Anwendungen, die sie schützt, tot. Die zentrale Bereitstellung ist hier im Nachteil, da im Fail-Open-Szenario keine der Anwendungen hinter der WAF geschützt ist, während im Fail-Closed-Szenario keine der Anwendungen erreicht werden kann. Um diese Probleme zu umgehen, benötigen größere Anlagen eine hohe Verfügbarkeit, die man über Clustering und Redundanzen bereitstellen muss. Dies kann die zu erwartenden Gesamtkosten für die Installation der WAF wesentlich erhöhen.

Zwei Sicherheitsmodelle

Wenn es darum geht, zu entscheiden, welcher Datenverkehr blockiert und welcher durchgelassen werden soll, befolgt eine WAF entweder ein positives oder ein negatives Sicherheitsmodell. Ein positives Sicherheitsmodell, auch "Whitelisting" genannt, blockiert den gesamten Datenverkehr, außer solchem, der als gut bekannt ist. Ein negatives Sicherheitsmodell, auch als "Blacklisting" bezeichnet, erlaubt den gesamten Datenverkehr, mit Ausnahme dessen, was als schlecht bekannt ist. Beide Fälle erfordern eine klare Definition von "guten" und "schlechten" Requests, die in der Praxis fast unmöglich zu erreichen ist. Einige WAFs versuchen, beide Modelle zu benutzen, die meisten Produkte halten sich jedoch an eines.

Keines der beiden Modelle ist perfekt. Das positive Modell kann einen enormen Aufwand für die Konfiguration erfordern, um jede mögliche Kombination von Request-Parametern, Headern etc. genau zu definieren, die ein "guter" Request haben kann. Dieser Ansatz ist auch relativ empfindlich gegenüber Veränderungen in der Anwendung. Wenn ein neues Eingabefeld der Anwendung hinzugefügt wird, muss die WAF-Konfiguration gleichzeitig an diese Gegebenheiten angepasst werden, sonst werden alle Anforderungen an die Anwendung blockiert. Unsere Forschung legt nahe, dass das Whitelisting bei komplexen Installationen, die mehrere Anwendungen schützen, nicht praktikabel ist, auch wenn es für einige besondere Fälle durchaus sinnvoll sein kann.

Das negative Sicherheitsmodell hat auch seine Grenzen, denn es ist äußerst schwierig, eine Liste aller möglichen Arten bösartiger Requests zu erstellen. Das bedeutet, dass es zwangsläufig einige böswillige Zugriffe schaffen, an der WAF vorbeizukommen und die Web-Anwendung zu erreichen. Automatische Lernverfahren, die eine WAF trainieren können, guten von schlechtem Verkehr zu unterscheiden, sind nicht absolut zuverlässig und werden nicht helfen, dieses Problem komplett zu lösen.

WAF-Einsatzarten

WAFs können je nach Netzarchitektur auf verschiedene Arten eingesetzt werden. Einige Produkte lassen sich in verschiedenen Modi betreiben, andere unterstützen nur einen. Jeder Modus hat Vor- und Nachteile, die man sorgfältig prüfen muss.

• Reverse Proxy: Der vollständige Reverse-Proxy-Modus ist die häufigste Einsatzart. Eine Reverse-Proxy-WAF befindet sich zwischen der Firewall und dem Web-Server, und jeglicher Netzverkehr erfolgt durch sie hindurch. Die IP-Adressen der WAF werden veröffentlicht, eingehende Verbindungen enden an diesen Adressen. Die WAF erledigt die Zugriffe auf die Web-Anwendungen im Namen des ursprünglichen Browsers. Der Reverse-Proxy-Modus ermöglicht es der WAF, zahlreiche zusätzliche Funktionen anzubieten (zum Beispiel SSL-Terminierung), die in einigen anderen Betriebsarten nicht bereitgestellt werden können. Der Nachteil des Reverse-Proxy-Modus ist, dass er die Latenz erhöhen kann, wodurch eventuell die Leistung verringert wird und es sogar zu funktionalen Problemen für einige leistungskritische Anwendungen kommen kann.

• Transparent Proxy: Eine WAF im transparenten Proxy-Modus befindet sich ebenfalls zwischen der Firewall und dem Web-Server. Allerdings verfügt sie über keine IP-Adresse. Dieser Modus hat den Vorteil, dass keine Änderungen an der bestehenden Netzinfrastruktur nötig sind. Allerdings lässt sich ein Teil der zusätzlichen Funktionen, die Reverse-Proxies anbieten, hier nicht bereitstellen. Zum Beispiel ist SSL-Terminierung nicht möglich.

• Layer-2-Bridge: Eine Bridge ist ein Layer-2-Gerät, das zwei physikalisch getrennte Netzwerke verbindet. Als Layer-2-Gerät achtet eine Bridge nur auf die MAC-Adressen eines Pakets (nicht auf die IP-Adressen) und besitzt keine Informationen über das Routing auf der IP-Ebene. In diesem Modus sitzt die WAF zwischen der Firewall und den Web-Anwendungen und ist in der Regel auf hohen Durchsatz ausgerichtet. Diese Einsatzart bietet hohe Leistung und keine wesentlichen Änderungen am Netz, jedoch nicht die erweiterten Dienstleistungen, die andere WAF-Modi besitzen. Die Einschränkung für SSL-Terminierung gilt auch hier.

• Netzmonitor/Out of Band: Dies ist ein interessanter Modus, in dem die WAF nicht zwischengeschaltet ist und der Netzverkehr nicht durch sie hindurchgelenkt wird. Stattdessen erhält die WAF Datenverkehr aus einem Monitoring-Port, was sehr nützlich sein kann, um eine WAF zu testen, ohne den Netzverkehr zu stören. In dieser Konfiguration agiert die WAF mehr als ein Intrusion-Detection-System (IDS), obwohl sie immer noch Netzverkehr blockieren kann, indem sie TCP-Reset-Signale sendet.

• Host/Server-basierend: Host- oder Server-basierende WAFs sind Softwareanwendungen, die auf einem Web-Server installiert werden. Host-basierende WAFs sind hoch spezialisiert und erlauben eine detaillierte Konfiguration der HTTP-Traffic-Analyse. Da sie aber nichts über das Netz wissen, bieten sie einige der zusätzlichen Funktionen netzgestützter WAFs nicht an. Allerdings hat eine Host-basierende WAF viele Vorteile. Zum Beispiel beseitigt sie das Problem des gemeinsamen Versagenspunkts.

• Eingebettete WAFS: Es ist möglich, vom Konzept der Host-basierenden WAFs einen Schritt weiterzugehen und die Filterfähigkeiten der WAF in eine Anwendung selbst zu integrieren. Sowohl Java- als auch .NET-Anwendungen verfügen über Standardoptionen, um Komponenten zum HTTP-Stream entweder vor oder nach der Web-Anwendung hinzuzufügen. Diese Filter sind dann mehr ein Teil der Anwendung als ein Teil der Infrastruktur. Der wesentliche Unterschied zu den zentralen Modi besteht darin, dass das Entwicklerteam der Anwendung dafür zuständig ist, die Filter zu konfigurieren und die WAF zu verwalten. Abhängig von Ihrer Organisation kann dies ein Vorteil oder ein Nachteil sein.Zusätzliche WAF-Funktionen

  Zusätzliche WAF-Funktionen

  Viele WAFs bieten zusätzliche Funktionen an, um die Integration in die Anwendungslandschaft zu erleichtern. Etliche solche Features sind abhängig von der gewählten Einsatzart.

• Caching: Dies verringert die Last der Web-Server und erhöht die Leistung durch das Zwischenspeichern von Kopien der regulär angeforderten Inhalte auf der WAF. Caching ist auch eine Standardfunktion vieler Web-Server.

• Load Balancing: Load Balancing verteilt eingehende Requests auf mehrere Backend-Server zur Verbesserung von Leistung und Zuverlässigkeit. Die meisten WAFs stellen diese Funktion bereit, indem sie sich in einen bestehenden Load Balancer integrieren.

• Connection Pooling: Dies reduziert den gesamten TCP-Overhead für den Web-Server, indem es mehreren Requests erlaubt, dieselbe Verbindung zu nutzen.

• Komprimierung: Die WAF komprimiert automatisch einige Web-Inhalte, wenn sie an den Browser gesendet werden, was den Netzverkehr reduziert. Der Browser kann sie dann dekomprimieren. Dies ist ebenfalls eine Standardfunktion vieler Web-Server.

• SSL-Beschleunigung: Wenn die SSL-Terminierung in der WAF stattfinden soll, dann kann die hardwarebasierende Verarbeitung die Leistung verbessern. Dies ist besonders interessant für WAFs, die Add-ons zu bestehenden Netzkomponenten sind, zum Beispiel Load Balancer, Firewalls und Switches.

• Zentrale Verwaltung: Sind im Betrieb viele WAFs installiert, kann es die Verwaltung erheblich verbessern, wenn der Hersteller eine zentrale Management-Konsole anbietet, die alle installierten Instanzen von einem Standort aus kontrollieren kann. Das ist sehr nützlich, falls es zum Beispiel um das Verteilen von Richtlinien geht. Die zentrale Verwaltung ist vor allem bei Host-basierenden (verteilten) und eingebetteten WAFs ein wichtiges Thema.

• Zentrales Logging: Weil Firewalls auf Anwendungsebene das gesamte Netzpaket und nicht nur die Netzadressen und Ports untersuchen, haben sie umfangreichere Logging-Möglichkeiten und können anwendungsspezifische Befehle aufzeichnen. Also lassen Sie nicht zu, dass diese Möglichkeit der Informationssammlung verloren geht! Die Analyse der Log-Dateien kann Sie vor drohenden oder aktuellen Angriffen warnen. Legen Sie also fest, welche Informationen Ihre Firewall protokollieren soll - vorzugsweise sollten dies die vollständigen Request- und Antwortdaten einschließlich Header- und Body-Payload sein. Die Zeit und das Know-how zur Log-Analyse muss natürlich auch gegeben sein.

 

Leistung

Generell gilt: Die Leistung von WAFs hängt von der Betriebsart, dem Sicherheitsmodell und der Request-Größe ab. Die Betriebsart ist das offensichtlichste Unterscheidungsmerkmal, wenn es um Leistung geht. Hardwarebasierende transparente Proxies und Bridges werden in der Regel die beste Rohleistung aufweisen, da sie auch meist die geringste Auswirkung auf das Netz haben und außerdem auf hoch optimierten Plattformen arbeiten. Dieser Umstand kann allerdings im Zuge anderer Aspekte schnell an Bedeutung verlieren. Zum Beispiel bedeutet die zentrale Bereitstellung normalerweise, dass eine WAF viele Anwendungen bedienen muss und dass die Anforderungen an sie deshalb entsprechend höher sind. Umgekehrt beeinflussen im verteilten Einsatz etwa bei Host-basierenden oder eingebetteten WAFs die Leistung nur eine oder einige wenige Anwendungen.

Es kann überraschen, dass die Leistung auch von der Art und Komplexität des Sicherheitsmodells (positiv oder negativ) abhängt. Das ist im Hinblick auf die Filterung leicht zu verstehen. Je komplexer die Filterausdrücke sind und je mehr Ausdrücke es gibt, auf die getestet werden muss, desto mehr Rechenleistung wird für die Analyse benötigt. Hier ist das zentrale Modell einer WAF, die den Traffic für eine Vielzahl von Anwendungen analysiert und auch versucht, sehr tiefe Einsicht in den HTTP-Verkehr zu nehmen, klar im Nachteil.

Schließlich zählt die Request-Größe zu den wichtigen Leistungsfaktoren. Aufgrund der Art und Weise, mit der die meisten WAFs ihre Filter auswerten, steigt die Nachfrage nach Rechenleistung nicht linear mit der Request-Größe, sondern schneller als diese. Da Request-Größen um mehr als den Faktor zehn variieren (typischerweise zwischen ein paar hundert Bytes und ein paar Kilobytes), kann dies allein schon einen relativen Leistungsunterschied um das Zehnfache oder mehr bedeuten.

Konfiguration, Handhabung und Wartung

Sobald man die verschiedenen Betriebsarten, Funktionen etc. einer WAF kennt, ist es an der Zeit, über die wichtigsten, leider auch am wenigsten verstandenen Aspekte der Web Application Firewalls zu diskutieren: Betrieb, Wartung und Konfiguration. Das Hauptproblem ist, dass eine WAF, im Gegensatz zu einer Netz-Firewall, eng mit den Anwendungen hinter ihr verbunden ist. Wenn eine WAF eine Anwendung schützen soll, dann muss sie genug über die zulässigen Werte für jedes einzelne ihrer Felder wissen, um die eingegebenen Daten genau überprüfen zu können. In gewissem Sinn muss dann die Anwendungslogik in die WAF selbst hineinkonfiguriert werden, wodurch eine sehr enge Verbindung zwischen WAF und Anwendung entsteht. Die WAF muss Angriffs-Strings, die oft Sonderzeichen wie einfache Anführungszeichen enthalten, von zulässigen Eingaben, die ebenfalls Sonderzeichen enthalten, unterscheiden können. Letzteres ist zum Beispiel der Fall, wenn Herr O'Reilly seinen Namen eingibt. Eine Anwendung kann Zeichen wie $, <,>, /, *, "," akzeptieren, während eine andere nur $ und * annimmt. Eine dritte Anwendung wiederum benötigt XML-Strings als Eingabe und muss deshalb Daten akzeptieren, die leicht mit Angriff-Strings zu verwechseln sind.

Das Problem ist, dass detaillierte Kenntnisse über eine Anwendung auf diesem Niveau nur im Entwicklungsteam oder in der Fachabteilung vorhanden sind. Die für das Rechenzentrum und die Infrastruktur zuständigen Gruppen haben weder das technische Verständnis noch die Kenntnis zum Geschäftsprozess jeder einzelnen Anwendung, um eine WAF auf diese Weise zu konfigurieren und zu warten. Dennoch wollen viele Unternehmen ihre WAFs genauso betreiben wie ihre Netzwerk-Firewalls: als Geräte im Rechenzentrum. Frustration und gegenseitige Schuldzuweisungen sind die Folge.

Daran wird auch deutlich, dass Updates und Änderungen zu einer schweren Belastung werden können. Selbst bei einer kleinen Änderung an einer bestehenden Anwendung, wenn zum Beispiel der Feldname nur eines einzigen Parameters geändert wird, muss man dies auch in der WAF neu konfigurieren. In vielen Unternehmen dauert es eine Woche oder mehr, um die Änderungsanforderungen (Change Requests) für Firewalls zu überprüfen und umzusetzen. Deshalb muss eine neue WAF-Konfiguration gleichzeitig mit den Änderungen an der Anwendung angestoßen werden! Das Problem verstärkt sich, je enger die Verbindung zwischen WAF und Anwendungen ist. Daher Vorsicht bei der Verwendung von zu vielen "fortgeschrittenen" Angriffs-Erkennungsfunktionen, da sie in der Regel zu einer noch engeren Kopplung zwischen WAF und Anwendung führen.

Schritte zur WAF-Auswahl

Wer auf der Suche nach einer passenden WAF ist, sieht sich zunächst mit einer verwirrenden Anzahl von Produkten konfrontiert. Um das richtige Erzeugnis auszuwählen, können die nachfolgenden Schritte sehr nützlich sein.

• Analysieren Sie, was Sie mit der WAF erreichen werden und was nicht. Verbesserte Sicherheit als Teil einer kompletten Defense-in-Depth-Strategie ist das korrekte Ziel.

• Bestimmen Sie, welche Art von WAF-Architektur und -Einsatz die beste für Sie ist. Beachten Sie dabei die Netzstrukturen, die Anwendungsarten sowie spezielle Eigenschaften und Synergien mit bestehenden Geräten.

• Schätzen Sie den möglichen Einfluss auf Ihre bestehenden Systeme und Prozesse ab. Planen Sie viel Zeit für die volle Bewertung der verschiedenen Produkte ein. Treffen Sie keine übereilte Entscheidung .

• Schätzen Sie ab, wie Sie die WAF verwalten, unterstützen und handhaben werden. Wer wird verantwortlich sein, und wie wird die WAF konfiguriert? Es gibt möglicherweise große versteckte Auifwände, die zu den Gesamtkosten für den Besitz beitragen. Zum Beispiel kann es nötig sein, neue Job-Funktionen an kritischen Organisationsschnittstellen zu schaffen.

• Fordern Sie Hersteller dazu auf, detailliert zu beschreiben, wie sie Ihre speziellen Probleme lösen werden. Bringen Sie sie dazu, Lösungen für konkrete Probleme vorzuschlagen. Untersuchen Sie, welchen Support die Hersteller bieten.

• Betreiben Sie ein Pilotprojekt, um die Durchführbarkeit zu prüfen.

  Quelle: http://www.computerwoche.de/security/1907735/index9.html

---