1.10. Sécurisation des applications web sur un serveur web à l'aide de ModSecurity
ModSecurity est un pare-feu d'application web (WAF) open source supporté par divers serveurs web tels qu'Apache, Nginx et IIS, qui réduit les risques de sécurité dans les applications web. ModSecurity fournit des ensembles de règles personnalisables pour configurer votre serveur.
Le paquet mod_security-crs contient l'ensemble de règles de base (CRS) avec des règles contre les scripts intersites, les mauvais agents utilisateurs, les injections SQL, les chevaux de Troie, les détournements de session et d'autres exploits.
1.10.1. Déployer le pare-feu applicatif web ModSecurity pour Apache
Pour réduire les risques liés à l'exécution d'applications web sur votre serveur web en déployant ModSecurity, installez les paquets mod_security et mod_security_crs pour le serveur HTTP Apache. Le paquet mod_security_crs fournit l'ensemble de règles de base (CRS) pour le module ModSecurity de pare-feu applicatif basé sur le web (WAF).
Procédure
Installez les paquets
mod_security,mod_security_crs, ethttpd:# dnf install -y mod_security mod_security_crs httpdDémarrez le serveur
httpd:# systemctl restart httpd
Vérification
Vérifiez que le pare-feu d'application web ModSecurity est activé sur votre serveur HTTP Apache :
# httpd -M | grep security security2_module (shared)Vérifiez que le répertoire
/etc/httpd/modsecurity.d/activated_rules/contient les règles fournies parmod_security_crs:# ls /etc/httpd/modsecurity.d/activated_rules/ ... REQUEST-921-PROTOCOL-ATTACK.conf REQUEST-930-APPLICATION-ATTACK-LFI.conf ...
1.10.2. Ajouter une règle personnalisée à ModSecurity
Si les règles contenues dans l'ensemble de règles de base (CRS) de ModSecurity ne correspondent pas à votre scénario et si vous souhaitez prévenir d'autres attaques possibles, vous pouvez ajouter vos propres règles à l'ensemble de règles utilisé par le pare-feu applicatif basé sur le web de ModSecurity. L'exemple suivant illustre l'ajout d'une règle simple. Pour créer des règles plus complexes, voir le manuel de référence sur le site web ModSecurity Wiki.
Conditions préalables
- ModSecurity pour Apache est installé et activé.
Procédure
Ouvrez le fichier
/etc/httpd/conf.d/mod_security.confdans un éditeur de texte de votre choix, par exemple :# vi /etc/httpd/conf.d/mod_security.confAjoutez l'exemple de règle suivant après la ligne commençant par
SecRuleEngine On:SecRule ARGS:data "@contains evil" "deny,status:403,msg:'param data contains evil data',id:1"
La règle précédente interdit l'utilisation de ressources à l'utilisateur si le paramètre
datacontient la chaîneevil.- Enregistrez les modifications et quittez l'éditeur.
Redémarrez le serveur
httpd:# systemctl restart httpd
Vérification
Créer une
test.htmlpage :# echo "mod_security test" > /var/www/html/test.htmlRedémarrez le serveur
httpd:# systemctl restart httpdDemande
test.htmlsans données malveillantes dans la variableGETde la requête HTTP :$ curl http://localhost/test.html?data=good mod_security testDemande
test.htmlavec des données malveillantes dans la variableGETde la requête HTTP :$ curl localhost/test.html?data=xxxevilxxx <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>403 Forbidden</title> </head><body> <h1>Forbidden</h1> <p>You don't have permission to access this resource.</p> </body></html>Vérifiez le fichier
/var/log/httpd/error_loget localisez l'entrée du journal concernant le refus d'accès avec le messageparam data containing an evil data:[Wed May 25 08:01:31.036297 2022] [:error] [pid 5839:tid 139874434791168] [client ::1:45658] [client ::1] ModSecurity: Access denied with code 403 (phase 2). String match "evil" at ARGS:data. [file \N- "/etc/httpd/conf.d/mod_security.conf\N"] [line \N- "4\N"] [id \N- "1\N"] [msg \N- "param data contains evil data\N"] [hostname \N- "localhost\N"] [uri \N- "/test.html\N"] [unique_id \N- "Yo4amwIdsBG3yZqSzh2GuwAAAIY\N"]
Ressources supplémentaires
