Modsecurity-apache/Description

From aldeid
Jump to navigation Jump to search

Qu'est-ce que Modsecurity?

Description

Modsecurity est un pare-feu applicatif, se présentant sous la forme d'un module d'Apache. Il permet de protéger le serveur Web contre nombre d'attaques, grâce à son paramétrage souple via un fichier de configuration listant les règles à appliquer. Modsecurity permet par exemple d'interdire les requêtes mal formées, pouvant être à l'orgine des attaques sur les fichiers .htaccess. Par ailleurs, son système de journalisation permet la détection d'intrusions.

Versions

Modsecurity est proposé dans 2 versions :

  • Modsecurity 1.x : version initiale, compatible avec Apache 1.x et 2.x. Le nombre de couches de traitements est de 2 ("Input Filtering" et "Output Filtering").
  • Modsecurity 2.x : nouvelle version, uniquement compatible avec Apache 2.x. Le nombre de couches de traitements a été passé à 5 (REQUEST_HEADERS, REQUEST_BODY, RESPONSE_HEADERS, RESPONSE_BODY, LOGGING).

La syntaxe de la version 2 a évolué et les règles de la première version ne sont pas compatibles avec la nouvelle version.

Les phases de traitement

  • Phase 1 : En-têtes de requête : Les règles de cette phase sont traitées immédiatement après la lecture des en-têtes de requête par Apache, le corps de la requête n'ayant pas encore été analysé (tous les arguments de la requête ne sont alors pas connus).

Remarque : Le traitement des règles spécifiques à des emplacements d'Apache (VirtualHosts) doit être effectué en phase 2.

  • Phase 2 : Corps de requête : Toutes les règles applicatives doivent se retrouver dans cette phase. La version actuelle de ModSecurity2 supporte les encodages suivants : application/x-www-form-urlencoded (données de formulaires), multipart/form-data (transfert de fichiers) et text/xml (parsing de fichier XML)
  • Phase 3 : En-têtes de réponse : Les règles de cette phase sont traitées juste avant le renvoi des en-têtes de réponse au client, ce qui permet d'intercepter le contenu avant qu'il ne soit renvoyé.

Remarque : A cette phase, il n'est en revanche pas possible d'intercepter les erreurs 404, ainsi que certains éléments (Date, Server, Connection) ajoutés par un proxy.

  • Phase 4 : Corps de réponse : A cette phase, les règles se focalisent sur le contenu qui sera renvoyé au client, permettant d'intercepter des erreurs, des fuites d'informations ainsi que des échecs d'authentification.
  • Phase 5 : Journalisation : Les règles de cette phase sont traitées juste avant l'écriture des événements dans les fichiers journaux, permettant l'interception d'erreurs Apache. Il est important de préciser qu'à cette phase, il n'est plus possible de modifier le contenu qui sera renvoyé au client.