WAF oder Web Application Firewall ist ein toller Marketing-Name, der eine Technologie beschreibt, die schon lange vor der Erfindung des Begriffs existiert hat. Bevor die WAF als WAF bekannt war hiess sie Full Application Reverse Proxy und erlaubte schon damals das Forwarding, Inspecting und Sanitizing (oder Blocking) von Protocol Requests auf einem Application Server.

Einführung

Server sind meistens sehr wichtige Assets oder in kritischen Zonen positioniert und haben daher eine zusätzliche Schutzschicht. Aber Achtung: Eine WAF ist kein magisches Ding, das alle Ihre Probleme lösen wird. Bei der Veröffentlichung von We Applications sollten Sie daher auf folgende Sicherheitsregeln achten:

• Integrieren Sie ein Threat Risk Model wenn Sie Applications designen, wie zum Beispiel das OWASP Risk Model
• Der Code von veröffentlichten Applications sollte stets einem Review unterzogen werden.
• Ebenso sollte das Implementation Design (Interfaces, Application Communication et cetera) immer einem Review unterzogen werden.
• Middleware (Java, SQL, .Net, . . .) muss gesichert sein
• Das unter der Applikation liegende Betriebssystem muss gesichert sein.
• Die Autorisation und die Authentifikation im gesamten Framework muss einem Review unterzigen werden.
• Die Applikation vor der Veröffentlichung mit den Top Ten Vulnerabi-lities der OWASP abgleichen.
• Die Applikationsumgebung muss vor der Veröffentlichung einem Penetration Test unterzogen werden.
• Setzen Sie ein Anomaly Detection System ein, das Ihnen hilft, wenn die Dinge anfangen, schief zu gehen.
• Und zum Schluss: Vergessen Sie nicht, Logs schlau einzusetzen und die Informationen aus den Logs sicher aufzubewahren. Wenn Dinge schiefgehen, sind diese Logs von unschätzbarem Wert.

Die Implementation einer WAF in einer fertig designten Security measure ergibt Sinn wenn die obigen Kriterien alle erfüllt sind, da sie eine zusätzliche Schicht der Verteidigung darstellt. Die Erfahrung hat uns gezeigt, dass es nie zu viele Sicherheitsmassnahmen gibt, wenn es um Web Application Security geht.

Warum sollte eine WAF benutzt werden?

Im Normalfall empfiehlt es sich, eine WAF-Instanz im System aufzubauen, wenn mindestens eines der folgenden Kriterien – oder auch mehrere – in Bezug auf Web Applications zutrifft:

• Closed Source und keine Möglichkeit, den Source Code einzusehen
• Vulnerabilites, die nicht behoben oder im System mitigiert werden können
• Zu alt, um noch gepatcht zu werden.
• Zu kritisch, um gepatcht zu werden
• Zu komplex, um effizient gesichert werden zu können.
• Authentifikation/Autorisation die nicht auf dem System vorhanden ist.

Vielleicht finden Sie für Ihr Unternehmen einen weiteren kritischen Faktor, aber die obigen Punkte geben ein sicheres Grundgerüst für die Suche nach weiteren Faktoren. Virtual Patching ist ein Begriff, der in solchen Fällen genutzt wird, um eines der Hauptfeatures der WAF zu beschreiben: Das Feature erlaubt es, virtuelle Patches auf eine virtuelle Webapplikation anzuwenden und somit die Attacke zu verhinder bevor sie auf dem Application Proxy Gateway stattfinden kann.

Das Argument kann gemacht werden, dass eine solche Attacke das Gateway selbst betreffen kann (wir haben stets ein Auge auf das Application Protocol, nicht wahr?) und ja, Sie haben recht: Das Leben mit einer WAF ist ein gefährliches Leben.

Die Konfiguration einer WAF und die Einstellungen der kleinen Details darf auf keinen Fall unterschätzt werden. Darum habe ich zu Beginn dieses Kapitels erwähnt, dass ein WAF keine magische Wunderwaffe ist, die alles für Sie erledigen wird. Das wird auch immer so bleiben, denn Sie sollten immer daran denken: Sicherheit ist kein statisches Objekt. Sie ist ein steter Prozess, der wohl niemals enden wird.

Blacklisting vs. Whitelisting

Bei WAFs müssen wir zwischen zwei Hauptkategorien des Modus Operandi unterscheiden. Es gibt da zwei Herangehensweisen: Die Blacklist und die Whitelist, auch als positives und negatives Security Modell bekannt.

Die Blacklist-Methode versucht, alle schlechten Dinge basierend auf der Blacklist, die Sie selbst erstellen oder konfiguriert haben, zu blockieren. Die Whitelist-Methode verucht, eine Baseline von erlaubten Aktionen zu definieren, die auf die Web Application zutreffen.

Wie Sie vielleicht schon erkannt haben, kann eine WAF auch eine Mischung dieser zwei Herangehensweisen verfolgen, damit die folgenden Punkte erfüllt werden.

• Schutz vor den Top10 OWASP Vulnerabilities
• Nur wenige False Positives ausgeben
• Keine False Negatives
• Schutz vor Brute Force Attacken
• Schutz vor Cross Site Scripting, SQL Injection, CSRF und File Inclusions
• Merkwürdige Zeichen blockieren
• Blockierung von merkwürdigen Requests
• HTTP und XML Requests müssen gesäubert werden

Um dies zu erreichen gibt es einige gute kommerzielle Lösungen, wie zum Beispiel Airlock. Diese erfüllen beinahe alle Anforderungen, aber ich würde gerne das Open Source Projekt NAXSI näher beleuchten.

Das NAXSI-Projekt

Das NAXSI-Projekt ist weit weniger bekannt als das ModSecurity Open Source Projekt aber hat dennoch einen hochinteressanten Zugang zur Sicherheit und zu Features. NAXSI nutzt die kleine und effiziente Reverse Proxy Engine des Nginx Web Servers anstelle der Apache Engine, die von ModSecurity verwendet wird. Aus Blick eines Security-Experten ist das auch weniger Code.

• Die Haupt-Features von NAXSI:
• Schutz vor Cross Site Scripting, SQL Injection, CSRF und File Inclusions
• Schnelle Engine
• Relativ einfache Konfiguration
• Prüfung von GET/POST Requests
• Prüfung von HTTP Headers und Cookies
• Verbot von gefählichen Symbolen und SQL-Keywords
• Erlaubt die Whitelist-Methode bei der Konfiguration einer Web Application Baseline.
• Kann sowohl im Learn- wie auch im Production-Mode laufen.
• Nutzt keine bekannten Attack-Signaturen.

Installation

Installieren wir doch NAXSI auf einem Ubuntu-Server 12.04 LTS. Wir könnten die Software auch nach den Nginx Prerequisites installeren. Nach der kurzen Installation mit openssh, installieren wir NAXSI mit

sudo apt-get install nginx-naxsi

Erste Konfiguration In der nginx-Konfigurations-Datei /etc/nginx/nginx.conf muss die folgende Zeile unkommentiert werden, damit die grundlegenden Rulesets aktiviert werden:

##
# nginx-naxsi config
##
# Uncomment it if you installed nginx-naxsi
##
include /etc/nginx/naxsi_core.rules;

Beachten Sie, dass diese Datei kein Attack Signature Repositiry ist, sondern lediglich ein Score Rules Set. Konfigurieren wir NAXSI also für unsere Website www.scip.ch. Damit wir das tun können, müssen wir die Nginx Konfigurationsdatei in /etc/nginx/sites-enabled/ default bearbeiten und die folgenden Einträge im Server-Kontext hinzufügen:

server {
        proxy_set_header Proxy-Connection “”;    
        listen   80;


        location / {
                # put your website IP here
                proxy_pass http://80.74.141.2/;

                # put your website FQDN here
                proxy_set_header Host www.scip.ch;

                # Uncomment to enable naxsi on this location
                include /etc/nginx/naxsi.rules;
                }

        # Only for nginx-naxsi : process denied requests
        location /RequestDenied {
                # For example, return an HTTP error code
                return 418;
                }
        }

Damit sollten Sie in der Lage sein, den nginx-Service zu starten, der NAXSI mit dem folgenden Befehl starten wird:

sudo service nginx start

Stellen Sie sicher, dass sie ein wachsames Auge in auf Fehlemeldungen in der Konsole oder dem Error-Log in /var/log/nginx/error.log werfen. Verifizieren Sie mit sudo netstat –antup, dass der nginx-Daemon den konfigurierten Port (in unserem Falle ist das tcp/80) öffnet. Der Output sollte so aussehen:

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address    Foreign Address   State       PID/Program name
tcp        0      0 0.0.0.0:80       0.0.0.0:*         LISTEN      9865/nginx
tcp        0      0 0.0.0.0:22       0.0.0.0:*         LISTEN      8484/sshd
tcp        0      0 127.0.0.1:6010   0.0.0.0:*         LISTEN      9627/0
tcp        0      0 127.0.0.1:6011   0.0.0.0:*         LISTEN      9062/1
tcp        0     32 x.y.z.52:22      x.y.z.36:49749    ESTABLISHED 9046/sshd: anco
udp        0      0 0.0.0.0:68       0.0.0.0:*                     649/dhclient3

Um zu überprüfen, ob die Konfiguration funktioniert, starten Sie eine Browser Session und rufen Sie die IP-Adresse ihres Testservers auf (x.y.z.52:80). Sie sollten die in der obigen Config-File konfigurierte Website (www.scip.ch) sehen. Um weiter vorgehen zu können, müssen Sie sicherstellen, dass alle Web Requests per Proxy über die nginx-NAXSIWAF geleitet werden. Um das zu tun können Sie entweder die browsereigenen Einstellungen verwenden, oder die IP-Adresse der Test-Website in der System hostfile fälschen. Ich bevorzuge letztere Methode.

x.y.z.52     www.scip.ch

Hier sind die Locations der host-Files. Sie benötigen Admin-Rechte um die Änderungen speichern zu können:

Nun können wir auf unsere Website www.scip.ch browsen und sicher sein, dass unsere Test-NAXSI-WAF den Inhalt untersuchen wird. Aber denken Sie stets daran: Die WAF ist im Learning Mode. Sie wird nur in den nginx Error Logs (/var/log/nginx/error.log) Fehler ausgeben und keine Bad Scored Requests blockieren.

Wie es funktioniert

Die naxsi_core.rules sind dafür verantwortlich, den HTTP-Inputs Scores hinzuzufügen und das sieht so aus:

MainRule "str:;" "msg:; in stuff" "mz:BODY|URL|ARGS" "s:$SQL:4" id:1008;
#
MainRule "str:<" "msg:html open tag" "mz:ARGS|URL|BODY|$HEADERS_VAR:Cookie" "s:$XSS:8" id:1302;
#
MainRule "str:&#" "msg: utf7/8 encoding" "mz:ARGS|BODY|URL|$HEADERS_VAR:Cookie" "s:$EVADE:4" id:1400;
#
MainRule "rx:.ph*|.asp*" "msg:asp/php file upload!" "mz:FILE_EXT" "s:$UPLOAD:8" id:1500;

Diese Datei verwendet die logische Konfiguration zum Scoring des Inputs. Das Resultat wird in /etc/nginx/naxsi.rules verwendet, um zu entscheiden ob ein solcher Input erlaubt ist oder nicht. Das Format ist einfach:

• Definition der Suche: string (str:) oder regular expression (rx:)
• Definition der Message für die Logfile (msg:)
• Kategorisierung der Rule (s:)
• Identifikation der Rule (id:)
  Definition des Suchortes (mz:). Die untenstehende Tabelle liefert einen kleinen Überblick

Schauen wir uns nun die zweite NAXSI Config-File in /etc/nginx/ naxsi.rules an, wo das Hauptverhalten von NAXSI definiert wird. Die Datei sieht so aus:

# config mode section
LearningMode;
SecRulesEnabled;
#SecRulesDisabled;
DeniedUrl "/RequestDenied";
#
# check rules section
CheckRule "$SQL >= 8" BLOCK;
CheckRule "$RFI >= 8" BLOCK;
CheckRule "$TRAVERSAL >= 4" BLOCK;
CheckRule "$EVADE >= 4" BLOCK;
CheckRule "$XSS >= 8" BLOCK;

Eine Erklärung des Inhalts:

• LearningMode aktiviert den Learning Mode. In diesem Modus sind Requests nicht blockiert und Whitelists können generiert werden
• SecRulesEnabled oder SecRulesDisabled aktiviert oder deaktiviert NAXSI für die Location oder die Section.
• DeniedURL leitet die URL für blockierte Requests weiter. Dies kann ein
  HTTP-Error-Code wie 4xx sein, oder die Umleitung auf eine HTMLSite, die mit Code versehen ist, der uns hilft, False Positives zu verfolgen.
• CheckRule: Der obige Score wird hier basierend auf den Category Check Scores evaluiert. Wenn ein Request einen Score in den naxsi. core.rules erreicht, dann wird dieser aufgezeichnet und der jeweiligen Kategorie hinzugefügt (SQL, XSS, EVADE, . . .), wenn der Overall Score für die Kategorien erreicht wird (8 in SQL als default) und der Input als bad bezeichnet wird.

Wenn Sie eine Whitelist – also das positive Sicherheits-Modell) verwenden, werden Sie die Whitelist-Einträge (BasicRule-Statements) in folgender Config-Datei finden.

# Whitelist '|', as it's used on the /report/ page, in argument 'd'
BasicRule wl:1005 "mz:$URL:/report/|$ARGS_VAR:d";
# Whitelist ',' on URL zone as it's massively used for URL rewritting !
BasicRule wl:1008 "mz:URL";

Der obige Eintrag wird dazu führe, dass ein Teil der Checkrule in naxsi_ core.rules deaktiviert wird, was ein spezifisches Verhalten erlaubt und False Positives eliminiert. BasicRule könnte mehr oder weniger spezifisch sein, je nach Ihre Security-Bedürfnissen.

Informationssammlung

An diesem Punkt haben wir unsere Testinstallation so weit, dass sie den HTTP-Flow inspiziert und verdächtige wie auch schädliche Dinge in /var/log/nginx/error.log meldet. Werfen wir also einen Blick auf die Art und Weise, wie NAXSI Fehler dokumentiert:

> error.log <
2012/11/30 04:57:55 [error] 9866#0: *47 NAXSI_FMT: ip=x.y.z.36&server=x.y.z.52&uri=/testmiztot&total_processed=8589934625&total_blocked=679029381853280060&zone0=URL&id0=1999&var_name0=, client:x.y.z.36, server: localhost, request: "GET /testmiztot HTTP/1.1", host: "x.y.z.52"

Dies ist eine spezielle Error-Message. Sie wurde auf einem speziellen HTTP URL GET-Request generiert und es handelt sich nicht un einen schlimmen Bad Request. Um die Funktionalität der WAF zu testen, habe ich diese Regel in /etc/nginx/naxsi_core.rules festgehalten:

MainRule 	"str:testmiztot" 	"msg:foobar 	test 	pattern" 	"mz:URL" 
"s:$SQL:42" id:1999;

Diese Rule wird immer dann ausgelöst wenn der testmiztot-String in der Adresse (mz:URL) des HTTP GET-Requests festgestellt wird und in der SQL Kategorie mit 42 bewertet wird (s:$SQL:42). Das wird dann als Bad Request bewertet werden, da das Limit der SQL-Kategorie bei 8 liegt. Der msg:-Text wird im Learning Mode Log angzeigt und dazu verwendet, die Whitelist-Baseline zu generieren.

Zusammenfassung

NAXSI ist Open Source, liefert hohe Performance, muss wenig gewartet warden und nutzt die sehr gute Nginx Reverse-Proxy-Engine. Dennoch: NAXSI ist jung und hat noch viele bekannte Bugs, die allesamt auf der offiziellen Website des Projekts eingesehen werden können. Daher: Testen Sie es und stellen Sie ohne Zweifel fest, ob NAXSI in Ihrem Unternehmen nützlich eingesetzt werden kann.

Über den Autor

Andrea Covello ist seit den 1990er Jahren im Bereich der Informationssicherheit tätig. Seine Schwerpunkte liegen traditionell im Engineering, wobei er als Spezialist im Bereich Windows-Sicherheit, Firewalling und Virtualisierung gilt.