Prinzipbedingt müssen Web-Server aus dem Internet erreichbar sein. Intern sind die Web-Server meist mit Datenbanken verbunden, in denen auch sensible Informationen abgelegt sind. Damit stellen Web-Server eine attraktive und lohnende Angriffsfläche auf Firmeninterna global bereit.
Eine klassische Firewall mit ihren Regeln für Ports und IP-Adressen kann keinen Schutz für Web-Server bieten, da der Datenaustausch ja gewünscht und meist auch legitim ist. Erst eine Web Application Firewall (WAF) bietet einen Ausweg aus diesem Dilemma. Sie analysiert die vom Benutzer an den Webserver übertragenen Daten und findet darin Manipulationen und auffällige Muster.
Eine WAF untersucht die Anfragen an den Web-Server im Kontext der angefragten Applikation und blockiert Angriffe wie zum Beispiel SQL-Injection oder XSS-Attacken, bevor sie überhaupt zum Web-Server gelangen können. Darüber hinaus werden die als Antwort ausgelieferten Web-Seiten auf sensible Daten hin untersucht, die nicht nach außen gelangen sollen.
Die Integration
Eine WAF lässt sich auf mehrere Arten in eine bestehende Netzumgebung integrieren. Grundsätzlich gibt es die beiden Betriebsmodi "Reverse Proxy" und "Bridge". Bei der Integration als Bridge wird die WAF wie ein Switch einfach in die Netzverbindung eingeschleift. Hierbei sind keine Änderungen am Routing, der Konfiguration der Firewall oder des Netzes erforderlich. Die WAF liest den Netzverkehr passiv mit.
Meist erfolgt die Integration einer WAF allerdings als Reverse Proxy. Dabei wird die direkte Verbindung zwischen dem Browser des Benutzers und dem Web-Server aufgebrochen. Statt mit dem Web-Server spricht der Browser mit der WAF. Nach Überprüfung der Anfrage baut Letztere eine eigene Verbindung zum Web-Server auf und liefert die erhaltenen Antwortseiten an den Browser aus.
Benutzereingaben in eine Web-Applikation werden vom Web-Browser in Form von GET- oder POST-Parametern an den Web-Server übermittelt. Hierzu zählen auch Auswahlfelder oder Parameter, die von der Applikation als so genannte Hidden-Parameter gesetzt werden. Alle diese Parameter können von Angreifern manipuliert und missbraucht werden.
Zu den Grundfunktionen einer WAF zählt, diese Angriffe zu erkennen und zu blockieren und die übermittelten Parameter vor Manipulationen zu schützen. Des Weiteren verhindert sie, dass Daten gestohlen beziehungsweise ausgespäht werden. Einige WAF-Produkte bieten zusätzlich an, die Benutzerauthentisierung einer Web-Applikation zu übernehmen.
Wie eine WAF Angriffe erkennt
Die Angriffserkennung erfolgt in mehreren Schritten: Zunächst werden alle übermittelten Daten "normalisiert", sprich: sämtliche Codierungen, die einen Angriff tarnen könnten, werden aufgelöst. In einem nächsten Schritt folgt die Filterung durch verschiedene Listen - im Idealfall zuerst anhand einer Whitelist. Dabei handelt es sich um eine Liste, in der für jeden Parameter und jede URL der Web-Applikation die jeweils gültigen Werte hinterlegt sind, was auch als "positives Sicherheitsmodell" bezeichnet wird: Demnach ist alles verboten, was nicht explizit erlaubt ist.
Ergänzend filtern alle WAFs die Anfragen durch Blacklists. Das sind Listen mit bekannten Angriffsmustern, die auf die übermittelten Parameter angewendet werden. Tritt eines dieser Angriffsmuster in einer Anfrage auf, wird diese blockiert. Diese Art der Filterung nennt sich "negatives Sicherheitsmodell": Was nicht explizit verboten wird, ist erlaubt. Im Unterschied zu einem IDS/IPS (Intrusion Detection/Prevention System) untersucht die WAF hierbei nicht nur den Datenstrom als Ganzes, sondern analysiert auch das zugrunde liegende HTTP (Hypertext Transfer Protocol) und prüft die einzelnen Bestandteile der Anfrage bezogen auf jedes einzelne Formular oder sogar Feld.
Die WAF taucht demnach wesentlich tiefer in die Kommunikation ein und ist so in der Lage, viele bekannte Angriffe zu erkennen. Da die Attacken stets auf denselben Grundlagen basieren, müssen diese Muster nur selten erneuert werden. Für eine erfolgreiche SQL-Injection muss zum Beispiel gültiges SQL eingesetzt werden. Dieser Standard ist seit vielen Jahren unverändert. Die zugehörigen Angriffsmuster sind also nur bei einer Änderung des SQL-Standards anzupassen.
Schutz vor Manipulation
Grundsätzlich gibt es zwei Arten von Objekten, die es vor Manipulationen zu schützen gilt: Das sind zum einen die vom Browser des Benutzers an die WebApplikation übermittelten Parameter, deren Inhalt aus Benutzereingaben in Formulare oder aus Auswahlfeldern stammt. Zum anderen übermittelt die Web-Applikation ein oder mehrere Cookies an den Browser, in denen sensible Daten wie Session-Informationen oder Authentisierungs-Tokens gespeichert sein können.
Es gibt WAFs, die zum Schutz dieser Objekte anbieten, die tatsächlichen Werte von Auswahlfeldern oder Cookies durch verschlüsselte Werte zu ersetzen und so einer Manipulation vorzubeugen. Ein Angreifer kann nun die Werte dieser Objekte nicht mehr nach Belieben verändern. Weil er den geheimen Schlüssel nicht kennt, kann er den manipulierten Inhalt nicht so chiffrieren, dass die WAF dies akzeptieren würde.
Verschlüsselung wird zudem von manchen Herstellern als Schutz vor "Forceful Browsing" eingesetzt - dabei handelt es sich um das Ausspähen von Daten durch die direkte Eingabe von URL-Pfaden beziehungsweise Dateinamen, die normalerweise nicht über Hyperlinks der Web-Applikation erreichbar wären. Um dem entgegenzuwirken, werden alle in einer HTML-Seite vorhandenen Hyperlinks durch verschlüsselte Varianten ersetzt. Die WAF akzeptiert nur noch Seitenaufrufe, die durch Aufruf eines solchen Links erfolgen. Ohne den geheimen Schlüssel kann ein Angreifer keine URL mehr direkt aufrufen oder Dateinamen erraten.
Sollte es einem Angreifer trotz der genannten Maßnahmen gelingen, die Web-Applikation zu manipulieren, um Daten zu stehlen, kann die WAF dennoch eingreifen: Auch die ausgehenden Daten werden auf bestimmte Muster untersucht. Die Auslieferung sensibler Daten wie etwa Kreditkartennummern lässt sich so blockieren oder in der ausgelieferten Seite maskieren.
Durch das Filtern ausgehender Seiten lässt sich aber auch verhindern, dass möglicherweise wichtige Details ausgespäht werden. Fehlerseiten von Applikations- oder Web-Servern enthalten häufig detaillierte, für Angreifer wertvolle Informationen über die darunterliegende Infrastruktur. Daher werden diese Seiten von der WAF durch eigene Seiten ersetzt oder auf unverfängliche Seiten umgeleitet.
Authentisierung via WAF
Viele WAF-Produkte lassen sich auch als zentrale Authentisierungsinstanz für Web-Applikationen einsetzen. Die Möglichkeiten reichen hier von einer herkömmlichen "Basic-Auth" mit einer in der WAF gepflegten Benutzerdatenbank über die Authentisierung mit Client-Zertifikaten bis hin zu Single-Sign-on-Portalen mit Unterstützung für komplexe Benutzerdatenbanken (etwa Host-Anbindung oder Kerberos-Token).
Eine WAF kann auch per SSL verschlüsselte Anfragen inspizieren. Das originäre Server-Zertifikat samt Schlüssel wird dabei auf der WAF eingespielt, die (im Reverse-Proxy-Modus) dann die SSL-Verbindungen terminiert. Nach der Untersuchung der Anfrage kann die Verbindung zum eigentlichen Web-Server erneut verschlüsselt werden oder - je nach Anforderung - auch unchiffriert erfolgen. Für den Betrieb im Bridge-Modus wird SSL transparent inspiziert.
Um ihren Zweck erfüllen zu können, benötigt eine WAF eine Policy, die möglichst gut an die zu schützende Applikation angepasst ist. Eine solche Policy lässt sich auf unterschiedliche Weise erstellen. Auch können unter Umständen mehrere sich ergänzende Schutzmechanismen in einer Policy parallel verwendet werden.
Policies, Black- und Whitelists
Die Blacklists der Hersteller müssen lediglich aktiviert werden, um wirksam zu werden. Anspruchsvoller ist die Erstellung von Whitelists, da diese genau an die jeweilige Applikation und die dort verwendeten Parameter anzupassen sind. Bei vielen WAFs lässt sich ein Lernmodus aktivieren. Aus gültigen Anfragen werden dann die zulässigen Parameterwerte und URLs extrahiert und in die Policy übernommen.
Bei Web-Applikationen, die sich oft ändern, stößt dieses Verfahren allerdings schnell an seine Grenzen. Hier werden dann dynamisch erstellte Policies oder ein generisches Regelwerk angewendet, das die Parameter eher mit regulären Ausdrücken beschreibt, als konkrete Werte vorzugeben.
Durch geschickte Kombination von Blacklists und relativ generischen Whitelists lässt sich in der Praxis ein hohes Sicherheitsniveau erreichen und der Aufwand für die Pflege des Regelwerks dennoch gering halten.
Bei der Erstellung einer Policy handelt es sich meist um einen iterativen Prozess, bei dem anfangs noch Fehlalarme - so genannte False Positives - auftreten können. Dabei werden an sich legitime Anfragen als Angriff eingestuft und blockiert. Abhilfe schafft hier ein Feature, das sich "One-Click-Refinement" nennt: Aus dem Logviewer der WAF heraus können mit nur einem Mausklick Ausnahmen für solche Requests erstellt werden.
Eine weitere Hilfe zur Erkennung und Behebung von False Positives ist ein passiver Betriebsmodus, der in der ersten Zeit der Inbetriebnahme eingeschaltet werden kann. In diesem Modus wird nicht blockiert, sondern nur ein Eintrag im Logfile generiert.
WAF-Marktübersicht
In der Entwicklung des WAF-Markts lässt sich seit einiger Zeit ein Trend beobachten: Kleinere hochspezialisierte Anbieter von WAF-Lösungen werden von den großen Playern übernommen. Die akquirierten WAF-Lösungen werden dann in vorhandene und etablierte Plattformen integriert. Daraus ergibt sich auch der Trend zu Appliance-Lösungen. Lösungen auf Modulbasis oder reine Software-Lösungen spielen eine immer geringere Rolle. Einige gibt es aber noch.
|
Hersteller |
Art |
Herkunft/Plattform |
|
Hardware-Appliance |
Übernahme von Magnifire (2005); Integration in BigIP Plattform als ASM | |
|
Hardware-Appliance |
Übernahme von NetContinuum (2007) | |
|
Hardware-Appliance |
Übernahme von Teros (2005); Integration in NetScaler-Plattform | |
|
Hardware-Appliance |
Übernahme von Reactivity (2007); Integration als WAF-Modul im ACE-XML-Gateway | |
|
Hardware-Appliance |
Eigenentwicklung (seit 2002); Produktlinie rWeb, Integration in Apache Webserver | |
|
Hardware-Appliance |
Eigenentwicklung (seit 2001); Produktlinie SecureSphere | |
|
Soft-Appliance |
Übernahme von Visonys (2008); noch keine Integration | |
|
Modul |
Eigenentwicklung (seit 2006); Produktlinie Hyperguard; Modul für diverse Web-Server | |
|
Modul |
Eingeschränkte OpenSource-Lösung, Modul für Apache Webserver beziehungsweise Zeus-Loadbalancer | |
|
Hardware-Appliance |
Zwei Produktlinien: - Eigenentwicklung WebDefend - Kommerzielle Appliance basierend auf Übernahme von ModSecurity (2008) | |
|
Software |
Übernahme von KaVaDo (2005); Softwarelösung für die Plattformen Linux, Solaris und Windows |
Zu den größeren WAF-Herstellern zählen etwa F5, Citrix und Barracuda, die auf ihren etablierten Plattformen Features wie SSL-Beschleunigung und Load Balancing mit den WAF-Techniken kombinieren. Damit decken sie ein breites Spektrum an Anforderungen ab, die vor einer Web-Server-Farm gefragt sind. Allen gemein sind hier Hardware-Appliances, die in verschiedenen Ausbaustufen angeboten werden. Die WAF-Technik lässt sich dabei häufig durch einfaches Nachlizenzieren auf bereits vorhandenen Plattformen freischalten.
WAF als Appliance
Auch die spezialisierteren und kleineren Hersteller vertreiben ihre Lösung oft als Appliance, bieten daneben aber auch andere, sehr flexible Möglichkeiten an, ihre Produkte einzusetzen. Der einzige reine Appliance-Hersteller in diesem Umfeld ist Imperva mit "SecureSphere". Im Gegensatz dazu ist Protegrity als der einzige reine Softwarehersteller zu nennen, der mit "Defiance TMS" eine Stand-alone-Software für verschiedene Betriebssystem-Plattformen anbietet.
Zwischen diesen beiden Playern gibt es eine Reihe von Herstellern, die WAF-Technik neben einer vorkonfigurierten Appliance als Modul für verschiedene Web-Server anbieten. Art of Defence hat Plug-ins für Apache beziehungsweise Microsofts IIS oder ISA Server im Programm, lässt sich aber auch auf Plattformen wie dem "ZEUS Loadbalancer" oder der "GeNUScreen Firewall" einsetzen. Breach wiederum offeriert neben seinen beiden Appliance-Serien kommerziellen Support für "ModSecurity", dessen Hauptentwickler das Unternehmen letztes Jahr angestellt hat. Sehr flexibel ist „rWeb“ von DenyAll, das sich auf Hardware verschiedenster Hersteller einsetzen lässt - unter anderem als Modul für die Blade-Plattform von Crossbeam.
Immer mehr Hersteller entdecken zudem die Möglichkeit, ihre WAF als virtuelle Maschine für VMWares ESX Server anzubieten. Als Beispiel wären hier Phion mit "Visonys Airlock", das als Image für physische Hardware sowie als VMware-Image verfügbar ist, und Art of Defence zu nennen, das ebenfalls ein Image für diese Plattform bereitstellt. Offen bleibt hier natürlich, inwiefern eine virtualisierte Plattform mit ihren Angriffspunkten die richtige Umgebung für eine Sicherheitsinstanz wie eine Firewall darstellt.
Die Stolpersteine
So komplex Integration und Betrieb einer WAF zunächst erscheinen mögen, hält sich der Aufwand doch erfreulich in Grenzen - wenn man einige Grundsätze beachtet.
Nach der Entscheidung, ob die WAF als Bridge oder Reverse Proxy integriert wird, gilt es, eine hinreichend lange Testphase einzuplanen, in der die Policy erstellt und optimiert wird. In dieser Phase kommt es darauf an, die richtige Balance zwischen erreichbarem Sicherheitsniveau und vertretbarem Administrationsaufwand zu finden. Das erfordert sicher einige Erfahrung. Wird diese Aufgabe sorgfältig erledigt, verläuft der Übergang vom Test- zum Produktionsbetrieb jedoch ohne nennenswerte Probleme.
In der Regel wird die WAF als "Firewall" organisatorisch der für das Netz zuständigen Administratorengruppe zugeordnet. Der Betrieb der WAF stellt dieses Umfeld vor nicht allzu große Herausforderungen, da für den Betrieb einer WAF - entgegen der Ausrede mancher Administratoren - keine Softwareentwicklungskenntnisse nötig sind. Grundkenntnisse in Sachen http oder zur Schreibweise von URLs sind jedoch erforderlich.
Fazit
Die Auswahl und die anschließende Integration einer WAF sind keine alltäglichen Aufgaben. Wurden diese Anfangshürden jedoch überwunden, hat sich die Sicherheit der Web-Applikationen um ein Vielfaches verbessert - ohne dass sich der Administrationsaufwand in gleichem Maße erhöht.
Nicht zuletzt ist dies auch ein positives Signal für den potenziellen Anwender oder Kunden: Hier wird das Thema Sicherheit verantwortungsvoll behandelt und proaktiv umgesetzt. (ala)
Diesen Beitrag haben wir von unserer Schwesterpublikation ComputerWoche übernommen.