Sécurité Informatique

Titre de l'article : Mod_security : Le module de sécurisation d'Apache
Auteur : Yannick Hamon, consultant sécurité Xmco Partners
Courriel : yannick.hamon@xmcopartners.com
Date : Novembre 2006
Version complète en PDF : Actu Sécurité Novembre 2006
Sections :
Les services web
Le module "mod_security"
Un accès facile pour un système complexe
Les fausses idées reçues
Les fonctionnalités
L'implémentation
Conclusion
Bibliographie


>Mod_security : Le module de sécurisation d'Apache

L'ouverture des entreprises sur le monde "via Internet" est devenue un besoin incontournable. Malheureusement, la sécurité des applications n'est pas suffisamment prise en compte.
Ainsi, plus de 70% des exploits publiés concernent une vulnérabilité liée à une application web. Devant ce constat alarmant, la société "Breach Security" a développé un module pour les serveurs web Apache afin d'améliorer sensiblement la sécurité de ces applications sans modifier l'architecture existante.

Mod_security [1] permet de lutter contre les attaques classiques comme l'injection de commandes SQL, la lecture de fichiers sensibles, l'accès à des répertoires arbitraires, etc. Ce module apporte une couche de sécurité en amont des services web.

Les services web

Un accès facile pour un système complexe

Le principal avantage des services web est la capacité de partager certaines ressources de l'entreprise depuis n'importe quel accès Internet.

Cependant, devant l'étendue des vecteurs d'attaques, la sécurité des applications web devient rapidement un empilement de solutions ou de méthodes qui corrigent certains problèmes tout en apportant de nouvelles vulnérabilités.
Par exemple, les ressources partagées représentent parfois des données privées dont l'accès doit être restreint aux seuls utilisateurs autorisés. Les applications nécessitent donc de fournir un service d'authentification et d'autorisation afin de gérer les connexions entrantes.
Or, ce mécanisme implique souvent l'utilisation d'une base de données afin de stocker les informations des utilisateurs.

Ce composant supplémentaire nécessite alors de prendre en compte des tentatives de contournement de l'authentification par injection de commandes SQL arbitraires au sein de la base de données ainsi que les tentatives d'exploitation de failles connues du serveur de base de données relationnelles.

La complexité et la sécurité de chaque élément des applications entraînent une escalade des technologies au sein de l'architecture web. Les services web sont, aujourd'hui, devenus la cible privilégiée des pirates informatiques car les attaques ne nécessitent que peu de moyens : un simple accès Internet.
La sécurité de chaque composant de l'architecture est, généralement, partiellement implémentée ce qui donne un niveau global assez faible. Par conséquent, plus une application est complexe et plus l'attaquant a de chance de trouver une faille de sécurité.

Les fausses idées reçues

Le pare-feu est un élément du réseau indispensable. Il permet de bloquer les attaques des couches basses du modèle OSI. Néanmoins, il ne protège pas l'application web. Les failles des services web sont dues à des erreurs liées à un comportement anormal de l'application. Le trafic est totalement légitime pour le réseau. Le pare-feu ne bloquera donc pas les flux du pirate.

L'implémentation du protocole SSL permet de remédier aux problèmes de confidentialité, d'intégrité et d'authentification des services webs. Ainsi, une entreprise et un utilisateur peuvent garantir leur authenticité et vérifier que les messages échangés ne sont ni altérés ni accessibles par une tierce personne. Or, les messages échangés peuvent exploiter une faille applicative; l'utilisation de la cryptographie ne protège donc pas le service web.

Mod_security
Figure1: Implémentation du module mod_security

D'autre part, il est courant de voir des services web exécutés sous des privilèges systèmes élevés, le plus souvent l'administrateur.
Or, en exploitant une faille applicative, un pirate obtiendrait alors des privilèges élevés sur le serveur hébergeant le service. Il pourrait ainsi prendre le contrôle total de la machine. Dans la majorité des cas, un serveur applicatif n'a besoin d'aucun privilège particulier.

Le module "mod_security"

Les fonctionnalités du module "mod_security"

Ce module, open source et sous licence GPL, est destiné à renforcer la sécurité du service web et ce, directement par l'intermédiaire du serveur HTTP. Les principales opérations s'effectuent durant le traitement des entrées/sorties du serveur. C'est-à-dire, avant la prise en charge des données par l'application et après l'exécution du processus.
Toutes les requêtes entrantes sont ainsi analysées et traitées en amont afin de bloquer les techniques de contournement et d'encodage de caractères. Les paramètres fournis par les méthodes POST et GET sont, de même, interceptés et peuvent être journalisés dans leur globalité pour une analyse postérieure. Les données reçues sont étudiées afin de bloquer les débordements de tampon, la présence de «shellcode», l'accès en lecture à des fichiers sensibles et l'injection de scripts ou de commandes. Dans le cas où l'application permet de télécharger des fichiers sur le serveur, le module peut vérifier l'extension des fichiers et exécuter un script externe à l'instar d'un anti-virus.

Mod_Security permet également de filtrer les messages renvoyés au client afin de supprimer tous les messages d'erreurs trop explicites. En effet, ces messages contiennent souvent des informations précieuses qui aident un pirate à préparer son attaque.

Afin d'élever la sécurité globale du système, le module exécute automatiquement le serveur HTTP sous des privilèges restreints ainsi que dans un environnement limité (chroot). Cette solution permet de diminuer les impacts lors de l'exploitation d'une vulnérabilité non corrigée ou inconnue.

L'implémentation

Le module "Mod_Security" a été développé afin d'élever le niveau de sécurité global de l'application web sans repenser celle-ci. L'implémentation de ce module ne nécessite qu'une simple modification du fichier de configuration du serveur HTTP Apache ainsi que le redémarrage du service. Les lignes ajoutées au fichier de configuration permettent de paramétrer les filtres et les options souhaités.

Exemples

<IfModule mod_security.c>
# Démarrage du processus de filtrage
SecFilterEngine On
# Filtrage des caractères d'entrées
SecFilterCheckURLEncoding On
SecFilterCheckUnicodeEncoding On
# Traitement des cookies
SecFilterNormalizeCookies
# Filtrage des caractères de sorties
SecFilterScanOutput On
# Filtrage du contenu des requêtes 'POST'
SecFilterScanPOST On
# Action par défaut : log & rejet
SecFilterDefaultAction
# Protection contre le "Directory Transversal"
SecFilter "\.\./"
# Protection contre l'injection de commande SQL de type "xp_cmdshell"
SecRule ARG:p "xp_cmdshell" "t:lowercase"

</IfModule>
Figure2: Exemples de règles du module mod_sec

Par ailleurs, les entreprises qui ne disposent pas de serveurs HTTP Apache, peuvent implémenter cette solution en ajoutant un "reverse-proxy" à leur infrastructure afin de sécuriser et d'augmenter la disponibilité des applications webs.

Conclusion

Le module Mod_Security représente une solution pour les entreprises qui ne peuvent pas modifier aisément leurs applications web. Cet avantage permet de réduire les temps de déploiement mais surtout d'alléger le code source des applications, facteur de stabilité et de sécurité.

Bibliographie

[1] Mod_security : http://www.modsecurity.org



Actualite Securite

Version complète en PDF

> Autres articles

+ Tous les articles



> Le cabinet Xmco Partners

+ La société

+ Contacts