Mit den Tipps und Workshops im ADMIN-Magazin 03/2013 sichern Administratoren ihre Webserver und Netze gegen Angriffe ab: gegen Abhören sensibler Informationen, ... (mehr)

Modi: Live vs. Learning

Naxsi kann in zwei Modi betrieben werden: Live und Learning ( Abbildung 3 ). Wie jede WAF oder IDS, die im Zweifel Anfragen blocken, muss Naxsi für die jeweilige Applikation angepasst werden. Man weiß aus Sysadmin-Sicht nie, mit welchen Schandtaten der Entwickler zu rechnen ist: So sind zwei KByte große Cookies, in denen Daten wild codiert gespeichert werden, keine Seltenheit und bringen selbst erfahrene WAF-Admins schnell an den Rand des Wahnsinns. Für diese Fälle gibt es den Lernmodus, der es erlaubt, hinter einer Htaccess-geschützten Test-Domain die Applikation komplett durchzutesten und aus den Abfragen und Events passende Whitelists zu generieren, die man dann im Live-Betrieb in eine scharfgeschaltete WAF einspeist.

Abbildung 3: Nur im Live-Modus blockiert Naxsi verdächtige Anfragen. Der Lernmodus hilft bei der Zusammenstellung von Regeln.

Im Lernmodus werden Anfragen zwar registriert, aber nicht geblockt. Da jede Anfrage legitim ist, können aus den False Positives Whitelists generiert werden, die im Live-Betrieb dafür sorgen, dass dort die False Positives nicht auftreten.

Wenn man Naxsi als Web Application Firewall vor Webapplikationen einsetzt, die einen hohen Grad an Agilität aufweisen und sich laufend in Funktion und Umfang ändern, muss man den Lernmodus und die daraus entstehenden Whitelists in den Deployment-Prozess integrieren.

Regeln

Die Naxsi-Regeln sind einfach im Aufbau, flexibel im Handling und um einiges einfacher strukturiert als etwa die Apache-Mod-Security- oder Snort-Rules. Die Regeln bestehen aus einem Designator, einem Suchpattern ( »str« oder »rx« ), einem Kurztext ( »msg« ), der Match Zone ( »mz« ), dem Score ( »s« ) und der Unique ID ( »id« ).

Als Suchpattern sind Strings und Regular Expressions erlaubt, wobei Strings aus Performance-Gründen im Allgemeinen zu bevorzugen sind. Match Zones kennzeichnen die Bereiche eines Requests, in denen Naxsi nach den definierten Pattern sucht. Match Zones sind kombinierbar und können über folgende Werte definiert werden:

  • »URL« : Prüft auf das Suchpattern in der URL (Server-Pfad).
  • »ARGS« : Sucht das Pattern in Request-Argumenten.
  • »FILE_EXT« : Testet den Dateianhang auf das Suchmuster.
  • »BODY« : Prüft im Body eines POST-Requests auf das Suchpattern; kann über »$BODY_VAR:VarName« weiter eingegrenzt werden.
  • »HEADERS« : Sucht das Suchpattern im Header eines Requests und kann weiter eingegrenzt werden: »$HEADERS_VAR:User-Agent« , »$HEADERS_VAR:Cookie« , »$HEADERS_VAR:Content-Type« , »$HEADERS_VAR:Connection« , »$HEADERS_VAR:Accept-Encoding« .

Der Score gibt an, mit welchem Wert das jeweilige Event bedacht wird. So lassen sich Signaturen erstellen, die für sich alleine noch nicht dazu führen, dass die Firewall die Verbindung blockert, sondern erst in der Summe mit anderen Events. Scores und Check Rules lassen sich frei konfigurieren und erweitern.

Listing 3 zeigt ein Beispiel für ein Naxsi-Regelset. Regel 1 in Zeile 1 prüft, ob die gegebene URL aufgerufen wird. Suchpattern ist ein String. Der UWA-Score wird um 8 erhöht, wenn die Regel zutrifft. Die Regel 2 testet, ob die gegebene Regular Expression im BODY eines POST-Requests auftritt. Regel 3 prüft, ob der Authorization-Header die gegebene Zeichenkette (Base64-encodiertes Passwort »admin« ) enthält, wenn die URL »/manager« aufgerufen. Regel 4 testet dann, ob der gegebene String (RFI) in den Request-Parametern, BODY oder im Cookie vorkommt, egal es ein ob GET- oder POST-Request ist. Schließlich prüft Regel 5, ob der gegebene String in URL, BODY, ARGS oder im Cookie vorkommt.

Listing 3

Naxsi-Regeln

 

Ähnliche Artikel

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023