Présentation modsecurity pour Apache

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

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 :

modsecurity_bloque_UA


et le log correspondant à la requête :
modsecurity_bloque_UA2

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

Il existe pas mal de packages de règles fournies gratuitement – exemple :

Voici d’autres exemples de logs d’une tentative d’enregistrement d’un spam bot sur le forum.
Ce dernier est bloqué.
modsecurity_spam_forum
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.modsecurity_SPAM_Wordpress

 

Ci-dessous, blocage d’une SQLi : modsecurity_SQLi

Blocage d’une attaque XSS : modsecurity_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]):

modsecurity et DDoS

modsecurity et DoS

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

avec modsecurity :
modsecurity_benchmark_modsec_active

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 => http://www.malekal.com/modsec/index.php
Le billet de présentation de cette page de statistiques : http://www.malekal.com/2013/10/31/honeypot-web-statistiques-des-attaques-web-sur-malekal-com/

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>

Désactiver les règles sur des pages spécifiques – les regex sont autorisées:

<LocationMatch "/[0-9a-zA-Z/_.+-]+\.example)">
 SecRuleEngine off
 </LocationMatch>

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"

Comment lire d'autres tutoriels de malekal.com ?

Si le site vous a aidé, svp, débloquez les bloqueurs de publicités, n'hésitez pas non plus à partager l'article ou le site sur les réseaux sociaux.

Pour pouvoir lire plus d'articles et tutoriels, utilisez le menu en haut du site. Plein d'articles et tutos utiles vous attendent !

Besoin d'aide ?

Posez votre question ou soumettez votre problème sur le forum malekal.com pour obtenir une aide efficace : Aller sur le forum malekal.com
(Visited 138 times, 1 visits today)

2 thoughts on “Présentation modsecurity pour Apache

  1. Notez bien qu’une configuration mal ajustée entrainera de manière rapide vos serveurs vers les abimes, évaluez bien vos besoins, réfléchissez aux situations et surtout à la nécessité ou non … d’utiliser les fonctionnalités de logging. Si l’attaquant repère une faiblesse dans les journalisations ( ou autres ), il n’aura aucun mal à les exploiter pour sursaturer vos propres mécanismes de défense et ainsi utiliser ce camouflage temporaire pour mener une attaque ciblée plus complexe.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *