ModSecurity
Les règles ModSecurity optionnelles d'InfraFence pour Apache - 13 règles qui bloquent les attaques dès la première requête, activation, test, retour arrière et journal d'audit.
Dernière mise à jour:
Le pare-feu web lit les journaux après la requête. Sur Apache avec ModSecurity, InfraFence peut aussi ajouter 13 règles qui lui sont propres et refusent les attaques à l'intérieur du serveur web, dès la première requête.
Prérequis
- Apache avec le module ModSecurity (
mod_security2) déjà installé. InfraFence n'installe pas ModSecurity. - Autoriser les modifications de la configuration du serveur web activé dans Paramètres › Agent. C'est désactivé par défaut.
- Aucun panneau d'hébergement, LiteSpeed ou outil de gestion de configuration aux commandes de la configuration du serveur web. Le contrôle en lecture seule les détecte, et InfraFence ne modifie alors jamais la configuration (par exemple
cPanel manages the web server configuration and may overwrite edits).
nginx n'est pas modifié pour ModSecurity.
Ce qui est ajouté
Les règles sont placées dans /etc/modsecurity/infrafence/, incluses depuis la configuration ModSecurity existante avec IncludeOptional /etc/modsecurity/infrafence/*.conf. Chaque règle répond 403 :
| Règle | Bloque |
|---|---|
| 9910001 | Injection SQL |
| 9910002 | Cross-site scripting |
| 9910003 | Exécution de code à distance |
| 9910004 | Path traversal |
| 9910005 | SSRF, y compris les adresses de métadonnées cloud |
| 9910006 | Shellshock |
| 9910007 | Accès à des web shells |
| 9910008 | Sondes .env |
| 9910009 | Sondes de fichiers de configuration |
| 9910010 | Injection d'en-têtes |
| 9910012 | Log4Shell |
| 9910013 | Spring4Shell |
| 9910014 | User agents de scanners connus |
Les bannissements actifs sont aussi écrits sous forme de règles ModSecurity (jusqu'à 5 000 adresses), ce qui compte lorsque les visiteurs atteignent Apache via un proxy ou un CDN et que le pare-feu ne voit que le proxy.
Comment c'est appliqué sans risque
La mise en place est une transaction : l'agent sauvegarde les fichiers qu'il va modifier, écrit les règles et l'include, puis lance apachectl configtest. Si quelque chose échoue, tout est remis en l'état et le tableau de bord reçoit un événement webserver_config_error. Si le test réussit, Apache se recharge en douceur (apachectl graceful), sans couper les connexions ouvertes, et le tableau de bord reçoit modsecurity_enabled. Les rechargements sont regroupés, au plus un toutes les 5 minutes.
Désactivation
Désactiver Autoriser les modifications de la configuration du serveur web arrête toute nouvelle modification. Les règles déjà en place sont retirées par infrafence-agent uninstall --clean ou par le programme de désinstallation, là encore après un test de configuration.
Le journal d'audit
Quel que soit votre serveur web, si ModSecurity écrit un journal d'audit, l'agent le lit et signale chaque interception avec les identifiants de règle, l'URL, la méthode et le mode du moteur (ENABLED ou DETECTION_ONLY). Il trouve le journal aux emplacements habituels, ou à MODSEC_AUDIT_LOG.
Correctifs virtuels
Les correctifs virtuels pour les CVE exploitées utilisent la même configuration ModSecurity.