|
|
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
|
