Comment installer et configurer ModSecurity avec NGINX

ModSecurity 3.x (libmodsecurity) nécessite plusieurs dépendances. Installez-les selon votre distribution :

Ubuntu/Debian :

sudo apt update
sudo apt install -y apt-utils autoconf automake build-essential \
  git libcurl4-openssl-dev libgeoip-dev liblmdb-dev libpcre2-dev \
  libtool libxml2-dev libyajl-dev pkgconf wget zlib1g-dev

RHEL/CentOS/Rocky :

sudo dnf install -y gcc-c++ flex bison yajl curl-devel zlib-devel \
  pcre2-devel autoconf automake git curl make libxml2-devel \
  pkgconfig libtool httpd-devel lmdb-devel GeoIP-devel

Clonez le dépôt ModSecurity et compilez la bibliothèque :

cd /opt
sudo git clone --depth 1 -b v3/master --single-branch https://github.com/owasp-modsecurity/ModSecurity
cd ModSecurity

# Initialiser et mettre à jour les sous-modules
sudo git submodule init
sudo git submodule update

# Compiler et installer
sudo ./build.sh
sudo ./configure
sudo make
sudo make install

Le connecteur ModSecurity pour NGINX intègre libmodsecurity à NGINX en tant que module dynamique :

# Cloner le connecteur
cd /opt
sudo git clone --depth 1 https://github.com/owasp-modsecurity/ModSecurity-nginx.git

# Récupérer votre version de NGINX
nginx -v

# Téléchargez les sources NGINX qui correspondent EXACTEMENT à votre version installée.
# Remplacez 1.30.4 ci-dessous par la version indiquée par 'nginx -v'
# (1.30.4 est la version stable actuelle au moment de la rédaction).
wget http://nginx.org/download/nginx-1.30.4.tar.gz
tar -xzf nginx-1.30.4.tar.gz
cd nginx-1.30.4

# Compiler le module dynamique
./configure --with-compat --add-dynamic-module=../ModSecurity-nginx
make modules

# Copier le module dans le répertoire des modules de NGINX
sudo cp objs/ngx_http_modsecurity_module.so /etc/nginx/modules/

Chargez le module ModSecurity dans votre configuration NGINX :

Ajoutez cette ligne tout en haut de /etc/nginx/nginx.conf (avant le bloc events) :

load_module modules/ngx_http_modsecurity_module.so;

Testez la configuration :

sudo nginx -t

Vous devriez voir : syntax is ok et test is successful.

Mettez en place le répertoire de configuration de ModSecurity et la configuration de base :

# Créer l'arborescence de répertoires
sudo mkdir -p /etc/nginx/modsec

# Copier la configuration recommandée
sudo cp /opt/ModSecurity/modsecurity.conf-recommended /etc/nginx/modsec/modsecurity.conf

# Copier le fichier de correspondance Unicode
sudo cp /opt/ModSecurity/unicode.mapping /etc/nginx/modsec/

Le fichier recommandé est livré avec SecRuleEngine DetectionOnly. Modifiez /etc/nginx/modsec/modsecurity.conf et ne faites passer le moteur en mode blocage qu'une fois les faux positifs éliminés :

# Modifiez cette ligne :
SecRuleEngine DetectionOnly

# En (une fois prêt pour la production) :
SecRuleEngine On

L'OWASP Core Rule Set offre une protection complète contre les attaques courantes. Le projet CRS recommande d'installer une version taguée et prise en charge plutôt que de suivre la branche de développement principale :

cd /etc/nginx/modsec

# Clonez un tag de version prise en charge spécifique. Consultez la page
# des releases pour connaître la dernière version :
# https://github.com/coreruleset/coreruleset/releases
sudo git clone --branch v4.28.0 --depth 1 https://github.com/coreruleset/coreruleset.git
cd coreruleset

# Créer le fichier de configuration CRS à partir de l'exemple
sudo cp crs-setup.conf.example crs-setup.conf

# Activer les modèles d'exclusion. Le glob rules/*.conf ne prend PAS en
# compte les deux fichiers d'exclusion, qui ne sont livrés qu'au format
# .example ; copiez-les en .conf, sinon vos exclusions personnalisées
# before/after-CRS ne seront jamais chargées.
sudo cp rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example \
  rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
sudo cp rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf.example \
  rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf

Créez un fichier de règles principal dans /etc/nginx/modsec/main.conf :

Include /etc/nginx/modsec/modsecurity.conf
Include /etc/nginx/modsec/coreruleset/crs-setup.conf
Include /etc/nginx/modsec/coreruleset/rules/*.conf

Activez ModSecurity pour vos sites en ajoutant des directives à vos blocs server :

server {
    listen 80;
    server_name example.com;

    # Activer ModSecurity
    modsecurity on;
    modsecurity_rules_file /etc/nginx/modsec/main.conf;

    location / {
        proxy_pass http://backend;
        # ... autres directives
    }
}

Rechargez NGINX pour appliquer les changements :

sudo nginx -t && sudo systemctl reload nginx

Vérifiez que ModSecurity fonctionne en envoyant une attaque de test :

# Ceci devrait être bloqué (tentative d'injection SQL)
curl -I 'http://your-server.com/?id=1%20OR%201=1'

# Ceci devrait être bloqué (tentative de XSS)
curl -I 'http://your-server.com/?q=<script>alert(1)</script>'

Consultez le journal d'audit de ModSecurity :

sudo tail -f /var/log/modsec_audit.log

Vous devriez voir des entrées indiquant les requêtes bloquées, avec les identifiants de règles et les détails de l'attaque.

Configurez la journalisation de ModSecurity dans /etc/nginx/modsec/modsecurity.conf :

# Paramètres du journal d'audit
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^(?:5|4(?!04))"
SecAuditLogParts ABIJDEFHZ
SecAuditLogType Serial
SecAuditLog /var/log/modsec_audit.log

# Journal de débogage (à désactiver en production)
SecDebugLog /var/log/modsec_debug.log
SecDebugLogLevel 0

Créez les fichiers de journaux avec les bonnes permissions :

sudo touch /var/log/modsec_audit.log
sudo chown www-data:www-data /var/log/modsec_audit.log

Après avoir fonctionné en mode DetectionOnly, examinez les journaux à la recherche de faux positifs. Approches d'ajustement courantes :

Exclure des règles spécifiques :

# Dans /etc/nginx/modsec/coreruleset/crs-setup.conf ou un fichier personnalisé :
SecRuleRemoveById 942100  # Désactiver une règle spécifique par son ID
SecRuleRemoveByTag "attack-sqli"  # Désactiver toutes les règles SQLi par tag (CRS 4)

Dans CRS 3 et 4, le tag des injections SQL est attack-sqli (ou OWASP_CRS/ATTACK-SQLI). L'ancien tag CRS 2.x OWASP_CRS/WEB_ATTACK/SQL_INJECTION n'existe plus et ne correspond à aucune règle ; vérifiez donc toujours les noms de tags dans les fichiers de règles avant de vous appuyer sur une exclusion.

Exclure des règles pour des URL spécifiques :

SecRule REQUEST_URI "@beginsWith /api/upload" \
  "id:1000,phase:1,pass,nolog,\
   ctl:ruleRemoveById=200002"

Ajuster le niveau de paranoïa :

Dans crs-setup.conf, définissez le niveau de paranoïa (1 = faible taux de faux positifs, 4 = sécurité maximale) :

SecAction "id:900000,phase:1,pass,t:none,\
  setvar:tx.blocking_paranoia_level=1"