Lesen Sie Teil 1 der Artikelserie hier!
Einzelmaßnahmen bieten keinen vollständigen Schutz gegen unerwünschte Angriffe auf unternehmenskritische Daten. Werden beispielsweise ausschließlich Anwendungen abgesichert, sind immer noch direkte Angriffe gegen die Infrastruktur möglich. Umgekehrt gilt das auch für eine reine Härtung der Infrastruktur, wie sie in der Vergangenheit in vielen Unternehmen praktiziert wurde. Sie lässt den Angriffskanal Webanwendung als nicht zu unterschätzende Sicherheitslücke völlig unberücksichtigt. Es ist ersichtlich, dass nur durch eine ganzheitliche Betrachtung ein angemessener Schutzgrad für ein IT-System erzielt werden kann. Im ersten Teil des Artikels wurden Ursachen für Sicherheitslücken in Webanwendungen sowie konkrete Angriffsvektoren beispielhaft vorgestellt. Darüber hinaus haben die Autoren einige organisatorische Maßnahmen zur Optimierung des Entwicklungsprozesses in Bezug auf IT-Sicherheit diskutiert. Neben Tipps zur Absicherung des Quellcodes einer Webanwendung wurden einige fertige Softwarelösungen vorgestellt und deren wesentliche Eigenschaften erläutert. Der zweite Teil des Artikels wird tiefer in die technischen Details des Open-Source-Produkts WebCastellum einsteigen und sich mit Installation und Konfiguration der Web Application Firewall (WAF) befassen. Außerdem werden einige Messungen zum Einfluss der WAF auf das Antwortzeitverhalten einer Anwendung diskutiert. Ausgehend von ihren praktischen Erfahrungen nehmen die Autoren eine kritische Bewertung vor und geben einige Empfehlungen zum Vorgehen.
Integrierter Schutzschild
Die hier betrachtete WAF WebCastellum (siehe auch hier) wird im Gegensatz zu anderen erhältlichen Produkten nicht im Perimeterbereich einer IT-Infrastruktur, sondern direkt bei der Anwendung im Klassenpfad betrieben. WebCastellum ist vollständig in Java implementiert und ist für J2EE/JavaEE Versionen ab 1.4 verfügbar. Es wird in Form einer jar-Datei geliefert und benötigt zusätzlich ein Regel-Repository. WebCastellum nutzt ausschließlich das JavaSE- und JavaEE-API, darüber hinaus kommen keinerlei Fremdbibliotheken zum Einsatz, um damit verbundene Sicherheitsrisiken auszuschließen. Es wird in das Webarchiv einer Anwendung integriert und als vorgeschalteter Servlet-Filter konfiguriert. Das Regel-Repository wird auf Dateiebene mitgeliefert und enthält bereits sehr umfangreiche Regeldefinitionen, die für die meisten Anwendungen ohne große Anpassungen verwendet werden können. Die Regeldateien können innerhalb des Webarchivs als Bestandteil des Klassenpfades abgelegt und anwendungsbezogen referenziert werden. Damit ist eine Anwendung atomar abgesichert. Alternativ lassen sich die Regeln jedoch auch im Dateisystem des Application Servers, in einer zentralen Datenbank oder einem LDAP-Verzeichnis verwalten. In Unternehmen mit großer Anwendungslandschaft ist es oftmals sinnvoll, ein zentrales Regel-Repository in einer Datenbank vorzuhalten. WebCastellum enthält hierfür eine Möglichkeit, vorhandene Regel-Files automatisch in eine Datenbanktabelle zu überführen. Durch Verwaltung der Regeln in einer zentralen Datenbank lassen sich sowohl gemeinsame Regeln für mehrere Anwendungen als auch spezielle Regeln für einzelne Anwendungen definieren.
Sobald die Anwendung inklusive WebCastellum auf dem Webcontainer ausgeliefert wurde, erfolgt eine Überwachung sämtlicher Anfragen und Antworten. Da Angriffe gegen eine Webanwendung oftmals durch eine Enkodierung von URL-Bestandteilen verschleiert werden, wendet WebCastellum automatisch alle relevanten Dekodierungspermutationen auf die Anfrage an und normalisiert diese zur Prüfung. Sämtliche Regeln können daher in normalisierter, lesbarer Form definiert werden. Anschließend zerlegt die WAF eine eingehende Anfrage des Browsers in seine Bestandteile, z. B. URL, Parameter, Header, Cookies, und wendet auf einzelne oder mehrere Bestandteile entsprechend definierte Regeln an. Dies steuert der Regelmanager, indem er sich prophylaktischer und abwehrender Algorithmen bedient. Im Falle eines Angriffsversuchs wird dieser in einer Attack-Log-Datei dokumentiert sowie je nach Einstellung die Sitzung des Angreifers augenblicklich terminiert. Der HTTP-Antwortcode für einen solchen Fall ist einstellbar. Neben der Sitzungsterminierung lässt sich zusätzlich eine Client-IP temporär für ein definiertes Zeitintervall blockieren, der Angreifer wird also ausgesperrt. Das geschieht nach Überschreitung eines einstellbaren Schwellwerts für erkannte Angriffsversuche eines Clients.
Um die Schritte nachzuvollziehen, die zu einem Angriff führten, arbeitet WebCastellum mit einem Ringspeicher. Kontinuierlich werden Informationen über eine konfigurierbare Anzahl aufeinanderfolgender Anfragen im Speicher vorgehalten. Im Fall eines erkannten Angriffsversuches werden alle Informationen der bösartigen Anfrage sowie einer entsprechenden Anzahl von Anfragen vor und nach dem Angriff in der Attack-Log-Datei ausgegeben. Die Detailliertheit der Angaben ermöglicht eine genaue forensische Analyse. Abbildung 1 gibt einen Überblick über die Funktionsweise der WAF. WebCastellum ist unter der "Eclipse Public License" auf der Seite http://www.webcastellum.org/download.html quelloffen verfügbar.
