HSC
Cabinet de consultants en sécurité informatique depuis 1989 - Spécialisé sur Unix, Windows, TCP/IP et Internet
Mode texte : accès au contenu de la page
Hervé Schauer Consultants
Vous êtes ici : Accueil > Ressources > Brèves > ModSecurity
Accéder au : Site HSC des formations
Télécharger le catalogue des formations
Recherche :  
English version
   Services   
o Domaines de compétences
o Conseil & Expertise
o Prestations ISO 27001
o Audit & Évaluation
o Tests d'intrusion
o Tests de vulnérabilités (TSAR)
o Analyse Forensique
o Certification ARJEL
o Formations
o E-learning
   Conférences   
o Agenda
o Interventions passées
o Tutoriels
   Ressources   
o Index thématique
o Brèves
o Présentations
o Cours
o Articles
o Outils (téléchargement)
o Veille en vulnérabilité
   Société   
o Hervé Schauer
o Equipe
o Offres d'emploi
o Références
o Historique
o Partenariats
o Associations
   Presse et
 communication
 
 
o Newsletter HSC
o Bulletin juridique HSC
o Revue de presse
o Communiqués de presse
o Publications
   Contacts   
o Coordonnées
o Requêtes particulières
o Accès à nos locaux
o Hôtels proches de nos locaux
|>|ModSecurity  

par Stéphane Milani (02/03/2006)



--[ Présentation de ModSecurity ]---------------------------------------

--[ 1. Introduction ]---------------------------------------------------

Cette brève présente le module ModSecurity de Apache.

mod_security est un moteur de détection et de prévention d'intrusion 
Open Source pour les applications Web. Le terme plus générique de 
pare-feu applicatif peut être utilisé.


--[ 2. Dispositifs ]----------------------------------------------------

mod_security intègre plusieurs dispositifs permettant d'augmenter la 
puissance de protection contre des attaques web.

Ces dispositifs sont le filtrage de requêtes, les techniques anti-
évasion, l'analyse du contenu lors de l'utilisation de la méthode POST, 
la journalisation des requêtes, le filtrage HTTPS, le filtrage des 
données compressées.

A titre informatif, il est intéressant de voir également comment peut 
être mis en place le filtrage d'URL avec un Apache installé en relais 
inverse avec mod_rewrite:
http://www.hsc.fr/ressources/breves/filtre-relais-inverse.html.fr
http://www.hsc.fr/ressources/breves/pourquoi-relais-inverse.html.fr


--[ 3. Exemple d'architecture ]-----------------------------------------

mod_security peut être utilisé en tant que relais inverse plutôt que 
intégré à chaque serveur à protéger. Ceci permet ainsi de protéger 
plusieurs serveurs Web même si ces derniers ne sont pas des Apache.

Ceci peut être fait en couplant un ensemble de modules tels que
 mod_security, mod_proxy, mod_rewrite, mod_dosevasive ou mod_headers.

Dans le cas de l'utilisation de mod_security en relais inverse, 
l'architecture ci-dessous peut très bien être envisageable:

                                mod_security     Serveur Web 
                                     +        (IIS, Apache, Iplanet)
                 Pare-feu        mod_proxy   
                   _____            ____              __
              443 |     |          |    |            |  |
Client <--------->|     |<-------->|    |<---------->|  |
 Web           80 |_____|          |____|            |__|



--[ 4. Configuration de base ]------------------------------------------

La configuration de mod_security peut s'effectuer par l'intermédiaire du
fichier modsecurity.conf. Une directive doit alors être rajoutée dans le
fichier de configuration httpd.conf de Apache:
  Include conf/modsecurity.conf

L'activation de mod_security afin de normaliser les requêtes effectuées 
sur le serveur Web se fait grâce à la variable SecFilterEngine dans le 
fichier modsecurity.conf:

  SecFilterEngine On

L'activation des fonctionnalités de mod_security peut également être 
faite uniquement pour le contenu dynamique:
  
  SecFilterEngine DynamicOnly

Une fois activé, mod_security interceptera et vérifira toutes les 
requêtes entrantes sur le serveur Web. Les requêtes seront ensuite 
passées aux filtres définis par l'utilisateur et seront soit acceptées, 
soit refusées. 

Les lignes suivantes sont à rajouter dans le fichier modsecurity.conf 
afin d'effectuer certaines actions:

- Interception des requêtes POST:
  SecFilterScanPOST On

- Changer l'identité du serveur Web Apache:
  SecServerSignature "Apache/1.3.33 (Darwin)"

- Pour les applications web, seuls les encodages
  application/x-www-form-urlencoded et multipart/form-data sont utilisés. 
  Il est possible de spécifier que seules les requêtes avec ces deux 
  encodages soient acceptées:
  SecFilterSelective HTTP_Content-Type "!(^$|^application/x-www-form-urlencoded$|^multipart/form-data;)"

- Prévention contre le chunked transfer encoding:
  SecFilterSelective HTTP_Transfer-Encoding "!^$"

- Prévention contre les URL mal encodées (typiquement pour ne pas violer 
  le système de numérotation hexadécimale, ou pour vérifier qu'une 
  chaîne Unicode est valide):
  SecFilterCheckURLEncoding On
  SecFilterCheckUnicodeEncoding On

- Prévention contre les attaques par débordement de tampon en limitant 
  la quantité d'octets autorisés dans les chaînes de requêtes (par 
  exemple, si le langage utilisé dans les applications est l'anglais, 
  limiter le byte range à 32-126):
  SecFilterForceByteRange 32 126

- Interdire les requêtes invalides avec un statut erreur 400 et 
  journaliser cette action:
  SecFilterDefaultAction "deny,log,status:400"

- Journaliser les actions et les requêtes suspectes:
  SecAuditEngine RelevantOnly
  SecAuditLog /var/www/logs/audit_log


--[ 5. Règles de filtrage ]---------------------------------------------

mod_security utilise des règles de filtrage formées d'expressions 
régulières afin d'analyser les en-têtes, les variables d'environnement, 
les variables de serveur, les cookies utilisateur ou le payload des 
méthodes POST.

- Les règles s'écrivent, d'une manière générale, à l'aide de la 
  directive SecFilter. Celle-ci permettra d'appliquer une règle à 
  l'ensemble des informations envoyées par le navigateur:
  SecFilter MOT_RECHERCHE

- Par exemple, la règle pour bloquer l'accès à l'URL
  http://www.hsc.fr/tmp/essai.sh peut être la suivante:
  SecFilter /tmp/

- Bloquer l'accès au fichier passwd:
  SecFilter /etc/passwd

- Interdire la commande ls:
  SecFilter /bin/ls

- Provoquer une redirection:
  SecFilter /etc/passwd redirect:http://www.hsc.fr/mauvaise/requete.html

- Il est également possible de n'écrire des règles que pour certaines 
  parties des requêtes HTTP (REMOTE_ADDR, QUERY_STRING, COOKIES_VALUES, 
  etc...):
  SecFilterSelective QUERY_STRING MOT_RECHERCHE

Les exemples suivants sont intéressants pour se faire une idée sur 
l'écriture des règles:

- Accepter seulement les versions de protocole valides:
  SecFilterSelective SERVER_PROTOCOL !^HTTP/(0\.9|1\.0|1\.1)$

- Permettre seulement les méthodes indispensables:
  SecFilterSelective REQUEST_METHOD !^(GET|HEAD|POST)$

- Interdire la méthode TRACE:
  SecFilterSelective REQUEST_METHOD "TRACE"

- Exiger HTTP_USER_AGENT et HTTP_HOST dans chaque requête:
  SecFilterSelective "HTTP_USER_AGENT|HTTP_HOST" "^$"

- Exiger une longueur exacte du corps du message pour chaque requête 
  POST:
  SecFilterSelective REQUEST_METHOD ^POST$ chain
  SecFilterSelective HTTP_Content-Length ^$

- Empêcher l'accès au fichier /etc/shadow:
  SecFilterSelective THE_REQUEST "/etc/shadow"

- Empêcher la commande /bin/ps:
  SecFilterSelective THE_REQUEST "/bin/ps"

- Empêcher une attaque transversale de répertoire:
  SecFilter "\.\./"

- Empêcher le téléchargement de fichiers avec wget:
  SecFilterSelective THE_REQUEST "wget "

- Bloquer le bot DTS Agent:
  SecFilterSelective HTTP_USER_AGENT "DTS Agent"

- Bloquer le proxy ouvert ayant comme adresse 12.148.163.152:
  SecFilterSelective REMOTE_ADDR 12\.148\.163\.152


--[ 6. Détection des attaques de type injection SQL ]-------------------

mod_security permet la détection des attaques de type injection SQL.

Pour rappel, une injection SQL consiste à modifier une variable utilisée 
par une requête SQL de manière à ce que des commandes arbitraires soient
exécutées.
La requête SQL modifiée pourrait alors avoir la forme suivante:
  SELECT * FROM users WHERE username = 'hsc' and password = 'xxx' OR 1=1--' 

La règle à appliquer pour contrer cette attaque serait:
  SecFilter "or.+1[[:space:]]*= [[:space:]]1"

Les règles suivantes sont utiles pour contrer certaines requêtes:
  SecFilter "delete[[:space:]]+from"
  SecFilter "create[[::space:]]+table"
  SecFilter "update.+set.+="
  SecFilter "insert[[:space:]]+into"
  SecFilter "select.+from"
  SecFilterSelective ARGS "drop[[:space:]]+database"
  SecFilterSelective ARGS "drop[[:space:]]+table"

Pour les attaques sur les bases de données MS-SQL, la commande 
xp_cmdshell est couramment utilisée. Les règles suivantes sont 
intéressantes dans ce cas:
  SecFilter "exec.+xp_"
  SecFilter "@@[[:alnum:]]+"
  SecFilter "exec.+sp_"
  SecFilter "load[[:space:]]+data"


--[ 7. Détection des attaques XSS ]-------------------------------------

Les attaques par Cross-Site-Scripting (XSS) sont multiples et variées 
sur les applications Web. De ce fait, définir des règles pour 
mod_security n'est pas trivial et les règles doivent être adaptées aux 
besoins propres des applications.

Cependant, une base de départ peut être la suivante afin d'interdire le 
HTML et le JavaScript dans les requêtes:
  SecFilter "<script"
  SecFilter "<.+>"
  SecFilter "<(.|\n)+>"
  SecFilter "<( |\n)*script"
  SecFilter "<[[:space:]]*script"

Toutes les règles sont à adapter en fonction des applications de manière 
à éviter les faux positifs qui peuvent être nombreux.


--[ 8. Conclusion ]-----------------------------------------------------

Avec la multiplication des attaques sur les applications Web, le simple
filtrage IP n'est plus suffisant pour se protéger des attaques et les
fonctionnalités de mod_security deviennent indispensables.
Configuré en relais inverse filtrant, mod_security permet d'augmenter sa
sécurité et de se protéger efficacement contre des attaques de type 
injection SQL ou XSS et ceci sans ré-écrire les applications Web.
La configuration des règles de filtrage peut nécessiter un travail 
poussé mais nécessaire pour trouver le bon compromis entre sécurité et 
bon fonctionnement des applications.


	                     -- Stéphane Milani <Stephane.Milani@hsc.fr>


--[ 9. Références ]-----------------------------------------------------

- Le site Web de mod_security
  http://www.modsecurity.org

- Présentation de mod_security (Apache)
  Frédéric Laplagne - OSSIR
  http://www.ossir.org/resist/supports/cr/20050627/mod_security.pdf

- Apache en relais inverse
  Denis Ducamp
  http://www.hsc.fr/ressources/breves/relais-inverse.html.fr

- Pourquoi un relais inverse
  Denis Ducamp
  http://www.hsc.fr/ressources/breves/pourquoi-relais-inverse.html.fr

- Filtrer des URLs dans un relais inverse
  Denis Ducamp
  http://www.hsc.fr/ressources/breves/filtre-relais-inverse.html.fr

- Mise en oeuvre de filtrage avec mod_eaccess sur un relais HTTP inverse
  Christophe Premel
  http://hsc.fr/ressources/breves/filtrage-url.html.fr

- Aspects de HTTP/1.1 pour la réalisation d'un relais de sécurité
  Marc Baudoin
  http://www.hsc.fr/ressources/presentations/http-1.1/index.html.fr

- Présentation sur les attaques XSS
  Alain Thivillon
  http://www.hsc.fr/~thivillon/04_failles_xss.pdf

- Présentation Sécurité des bases de données et des ERP
  Alain Thivillon et Nicolas Jombart
  http://www.hsc.fr/ressources/presentations/csm05-bderp/index.html.fr

- PCRE - Perl-compatible regular expressions
  http://www.pcre.org/pcre.txt

- perlre - Perl regular expressions
  http://perldoc.perl.org/perlre.html



Dernière modification le 14 septembre 2007 à 12:04:12 CET - webmaster@hsc.fr
Mentions légales - Informations sur ce serveur - © 1989-2013 Hervé Schauer Consultants