Comment configurer ModSecurity avec Nginx sur Debian/Ubuntu

Ce tutoriel va vous montrer comment installer et utiliser ModSecurity avec Nginx sur les serveurs Debian/Ubuntu. ModSecurity est le pare-feu d'application Web open source le plus connu. (WAF), offrant une protection complète pour vos applications Web (telles que WordPress, Nextcloud, Ghost, etc.) contre un large éventail d'attaques de couche 7 (HTTP), telles que l'injection SQL, les scripts intersites et l'inclusion de fichiers locaux.

Remarque :Ce tutoriel fonctionne sur toutes les versions actuelles de Debian et Ubuntu, y compris Debian 10, Ubuntu 18.04, Ubuntu 20.04 et Ubuntu 20.10.

Les applications Web sont intrinsèquement non sécurisées. Si vous êtes un administrateur WordPress, vous entendrez probablement des nouvelles de pirates exploitant les vulnérabilités des plugins et des thèmes WordPress de temps en temps. Il est essentiel que vous déployiez un WAF sur votre serveur Web, en particulier lorsque vous avez d'anciennes applications qui ne reçoivent pas de mises à jour. ModSecurity a été créé à l'origine par Ivan Ristić en 2002, actuellement maintenu par Trustwave SpiderLabs. C'est le WAF le plus largement déployé au monde, utilisé par plus d'un million de sites Web. cPanel, le panneau de contrôle d'hébergement le plus utilisé, inclut ModSecurity comme WAF.

Vous avez peut-être entendu parler d'autres pare-feu basés sur l'hôte comme iptables, UFW et Firewalld, etc. La différence est qu'ils fonctionnent sur les couches 3 et 4 du modèle OSI et prennent des mesures en fonction de l'adresse IP et du numéro de port. ModSecurity, ou pare-feu d'applications Web en général, est spécialisé pour se concentrer sur le trafic HTTP (couche 7 du modèle OSI) et agit en fonction du contenu de la requête et de la réponse HTTP.

ModSécurité 3

ModSecurity a été initialement conçu pour le serveur Web Apache. Il pouvait fonctionner avec Nginx avant la version 3.0 mais souffrait de mauvaises performances. ModSecurity 3.0 (alias libmodsecurity ) est sorti en 2017. Il s'agit d'une version marquante, en particulier pour les utilisateurs de Nginx, car il s'agit de la première version à fonctionner nativement avec Nginx. La mise en garde de ModSecurity 3 est qu'il n'a pas encore toutes les fonctionnalités de la version précédente (2.9), bien que chaque nouvelle version ajoutera certaines des fonctionnalités manquantes.

Étape 1 :Installez la dernière version de Nginx sur Debian/Ubuntu

ModSecurity s'intègre à Nginx en tant que module dynamique, ce qui vous permet de compiler le code source de modules individuels sans compiler Nginx lui-même.

Le binaire Nginx doit être compilé avec le --with-compat argument, ce qui rendra les modules dynamiques binairement compatibles avec votre binaire Nginx existant. Cependant, tous les binaires Nginx livrés depuis le référentiel Debian/Ubuntu par défaut ne sont pas compilés avec le --with-compat argument. Pour faciliter les choses, nous pouvons installer la dernière version de Nginx depuis le ondrej/nginx-mainline PPA, qui est maintenu par un développeur Debian.

Remarque :Le référentiel nginx.org fournit également la dernière version de Nginx. Cependant, le ondrej/nginx-mainline PPA fournit des modules dynamiques supplémentaires qui pourraient vous être utiles, tels que le module Brotli.

Ubuntu

Si vous utilisez Ubuntu 16.04, 18.04, 20.04 ou 20.10, exécutez les commandes suivantes pour installer la dernière version de Nginx.

sudo add-apt-repository ppa:ondrej/nginx-mainline -ysudo apt updatesudo apt install nginx-core nginx-common nginx nginx-full

Au cours du processus d'installation, il peut vous indiquer que le distributeur de packages a fourni une version mise à jour du fichier de configuration principal. Il est recommandé d'appuyer sur n pour conserver votre version actuelle. Vous pourrez toujours examiner la différence plus tard.

Par défaut, seul le référentiel binaire est activé. Nous devons également activer le référentiel de code source afin de télécharger le code source Nginx. Modifiez le fichier de référentiel principal Nginx.

sudo nano /etc/apt/sources.list.d/ondrej-ubuntu-nginx-mainline-*.list

Trouvez la ligne qui commence par # deb-src .

# deb-src http://ppa.launchpad.net/ondrej/nginx-mainline/ubuntu/focal main

Supprimez le # caractère pour activer ce référentiel de code source.

deb-src http://ppa.launchpad.net/ondrej/nginx-mainline/ubuntu/focal main

Enregistrez et fermez le fichier. Ensuite, mettez à jour l'index du référentiel.

mise à jour sudo apt

Debian

Si vous utilisez Debian 10 ou Debian 11, exécutez les commandes suivantes pour installer la dernière version de Nginx.

curl -sSL https://packages.sury.org/nginx-mainline/README.txt | sudo bash -xsudo apt update sudo apt install nginx-core nginx-common nginx nginx-full

Au cours du processus d'installation, il peut vous indiquer que le distributeur de packages a fourni une version mise à jour du fichier de configuration principal. Il est recommandé d'appuyer sur n pour conserver votre version actuelle. Vous pourrez toujours examiner la différence plus tard.

Par défaut, seul le référentiel binaire est activé. Nous devons également activer le référentiel de code source afin de télécharger le code source Nginx. Modifiez le fichier de référentiel principal Nginx.

sudo nano /etc/apt/sources.list.d/nginx-mainline.list

Vous devriez trouver une seule ligne qui active le référentiel binaire Nginx. Ajoutez la ligne suivante pour activer le référentiel de code source Nginx sur Debian 10.

deb-src https://packages.sury.org/nginx-mainline/ buster main

Si vous utilisez Debian 11, ajoutez plutôt la ligne suivante.

deb-src https://packages.sury.org/nginx-mainline/bullseye main

Enregistrez et fermez le fichier. Ensuite, mettez à jour l'index du référentiel.

mise à jour sudo apt

Vérification des arguments de configuration de Nginx

Vérifiez maintenant les arguments de configuration de Nginx avec la commande suivante :

sudo nginx -V

Tous les binaires Nginx dans le PPA sont compilés avec le --with-compat arguments.

Étape 2 :Télécharger le package source Nginx

Bien que nous n'ayons pas besoin de compiler Nginx lui-même, nous avons besoin du package de code source Nginx pour compiler le module dynamique ModSecurity. Exécutez la commande suivante pour créer un nginx répertoire sous /usr/local/src/ pour stocker le package de code source Nginx. Remplacer username avec votre vrai nom d'utilisateur.

sudo chown username:username /usr/local/src/ -R mkdir -p /usr/local/src/nginx

cd dans le répertoire source de Nginx.

cd /usr/local/src/nginx/

Téléchargez le package source Nginx avec les commandes ci-dessous :

sudo apt install dpkg-devapt source nginx

Si vous voyez le message d'avertissement suivant, vous pouvez l'ignorer en toute sécurité.

W :Le téléchargement est effectué hors bac à sable en tant que root car le fichier "nginx_1.19.5.orig.tar.gz" n'est pas accessible par l'utilisateur "_apt". - pkgAcquire::Run (13 :Autorisation refusée)

Consultez les fichiers de code source téléchargés.

ls

Exemple de sortie :

nginx-1.19.5nginx_1.19.5-3+ubuntu20.04.1+deb.sury.org+1.debian.tar.xznginx_1.19.5-3+ubuntu20.04.1+deb.sury.org+1.dscnginx_1.19.5 .orig.tar.gz

Assurez-vous que la version du code source est la même que votre version binaire Nginx (sudo nginx -v ).

Étape 3 :Installez libmodsecurity3

libmodsecurity est la bibliothèque ModSecurity qui effectue le filtrage HTTP pour vos applications Web. Sur Debian 10 et Ubuntu 20.04, 20.10, vous pouvez l'installer avec sudo apt install libmodsecurity3 , mais je vous recommande de le compiler à partir de la source.

Pour compiler libmodsecurity , clonez d'abord le code source de Github.

sudo apt install gitgit clone --depth 1 -b v3/master --single-branch https://github.com/SpiderLabs/ModSecurity /usr/local/src/ModSecurity/cd /usr/local/src/ ModSécurité/

Installez les dépendances de build.

sudo apt install gcc make build-essential autoconf automake libtool libcurl4-openssl-dev liblua5.3-dev libfuzzy-dev ssdeep gettext pkg-config libpcre3 libpcre3-dev libxml2 libxml2-dev libcurl4 libgeoip-dev libyajl-dev doxygen 

 Installez les sous-modules requis.
 
mise à jour du sous-module git submodule initgit
 

 Configurez l'environnement de construction.
 
./build.sh ./configure
 

 Si vous voyez l'erreur suivante, vous pouvez l'ignorer.
 
fatal :aucun nom trouvé, ne peut rien décrire.
 

 Compilez le code source avec la commande suivante. Par défaut, make n'utilisera qu'un seul cœur de processeur. J'ai 4 cœurs CPU sur mon serveur, donc je spécifie 4 tâches (-j4 ) pour make pour accélérer le processus de compilation. Modifier 4 à votre propre nombre de cœurs de processeur.
 
faire -j4
 

 Après le make commande terminée sans erreur, installez le binaire.
 
sudo make install
 

 Il sera installé sous /usr/local/modsecurity/ répertoire.
 
Dépannage des erreurs de compilation
 
erreur #1
 

 Si vous voyez l'erreur suivante lors de l'exécution du make commande, c'est probablement parce que votre serveur n'a plus de RAM.
 
g++ :erreur interne du compilateur :tué (programme cc1plus)
 

 Les lignes suivantes dans /var/log/syslog indique que le serveur manque de mémoire, envisagez donc de mettre à niveau les spécifications du serveur.
 

 
 

 Alternativement, vous pouvez créer un espace d'échange pour résoudre le problème de mémoire insuffisante. Cependant, il ne doit être utilisé que comme mesure temporaire. L'utilisation de l'espace d'échange sur les serveurs SSD peut nuire aux performances du système.
 
erreur #2
 

 Si vous voyez l'erreur suivante lors de la compilation de ModSecurity,
 
utils/geo_lookup.cc :Dans la fonction membre 'bool modsecurity::Utils::GeoLookup::lookup(const string&, modsecurity::Transaction*, std::function&)>) const':utils/geo_lookup.cc:124:32 :erreur :conversion invalide de 'const MMDB_s*' en 'MMDB_s*' [-fpermissive]r =MMDB_lookup_string(&mmdb, target.c_str( ), &gai_error, &mmdb_error);
 

 C'est probablement parce que vous avez installé une version obsolète de libmaxminddb-dev . Vous pouvez supprimer ce package.
 
sudo apt supprimer libmaxminddb-dev
 

 Et installez libgeoip-dev , qui est une alternative à libmaxminddb-dev .
 
sudo apt install libgeoip-dev
 

 Puis recompilez ModSecurity.
 
faire nettoyer./configuremake -j4
 

 Installez le binaire.
 
sudo make install
 
Étape 4 :Téléchargez et compilez le code source du connecteur ModSecurity v3 Nginx
 

 Le connecteur ModSecurity Nginx liens libmodsecurity au serveur Web Nginx. Clonez le référentiel Git du connecteur ModSecurity v3 Nginx.
 
git clone --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx.git /usr/local/src/ModSecurity-nginx/
 

 Assurez-vous d'être dans le répertoire source de Nginx.
 
cd /usr/local/src/nginx/nginx-1.19.5/
 

 Installez les dépendances de construction pour Nginx.
 
sudo apt build-dep nginxsudo apt install uuid-dev
 

 Ensuite, configurez l'environnement avec la commande suivante. Nous ne compilerons pas Nginx lui-même, mais compilerons le ModSecurity Nginx Connector uniquement. Le --with-compat flag rendra le module binaire compatible avec votre binaire Nginx existant.
 
./configure --with-compat --add-dynamic-module=/usr/local/src/ModSecurity-nginx
 

 Créez le connecteur ModSecurity Nginx module.
 
faire des modules
 

 Le module sera enregistré sous objs/ngx_http_modsecurity_module.so . Copiez-le dans le /usr/share/nginx/modules/ répertoire.
 
sudo cp objs/ngx_http_modsecurity_module.so /usr/share/nginx/modules/
 
Étape 5 :Charger le module de connecteur ModSecurity v3 Nginx
 

 Modifiez le fichier de configuration principal de Nginx.
 
sudo nano /etc/nginx/nginx.conf
 

 Ajoutez la ligne suivante au début du fichier.
 
load_module modules/ngx_http_modsecurity_module.so ;
 

 Ajoutez également les deux lignes suivantes dans le http {...} afin que ModSecurity soit activé pour tous les hôtes virtuels Nginx.
 
modsecurity on;modsecurity_rules_file /etc/nginx/modsec/main.conf;
 

 
 

 Enregistrez et fermez le fichier. Ensuite, créez le /etc/nginx/modsec/ répertoire pour stocker la configuration de ModSecurity
 
sudo mkdir /etc/nginx/modsec/
 

 Copiez ensuite le fichier de configuration de ModSecurity.
 
sudo cp /usr/local/src/ModSecurity/modsecurity.conf-recommended /etc/nginx/modsec/modsecurity.conf
 

 Modifiez le fichier.
 
sudo nano /etc/nginx/modsec/modsecurity.conf
 

 Trouvez la ligne suivante.
 
SecRuleEngine DetectionOnly
 

 Cette configuration indique à ModSecurity de consigner les transactions HTTP, mais ne prend aucune mesure lorsqu'une attaque est détectée. Remplacez-le par ce qui suit, afin que ModSecurity détecte et bloque les attaques Web.
 
SecRuleEngine activé
 

 Trouvez ensuite la ligne suivante (ligne 224), qui indique à ModSecurity quelles informations doivent être incluses dans le journal d'audit.
 
SecAuditLogParts ABIJDEFHZ
 

 Cependant, le paramètre par défaut est erroné. Vous saurez pourquoi plus tard lorsque j'expliquerai comment comprendre les journaux de ModSecurity. Le paramètre doit être modifié comme suit.
 
SecAuditLogParts ABCEFHJKZ
 

 Si vous avez un site Web de codage, vous souhaiterez peut-être désactiver l'inspection du corps de la réponse, sinon vous risquez d'obtenir des erreurs interdites 403 simplement en chargeant une page Web avec beaucoup de contenu de code.
 
SecResponseBodyAccess désactivé
 

 Enregistrez et fermez le fichier. Ensuite, créez le /etc/nginx/modsec/main.conf fichier.
 
sudo nano /etc/nginx/modsec/main.conf
 

 Ajoutez la ligne suivante pour inclure le /etc/nginx/modsec/modsecurity.conf fichier.
 
Inclure /etc/nginx/modsec/modsecurity.conf
 

 Enregistrez et fermez le fichier. Nous devons également copier le fichier de mappage Unicode.
 
sudo cp /usr/local/src/ModSecurity/unicode.mapping /etc/nginx/modsec/
 

 Testez ensuite la configuration de Nginx.
 
sudo nginx -t
 

 Si le test réussit, redémarrez Nginx.
 
sudo systemctl redémarrer nginx
 
Étape 6 :Activer l'ensemble de règles de base OWASP
 

 Pour que ModSecurity protège vos applications web, vous devez définir des règles pour détecter les acteurs malveillants et les bloquer. Pour les débutants, c'est une bonne idée d'installer les ensembles de règles existants, afin que vous puissiez commencer rapidement et ensuite apprendre les choses sérieuses sur la route. Il existe plusieurs jeux de règles gratuits pour ModSecurity. L'ensemble de règles de base OWASP (CRS) est le jeu de règles standard utilisé avec ModSecurity.
 
 
C'est un ensemble de règles gratuit, géré par la communauté et le plus largement utilisé qui fournit une configuration par défaut vendue pour ModSecurity.
 
Il contient des règles pour aider à arrêter les vecteurs d'attaque courants, y compris l'injection SQL (SQLi), les scripts intersites (XSS) et bien d'autres.
 
Il peut s'intégrer au projet Honeypot.
 
Il contient également des règles pour détecter les bots et les scanners.
 
Il a été réglé grâce à une large exposition pour avoir très peu de faux positifs.
 
 

 Téléchargez le dernier CRS OWASP depuis GitHub.
 
wget https://github.com/coreruleset/coreruleset/archive/v3.3.0.tar.gz
 

 Extrayez le fichier.
 
tar xvf v3.3.0.tar.gz
 

 Déplacez le répertoire vers /etc/nginx/modsec/ .
 
sudo mv coreruleset-3.3.0/ /etc/nginx/modsec/
 

 Renommez le crs-setup.conf.example fichier.
 
sudo mv /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.conf.example /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.conf
 

 Modifiez ensuite le fichier de configuration principal.
 
sudo nano /etc/nginx/modsec/main.conf
 

 Ajoutez les deux lignes suivantes, ce qui permettra à Nginx d'inclure le fichier de configuration CRS et les règles individuelles.
 
Inclure /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.confInclude /etc/nginx/modsec/coreruleset-3.3.0/rules/*.conf
 

 
 

 Enregistrez et fermez le fichier. Testez ensuite la configuration de Nginx.
 
sudo nginx -t
 

 Si le test réussit, redémarrez Nginx.
 
sudo systemctl redémarrer nginx
 
Étape 7 :Découvrez comment fonctionne OWASP CRS
 

 Jetons un coup d'œil au fichier de configuration de CRS, qui vous fournit une bonne documentation sur le fonctionnement de CRS.
 
sudo nano /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.conf
 

 Vous pouvez voir que OWASP CRS peut fonctionner en deux modes :
 
 
mode autonome . C'est le mode traditionnel utilisé dans CRS v2.x. Si une requête HTTP correspond à une règle, ModSecurity bloquera immédiatement la requête HTTP et arrêtera d'évaluer les règles restantes.
 
mode de notation des anomalies . C'est le mode par défaut utilisé dans CRS v3.x. ModSecurity vérifiera une requête HTTP par rapport à toutes les règles et ajoutera un score à chaque règle correspondante. Si un seuil est atteint, alors la requête HTTP est considérée comme une attaque et sera bloquée. Le score par défaut pour les demandes entrantes est de 5 et pour la réponse sortante est de 4.
 
 

 
 

 Lors de l'exécution en mode de notation des anomalies, il existe 4 niveaux de paranoïa.
 
 
Niveau de paranoïa 1 (par défaut)
 
Paranoïa niveau 2
 
Paranoïa niveau 3
 
Paranoïa niveau 4
 
 

 Avec chaque augmentation du niveau de paranoïa, le CRS active des règles supplémentaires vous donnant un niveau de sécurité plus élevé. Cependant, des niveaux de paranoïa plus élevés augmentent également la possibilité de bloquer certains trafics légitimes en raison de fausses alarmes.
 

 
 

 Ce sont les deux concepts de base que vous devez comprendre avant d'utiliser le CRS. Nous pouvons maintenant fermer le fichier. Les règles CRS individuelles sont stockées dans /etc/nginx/modsec/coreruleset-3.3.0/rules/ annuaire. Chaque règle correspondante augmentera le score d'anomalie.
 
Étape 8 :Tester
 

 Pour vérifier si ModSecurity fonctionne, vous pouvez lancer une simple attaque par injection SQL sur votre propre site Web. (Veuillez noter qu'il est illégal d'effectuer des tests de sécurité sur les sites Web d'autres personnes sans autorisation.) Entrez l'URL suivante dans votre navigateur Web.
 
https://votredomaine.com/?id=3 ou 'a'='a'
 

 Si ModSecurity fonctionne correctement, votre serveur Web Nginx devrait renvoyer un message d'erreur 403 interdit.
 

 
 

 Le navigateur Firefox peut ne pas afficher le message d'erreur 403. Vous pouvez appuyer sur Ctrl+Shift+I pour ouvrir la fenêtre des outils de développement et sélectionner le network languette. Appuyez ensuite sur F5 pour recharger la page Web. Vous devriez maintenant voir le code d'erreur 403 dans Firefox.
 

 Si ModSecurity s'exécute dans DetectionOnly mode, il ne bloquera pas cette attaque par injection SQL.
 
Étape 9 :Comprendre les journaux ModSecurity
 

 Il est important d'analyser les journaux ModSecurity, afin que vous sachiez quel type d'attaques sont dirigées vers vos applications Web et que vous puissiez prendre de meilleures mesures pour vous défendre contre les acteurs de la menace. Il existe principalement deux types de journaux dans ModSecurity :
 
 
journal de débogage :désactivé par défaut.
 
journal d'audit :/var/log/modsec_audit.log 
 
 

 Pour comprendre les journaux d'audit de ModSecurity, vous devez connaître les 5 phases de traitement dans ModSecurity, qui sont :
 
 
Phase 1 :Inspecter les en-têtes de requête
 
Phase 2 :Inspecter le corps de la demande
 
Phase 3 :Inspecter les en-têtes de réponse
 
Phase 4 :Inspecter le corps de la réponse
 
Phase 5 :Action (consignation/blocage des requêtes malveillantes)
 
 

 Il existe également deux types de fichier de journalisation.
 
 
Série :un fichier pour tous les journaux. C'est la valeur par défaut.
 
Simultané :plusieurs fichiers pour la journalisation. Cela peut fournir de meilleures performances d'écriture. Si vous constatez un ralentissement de vos pages Web après l'activation de ModSecurity, vous pouvez choisir d'utiliser le type de journalisation simultanée.
 
 

 Les événements du journal sont divisés en plusieurs sections.
 
 
section A :en-tête du journal d'audit
 
section B :en-tête de la demande
 
section C :corps de la demande
 
section D :réservée
 
section E :corps de réponse intermédiaire
 
section F :en-têtes de réponse finale
 
rubrique G :réservée
 
section H :bande-annonce du journal d'audit
 
section I :alternative au corps de requête compact, qui exclut les fichiers
 
section J :informations sur les fichiers téléchargés
 
section K :chaque règle correspondant à un événement, par ordre de correspondance
 
section Z :limite finale
 
 

 Si vous exécutez un site Web à fort trafic, le journal d'audit ModSecurity peut devenir trop volumineux très rapidement, nous devons donc configurer la rotation des journaux pour le journal d'audit ModSecurity. Créez un fichier de configuration logrotate pour ModSecurity.
 
sudo nano /etc/logrotate.d/modsecurity
 

 Ajoutez les lignes suivantes à ce fichier.
 
/var/log/modsec_audit.log{ rotation 14 jours manquantsok compress delaycompress notifempty}
 

 Cela fera tourner le fichier journal tous les jours (quotidiennement ), compresser les anciennes versions (compresser ). Les 14 fichiers journaux précédents seront conservés (rotate 14 ), et aucune rotation ne se produira si le fichier est vide (notifempty ). Enregistrez et fermez le fichier.
 

 Si votre journal ModSecurity est vide, vous devrez peut-être redémarrer Nginx.
 
sudo systemctl redémarrer nginx
 
Étape 10 :Gérer les faux positifs
 

 ModSecurity est un pare-feu d'application Web générique et n'est pas conçu pour une application Web spécifique. L'ensemble de règles de base OWASP est également un ensemble de règles génériques sans application particulière à l'esprit, il est donc probable que vous verrez des faux positifs après avoir activé ModSecurity et OWASP CRS. Si vous augmentez le niveau de paranoïa dans le CRS, il y aura plus de faux positifs.
 

 Par exemple, par défaut, le CRS interdit l'injection de commande Unix comme la saisie de sudo sur une page web, ce qui est assez courant sur mon blog. Pour éliminer les faux positifs, vous devez ajouter des exclusions de règles au CRS.
 
Exclusions de règles spécifiques à l'application 
 

 Certaines exclusions prédéfinies et spécifiques à l'application sont livrées avec OWASP CRS. Modifiez le crs-setup.conf fichier.
 
sudo nano /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.conf
 

 Accédez aux Exclusions de règles spécifiques à l'application section et recherchez les lignes suivantes.
 
#SecAction \# "id:900130,\# phase:1,\# nolog,\# pass,\# t:none,\# setvar:tx.crs_exclusions_cpanel=1,\# setvar:tx.crs_exclusions_drupal=1,\# setvar:tx.crs_exclusions_dokuwiki=1,\# setvar:tx.crs_exclusions_nextcloud=1,\# setvar:tx.crs_exclusions_wordpress=1,\# setvar:tx.crs_exclusions_xenforo=1"
 

 Par exemple, si je veux activer les exclusions WordPress, les lignes ci-dessus doivent être remplacées par les suivantes. Veuillez faire attention à la syntaxe. Il ne doit y avoir aucun commentaire entre t:none,\ et setvar:tx.crs_exclusions_wordpress=1" . (La barre oblique inverse \ caractère à la fin indique que la ligne suivante est une continuation de la ligne actuelle.)
 
SecAction \ "id:900130,\ phase:1,\ nolog,\ pass,\ t:none,\ setvar:tx.crs_exclusions_wordpress=1"# setvar:tx.crs_exclusions_cpanel=1,\# setvar:tx. crs_exclusions_drupal=1,\# setvar:tx.crs_exclusions_dokuwiki=1,\# setvar:tx.crs_exclusions_nextcloud=1,\# setvar:tx.crs_exclusions_xenforo=1"
 

 Enregistrez et fermez le fichier. Testez ensuite les configurations Nginx.
 
sudo nginx -t
 

 Si le test réussit, rechargez Nginx pour que la modification prenne effet.
 
sudo systemctl recharger nginx
 

 Notez que si vous avez plusieurs applications telles que (WordPress, Nextcloud, Drupal, etc.) installées sur le même serveur, les exclusions de règles ci-dessus seront appliquées à toutes les applications. Pour minimiser les risques de sécurité, vous devez activer une exclusion de règle pour une seule application. Pour ce faire, accédez au /etc/nginx/modsec/coreruleset-3.3.0/rules/ répertoire.
 
cd /etc/nginx/modsec/coreruleset-3.3.0/rules
 

 Renommez le REQUEST-900-EXCLUSION-RULES-BEFORE-CRS fichier.
 
sudo mv REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
 

 Modifiez ensuite ce fichier.
 
sudo nano REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
 

 Ajoutez la ligne suivante au bas de ce fichier. Si votre WordPress utilise le blog.yourdomain.com sous-domaine et l'en-tête de requête envoyé par le navigateur du visiteur contient ce sous-domaine, alors ModSecurity appliquera les exclusions de règles pour WordPress.
 
SecRule REQUEST_HEADERS :Host "@streq blog.yourdomain.com" "id:1000,phase:1,setvar:tx.crs_exclusions_wordpress=1"
 

 Si vous avez installé Nextcloud sur le même serveur, vous pouvez également ajouter la ligne suivante dans ce fichier, ainsi si un visiteur accède à votre sous-domaine Nextcloud, ModSecurity appliquera les exclusions de règles Nextcloud.
 
SecRule REQUEST_HEADERS :Host "@streq nextcloud.yourdomain.com" "id:1001,phase:1,setvar:tx.crs_exclusions_nextcloud=1"
 

 Enregistrez et fermez ce fichier. Testez ensuite les configurations Nginx.
 
sudo nginx -t
 

 Si le test réussit, rechargez Nginx pour que la modification prenne effet.
 
sudo systemctl recharger nginx
 
Exclusions de règles personnalisées
 

 L'activation des exclusions de règles prédéfinies spécifiques à l'application peut ne pas éliminer tous les faux positifs. Si tel est le cas, vous devez examiner le journal d'audit de ModSecurity (/var/log/modsec_audit.log ), vérifiez quelle règle a causé le faux positif et ajoutez vos exclusions de règles personnalisées dans le REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf fichier.
 

 La section H du journal d'audit vous indique quelle règle correspond. Par exemple, si j'essaie d'utiliser le <code>...</code> HTML dans le formulaire de commentaire, ModSecurity bloque mon commentaire. Le journal suivant m'indique que la requête HTTP correspond à une règle dans REQUEST-941-APPLICATION-ATTACK-XSS.conf (ligne 527). L'ID de règle est 941310. L'URI de la requête est /wp-comments-post.php .
 

 
 

 Il est détecté comme une attaque de filtre XSS d'encodage malformé. Cependant, je veux que les utilisateurs puissent utiliser le <code>...</code> et <pre>...</pre> Balise HTML dans le formulaire de commentaire, j'ai donc créé une exclusion de règle. Ajoutez la ligne suivante au bas du REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf fichier.
 
SecRule REQUEST_URI "@streq /wp-comments-post.php" "id:1002,phase:1,ctl:ruleRemoveById=941310"
 

 Cette ligne indique à ModSecurity que si l'URI de la requête est /wp-comments-post.php , n'appliquez pas la règle ID 941310. Enregistrez et fermez le fichier. Testez ensuite la configuration Nginx.
 
sudo nginx -t
 

 Si le test réussit, rechargez Nginx.
 
sudo systemctl recharger nginx
 

 Si un faux positif correspond à plusieurs ID de règle, vous pouvez ajouter des exclusions de règle sur une seule ligne comme suit :
 
SecRule REQUEST_URI "@streq /wp-admin/post.php" "id:1003,phase:1,ctl:ruleRemoveById=941160 ,ctl:ruleRemoveById=941310 ,ctl:ruleRemoveById=942100 "
 

 Remarque :Il n'est pas recommandé de désactiver trop de règles de niveau 1 dans le CRS OWASP, car cela rendra votre site Web plus facilement piratable. Ne désactivez les règles que si vous savez ce que vous faites.
 
Liste blanche IP
 

 Si vous souhaitez désactiver ModSecurity pour votre propre adresse IP, mais le laisser activé pour toutes les autres adresses IP, ajoutez la règle personnalisée suivante dans le REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf dossier. Remplacer 12.34.56.78 avec votre adresse IP réelle.
 
SecRule REMOTE_ADDR "^12\.34\.56\.78" "id:1004,phase:1,allow,ctl:ruleEngine=off"
 

 Pour mettre un sous-réseau en liste blanche, utilisez la syntaxe suivante, qui mettra en liste blanche le 10.10.10.0/24 réseau.
 
SecRule REMOTE_ADDR "^10\.10\.10.*" "id:1005,phase:1,allow,ctl:ruleEngine=off"
 

 Enregistrez et fermez le fichier. Testez ensuite les configurations Nginx.
 
sudo nginx -t
 

 Si le test réussit, redémarrez Nginx pour que la modification prenne effet.
 
sudo systemctl redémarrer nginx
 
Règles de chaînage
 

 Si votre Nginx possède plusieurs hôtes virtuels, vous pouvez ajouter votre adresse IP à la liste blanche pour un hôte virtuel spécifique. Vous devez enchaîner deux règles comme suit :
 
SecRule REMOTE_ADDR "^12\.34\.56\.78" "id:1004,phase:1,allow,ctl:ruleEngine=off,chain"SecRule REQUEST_HEADERS:Host "@streq nextcloud.yourdomain.com" "t:aucun"
 

 La chain mot-clé à la fin de la première règle indique que le ruleEngine=off l'action ne sera prise que si la condition de la règle suivante est également vraie.
 
(Facultatif) Intégrez ModSecurity à Project Honeypot
 

 Project Honeypot maintient une liste d'adresses IP malveillantes connues, accessible gratuitement au public. ModSecurity peut s'intégrer à Project Honeypot et bloquer les adresses IP sur la liste Project Honeypot.
 

 Notez que l'utilisation de Project Honeypot ralentira votre site Web pour les nouveaux visiteurs, car votre serveur Web devra envoyer une requête à Project Honeypot avant de pouvoir envoyer une réponse au nouveau visiteur. Cependant, une fois les données de réputation IP mises en cache sur votre serveur Web, l'impact sur les performances sera très minime.
 

 Pour utiliser Project Honeypot, créez d'abord un compte gratuit sur son site Web. Accédez ensuite au tableau de bord de votre compte et cliquez sur get one lien pour demander une clé d'accès pour la liste noire HTTP.
 

 
 

 Ensuite, modifiez le crs-setup.conf fichier.
 
sudo nano /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.conf
 

 Trouvez les lignes suivantes.
 
#SecHttpBlKey XXXXXXXXXXXXXXXXXX#SecAction "id:900500,\# phase:1,\# nolog,\# pass,\# t:none,\# setvar:tx.block_search_ip=1,\# setvar:tx.block_suspicious_ip =1,\# setvar:tx.block_harvester_ip=1,\# setvar:tx.block_spammer_ip=1"
 

 Supprimer le début # caractères pour les décommenter et ajoutez votre clé API HTTPBL obtenue auprès de Project Honeypot.
 

 
 

 Notez que block_search_ip doit être défini sur 0 (désactivé), car nous ne voulons pas bloquer les robots des moteurs de recherche. Enregistrez et fermez le fichier. Rechargez ensuite Nginx.
 
sudo systemctl recharger nginx
 

 Désormais, ModSecurity interrogera Project Honeypot sur toutes les requêtes HTTP. Pour tester si cela fonctionne, modifiez le fichier /etc/nginx/modsec/main.conf.
 
sudo nano /etc/nginx/modsec/main.conf
 

 Ajoutez la ligne suivante à la fin de ce fichier. Cela nous permet de passer une adresse IP dans une URL. (Une fois le test réussi, vous pouvez supprimer cette ligne du fichier.)
 
SecRule ARGS:IP "@rbl dnsbl.httpbl.org" "phase:1,id:171,t:none,deny,nolog,auditlog,msg:'RBL Match for SPAM Source'
 

 Enregistrez et fermez le fichier. Testez les configurations Nginx.
 
sudo nginx -t
 

 Rechargez ensuite Nginx.
 
sudo systemctl recharger nginx
 

 Accédez au site Web de Project Honeypot et recherchez une adresse IP malveillante, par exemple 134.119.218.243. Exécutez la commande suivante pour tester la liste noire HTTP.
 
curl -i -s -k -X $'GET' 'https://votredomaine.com/?IP=134.119.218.243'
 

 Votre serveur Web devrait renvoyer une réponse 403 interdit, car l'adresse IP sur Project Honeypot.
 
Comment utiliser Brotli avec ModSecurity dans Nginx
 

 Traditionnellement, les pages Web sont compressées avec GZIP pour une vitesse de chargement plus rapide. Développé par Google, Brotli est un nouvel algorithme de compression qui offre un meilleur taux de compression. Il est pris en charge par tous les principaux navigateurs Web. Pour utiliser Brotli dans Nginx, vous devez d'abord installer le module Brotli Nginx à partir de ondrej/nginx-mainline APP.
 
sudo apt install libnginx-mod-brotli
 

 Ouvrez ensuite le fichier de configuration principal de Nginx.
 
sudo nano /etc/nginx/nginx.conf
 

 Ajoutez les lignes suivantes dans le http {...} contexte.
 
 brotli on ; brotli_comp_level 6 ; brotli_static activé ; application brotli_types/application atom+xml/application javascript/application json/application rss+xml/application vnd.ms-fontobject/application x-font-opentype/application x-font-truetype/application x-font-ttf/x-javascript application/xhtml+xml application/xml police/eot police/opentype police/otf police/truetype image/svg+xml image/vnd.microsoft.icon image/x-icon image/x-win-bitmap text/css text/javascript texte/texte brut/xml ;
 

 Enregistrez et fermez le fichier, puis testez les configurations Nginx.
 
sudo nginx -t
 

 Si le test réussit, redémarrez Nginx.
 
sudo systemctl redémarrer nginx
 

 Allez maintenant sur la page d'accueil de votre site Web, ouvrez les outils de développement dans votre navigateur Web (dans Firefox, vous pouvez appuyer sur Ctrl+Alt+I to open it up). Select the Network tab, and press F5 to reload the web page. Click on the main HTML page.
 

 
 

 Check the response header on the right sidebar. If the content-encoding is set to br , then you have successfully enabled Brotli compression in Nginx.
 

 
 

 If the content-encoding is gzip , then your Nginx web server is still using GZIP.
 
Upgrading Nginx
 

 ModSecurity integrates with Nginx as a dynamic module, so every time the Nginx binary is upgraded, you need to rebuild the ModSecurity module for Nginx. This will make your application offline for a few minutes.
 

 If a newer version of Nginx is available in the repository, the sudo apt upgrade command will upgrade Nginx. The newer version of Nginx is not going to be compatible with the previously compiled ModSecurity module. If Nginx is upgraded by the sudo apt upgrade command, it will fail to restart as shown in the screenshot below.
 

 
 

 And if you run sudo nginx -t command, it tells you that Nginx expects a new version of the ModSecurity module.
 

 
 

 My advice is to prevent Nginx from being upgraded when you run sudo apt upgrade commande. This can be achieved by the following command:
 
sudo apt-mark hold nginx
 

 Now if you run sudo apt update;sudo apt upgrade , and the package manager tells you that the nginx package is held back from upgrading, then it means there’s a new nginx version available in the repository.
 

 
 

 You should download the new Nginx source package and compile the ModSecurity module again. Move the newly-compiled ModSecurity module to /usr/share/nginx/modules/ annuaire. Basically that means you need to remove everything under /usr/local/src/ directory (sudo rm /usr/local/src/* -rf ) and go through step 2 and step 4 again.
 

 Then unhold Nginx.
 
sudo apt-mark unhold nginx
 

 And upgrade Nginx.
 
sudo apt upgrade nginx
 

 Once the upgrade is complete, hold Nginx again.
 
sudo apt-mark hold nginx
 

 To show what packages are held, run
 
apt-mark showhold
 
Nginx Plus
 

 If you use the commercial Nginx Plus web server, then ModSecurity is included in the Nginx Plus binary. It’s known as the NGINX WAF .
 

 If you don’t want to spend time re-compiling the ModSecurity source code, then you might want to purchase Nginx Plus, as the ModSecurity module is pre-compiled in the Nginx Plus binary. Benefits of Using ModSecurity 3.0 with NGINX Plus:
 
 
You don’t need to compile the ModSecurity dynamic module yourself;  NGINX, Inc. provides a precompiled module for you, saving time and effort.
 
NGINX, Inc. has extensively tested the dynamic module, so you know it’s suitable for production usage.
 
NGINX, Inc. continually tracks changes and updates the module for every important change and security vulnerability, so you don’t have to do this yourself.
 
Each new release of NGINX Plus includes a new version of the dynamic module, so you can upgrade without having to re-compile ModSecurity.
 
You get 24×7 support with both installation of the ModSecurity and the OWASP Core Rule Set, as well as troubleshooting and debugging assistance.
 
 
How to Disable ModSecurity for a Virtual Host
 

 In this tutorial, I added the following line in the http {...} context.
 
modsecurity activé ;
 

 This will enable ModSecurity for all Nginx server blocks (aka virtual hosts). If you want to disable ModSecurity for a specific server block, then edit the server block file (/etc/nginx/conf.d/example.com.conf ) and add the following line to the server {...} context.
 
modsecurity off;
 

 Reload Nginx for the change to take effect.
 
sudo systemctl recharger nginx
 
FAQ
 
Static Module vs Dynamic Module in Nginx
 
 
A static module must be compiled with Nginx and it’s integrated with Nginx as one binary. It can’t be unloaded from Nginx.
 
A dynamic module is a separate package from the main Nginx binary. It can be loaded and unloaded in Nginx.
 
 
What does Binary Compatible Mean?
 
 
If a dynamic module is not binary compatible, then the module and Nginx should be compiled together. If there’s an existing Nginx binary installed from a software repository using apt-get , it must be removed and you need to install the compiled Nginx binary in order to use the dynamic module.
 
If a dynamic module is binary compatible, then this module can be compiled individually without compiling Nginx. The module can be used with your existing Nginx binary installed from a software repository. It’s not perfect, though.
 
 

 No matter a module is static or dynamic, binary compatible or non binary compatible, if you upgrade the Nginx binary later, you need to compile the module again.
 
Upgrade Server RAM
 

 ModSecurity can use a fair amount of RAM. If you can see the following error in your Nginx error log (/var/log/nginx/error.log), it means your server is short of RAM.
 
fork() failed while spawning "worker process" (12:Cannot allocate memory)sendmsg() failed (9:Bad file descriptor)sendmsg() failed (9:Bad file descriptor)sendmsg() failed (9:Bad file descriptor)
 

 You need to restart Nginx and upgrade server RAM, then the above error is not going to happen again.
 
How to Upgrade OWASP CRS
 

 Besides upgrading the ModSecurity Nginx module, you also need to upgrade the core rule set when a new version comes out. The process is straightforward.
 
 
Go through step 6 again to install the new version of core rule set.
 
Then go to step 10. Copy of your custom rules in the crs-setup.conf   and REQUEST-900-EXCLUSION-RULES-BEFORE-CRS file.
 
 

 Next, test Nginx configurations.
 
sudo nginx -t
 

 If the test is successful, reload Nginx for the change to take effect.
 
sudo systemctl recharger nginx
 

 How do you know if the new version is working? Launch a simple SQL injection attack like in step 8 and check your server logs. It will show you the CRS version that’s preventing this attack.