
J’en avais parlé sur la page [réseau] Sécuriser un serveur Apache/PHP/MySQL (LAMP) – voici une présentation rapide de modsecurity.
modsecurity est un WAF (Firewall WEB Applicatif) sous forme de module pour Apache (aussi disponible pour nginx).
Le module va analyser les requêtes envoyés à Apache et éventuellement les bloquer selon des règles prédéfinis (ou les laisser passer et les logguer).
Table des matières
Introduction
modsecurity permet donc de :
- détecter bloquer des attaques (SQLi, XSS etc)
- bloquer un UserAgent, des pages PHP, l’upload selon certains Mimes etc.
- toutes les rêquetes peuvent être logguées, c’est un avantage certains notamment pour les requêtes POSTs afin de détecter des attaques.
Par exemple, si l’on souhaite bloquer le UserAgent “KiKooUserAgent”, on doit créer la règle suivante :
SecRule REQUEST_HEADERS:User-Agent "KikooUserAgent" "phase:2,deny,msg:'Demo blocage userAgent'"
Ici donc, on a une directive deny. Il faut créer une règle SecDefaultAction sur la directive deny.
SecDefaultAction phase:2,deny,status:403,log,auditlog
Comme vous pouvez le constater, le serveur WEB renvoie un HTTP 403 (forbidden) et la requête est logguée.
Ainsi on obtient un HTTP 403 :
et le log correspondant à la requête :
Docs modsecurity sur les règles : http://www.modsecurity.org/documentation/modsecurity-apache/2.5.9/html-multipage/index.html
En français, vous avez : http://www.nbs-system.com/blog/modsecurity_howto.html
Les règles pour modsecurity
Il existe pas mal de packages de règles fournies gratuitement – exemple :
- http://www.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules#About_the_rules
- https://github.com/SpiderLabs/owasp-modsecurity-crs
Voici d’autres exemples de logs d’une tentative d’enregistrement d’un spam bot sur le forum.
Ce dernier est bloqué.
Ci-dessous, une tentative de spam en commentaire sur WordPress. Ce dernier est détecté comme RFI et est bloqué.
Notez que certains bots parvenaient à poster (non bloqué par Akismet), depuis la mise en place de modsecurity, plus de SPAM.
Ci-dessous, blocage d’une SQLi :
Blocage d’une attaque XSS :
Il est aussi possible de bloquer les HTTP Flood (je n’ai pas encore de recul sur cette fonctionnalité, si cela aide ou si cela est plutôt pénalisant [problème de ressources]):
Dans les autres possibilités, on peux convertir des règles snort en règles modsecurity : http://www.modsecurity.org/documentation/converted-snort-rules.html
Il est par exemple aussi possible, de faire scanner, les uploads de fichiers par clamav : https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/master/util/av-scanning/runav.pl
ou de faire communiquer modsecurity avec iptables: http://spamcleaner.org/fr/misc/modsec2ipt.html
Modsecurity et les performances
Modsecurity se greffant en amont du serveur WEB, il faut éviter de cumuler trop de règles, ce qui peux bien sûr jouer sur les performances du serveur WEB.
Dans mon cas, cela ne ressent pas.
Apache benchmark sans modsecurity :
avec modsecurity :
EDIT – Novembre 2013 : Statistiques blocage – Honeypot
Pour ceux que cela intéresse, j’ai fait une page qui donne des statistiques sur les attaques effectuées sur le serveur WEB => https://www.malekal.com/modsec/index.php
Le billet de présentation de cette page de statistiques : https://www.malekal.com/presentation-modsecurity-pour-apache/
EDIT – Aout 2015 : modsecurity avancé : antispam WordPress et phpBB
Un autre exemple d’utilisation modsecurity avancé avec un antispam pour WordPress et phpBB : modsecurity avancé : antispam WordPress et phpBB
D’autre part voici quelques règles si besoin.
Désactiver une règle sur une page précise par son ID :
<LocationMatch "/participer.php"> SecRuleRemoveById 960024 </LocationMatch>
Si l’on désire désactiver les règles sur des pages spécifiques alors on peut le faire de cette manière :
<LocationMatch "/[0-9a-zA-Z/_.+-]+\.example)"> SecRuleEngine off </LocationMatch>
Enfin pour désactiver une règle sur une page d’IP :
SecRule REQUEST_HEADERS:x-forwarded-for "@ipmatch 93.20.128.0/19" "phase:2,t:none,pass,nolog,noauditlog,ctl:ruleRemovebyID=666"