Home > Security > Premier pas avec mod_security

Premier pas avec mod_security

Un client m’a demandé récemment si je pouvais jeter un œil à mod_security pour ses besoins de protections d’URL (WAF, en anglais Web Application Firewall, plus d’infos sur l’article Wikipedia). En quelques mots, mod_security est un module Apache – comme son nom l’indique – qui apporte donc une fonctionnalité de filtre relativement avancé, mais avec l’avantage d’être opensource et donc gratuit. De plus, il vient avec un ensemble de règles déjà établies qui sont le fruit du travail du groupe OWASP, qui se définit comme un 501c3 not-for-profit worldwide charitable organization focused on improving the security of application software.

L’objectif de ma première approche de mod_security est relativement simple puisqu’il consiste à logger toutes les tentatives d’authentification avec un nom d’utilisateur qui contient des caractères hormis [a-zA-Z0-9]. Voici un récapitulatif de l’architecture (simple) mise en œuvre :

  • Distribution : CentOS
  • un apache (où sera installé le module mod_security) en frontal devant un Tomcat, en utilisant le mod_proxy (en HTTP)
  • un Tomcat avec une application de test nommée Xebia Travel développée par Xebia
  • L’authentification des utilisateurs sur l’application Xebia Travel s’effectue via un POST au travers d’un formulaire, avec les variables j_username et j_password

Une fois installé mod_security (depuis le dépôt EPEL), et quelques petites heures de recherche, voici le résultat que j’ai obtenu :


SecAuditLog /var/log/httpd/ecommerce-audit.log
SecDebugLog /var/log/httpd/ecommerce-security.log
SecDebugLogLevel 3
SecAuditEngine relevantonly

SecRequestBodyAccess On

SecRule ARGS:j_username "!@rx ^([A-Za-z0-9]+)$" auditlog,id:10000

Quelques explications :

  • Les directives SecAuditLog, SecDebug, SecDebugLogLevel et SecAuditEngine sont relativement explicites. Elles permettent en effet de configurer les différents fichiers de logs et d’audit, ainsi que leur verbosité
  • La directive SecRequestBodyAccess est très importante, puisqu’elle permet de dire à mod_security d’analyser non pas seulement les en-têtes des requêtes mais également le corps. Pourquoi est-ce important ? Parce qu’avec les formulaires de type POST, les variables sont passées non pas en en-tête, mais bien dans le corps du message. Sans cette directive, il est donc impossible d’analyser les arguments des formulaires de type POST
  • et enfin, la directive la plus importante à savoir SecRule qui est exécutée à chaque fois qu’une requête est effectuée avec l’argument j_username (POST ou GET), et je vérifie au travers d’une expression rationnelle (regex) qu’elle contient d’autres caractères que [A-Za-z0-9], auquel cas je lui définie l’action auditlog, en lui demendant d’identifier cette règle avec l’id 10000, ce qui s’avère pratique pour l’analyse du fichier d’audit.
  • Bien entendu, ce billet ne montre qu’un centième des utilisations possible de mod_security, mais si cela peut aider à commencer, sur ce, à bientôt !