HSC
Network Security Consulting Agency Since 1989 - Specialized in Unix, Windows, TCP/IP and Internet
Text mode: access to the page content
Hervé Schauer Consultants
You are here: Home > Resources > Tips > Présentation de mod_security2
Go to: HSC Trainings
Search:  
Version française
   Services   
o Skills & Expertise
o Consulting
o ISO 27001 services
o Audit & Assessment
o Penetration tests
o Vunerability assessment (TSAR)
o Forensics
o ARJEL
o Training courses
o E-learning
   Conferences   
o Agenda
o Past events
o Tutorials
   Resources   
o Thematic index
o Tips
o Lectures
o Courses
o Articles
o Tools (download)
o Vulnerability watch
   Company   
o Hervé Schauer
o Team
o Job opportunities
o Credentials
o History
o Partnerships
o Associations
   Press and
 communication
 
 
o HSC Newsletter
o Bulletin juridique HSC
o Press review
o Press releases
o Publications
   Contacts   
o How to reach us
o Specific inquiries
o Directions to our office
o Hotels near our office
|>|Présentation de mod_security2  

by Louis Nyffenegger (11/04/07)



---[ Présentation de mod_security2 ]------------------------------------------

Cet article traite de l'installation et du fonctionnement de mod_security2, 
la nouvelle version du célèbre pare feu applicatif.

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

Mod_security2 amène de nombreuses améliorations et une nouvelle syntaxe pour 
la création de règles de filtrage, nous allons voir comment installer et 
configurer cette nouvelle version de ce firewall applicatif.

À noter que cette version ne fonctionne qu'avec Apache2.

Pour toute information sur le fonctionnement de mod_security et sur la mise en 
place de mod_security, je vous conseille la brève de Stéphane Milani : 
http://www.hsc.fr/ressources/breves/modsecurity.html .


--[ 2. Différences avec mod_security 1 ]--------------------------------------

Cette nouvelle version de mod_security amène de nombreuses fonctionnalités par
rapport à la version précédente mais ne fonctionne plus avec Apache 1.3. De 
plus pour l'instant mod_security2 ne peut pas être compilé comme un module
statique.

Cette nouvelle version apporte le support du format XML, ce qui peut permettre
de mettre en place un firewall XML simple. 

La granularité du filtrage a aussi été grandement améliorée et on peut 
simplement créer des régles très précises. Là où mod_security ne gère que 2
phases (entrée/sortie), mod_security2 en gère 5.


--[ 3. Installation ]---------------------------------------------------------

Cette nouvelle version étant encore récente, sa distribution n'est pas encore 
faite dans toutes les distributions courantes.

Pour l'installer, il faut récupérer la dernière version sur le site de 
modsecurity : http://www.modsecurity.org/download/index.html .

Il suffit ensuite de décompresser l'archive : 

	$ tar -zxvf modsecurity-apache_$version.tar.gz

Puis, il faut faire quelques modifications dans le Makefile : 

	$ cd modsecurity-$version/apache2/ 

Il suffit ensuite de modifier les variables top_dir et INCLUDES (exemple pour 
Gentoo):

	top_dir = /usr/lib/apache2
	INCLUDES = -I /usr/include/apache2/ -I /usr/include/libxml2 

L'utilisation ou non de la libxml2 peut être décidée grâce à la ligne :

	DEFS = -DWITH_LIBXML2

Pour le filtrage d'un WebService, la bibliothèque XML2 est nécessaire.

Enfin, on peut lancer la compilation et l'installation de mod_security2 : 

	$ make
	$ sudo make install

Il ne reste plus qu'à créer le fichier de configuration minimale pour indiquer 
à Apache de charger mod_security2 et pour tester son fonctionnement (extrait du 
fichier /etc/apache2/modules.d/99_mod_sec2.conf) :

	LoadFile        /usr/lib/libxml2.so 
	LoadModule security2_module modules/mod_security2.so
	LoadModule unique_id_module modules/mod_unique_id.so
	SecRuleEngine On
	SecRequestBodyAccess Off
	SecResponseBodyAccess Off
	SecServerSignature "HSC"
	SecDebugLog modsec2_debug.log
	SecDebugLogLevel 3
	SecRule REQUEST_FILENAME "testhsc" log,deny,status:403,msg:'testhsc'

La ligne SecServerSignature "HSC" permet de changer la bannière du serveur.
La ligne SecRule REQUEST_FILENAME "testhsc" log,deny,status:403,msg:'testhsc' 
va permettre de faire un simple test du bon fonctionnement de mod_security2 en 
bloquant l'accès au fichier testhsc, toute tentative d'accès renverra une 
erreur 403 et sera journalisée avec le message 'testhsc'.

Après rechargement du serveur Apache :

	$ sudo /etc/init.d/apache2 restart

il est possible de tester le bon fonctionnement de mod_security2 : 

	$ telnet localhost 80
	Trying 127.0.0.1...
	Connected to localhost.
	Escape character is '^]'.
	GET / HTTP/1.0

	HTTP/1.1 200 OK
	Date: Tue, 10 Apr 2007 15:28:54 GMT
	Server: HSC
	[...]

La nouvelle bannière du serveur est maintenant visible.

L'accès au fichier testhsc est maintenant interdit : 	

	$ telnet localhost 80
	Trying 127.0.0.1...
	Connected to localhost.
	Escape character is '^]'.
	GET /testhsc HTTP/1.0

	HTTP/1.1 403 Forbidden
	Date: Tue, 10 Apr 2007 15:31:05 GMT
	Server: HSC
	[...]



Le résultat est visible dans les journaux de mod_security :

	$ sudo tail /var/log/apache2/modsec2_debug.log
	[...]
	[10/Apr/2007:17:31:05 +0200] [kinkakuji/sid#817abe0][rid#82439a0]
	[/testhsc][1] Access denied with code 403 (phase 2). Pattern match 
	"testhsc" at REQUEST_FILENAME. [msg "testhsc"]


--[ 4. Configuration ]--------------------------------------------------------

Voici un petit tour des options qui peuvent s'avérer utiles : 

	* SecServerSignature permet de modifier la bannière du serveur.
	
	* SecRequestBodyLimit limite la taille du corps des requêtes.
	
	* SecRuleEngine permet d'activer le moteur de règles qui peut 
	prendre 3 valeurs :  On,  Off, DetectionOnly.
	
	* SecRule pour la création de règle.

Les règles peuvent être appliquées à 5 instants lors du traitement d'une 
requête :
	
	* après la réception de l'en-tête de la requête, le corps de la 
	requête n'est pas encore disponible, les règles mises en place durant
	cette phase ne tiennent pas compte de la gestion des requêtes faite
	par Apache. Si une requête est bloquée durant cette phase, le serveur 
	HTTP ne verra même pas la requête.
	
	* après la réception du corps de la requête, durant cette phase, la 
	totalité des arguments envoyés à l'application est connue.
	
	* avant l'envoi de l'en-tête de la réponse.
	
	* avant l'envoi du corps de la réponse qui permet de modifier le corps
	de la réponse avant son envoi.
	
	* durant la phase de journalisation.

Mod_security2 met à disposition des variables sur lesquelles ont peu simplement
mettre en place des règles : 
	
	* ARGS pour traiter l'ensemble des arguments, ou accéder à un argument 
	en particulier, ou à tous les arguments sauf un, ...
	
	* AUTH_TYPE pour accéder au type d'authentification
	
	* HTTP_REFERER pour l'accès au Referer
	
	* REMOTE_ADDR et REMOTE_HOST pour connaître l'adresse IP ou le reverse
	DNS du client
	
	* le corps d'une requête grâce à REQUEST_BODY
	
	* l'en-tête d'une requête avec REQUEST_HEADERS
	
	* la méthode HTTP utilisée avec  REQUEST_METHOD
	
	* l'ensemble de la réponse en combinant RESPONSE_BODY et 
	RESPONSE_HEADERS

Il est ainsi possible d'accéder à l'intégralité des données transférées lors 
d'une requête HTTP au moment de la requête et de la réponse.


Mod_security donne aussi accès à des fonctions permettant d'encoder ou de 
décoder l'ensemble des variables que nous venons de voir. Il est ainsi possible
de décoder en base64, d'enlever les espaces, de calculer une empreinte  md5 ou
sha1, de décoder une url, ...

La validation d'une règle permet de spécifier une ou plusieurs actions, 
plusieurs actions sont ainsi disponibles : 
	
	* auditlog pour journaliser l'action dans le fichier d'audit
	
	* capture permet de sauvegarder la transaction, 10 captures sont 
	possibles
	
	* chain pour enchaîner plusieurs règles
	
	* ctl pour mettre à jour les règles de filtrage
	
	* deny : bloque la requête et l'interprétation des autres règles.
	
	* drop pour couper la connexion au niveau TCP
	
	* exec pour lancer un script externe (pour bloquer une adresse par
	exemple)
	
	* log pour journaliser la transaction
	
	* pass pour donner la main à la prochaine règle
	
	* phase pour spécifier la phase durant laquelle la règle sera mise
	en place
	
	* proxy pour relayer la requête vers un autre serveur (si mod_proxy
	est installé)
	
	* redirect pour rediriger le client
	
	* plusieurs actions de nettoyage sanitiseArg, sanitiseMatched, 
	sanitiseRequestHeader.
	
	* severity pour spécifier le niveau d'une alerte
	
	* status pour spécifier la réponse HTTP : 403, 404, ...
	
	* ...
	

--[ 4. Les règles génériques ]------------------------------------------------

Il est toujours possible d'utiliser les règles génériques fournies avec 
mod_security2, mais il est préférable de mettre en place un filtrage adapté à 
l'application hébergée. Les règles génériques risquent de prendre beaucoup 
plus de ressources que des règles spécialement mise en place pour une 
application donnée.

Les règles génériques sont présentes dans l'archive contenant le code de 
mod_security2. Plusieurs fichiers sont disponibles, pour les utiliser il 
suffit d'utiliser la directive Apache "Include".

Les jeux de règles suivants sont présents :
	
	* modsecurity_crs_10_config.conf qui est un fichier minimal 
	d'installation de mod_security est décrit les fonctions de base.
	
	* modsecurity_crs_20_protocol_violations.conf qui permet de vérifier 
	que les requêtes suivent bien le correctement le protocole HTTP et 
	permet de détecter certaines anomalies : méthode GET ou HEAD avec un 
	corps de message, méthode POST sans corps de message, blocage des 
	requêtes utilisant Apache comme un relais.
	
	* modsecurity_crs_21_protocol_anomalies.conf  permet de détecter des 
	anomalies dans les requêtes comme l'absence d'un User-Agent ou 
	l'absence de clause Accept.
	
	* modsecurity_crs_30_http_policy.conf permet de n'accepter que les 
	méthodes GET, HEAD, POST et OPTIONS, de n'accepter que les requêtes 
	dont le protocole est HTTP 0.9, 1.0 ou 1.1.

	* modsecurity_crs_35_bad_robots.conf bloque l'accès aux robots tel que
	le scanner nessus, bacunetix, ou des programmes en perl, ceci en se
	basant sur le User-Agent principalement.
	
	* modsecurity_crs_40_generic_attacks.conf permet de bloquer les 
	injections SQL, les injections de fichiers, l'accès à des fichiers 
	sensibles, l'injection de commande et les XSS. Ce filtrage se fait sur 
	la base d'une suite d'expression régulières complexes (et donc 
	consommatrice de ressources).

	* modsecurity_crs_45_trojans.conf qui tente de bloquer l'upload de 
	chevaux de Troie connus sur la machine.

	* modsecurity_crs_50_outbound.conf remplace les messages d'erreurs d'une
	application par des réponses HTTP 501. Ceci permet de cacher les 
	informations sensibles contenues dans les messages d'erreurs. Pour 
	limiter la consommation de ces règles, il est important de n'utiliser 
	que les règles correspondants aux technologies présentes sur le serveur.

	* modsecurity_crs_55_marketing.conf permet de journaliser le passage des
	robots d'indexation de Google, Yahoo et Microsoft.


--[ 5. Protection d'une Application Web ]-------------------------------------

Il est possible, comme avec la version précédente de protéger une application 
Web. 
Par exemple, une application présentant une injection SQL sur le champs id :

	http://www.hsc.fr/monapplication/index.php?id=3

Il est possible grâce à mod_security2 de faire une liste blanche des valeurs 
possibles pour la variable id. La variable id ne doit pouvoir qu'une valeur 
entière.

On peut facilement vérifier que la valeur est un entier grâce à la régle :

	SecRule ARGS:id "!(^[0-9]*$)" log,deny,status:403

Après un rechargement d'Apache2, la page index.php renvoie un erreur 403 si 
id n'est pas un entier.

NB: L'utilisation des directives plus petit que, plus grand que ne permet en 
rien de vérifier que la variable est un entier, si la variable n'est pas un
entier, la régle ne sera pas appliquée.

Un autre exemple, les vulnérabilités de type include : 

	http://www.hsc.fr/monapplication/index.php?file=home.php

On peut facilement vérifier que la valeur fait partie d'une liste blanche, 
grâce à la régle suivante (ici avec home et liens): 

	SecRule ARGS:file "!(^(home|liens)\.php$)" log,deny,status:403

Mod_security permet ainsi de bloquer la plupart des attaques de façon simple 
mais pour autant ne remplacera jamais de bonnes pratiques de développement.


--[ 6. Protection d'un Webservice ]-------------------------------------------

Cette nouvelle version amène la possibilité de filtrer des services Web sur 
HTTP. Nous allons voir comment on peut simplement faire une liste blanche sur 
les entrées provenant d'un utilisateur.

Pour cela nous allons utiliser un serveur Tomcat avec Jax-WS 2 pour la partie 
Webservice et le serveur Apache avec mod_security2 servira de connecteur HTTP.
Une base de données Mysql est utilisée pour le stockage.

    ________        ________________________        __________________ 
   |        |      |                        |      |                  |
   | Client |------| Apache + mod_security2 |------| Tomcat+ Jax-WS 2 |
   |________|      |________________________|      |__________________|
                                                           |
                                                      _____|____
                                                     |          |
                                                     |   Mysql  |
                                                     |__________|

Ce webservice permet pour un numéro de département donné de récupérer le nom
d'un département (stocké dans la base de données MySQL) à partir de son numéro.


Tout d'abord, si la génération de code n'est pas réalisée dynamiquement à 
partir du wsdl du webservice. Il est possible de bloquer cette accès à partir
de mod_security2. Pour cela, la règle suivante : 
	
		SecRule REQUEST_URI "\?wsdl$" log,deny,status:403

permet de bloquer l'accès aux wsdl. Un intrus n'ayant pas connaissance du 
fonctionnement du webservice aura déjà beaucoup plus de mal à s'y attaquer.


Le webservice présenté contient une injection SQL. Le message envoyé lors 
d'une interrogation classique du webservice ressemble à cela : 

<?xml version="1.0" ?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:ns1="http://host.hsc.fr/">
	<soapenv:Body>
		<ns1:getDptFromString>
			<dpt>76</dpt> 
		</ns1:getDptFromString>
	</soapenv:Body>
</soapenv:Envelope>


L'objectif de ce filtre n'est d'accepter qu'un numéro de département, il faut 
donc que la valeur du champs dpt soit au maximum de 3 chiffres.

	SecRule REQUEST_HEADERS:Content-Type "text/xml" \
    		phase:1,pass,ctl:requestBodyProcessor=XML,\
		ctl:requestBodyAccess=On
    	SecRule XML://dpt "!(^[0-9]{2,3}$)" phase:2,deny

Cette commande permet ainsi de s'assurer de la conformité des données avec 
l'utilisation classique du webservice. La commande "XML://dpt" correspond à
une requête XPath

Pour l'instant, il n'est pas possible de réaliser des requêtes XPath plus 
complexe sur les messages SOAP car la gestion des namespaces ne fonctionnent
pas encore (msre_action_xmlns_validate dans re_actions.c).


--[ 7. Conclusion ]-----------------------------------------------------------

Cette brève vous a présenté le fonctionnement de mod_security2 et comment il est
simplement possible de mettre en place un filtrage en amont d'une application 
Web ou d'un Webservice ayant des problèmes de sécurité.
Cependant, il ne faut pas oublier que la meilleure solution est tout de même 
d'adopter une politique de développement sécurisé dés la création de l'
application en définissant clairement les types de données attendues en entrée
et en pratiquant la programmation défensive.

                    -- Louis Nyffenegger < Louis.Nyffenegger@hsc.fr > --


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

- Le site du projet mod_security :
http://www.modsecurity.org/

- La documentation de mod_security2 :
http://www.modsecurity.org/documentation/modsecurity-apache/2.1.0/

- Brève de Stéphane Milani sur mod_security :
http://www.hsc.fr/ressources/breves/modsecurity.html

- Le site du projet Tomcat
http://tomcat.apache.org/

- Le site du projet Apache : 
http://httpd.apache.org/

- Xpath : 
http://xmlfr.org/w3c/TR/xpath/





Last modified on 24 April 2007 at 14:20:22 CET - webmaster@hsc.fr
Information on this server - © 1989-2013 Hervé Schauer Consultants