NAXSI, un module de filtrage HTTP pour nginx

Posté par  (site web personnel) . Modéré par patrick_g. Licence CC By‑SA.
Étiquettes :
34
14
nov.
2011
Sécurité

Ma société travaille depuis plusieurs mois sur un projet de WAF, ou pare‐feu applicatif, articulé autour du serveur HTTP et proxy inverse nginx. Après une foule de tests et une épreuve du feu pour le moins tendue, la première version stable de NAXSI, c’est son nom, est disponible au téléchargement en code source et en paquet Debian.

NAXSI est sous licence GPL v2 et s’utilise conjointement avec nginx. Son principal but est de bloquer de manière efficace les attaques classiques de type injection SQL, Cross‐Site Scripting, Cross‐Site Request Forgery, ou encore inclusion de sources tierces locales ou distantes.

Au contraire des WAF déjà connus, NAXSI ne se base pas sur des signatures, mais plutôt sur la détection d’attaques connues en interceptant des caractères et autres chaînes suspectes dans les requêtes HTTP. Tel un système anti‐pourriel, NAXSI affecte un score à la requête et, lorsque ce dernier est trop élevé, le client est redirigé sur une page de type 503.

Malgré ses récents faits d’armes, NAXSI reste un projet jeune, et en tant que tel, nécessite plus de tests. Aussi, n’hésitez pas à lui donner sa chance, vos retours seront grandement appréciés !

Aller plus loin

  • # pfff

    Posté par  . Évalué à -10.

    Pourquoi vous l'avez pas fait en PHP ? Le C c'est trop 90' !

    • [^] # Re: pfff

      Posté par  . Évalué à -10.

      Je pense que c'est par ce qu'ils n'ont pas voulu que ça marche sur tous les linux, la preuve c'est qu'ils ne fournissent qu'un .deb donc ça ne marche que sur Debian en fait.

  • # téchnique ?

    Posté par  (site web personnel) . Évalué à 2.

    En gros, vous avez un système version spamassasin, et non à base de signature comme les anti-virus, ni un filtre baysien (probabiliste ?). J'ai tout compris ?

    Au fait pourquoi avoir codé ça en C, qui est le langage le plus piégeur d'un point de vue sécurité ?

    "La première sécurité est la liberté"

    • [^] # Re: téchnique ?

      Posté par  (site web personnel) . Évalué à 7.

      Je suppose que vu que nginx est principalement utilisé comme frontal dans des architectures haute disponibilité et à gros volume, la scalabilité et la rapidité d'exécution du filtre est primordial. Cela doit justifier l'usage d'un langage comme le C.

    • [^] # Re: téchnique ?

      Posté par  . Évalué à 10.

      Le C est rapide, c'est le premier facteur et le second c'est que NginX est en C. Il est possible de le faire en LUA à priori mais vu les débits considéré, le développeur à évité le scripting pour des raisons d'optimisation.

      Actuellement le footprint mémoire & cpu constaté est de moins de 2%. Le main dev, est un expert en sécurité et lead pentester depuis 6 ans à NBS, il a donc vu et développé plus d'un overflow et y a été sensible lors de son développement.

      Enfin, pour les règles, oui, le principe est assez proche de spam assassin, l'idée étant plus de faire de la whitelist que de la signature.

  • # PHP vs C

    Posté par  . Évalué à 9.

    Le PHP serait trop lent pour faire ce type de traitements sur des machines (les reverses proxy) qui ont des millions de pages à livrer à l'heure. Le C est un langage compilé, qui permet d'optimiser ce type de traitement et permet d'appliquer un filtrage des dizaines de fois plus rapidement que PHP ne le pourrait.

    Par ailleurs, c'est une extension de Nginx, donc il faut le faire tourner dans les normes du processus parent, qui n'est pas non plus en PHP.

    Il ne viendrait à personne l'idée de faire Apache en PHP et faire un Nginx/Naxsi en PHP ca revient à peu prêt au même. Bientôt un kernel linux en php, very 2012 et web 3.0 ;)

    PS : c'est le soft utilisé pour protéger le site de charlie hebdo depuis son retour en ligne : http://twitter.com/#!/NAXSI_WAF

    • [^] # Re: PHP vs C

      Posté par  . Évalué à 3.

      Ne t'inquiètes, Linux en PHP, ça va arriver bientôt. Ça fera tourner Gnome-shell en Javascript, avec un lecteur audio en javascript builtin dans Firefox qui utilisera des codecs en javascripts. Enfin, la virtualisation se fera dans firefox, en javascript grâce à Bellard. vive les technos Web, le C, c'est surfait.
      (ah mais wait, j'y pense, en quoi vas on écrire tout ces interpréteurs ?)

      • [^] # Re: PHP vs C

        Posté par  (site web personnel) . Évalué à 4.

        J'utilise un cluster de relais de courriel codé en Perl : Qpsmtpd. Depuis qu'on utilise cette solution, on a des délais bien plus faible de livraison des courriel qu'avec Postfix par exemple.

        Un reverse proxy HTTP n'a rien à voir avec un relais SMTP mais c'est juste pour dire que les langages de script ne sont pas toujours mauvais. Idem avec la comparaison Nagios (coeur en C) / Shinken (coeur en Python).

        PS : l'ajout de module et la modification de code dans Qpsmtpd est hyper facile donc j'en ai fais quelque unes alors que je n'ai jamais modifié un Postfix ni recompilé celui-ci...

        • [^] # Re: PHP vs C

          Posté par  . Évalué à 3.

          Sans vouloir dire que tout devrait être écris en C. Shinken et je présume Qpsmtpd ont des design qui améliorent la performance (shinken permet de répartir la charge sur plusieurs machines par exemple).

          Nginx est vraiment très petit et très simple, il n'y a pas d'algorithme très complexe intégré ni rien de magique, à partir de là la performance intrinsèque du langage deviens intéressant.

          Il est aussi possible qu'ils aient voulu faire attention à la consommation mémoire. Sans vouloir dire que des langages comme python ou perl consomment beaucoup de mémoire ils en consomme plus que le C et ça a peut être son importance sur des machines comme le shiva plug.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: PHP vs C

          Posté par  . Évalué à 0.

          Shinken à la base était prévu comme POC pour montrer ce qu'il est possible de faire, c'est aussi pour ça qu'il est en Python. Cela étant, certains traitements sont mieux optimisés dans certains langages spécialisés (cf les regexp en Perl) que dans des langages génériques comme le C.

  • # A propos de nginx

    Posté par  . Évalué à 4.

    Il y a un article (en Anglais) sur ArsTechnica a ce sujet: http://arstechnica.com/business/news/2011/11/a-faster-web-server-ripping-out-apache-for-nginx.ars

  • # nginx et la modularité

    Posté par  . Évalué à 9.

    Une question à propos de nginx. Est ce que vous avez trouvé génant le fait de ne pas pouvoir distribuer séparément les binaires de nginx et de votre module ?

    Les modules de nginx, à la différence d'Apache, ne sont pas vraiment des modules chargés dynamiquement mais plutôt des options de compilation pour un binaire statique. Je trouve ce comportement handicapant pour un déploiment de binaires.

    "Suis-je le seul à avoir ce jugement ?"

    • [^] # Re: nginx et la modularité

      Posté par  (site web personnel) . Évalué à 5.

      Je dois avouer que je suis confronté au même problème. J'ai voulu ajouter un nouveau module (pour purger le cache) et je suis obligé de tout recompiler ce qui complique quand la machine de destination est un ARM avec peu de RAM donc obligé de partir sur de la cross compilation ...

      Enfin pour tempérer tout ça Nginx est vraiment d'une rapidité exceptionnelle, cela justifie quelques contraintes.

    • [^] # Re: nginx et la modularité

      Posté par  . Évalué à 10.

      Bonjour,

      En effet, le fait que nginx ne supporte pas de modules 'dynamiques' est quelque peu contraignant, mais cela se fait au profit d'une architecture de module beaucoup plus simple que apache par exemple.
      De plus, cela a certains avantages ici :

      • nginx est capable de faire un 'reload' SANS perdre les connexions actives, de par l'architecture worker / master process utilisée. On peux donc faire une upgrade de nginx avec 0 downtime

      • l'utilisation de librairies dynamiques/partagés a un impact en termes de performances (nginx a été notamment écrit pour gérer le problème dit des C10K

      • enfin, le fonctionnement, et la coordination nécessaire entre les modules (de part le mode de fonctionnement de nginx) rendrait le maintien de l'API complexe

      • finalement, l'utilisation d'un modèle statique permet de réduire au maximum les librairies embarquées

      De plus, nginx fonctionne comme une machine à état asynchrone, ce qui implique une architecture et un code assez particulier, puisque une grande partie du code doit être ré-entrante.

      voila !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.