Installation et configuration de Mod_security


Lock
Mod_security est un un pare-feu applicatif qui se présente sous la forme d'un module pour le serveur Web Apache. Son rôle est de détecter et de protéger le serveur contre des attaques en tout genre : injections SQL, cross-site scripting (XSS)... Voici comment l'installer et le configurer pour une utilisation basique.




Installation et configuration de Mod_security

Installation de Mod_security

Pour installer Mod_security sur une distribution à base de RPM (Red Hat, centOS, Fedora...), ouvrez un terminal et lancez la commande suivante en root :

yum install mod_security

Ou celle-ci pour une distribution à base de Debian :

sudo apt-get install libapache2-mod-security2

Configuration basique de Mod_security

Pour mettre en place la configuration minimale sur une distribution à base de Debian, il suffit de recopier le fichier d'exemple comme ceci :

sudo cp /usr/share/doc/mod-security-common/examples/modsecurity.conf-minimal /etc/apache2/conf.d/mod-security.conf

Pour une distribution à base de RPM (Red Hat, CentOS...), la configuration par défaut est déjà installée dans le dossier /etc/httpd/modsecurity.d.

L'étape suivante sera la mise en place de quelques options de base pour que le module fonctionne correctement. Voici un exemple de configuration à mettre à la fin du fichier /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf :

# On active mod_security pour tous les sites
SecRuleEngine On

# Signature du serveur
SecServerSignature "Skynet"

# On autorise mod_security a analyser 
# le corps des requets et des reponses
SecRequestBodyAccess On
SecResponseBodyAccess Off

# Taille maximum des requetes recues (128k)
SecRequestBodyLimit 131072

# Store up to 128 KB in memory
SecRequestBodyInMemoryLimit 131072

# Taille maximum des requetes de reponse (512k)
SecResponseBodyLimit 524288

# On indique un repertoire ou mod_security peut stocker des informations
SecDataDir "/var/tmp/modsecurity"

# Gestion des logs
# Les trois options sont On, Off et RelevantOnly
# Permet de ne journaliser que les requetes qui generent une alerte
SecAuditEngine RelevantOnly
# On precise quels statuts doivent etre journalise
# Ex: ^[45] log les erreurs 4XX et 5XX du serveur
SecAuditLogRelevantStatus ^5
SecAuditLogParts ABIFHZ
SecAuditLogType Serial
SecAuditLog /var/log/httpd/modsecurity-audit.log

# Gestion du log de debuggage
SecDebugLog /var/log/httpd/modsecurity-debug.log
SecDebugLogLevel 0

On créé ensuite le répertoire qui contiendra des informations pour Mod_security :

mkdir /var/tmp/modsecurity
chown -R apache:apache /var/tmp/modsecurity

Et on relance Apache pour prendre en compte les modifications :

/etc/init.d/httpd restart

Et on scrute les fichiers de logs pour détecter les éventuels problèmes :

tail -f /var/log/httpd/modsecurity-audit.log
tail -f /var/log/httpd/error_log

Pour ma part, j'ai remarqué que dans les logs le message suivant revenait souvent :

Request Missing a Host Header
Request Missing an Accept Header
Request Missing a User Agent Header
...

Cela arrive quand le client qui se connecte au serveur utilise des headers mal configurés. Ce n'est pas vraiment un problème de sécurité en soit, à moins d'être paranoïaque. J'ai donc désactivé la couche qui vérifie les en-têtes comme ceci :

cd /etc/httpd/modsecurity.d/base_rules/
mv modsecurity_crs_21_protocol_anomalies.conf \
modsecurity_crs_21_protocol_anomalies.conf.disable

J'ai également désactivé les règles qui détectent les mauvais robots. Car celles-ci bloquent les requêtes faite sur le site avec wget ou curl, or beaucoup d'articles publiés préconisent d'utiliser ces commandes :

mv modsecurity_crs_35_bad_robots.conf \
modsecurity_crs_35_bad_robots.conf.disable

Désactivation de Mod_security pour un site web précis

L'utilisation de Mod_security a eu quelques effets de bord sur Tux-planet. En effet, j'ai eu pas mal de problèmes avec l'interface d'administration de WordPress. Le module avait tendance à bloquer certaines actions comme l'écriture d'articles ou la modifications d'options...

De nombreux sites donnent des règles d'exception à appliquer, pour moi, elles ne fonctionnaient pas. Comme je suis le seul à accéder à l'interface de gestion et que celle-ci est déjà protégée par un .htaccess, j'ai choisi de désactiver le module de sécurité pour cette partie du site.

Voici un exemple de configuration Apache à utiliser pour désactiver Mod_security sur un virtuahost :

# On desactive Mod_security pour l'admin de wordpress
<LocationMatch "/wp-admin">
  <IfModule mod_security2.c>
    SecRuleEngine Off
  </IfModule>
</LocationMatch>

Test de sécurité

Je déconseille fortement la mise en place de Mod_security sur un serveur en production, ne serait-ce parce que ce genre de firewall applicatif génère des faux-positifs. Voici quelques exemples de tests que l'on peut réaliser. Les actions suivantes doivent par exemple être bloquées :

  • saisir "OR 1=1" dans un champ de recherche
  • ajouter "<script>xss</script>" à la fin d'une url du site
  • ajouter "/../../etc/passwd" à la fin d'une url du site
  • ...

Pensez également à tester les formulaires légitimes. Par exemple, l'ajout de commentaires pour un site à base de WordPress, ou l'ajout de message sur un forum doivent fonctionner normalement.


8 Commentaires pour "Installation et configuration de Mod_security"

Flux des commentaires de cet article Ajouter un commentaire
  •  

    Bon tuto :)

    (c'est drole, "Skynet" est le nom de notre ERP interne a ma boite :p )

    RépondreRépondre
    bourvill , le 14 janvier 2011 à 09:10
  •  

    Sa à l'air sympa, je vais tester cela :)

    RépondreRépondre
    totof , le 14 janvier 2011 à 11:09
  •  

    Merci pour ce tuto clair et très intéressant ;-)

    RépondreRépondre
    fabien , le 14 janvier 2011 à 12:28
  •  

    Merci pour le tuto clair et précis, j'ai juste une question concernant le schéma de Mod_security c'est créé avec quel logiciel ?

    RépondreRépondre
    Slown , le 15 janvier 2011 à 11:35
  •  

    @bourvill : Skynet is here, la fin du monde est proche.

    @totof : pendant ta période de test, scrute bien les fichiers de logs, les faux positifs peuvent-être nombreux...

    @fabien : de rien

    @Slown : aucune idée; l'image viens du site officielle.

    RépondreRépondre
    pti-seb , le 15 janvier 2011 à 13:16
  •  

    Voici une commande qui permet d'analyser uniquement les requêtes que mod security à blocqué avec les code 403 (forbidden), plutôt pratique :

    cat /var/log/httpd/modsecurity-audit.log | grep -B1 "Access denied with code 403" | more

    RépondreRépondre
    pti-seb , le 15 janvier 2011 à 14:31
  •  

    @pti-seb : useless use of cat ! :

    grep -B1 "Access denied with code 403" /var/log/httpd/modsecurity-audit.log |more

    :-)

    RépondreRépondre
    olafkewl , le 15 janvier 2011 à 19:09
  •  

    Merci pour cet article. Cependant, je ne comprends pas pourquoi tu déconseilles la mise en oeuvre de mod_security sur un serveur de production. Quel serait son intérêt dans ce cas ? Tu veux peut-être dire qu'il faut d'abord tester sa configuration sur un environnemment de recette ou de préprod ?

    RépondreRépondre
    anyone , le 1 janvier 2014 à 17:29
 

Ajouter un commentaire

actualité android apache apple astuce astuces bash bilboblog blog boot chrome clavier commande commandes conky date debian Desktop développement elementary exploit faille fedora firefox flash gimp gnome google graphique Graphisme hack hacking Hardware humour intel internet iphone jailbreak Jeux Kde kernel libre Linux log logiciels Logiciels Libres lucid lynx maemo mail maquette metasploit microsoft mobile mockup monitoring mozilla multi-touch musique mysql n900 nautilus nokia noyau openoffice open source password photos php Planet publicité redhat red hat rpm réseau screenshot script serveur serveurs shell sql ssh statistiques sysadmin system Sécurité thème tux-planet tv twitter ubuntu unity vidéo vidéos vlc voyage wallpaper windows wordpress yum