 |
|
|
| |
| PRATIQUE OUTILS |
|
|
|
| Installer et configurer ModSecurity |
| |
| Découvrez les principales directives et règles propres à sécuriser les requêtes HTTP reçues par votre site Web.
(11/01/2006) |
 |
 |
Forum |
|
|
Réagissez
dans les forums
de JDN Développeurs
|
Utilisé seul ou en tant que module Apache, ModSecurity
est aujourd'hui l'une des défenses de base des serveurs Web
- sans y perdre en robustesse pour autant. Son rôle est principalement
de protéger les sites des attaques possibles, comme les injections
de script, et vise à prévenir tous les types d'intrusion en provenance
de l'utilisateur, par le biais d'un grand nombre de filtres,
de techniques et d'analyses, au plus proche du protocole HTTP.
Mais l'outil n'est pas forcément plug'n'play : autant
l'installation est simple, autant la configuration peut se révéler
plus laborieuse - surtout qu'il est nécessaire de personnaliser
son fonctionnement, afin de ne pas le laisser tourner avec les
réglages de base... ModSecurity facilite largement la tâche
de sécurisation d'un serveur Web, mais l'objectif étant de le sécuriser
sans rendre l'existant inaccessible, la tâche est plus délicate.
ModSecurity
est disponible en
téléchargement sous forme de binaires pour plusieurs systèmes (Apache
et Netware pour Windows, FreeBSD, Debian et Gentoo), mais les
utilisateurs les plus avertis compileront directement le code
source. Une fois le module placé au bon endroit, il faudra le
déclarer auprès du serveur Web, en ajoutant une ligne au fichier
/etc/httpd.conf, par exemple
AddModule mod_security.c pour
Apache 1.3.x, ou LoadModule security_module
modules/mod_security.so pour Apache 2.0. Il suffira ensuite
de relancer Apache pour prendre le module en compte.
La configuration se fait ensuite directement dans le fichier
httpd.conf, dans .htaccess
si besoin est, ou simplement dans son propre fichier, à créer
soi-même et à lier depuis httpd.conf
(par exemple, avec Include conf/modsecurity.conf).
L'activation se fait à l'aide de la directive suivante :
SecFilterEngine On
Ses possibilités sont On, Off
(ne rien traiter) et DynamicOnly.
Cete dernière permet de ne prendre en compte que les
requêtes destinées à des pages statiques, et donc de ne pas
perdre du temps à laisser des tests sur les requêtes de pages
statiques.
Il faudra ensuite lui indiquer de vérifier les requêtes POST
en plus des habituelles GET.
Cette directive prend en compte, par défaut, les données envoyées
par formulaire et lors d'envois de fichiers, mais peut être
étendue.
SecFilterScanPOST On
Il sera également toujours bon de conserver une trace écrite
des traitements positifs du module. L'administrateur pourra
en parcourant le log trouver moult informations pour
cibler ou amoindrir ses filtres :
SecAuditEngine RelevantOnly
SecAuditLog logs/modsec_log
ModSecurity permet également de cacher sa version d'Apache,
une information parfois donnée trop facilement aux scripts qui
circulent. On ne lui autorise ici qu'à afficher son nom :
SecServerSignature "Apache"
Enfin, il est de bon aloi de disposer d'un comportement par
défaut, que le serveur doit adopter face à toute requête ne
passant pas les filtres mis en place. On lui demande ici de
bloquer la requête, de la noter, et de renvoyer un code HTTP
412 (signifiant : "la précondition donnée dans la requête a
échoué") :
SecFilterDefaultAction "deny,log,status:412"
Ensuite viennent les règles elles-mêmes. Elles sont nombreuses,
et la plupart peuvent être configurées selon les besoin et visiteurs
du site. Chacune est donc à tester pleinement lors de son ajout,
et il n'est pas recommandé d'ajouter une palanquée de règles
d'un coup, si l'on ne veut pas se retrouver à les retirer une
à une pour trouver celle qui rend le site inaccessible au plus
gros des visiteurs...
La plus simple est SecFilter.
Elle permet de préciser un mot-clef fatal (SecFilter
lapinot), avec expression régulière au besoin (SecFilter
mon[[:space:]]lapinot), un chemin à refuser (SecFilter
/bin/sh), ou tout l'inverse (SecFilter
!lapinot : la requête doit contenir "lapinot").
Rapide à mettre en place mais trop généraliste...
|
Forum |
|
|
Réagissez
dans les forums
de JDN Développeurs
|
ModSecurity peut en utiliser de nombreuses autres, et donne
les moyens d'être très précis dans les traiterments
à infliger aux requêtes. Une liste complète
se trouve sur le site
officiel. Prenez garde cependant à ne pas utiliser
toutes les règles possibles et imaginables, car chacune
nécessite un temps de traitement non négligeable...
|
|
|
|
|
|
|
