Présentation modsecurity pour Apache

modsecurity

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

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 :

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

Les règles pour modsecurity

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

modsecurity_spam_forum
modsecurity_SPAM_Wordpress

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.

modsecurity_SQLi

Ci-dessous, blocage d’une SQLi :

modsecurity_XSS

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]):

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 iptableshttp://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.

modsecurity_benchmark

Apache benchmark sans modsecurity :

modsecurity_benchmark_modsec_active

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

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"
(Visité 475 fois, 2 visites ce jour)
Noter cet article

2 Comments

  1. MODAM 12 août 2013
  2. MSN 12 août 2013

Add Comment