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)

Core Ruleset

Naxsi bringt ein eigenes Core Ruleset mit, das generische Signaturen gegen SQL Injections (SQLi), Remote File Inclusions (RFI), Directory Traversal, Cross Site Scripting (XSS) und einige Evading-Tricks enthält und zuverlässig vor der Ausnutzung eventueller Schwachstellen schützt. Die Standardinstallation hat im Test beispielsweise alle Mod-Security-Bypasses von Trustwaves Mod-Security-Challenge erkannt und geblockt [11]. Das Core Ruleset, bestehend aus circa 50 Regeln, sollte immer geladen werden, auch wenn aus diesem Bereich die meisten False Positives zu erwarten sind.

Bei Webseiten mit hohem Interaktionspotenzial wird Naxsi anfänglich jede Menge False Positives erzeugen. Für diesen Fall gibt es die Möglichkeit des Whitelistings. Die Whitelists gelten jeweils Location-basiert, das heißt, man kann für unterschiedliche Bereiche oder Webapps auf einem Server jeweils eigene Konfigurationen pflegen. Die Whitelists lassen sich einfach in einer Datei speichern und dann via Include laden.

Whitelist-Regeln sind ähnlich wie die Detection-Regeln aufgebaut. Der Designator »BasicRule« ist vorgeschrieben, danach folgt die Rule-ID, für die die Ausnahme gelten soll, gefolgt von der Match Zone:

BasicRule wl:1000 "mz:$URL:/dontpanic/index.php|$ARGS_VAR:topic";
BasicRule wl:1005 "mz:$URL:/lib/exe/fetch.php|$ARGS_VAR:media";

Naxsi lässt sich auf Location-Level jeweils zu- oder abschalten, selbst der Parallelbetrieb von Lernmodus und Livemodus für verschiedene Locations ist möglich. Die Konfiguration von Naxsi geschieht in drei Schritten: Zuerst definiert der Administrator auf HTML-/Server-Level die zu ladenden Regelsätze. Im Location-Kontext wird die Firewall dann ein- und ausgeschaltet oder in den Lernmodus versetzt. Schließlich geben die Check Rules an, ab welchem aufsummierten Score-Wert die Firewall den Request blocken soll. Die einzelnen Konfigurationsanweisungen lassen sich in Dateien auslagern, sodass man am Ende zu einer modularen Konfiguration gelangt (Listing 4 bis 6).

Listing 4

learning-mode.rules

 

Listing 5

Check Rules

 

Listing 6

Naxsi-Konfiguration via Includes

 

Doxi Rules

Man muss nicht tatenlos zusehen, wenn die eigene Server-Infrastruktur Tag und Nacht durch Bots nach Lücken abgesucht wird. Aus diesem Grund wurden die Doxi Rules [12] für Naxsi entwickelt, die den Ansatz verfolgen, bekannte Angriffe zu blocken. Die Doxi-Regeln erkennen eine Vielzahl an Scans nach aktuellen oder älteren Lücken wie der Wordpress-TimThump-RFI [13] und bieten einen guten Schutz gegen Skriptkiddies und automatisierte Angriffstools.

Dazu wurden 200 Webserver-spezifische Regeln aus den Emerging-Threats-Rulesets in das Naxsi-Format konvertiert, die via Sourcecode Repository frei verfügbar sind. Angelehnt an Emerging Threats gibt es folgende Regelsätze: »web_server.rules« , »scanner.rules« , »app_server.rules« , »web_apps.rules« und »malware.rules« . Ähnlich wie bei Emerging Threats werden Signaturen eingepflegt, wenn neue Sicherheitslücken in populären Apps oder Servern auftreten, und dann über Naxsi-Mailingliste und das Doxi-Blog bekannt gegeben.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
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

Google+

Ausgabe /2019