Installation de mod_security devant un serveur web Apache
Sommaire
I. Présentation de mod_security
Les applications et les portails web sont les éléments les plus attaqués et ils constituent le plus grand vecteur d'intrusion de nos jours, le fait est qu'ils sont quasi systématiquement présents lorsqu'une entreprise souhaite avoir une vue sur Internet et qu'ils engendrent forcément des interactions entre les visiteurs et le système de l'entreprise, que ce soit le l'OS, le code PHP/HTML, la base de données ... Il s'agit là de la porte d'entrée la plus commune pour les pirates informatique. Il est donc important de sécuriser un minimum cette porte d'entrée sur votre système d'information.
Le module tiers mod_security (module de sécurité) permet un filtrage applicatif web, c'est un outil très performant écrit à la base en tant que module Apache et ensuite exporté sur d'autres plates-formes comme Nginx ou Microsoft IIS. Nous allons ici faire un rapide tour des fonctionnalités de l’outil et ensuite voir son installation et son utilisation standard.
La fonction principale de mod_security est donc le filtrage des requêtes et des réponses générées entre les clients (visiteurs) et votre application ou site web. On appelle cela un Pare-feu applicatif ou un pare-feu web (Web Application Firewall - WAF) car il agit sur la couche 7 (application) du modèle OSI. La plupart des pare-feu au sens commun travaillent quant à eux sur la couche 3 et agissent au niveau des ports (port 22 SSH, port 80 Web...). Les WAF comme Mod_security vont eux beaucoup plus loin dans la lecture du contenu des paquets afin d'y voir et d'y filtrer plus d'informations.
Le filtrage en soi n'a aucun intérêt, c'est ce qui en découle qui est important. Mod_security peut remplir une mission de journalisation, c'est à dire de loger certaines réponses ou certaines requêtes ou alors de blocage sous certaines conditions que l'on appelle règle, nous verrons cela un peu plus tard. Dans certains cas ou certaines utilisations, mod_security peut également réécrire, ou plutôt corriger, des URL mal-formées afin de ne pas perturber l'application ou le site web qui traitera ces requêtes.
Mod_security accueille également des fonctionnalités avancées ou annexes comme la possibilité d'échange avec des pare-feu de plus bas niveau par l'exécution de scripts. Pour exemple, à la détection consécutive de plusieurs transgressions à des règles venant d'une même IP, on peut faire lancer à mod_security un script qui va demander au pare-feu de niveau 3 de bloquer cette IP. On trouve aussi la gestion et l'analyse de l'upload de fichiers ou la mesure de performance sur ses actions et sur le traitement/analyse des requêtes.
Note : Le tutoriel est effectué sur des machines Debian 7 avec Apache 2.2.22 et mod_security 2.6.6
II. Architecture mod_security Apache
Il faut savoir que mod_security est communément utilisé de deux façons, on peut soit l'utiliser en combinaison à un ProxyPass qui va donc être sur un serveur en amont du serveur web pour filtrer les requêtes, puis lui transmettre celles que mod_security juge légitimes. On peut alors représenter cette structure comme suivant :
On peut également directement installer mod_security sur le serveur web où se situe le site ou l'application web. Cela dans un but d'économie de machine bien entendu. Il faut savoir que le traitement et l'analyse des requêtes peuvent avoir un impact plus ou moins important sur la consommation des ressources par Apache sur le système, il faut donc évaluer cette consommation et prendre la bonne décision selon votre cas de figure. L'effet sur la protection de mod_security ne change pas d'une architecture à l'autre, si ce n'est que l'architecture qui semble la plus rassurante est la première étant donné qu'une requête malveillante n'atteindra pas le serveur web final (de manière "physique" disons):
Pour l'illustration du tutoriel, nous allons suivre la première architecture. Je vais mettre en tant que serveur web l'application DVWA (Damn Vulnerable Web Application) qui est une application web contenant un tas de vulnérabilités à exploiter. Le but ici est de tester ces vulnérabilités au travers de notre mod_security afin de voir s'il fait bien son travail.
Note : l'installation du serveur web et de DVWA ne sera pas expliquée ici, je pars du principe que le serveur web est déjà en place.
Sur le serveur dit mod_security (Reverse Proxy), nous allons utiliser le module ProxyPass afin de faire passer les requêtes d'un serveur à un autre, vous pourrez trouver plus d'informations sur l'utilisation de ce module dans mon tutoriel sur l'installation d'un reverse proxy Apache avec mod_proxy. Voici donc l'architecture sur laquelle je vais me baser dans ce tutoriel :
J'ai donc une "IP publique" qui est celle vers laquelle mes DNS vont pointer lorsque je souhaiterais joindre mon serveur web (192.168.31.167) puis un réseau internet pour y cacher mon serveur web qui au final ne sera contacté que par le reverse proxy après qu'il ait validé les requêtes entrantes.
III. Installation de mod_security
Nous allons maintenant passer à l'installation de mod_security.
A. Cas d'une architecture à deux serveurs
Note : Pour ceux qui sont dans le contexte de notre deuxième schéma d'infrastructure (mod_security et sites web sur un même serveur), passez directement à la partie III.B
La première chose que nous allons faire ici est de s'arranger pour que les requêtes transmises au serveur mod_security soient bien transmises au serveur web. Je passe pour cela par ProxyPass comme je l'ai dit précédemment. Ceci n'étant pas le sujet du tutoriel, je mets ici directement la configuration et les commandes utilisées :
On désactive le site par défaut et on active le module proxy_http
a2dissite default a2enmod proxy_http
Création d'un nouveau vhost :
vim /etc/apache2/sites-availables/waf
Voici la configuration à mettre dans ce fichier :
< VirtualHost *:80 >
ServerName www.dvwa.tuto
ProxyPreserveHost On
ProxyRequests On
ProxyPass / http://192.168.248.132/
ProxyPassreverse / http://192.168.248.132/
< /Virtualhost >
On active le nouveau vHost et on recharge Apache2 :
a2ensite waf service apache2 reload
Nous pouvons alors accéder à l'application web en saisissant l'URL de celle-ci, on peut également y accéder via l'IP étant donné que mod_security n'est pas encore installé.
Note : A ce stade, il est important de joindre son serveur web via une URL et non par l'IP. Mod_security bloque les requêtes HTTP 1.0 (autrement dit les requêtes HTTP via IP), c'est néanmoins une règle que nous pourrons désactiver plus tard. Pensez donc aux enregistrements DNS si besoin.
B. Mise en place du firewall applicatif mod_security
Nous allons (enfin) pouvoir passer au plus intéressant : l'installation du module mod_security. Étant sous Debian, je saisis la commande suivante :
apt-get install libapache-mod-security
On voit donc les dépendances du paquet :
Le répertoire /etc/modsecurity est alors créé avec une configuration par défaut qu'il faut renommer pour qu'elle soit effective :
cd /etc/modsecurity mv modsecurity.conf-recommended modsecurity.conf
Pour information, dans /etc/apache2/mod-enabled se trouvent les fichiers suivants :
Dans le mod-security.conf des modules apache2 on trouve :
On voit donc que tous les fichiers terminant par .conf dans le dossier /etc/modsecurity sont pris en compte, les autres non. La première chose à faire est donc de voir ce qui se trouve dans la configuration de mod-security. On va pour cela faire un tour dans le fichier /etc/modsecurity/modsecurity.conf.
Par défaut, on voit que la valeur SecRuleEngine est positionnée sur "Detection Only", comme je le disais un peu plus haut dans le tutoriel, mod-security est ici sur un mode de journalisation uniquement, il ne va donc rien bloquer, mais journaliser ce qui lui semble suspect. On va passer cette valeur à "On" comme suivant :
Pour une utilisation standard, le reste de la configuration par défaut devrait suffire. On sauvegarde donc le fichier.
IV. Gestion des CRS, les règles de filtrages
Une fois que mod_security est installé, il ne fait à vrai dire pas grand-chose. Toute la force de mod_security réside dans les règles qu'on lui demande d'appliquer aux requêtes et réponses qu'il filtre. Ces règles se nomment CRS (Core Rule Set), il en existe des exemples qui sont stockés sur le système, mais non utilisés à l'installation de mod_security. On peut également trouver les dernières versions en ligne sur le site de l'OWASP qui diffuse et met à jour gratuitement ces règles.
Les CRS ont pour force qu'elles font que mod_security devient un outil de protection "générique" au sens où il protège contre des types d'attaques (exemple : SQL injection, XSS, XST) plutôt que des vulnérabilités. On sait qu'une SQL injection aura "plus ou moins" une syntaxe reconnaissable, en revanche on ne sait peut être pas qu'une application y est vulnérable tant qu'un CVE n'a pas été diffusé et que la vulnérabilité n'a pas été révélée. Mod_security peut néanmoins protéger un site web contre une injection SQL au sens où il sait reconnaître sa syntaxe, on peut étendre cet exemple à des méthodes HTTP, des syntaxes de LFI/RFI, etc.
Dans un premier temps, nous allons utiliser les règles présentes par défaut sur le système, celles-ci se cachent dans /usr/share/modsecurity-crs :
On trouve alors ici plusieurs types de CRS (règles), règles de base, règles expérimentales, règles optionnelles ... Pour connaitre la version de ces règles, on peut regarder la version du paquet mod_security-crs :
Nous sommes ici en version 2.2.5.2. Dans un premier temps nous allons mettre en place les règles de base et voir leurs effets sur notre application web. On copie donc ces règles dans le dossier de configuration de mod_security :
mkdir /etc/modsecurity/activated_rules
On va ensuite lier les différentes règles dans ce dossier pour qu'elles soient incluses.
ln -s /usr/share/modsecurity-crs/base_rules/* /etc/modsecurity/activated_rules cp /usr/share/modsecurity-crs/modsecurity_crs_10_setup.conf /etc/modsecurity
Puis on demande au module mod-security d'Apache d'inclure ces fichiers :
vim /etc/apache2/mods-enabled/mod-security.conf
On y ajoute cette ligne :
Puis on recharge apache afin de que les différentes modifications de configuration faites soient prises en compte.
service apache2 reload
V. Tests de protection des règles de filtrage mod_security
Maintenant que nous avons mis en place les règles basiques, nous pouvons essayer d'en tester quelque une. Afin d'avoir un effet garanti de mon Firewall applicatif sur mon application protégée, j'ai décidé de mettre en place DVWA comme je l'ai dit plus haut. DVWA propose par exemple un cas d'attaque par injection SQL, nous allons prendre ce challenge comme exemple d'attaque. Je me connecte donc sur l'application et vais dans la partie SQL Injection, j'ai donc un champ à remplir dans lequel je vais mettre une chaîne de caractères souvent utilisée lors des injections SQL : OR '1' = '1
Je clique ensuite sur "Submit" pour envoyer ma requête qui va alors être analysée et traitée par Mod_security avant d'atteindre le serveur web. Et j'obtiens une erreur 403 "Forbidden" :
Il s'agit là de mod_security qui m'a tout simplement bloqué. On pourra avoir plus d'informations et confirmation du blocage dans le fichier /var/log/apache2/modsec_audit.log qui contient la journalisation des évènements de mod_security :
On voit alors l'horodatage de la journalisation, l'IP du client ayant générée la journalisation, mais également la requête HTTP qu'il a envoyée, un peu plus bas nous aurons des informations plus intéressantes :
En effet, on voit ici qu'il y a bien eu un access denied (erreur 403) et également que c'est une correspondance avec un pattern (une règle de chaîne de caractère) du fichier modsecurity_crs_41_sql_injection_attacks.conf qui a causé ce blocage. On en sait un peu plus sur l'attaque générée et également sur la règle qui a généré le blocage, ce qui est pratique dans des cas de faux positifs par exemple.
Il existe quantité de règles dans le système qui peuvent être ajoutées au "activated rules" prises en compte, on pourra également en écrire nous même pour avoir des règles plus précises et plus spécifiques à notre système, nous aborderons certainement ce sujet dans d'autres tutoriels. J'espère vous avoir fait une bonne introduction à ce qu'est mod_security et à son utilisation la plus standard. Il existe beaucoup de façons supplémentaires de l'utiliser, n'hésitez pas à proposer des sujets de discussion ou de tutoriels dans le forum pour échanger là dessus.
Super intéressant ! Article très bien fait merci beaucoup je comprends maintenant ce que ça veut dire ce fameux « mod_security »
après faire les étapes d’installation de ModSecurity. Comment tester le résultat
Super interessant! juste pour signaler une petite erreur dans la configuration du reverse proxy, j’ai passé une heure a trouver la sotution. En fait nous devez remplacer « ProxyPerserveHost On » par « ProxyPreserveHost On «
trés interessant votre article. j’aimerais savoir si cela est possible sous Win 7.
Merci pour le tuto, à noter cependant qu’il n’est plus à jour sur 2 points importants :
1) Le paquet Debian s’appelle dorénavant
libapache2-mod-security2
2) il ne crée plus de repertoire /usr/share/modsecurity-csr ni de regles *.csr par défaut comme présenté dans l’exemple ; il faut impérativement récupérer et activer les règles OSWAP avant de pouvoir tester quoi que ce soit.