NAXSI: Eine Open Source WAF

NAXSI

Eine Open Source WAF

Andrea Covello
von Andrea Covello
Lesezeit: 15 Minuten

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:

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:

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.

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.

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:

OSHost Configuration File
Windows %SYSTEMROOT%\system32\drivers\etc\hosts
Linux /etc/hosts

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:

mz entry Look in
URL URL path
ARGS HTTP argument
BODY HTML body entry
$HEADERS_VAR: HTTP header variable

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:

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

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.

Sie wollen die Sicherheit Ihrer Firewall prüfen?

Unsere Spezialisten kontaktieren Sie gern!

×
TIBER-EU Framework

TIBER-EU Framework

Dominik Altermatt

Vertrauen und KI

Vertrauen und KI

Marisa Tschopp

Datenverschlüsselung in der Cloud

Datenverschlüsselung in der Cloud

Tomaso Vasella

Cyber Threat Intelligence

Cyber Threat Intelligence

Marc Ruef

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv