ModSecurity and increasingly high CPU usage by httpd Apache process
Nous avons été confrontés à un ralentissement massif du serveur lors des premières semaines d'une migration de CEntOS 7 vers AlmaLinux 8. Voici un aperçu de la situation.
Problème
Sur un serveur Plesk 18 avec plusieurs sites Web hébergés, les process httpd utilisent beaucoup de CPU et les requêtes sont parfois lentes. La situation s'aggrave avec le temps. Plesk fonctionne avec des paramètres normaux (pas de personnalisation majeur) et utilise ModSecurity 2.9 sur Apache avec les règles Comodo.
Que se passe-t-il réellement
Les requêtes utilisent beaucoup de CPU en raison du jeu de règles ModSecurity. La désactivation temporaire de ModSecurity le démontre.
Le fichier /var/lib/mod_security/apache-ip.pag devient de plus en plus volumineux rapidement et ralentit les requêtes à mesure qu'il grandit.
Solutions
Solution 1 : utiliser un autre ensemble de règles
Le passage à ModSecurity 3.0 sur nginx avec l'ensemble de règles OWASP a résolu le problème. Mais il s’agit d’un ensemble de règles complètement différent.
Si cette solution est utilisée, il peut être judicieux de s'assurer que les requêtes transitent autant que possible par nginx, en s'assurant que tous les sites Web utilisent l'application FPM servie par nginx. Mais toutes [les requêtes semblent passer par nginx de toute façon](https://docs.plesk.com/en-US/obsidian/administrator-guide/web-servers/apache-and-nginx-web-servers-linux/apache- with-nginx.70837/), donc je ne suis pas sûr que cela soit obligatoire.
La requête SQL suivante vers la base de données psa peut donner une liste rapide de tous les sites Web n'utilisant pas ce gestionnaire PHP :
SELECT d.name, wsp.value FROM domains AS d
LEFT JOIN dom_param as dp ON dp.dom_id = d.id AND param = "webServerSettingsId"
LEFT JOIN WebServerSettingsParameters as wsp ON wsp.webServerSettingsId = dp.val AND wsp.name = "nginxServePhp"
WHERE wsp.value = "false"
Solution 2 : vider le fichier
Un fichier apache-ip.pag vide ou léger devrait également résoudre le problème. Par exemple, exécuter cette commande quotidiennement permettrait de garder la base de données gérable :
cat /dev/null > /var/lib/mod_security/apache-ip.dir
cat /dev/null > /var/lib/mod_security/apache-ip.pag
service httpd restart
Mais vider ce fichier signifie perdre des données, et pourrait également affaiblir la sécurité puisque ces données pourraient être utilisées par les règles ModSecurity.
Solution 3 : gérer correctement apache-ip.pag
Gérer correctement apache-ip.pag, ou du moins comprendre pourquoi il ne se comporte pas correctement serait la meilleure solution. Cependant, nous n’y sommes pas arrivés.
Les chemins possibles vers cette solution seraient :
- Analyse des logs plus exhaustive
- Scripts de nettoyage réguliers intelligents utilisant
modsec-sdbm-util(ou quelque chose de similaire) pour garderapache-ip.pagdans un état propre.