NAXSI est généralement considéré comme un « modèle positif de Pare-feu applicatif ». C’est un WAF (Web Application Firewall), open-source, offrant des performances élevées et une faible maintenance des règles de Pare-feu applicatif pour le plus célèbre des reverse proxy : NGINX.
NAXSI est un acronyme qui signifie Nginx Anti Xss & SQL Injection. Son but ultime est d’empêcher tout attaquant de tirer parti des vulnérabilités sur n’importe quel site ou application, quelle que soit la langue utilisée pour le développer. Nous aimons également présenter NAXSI comme un outil protégeant contre les menaces du TOP 10 OWASP.

Pourquoi un pare-feu d’applications Web

Une application Web a presque toujours une part de personnalisation. Même quand elle est basée sur un CMS, des modules à régler et à personnaliser entrent souvent en jeu, donc pour résumer :

Une application Web personnalisée :                                                                         Une application informatique classique :
Picture2

Dès lors que l’application est personnalisée et paramétrée, vous ne pouvez pas vous protéger contre les problèmes de sécurité de manière générale et automatique, (comme vous pouvez le faire pour la plupart des services techniques qui reposent sur des correctifs et des mises à jour de sécurité). Vous devez en effet prendre soin, vous-même, des questions de sécurité.

NAXSI, encore un autre pare-feu applicatif ?

NAXSI est un module de Nginx en charge de l’exécution du pare-feu applicatif. Cependant, même si la plupart des pare-feu applicatifs reposent sur des signatures plutôt complexes (souvent sous la forme d’expressions classiques), cela peut devenir très difficile à lire et à maintenir. Exemple de mod_security :

"(?:\b(?:(?:type\b\W*?\b(?:text\b\W*?\b(?:j(?:ava)?|ecma|vb)|application\b\W*?\bx-(?:java|vb)) \

script|c(?:opyparentfolder|reatetextrange)|get(?:special|parent)folder|iframe\b.{0,100}?\bsrc)\b| \

on(?:(?:mo(?:use(?:o(?:ver|ut)|down|move|up)|ve)|key(?:press|down|up)|c(?:hange|lick)| \

s(?:elec|ubmi)t|(?:un)?load|dragdrop|resize|focus|blur)\b\W*?=|abort\b)|(?:l(?:owsrc\b\W*?\b \

(?:(?:java|vb)script|shell|http)|ivescript)|(?:href|url)\b\W*?\b(?:(?:java|vb)script|shell)| \

background-image|mocha):|s(?:(?:tyle\b\W*=.*\bexpression\b\W*|ettimeout\b\W*?)\(|rc\b\W*?\b(?:(?:java|vb) \

script|shell|http):)|a(?:ctivexobject\b|lert\b\W*?\(|sfunction:))| \

<(?:(?:body\b.*?\b(?:backgroun|onloa)d|input\b.*?\btype\b\W*?\bimage)\b| ?(?:(?:script|meta)\b|iframe)| \

!\[cdata\[)|(?:\.(?:(?:execscrip|addimpor)t|(?:fromcharcod|cooki)e|innerhtml)|\@import)\b)"

NAXSI va plutôt se baser sur des règles simples, mettant principalement l’accent sur les expressions et caractères « dangereux », tels que <> ‘() [] {}; … .. Quand l’un de ces caractères ou expressions est en jeu dans une requête HTTP entrante, NAXSI augmentera le « score » de cette requête. Et, si et seulement si ce score de la requête atteint une des limites configurées par l’utilisateur (suspicion de SQL injection, XSS, TRAVERSAL, …), NAXSI mettra en place une action sur la requête entrante, action qui aura été définie par l’administrateur. Par exemple : bloquer la requête.
Ainsi, au lieu de limiter l’accès aux signatures d’attaques connues et d’autoriser toutes les autres requêtes (fonctionnement en listes noires), NAXSI bloque par défaut toutes les traces et suspicions d’attaques en se basant sur les caractères mentionnés ci-dessus qui font souvent partie du code injecté par les attaquants dans les requêtes web (liste blanche).

Forces et faiblesses de l’approche NAXSI

Points forts:

  • Bonne résistance contre les attaques inconnues / brouillées
  • Bonnes performances (faible empreinte mémoire, temps de traitement minimal)
  • Pas besoin de mises à jour des « signatures d’attaques »
  • Processus d’apprentissage fortement assisté
  • Gestion/Administration exigeant moins de connaissances techniques que la plupart des WAF

Faiblesses:

  • Apprentissage initial nécessaire pour une protection optimale
  • Applications en évolution rapide, nécessite une coordination avec les versions
  • Pas d’ «intelligence» propre de l’outil, inadaptée aux cas spécifiques

Comme vous pouvez le voir, la plus grosse « faiblesse » de NAXSI est son besoin d’apprentissage et de configuration. Cette approche utilisée est très efficace, mais sujettes à des faux positifs (interception de requêtes légitimes). Cependant, ne vous inquiétez pas, NAXSI est fourni avec l’outil « NXTOOL » pour vous aider :

CaptureNXTOOL a plusieurs buts

  1. Injection des événements NAXSI dans une base de données ElasticSearch (ES) : Ceci est à la fois utile pour le processus d’apprentissage et la visualisation des événements entrants.
  2. Génération d’une liste blanche : NXTOOL tentera de générer des listes blanches appropriées à votre application, de sorte que vous n’ayez pas à le faire manuellement.
  3. Rapports : NXTOOL, via des lignes de commande, vous permet d’obtenir rapidement une vue d’ensemble des exceptions qui se produisent, et vous donne des orientations sur quoi vous concentrer pendant le processus d’apprentissage.

Ici, quand nous parlons d’ « apprentissage», nous nous référons au fait d’identifier les « faux positifs » et de les autoriser. Si nous ne réalisons pas cette phase, nous prenons le risque de bloquer des requêtes d’utilisateurs légitimes de l’application. D’autre part, si nous n’appliquons pas cette phase d’apprentissage et que nous autorisons « trop de requête » sans filtrage, nous risquons d’offrir une fenêtre d’exploitation pour un attaquant externe. L’apprentissage est en effet une tâche cruciale.

Compte-rendu

Merci à ElasticSearch et Kibana, grâce à qui il est assez trivial d’obtenir une vue en temps réel de ce qui se passe. Ceci est extrêmement utile pour l’équipe des administrateurs / sécurité, car cela montre si une attaque se produit, ou si un nouveau site web est apparu pour lequel l’apprentissage doit être fait.

kibana-blur

Génération liste blanche et apprentissage

Il y a 3 approches possibles de l’apprentissage :

  • Apprentissage exhaustif et personnalisé : fournira un filtrage plus précis et juste
  • Apprentissage basé sur des modèles : selon votre application, vous pouvez compter sur l’un des modèles existants adaptés à votre application
  • Liste noire uniquement : En se basant sur le jeu de règles de tiers, vous pouvez décider d’opter pour l’approche de la liste noire. Cela vous permet d’outrepasser la plupart du temps la phase d’apprentissage. Toutefois, il ne fournit pas la meilleure protection, car NAXSI ne pourra bloquer que les requêtes comprenant une menace « connue » et qu’il a référencé.

 L’apprentissage exhaustif

Couvrir tous les détails de l’apprentissage exhaustif pourrait faire l’objet d’un article à part entière. Voici donc un rapide résumé du fonctionnement de NXTOOL :
NXTOOL proposera des listes blanches basées sur les données présentes dans ElasticSearch. Il fournira ces listes blanches sur la base de plusieurs facteurs possibles :

  • Statistiques : Si plus de 20% de vos utilisateurs ont le même facteur déclenchant, il s’agit probablement d’un faux positif
  • Comportement connu : Certaines applications spécifiques ont un comportement prévisible et NXTOOL saura les identifier. Il suggèrera de les associer aux listes blanches (par exemple : les cookies de Google Analytics).

L’apprentissage exhaustif se fait via NXTOOL en ligne de commande (voir la page de github wiki pour plus de détails) :
$ python nxtool.py -c nxapi.json -s www.xxx.fr -f

#Rule (1310,1311) : ] [ in stuff

#total hits 58

#'peers': u'x.x.x.x'

#'peers': u'y.y.y.y'

...

#'uri': u'/js/index.php'

#'var_name': u'name[]'

#'var_name': u'street[]'

...

# success : rule_ip is 345

# success : global_rule_ip_ratio is 17.0

...

BasicRule wl:1310,1311 "mz:$URL:/js/index.php|BODY|NAME";

L’approche Liste Noire

L’approche Liste Noire est l’exact opposé de l’apprentissage exhaustif. Au lieu de permettre explicitement les « anomalies » choisies, nous allons interdire spécifiquement et uniquement les demandes correspondantes à des schémas d’attaque connus.

Doxi-règles (les listes noires de NAXSI) sont édités et gérés par un tiers (mare-système), et peuvent être trouvé ici : https://www.mare-system.de/doxi/

Il est livré avec un outil CLI qui permet de mettre à jour facilement les signatures et de créer des rapports.

En conclusion

shema naxsi_2NAXSI est donc un WAF open-source, basé sur une approche liste blanche, permettant de filtrer les requêtes utilisateurs au niveau du reverse proxy Nginx afin de protéger les sites web et applications des éventuelles attaques pirates.

Très simple à mettre en place, cet outil devient très performant dès lors que la phase d’apprentissage a été correctement menée. Il est alors capable de protéger votre application contre les menaces du TOP 10 OWASP et notamment contre les attaques de type SQL injection, XSS, TRAVERSAL, …

Cet outil très performant est l’une des 20 couches de protection inclues dans l’offre CerberHost : hébergement de haute sécurité proposée par NBS System.

Thibault Koechlin
Thibault est le RSSI de NBS System et encadre l’équipe Sécurité de l’entreprise. Spécialiste des prestations de sécurité, qu’il effectue toujours pour nos clients, il est également créateur de NAXSI, un pare-feu applicatif open source, et de CerberHost, une solution de Cloud sécurisé unique sur le marché.