Dans ce tutoriel, je vais vous expliquer comment installer et configurer le Mod Security avec Apache2 sur Ubuntu pour la mise en place d’un WAF (Web Application Firewall)
Présentation du ModSecurity
ModSecurity est un module de sécurité qui s’installe avec un serveur Web Apache2 et qui permet d’ajouter une couche de sécurité en ajoutant un filtrage des requêtes.
ModSecurity va agir comme un pare-feu applicatif (Web Application Firewall) en détectant d’éventuelle attaque. Pour détecter les attaques ModSecurity s’appuie sur un liste de règle qui provient de OWASP (Open Web Application Security Project).
ModSecurty permet également de changer la signature du serveur Web et le faire passer pour un autre serveur comme IIS ou Nginx.
Le ModScurity peut aussi bien être installer sur Apache qui est utilisé comme serveur Web ou comme Reverse Proxy.
La mise en place sur Apache quand celui-ci est utilisé comme Reverse Proxy est particulièrement intéressant pour protéger un ensemble d’application en un point unique.
ModEcurity est aussi disponible pour Nginx et IIS.
Installer ModSecurity pour Apache sur Ubuntu
Pour Ubuntu, il existe un paquet tout prêt pour installer ModSecurity et le module Apache.
Entrer la commande suivante :
sudo apt install libapache2-mod-security2 -y
L’installation est terminée.
Entrer la commande suivante pour activer le module security2 sur Apache.
sudo a2enmod security2
Normalement, le module est activé à l’installation.
Le ModSecurity est installé et activé sur Apache2, nous allons passer à la configuration.
Pour activer réellement le mod_security, il faut redémarrer Apache mais il est nécessaire de passer par la configuration pour être pleinement fonctionnel.
Configurer ModSecurity
Aller dans le dossier des modules disponible pour Apache :
cd /etc/apache2/mod-available/
Dans le dossier, on retrouve le fichier de configuration de ModSecurity (security2.conf).
Regardons le contenu du fichier secyrity2.conf :
On peut voir le module charge des fichier conf qui se trouve dans le dossier
/etc/modsecurity/
et des fichiers de règles qui se trouve dans le dossier/usr/share/modsecurity-crs/
.
Aller voir dans le dossier /etc/modsecurity
/ :
cd /etc/modsecurity
Voici le contenu du dossier :
Le dossier contient aucun fichier avec l’extension .conf, de se fait pour le moment, le ModSecurity n’a pas de configuration, mais on peut voir qu’un fichier modsecurity.conf-recommended
est présent. On va utiliser ce fichier pour la configuration.
Pour se faire on va copier le fichier avec en changeant son extension :
sudo cp modsecurity.conf-recommended modsecurity.conf
Il faut maintenant éditer le fichier pour activer ModSecurity car par défaut la configuration en bloque pas les attaques.
sudo nano modsecurity.conf
Au début de fichier commenter SecRuleEngine DetectionOnly
et ajouter en dessous SecRuleEngine On
.
Redémarrer le service Apache pour la prise en compte de la configuration :
sudo systemctl restart apache2
Le ModSecurity est assez lourd et Apache peut prendre un peu plus de temps à charger.
Tester ModSecurity
Maintenant que tout est installé et configuré, on va tester le bon fonctionnement.
Depuis un navigateur, accéder à un site Web qui passe par Apache en ajoutant ceci à l’URL : a-php-file-not-exist.php?param=../../etc
.
Comme vous pouvez le voir, on a une erreur 403 (Forbidden) qui indique un blocage et non une erreur 404 (Not found).
Dans le fichier de log /var/log/apache2/modsec_audit.log
on peut la détection.
Aller plus loin avec ModSecurity
Activer le mode Debug
Pour avoir plus d’information sur les logs, il est possible d’activer le mode Debug.
Ouvrir le fichier /etc/modsecurity/modsecurity.conf
.
On va modifier les directives suivantes :
- SecDebugLog /var/log/apache2/modsecurity_debug.log
- SecDebugLogLevel 1
Redémarrer le service Apache pour la prise en compte.
Avec cette configuration, on arrive plus facilement à voir la règle qui bloque (949110).
Gérer les exceptions
Il est possible d’avoir des faux positifs et donc une règle qui bloque l’accès à une application.
Plutôt que désactiver la règle qui pourrait ne pas être un faux positif pour une autre application, on peut ajouter une exception dans la configuration du virtualhost.
Ici on va ajouter l’exception sur la règle 949110 pour le site website1 et laisser la règle active pour les autres virtualhost.
Dans le virtualhost ajouter :
<IfModule security2_module>
SecRuleRemoveById 949110
</IfModule>
Recharger la configuration d’Apache pour la prise en compte.
Je tente de nouveau d’accéder à l’URL qui a servi au test précédemment, j’arrive sur une erreur 404 maintenant.
Si je fais le test sur un autre site qui passe par le serveur Apache, j’ai toujours le blocage 403.
Changer la signature du serveur
Afin de masquer la version du serveur, je vais vous montrer comment changer la signature du serveur pour le faire passer pour un serveur IIS.
Ouvrir le fichier /etc/modsecurity/modsecurity.conf
.
Dans le fichier ajouter la ligne suivante à la fin :
SecServerSignature "Microsoft IIS10"
Maintenant sur la page d’erreur 403, la version du serveur est Microsoft IIS 10.
Dans les Header la version du serveur est aussi changé 😉
Crowdsec avec ModSecurity
Si vous avez lu plusieurs de mes tutoriels sur les serveurs Web (Apache2, Nginx, IIS), je parle régulièrement de Crowdsec pour bloquer les adresses IP malveillante.
Crowdsec dispose d’une collection qui permet d’analyser les logs de ModSecurity et de bloquer les adresses IP.
Si vous êtes dans une configuration Reverse Proxy où que votre serveur Web est publié sur Internet, je vous conseille forment de mettre les deux solutions en place pour garantir un plus haut niveau de sécurité.
Même si ModSecurity bloque déjà le trafic (au niveau 7) il peut être intéressant d’effectuer le blocage à un niveau plus bas par le pare-feu.
Vous avez maintenant toutes les informations nécessaires pour durcir la sécurité de vos serveurs Web Apache.
Avertissement