Comment installer ModSecurity 3 &OWASP Core Rule Set avec Nginx sur Debian 11 Bullseye

ModSecurity, souvent appelé Modsec, est un pare-feu d'application Web gratuit et open source (WAF) . ModSecurity a été créé en tant que module pour le serveur HTTP Apache. Cependant, depuis ses débuts, le WAF s'est développé et couvre désormais un éventail de capacités de filtrage des demandes et des réponses du protocole de transfert hypertexte pour diverses plates-formes telles que Microsoft IIS, Nginx et, bien sûr, Apache.

Comment fonctionne le WAF, le moteur ModSecurity est déployé devant l'application web, permettant au moteur de scanner les connexions HTTP entrantes et sortantes. ModSecurity est le plus souvent utilisé en conjonction avec l'ensemble de règles de base OWASP (CRS) , un ensemble de règles open source écrites dans le langage SecRules de ModSecurity et très apprécié par l'industrie de la sécurité.

L'ensemble de règles OWASP avec ModSecurity peut presque instantanément aider à protéger votre serveur contre :

Mauvais agents utilisateurs
DDOS
Scripts intersites Web
Injection SQL
Piratage de session
Autres menaces

Dans le didacticiel suivant, vous apprendrez comment installer ModSecurity avec Nginx sur le bureau ou le serveur Debian 11 Bullseye.

Prérequis

OS recommandé : Debian 11 Bullseye.
Compte utilisateur : Un compte utilisateur avec un accès sudo ou root.
Packages requis : répertoriés tout au long du didacticiel

Mettre à jour le système d'exploitation

Mettez à jour votre Debian système d'exploitation pour s'assurer que tous les packages existants sont à jour :

sudo apt update && sudo apt upgrade -y

Le tutoriel utilisera la commande sudo et en supposant que vous avez le statut sudo .

Pour vérifier le statut sudo sur votre compte :

sudo whoami

Exemple de sortie montrant l'état de sudo :

[joshua@debian~]$ sudo whoami
root

Pour configurer un compte sudo existant ou nouveau, visitez notre tutoriel sur Ajouter un utilisateur aux Sudoers sur Debian .

Pour utiliser le compte racine , utilisez la commande suivante avec le mot de passe root pour vous connecter.

su

Installer le package CURL &UNZIP

Le didacticiel utilise la commande curl and unzip pendant certaines parties. Pour vous assurer qu'il est installé, exécutez la commande suivante dans votre terminal :

sudo apt install curl unzip -y

Installer le dernier Nginx

Tout d'abord, vous devrez installer Nginx, et il est conseillé de le faire avec la dernière version stable ou principale de Nginx. Avant de continuer, il est recommandé de supprimer toutes les installations existantes de Nginx et installez la dernière version stable ou principale de Nginx .

Supprimer l'installation existante de Nginx

Arrêtez le service Nginx actuel :

sudo systemctl stop nginx

Supprimez maintenant l'installation Nginx existante comme suit :

apt-get purge nginx -y && sudo apt autoremove nginx -y

Importer le dernier référentiel Nginx et installer

Pour utiliser la dernière version de nginx mainline ou stable, vous devrez d'abord importer le référentiel.

Pour importer le référentiel principal :

curl -sSL https://packages.sury.org/nginx-mainline/README.txt | sudo bash -x

Pour importer un dépôt stable :

curl -sSL https://packages.sury.org/nginx/README.txt | sudo bash -x

Mettez à jour votre référentiel pour refléter la nouvelle modification :

apt update

Maintenant que vous avez installé le dépôt Nginx et mis à jour la liste des référentiels, installez Nginx avec ce qui suit :

apt install nginx-core nginx-common nginx nginx-full

Notez que vous pouvez être invité à conserver ou à remplacer votre /etc/nginx/ existant nginx.conf fichier de configuration lors de l'installation. Il est recommandé de conserver votre fichier de configuration actuel en appuyant sur (n) . Une copie sera faite quelle que soit la version du responsable, et vous pourrez également vérifier cela à l'avenir.

Ajouter le code source Nginx au référentiel

Seul le binaire est installé lors de l'installation de la dernière version de Nginx mainline ou stable par défaut. Cependant, vous aurez besoin de la source pour compiler Modsecurity plus loin dans le tutoriel.

Tout d'abord, ouvrez le fichier de configuration dans /etc/apt/sources.list.d avec nano comme ci-dessous :

Ligne principale :

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

Stable :

nano /etc/apt/sources.list.d/nginx.list

Dans mainline et stable, lorsque vous ouvrez le fichier, vous ne verrez qu'une seule ligne comme suit :

#Mainline File#
deb-src https://packages.sury.org/nginx-mainline/ bullseye main
#Stable File#
deb-src https://packages.sury.org/nginx/ bullseye main

Sous la ligne d'origine, ajoutez la ligne suivante :

Ligne principale :

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

Stable :

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

Exemple de ce à quoi cela devrait ressembler (exemple principal uniquement) :

Télécharger les sources Nginx

Vous devrez télécharger le code source Nginx pour compiler le module dynamique ModSecurity . Pour ce faire, vous devrez télécharger et stocker le package source à l'emplacement du répertoire /etc/local/src/nginx .

Créer et configurer des répertoires

Créez l'emplacement comme suit :

mkdir /usr/local/src/nginx && cd /usr/local/src/nginx

Facultatif - Attribuez une autorisation au répertoire si nécessaire comme ci-dessous :

chown username:username /usr/local/src/ -R

Installer les dépendances et exécuter le téléchargement

Ensuite, téléchargez le package source avec les éléments suivants :

apt install dpkg-dev -y && sudo apt source nginx

Remarque, vous verrez le message d'erreur suivant comme ci-dessous :

dpkg-source: info: extracting nginx in nginx-1.21.1
dpkg-source: info: unpacking nginx_1.21.1.orig.tar.gz
dpkg-source: info: unpacking nginx_1.21.1-1+0~20210802.31+debian11~1.gbp08d591.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 0001-Make-sure-signature-stays-the-same-in-all-nginx-buil.patch
dpkg-source: info: applying 0002-define_gnu_source-on-other-glibc-based-platforms.patch
W: Download is performed unsandboxed as root as file 'nginx_1.21.1-1+0~20210802.31+debian11~1.gbp08d591.dsc' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)

Cela peut être ignoré en toute sécurité.

Vérifier la version source

Ensuite, listez les fichiers de répertoires avec le ls commande comme suit :

ls

Vous devriez voir la sortie suivante dans votre /usr/src/local/nginx répertoire :

nginx-1.21.1
nginx_1.21.1-1+0~20210802.31+debian11~1.gbp08d591.debian.tar.xz
nginx_1.21.1-1+0~20210802.31+debian11~1.gbp08d591.dsc
nginx_1.21.1.orig.tar.gz
nginx_1.21.1.orig.tar.gz.asc

Ensuite, confirmez que le paquet source est le même que votre version Nginx installée sur votre système d'exploitation Debian. Pour ce faire, utilisez la commande suivante nginx -v commande comme suit :

sudo nginx -v

La source que vous avez téléchargée doit correspondre à la version binaire installée sur votre système.

Exemple :

nginx version: nginx/1.21.1

Installez libmodsecurity3 pour ModSecurity

Le paquet libmodsecurity3 est la partie réelle du WAF qui effectue le filtrage HTTP pour vos applications Web. Sur Debian 11, vous pouvez l'installer à partir du référentiel Debian 11 par défaut. Cependant, cela n'est pas recommandé comme avec la plupart des versions stables, et cela prend souvent du retard. Au lieu de cela, vous compilerez à partir de la source beaucoup plus à jour comme suit.

Cloner le référentiel ModSecurity de Github

La première étape est le clone de Github, et si vous n'avez pas installé git, vous devrez exécuter la commande suivante :

apt install git -y

Ensuite, clonez le référentiel GIT libmodsecurity3 comme suit :

git clone --depth 1 -b v3/master --single-branch https://github.com/SpiderLabs/ModSecurity /usr/local/src/ModSecurity/

Une fois cloné, vous devrez CD au répertoire :

cd /usr/local/src/ModSecurity/

Installer les dépendances libmodsecurity3

Pour compiler, vous devrez installer les dépendances suivantes comme suit :

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 -y

Maintenant, pour finir, installez les sous-modules GIT suivants comme suit :

git submodule init

Mettez ensuite à jour les sous-modules :

git submodule update

Construire l'environnement ModSecurity

La prochaine étape consiste maintenant à créer d'abord l'environnement. Utilisez la commande suivante :

./build.sh

Ensuite, exécutez la commande configure :

./configure

Remarque, vous verrez peut-être l'erreur suivante :

fatal: No names found, cannot describe anything.

Vous pouvez ignorer cela en toute sécurité et passer à l'étape suivante.

Compilation du code source de ModSecurity

Maintenant que vous avez construit et configuré l'environnement pour libmodsecurity3, il est temps de le compiler avec la commande make .

make

Une astuce pratique consiste à spécifier le -j car cela peut augmenter considérablement la vitesse de compilation si vous avez un serveur puissant. Par exemple, le serveur LinuxCapable a 6 processeurs, et je peux utiliser les 6 ou au moins utiliser 4 à 5 pour augmenter la vitesse.

make -j 6

Après avoir compilé le code source, lancez maintenant la commande d'installation dans votre terminal :

make install

Attention, l'installation se fait dans le dossier /usr/local/modsecurity/, auquel vous ferez référence plus tard dans le guide.

Installer le connecteur ModSecurity-nginx

Le connecteur ModSecurity-nginx est le point de connexion entre nginx et libmodsecurity. Fondamentalement, c'est le composant qui communique entre Nginx et ModSecurity (libmodsecurity3) .

Cloner le référentiel ModSecurity-nginx de Github

Semblable à l'étape précédente de clonage du référentiel libmodsecurity3, vous devrez à nouveau cloner le référentiel du connecteur à l'aide de la commande suivante :

sudo git clone --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx.git /usr/local/src/ModSecurity-nginx/

Installer les dépendances ModSecurity-nginx

Ensuite, répertoire CD dans le répertoire source Nginx comme suit :

cd /usr/local/src/nginx/nginx-1.21.1

Remarque :remplacez la version du guide par la version actuelle de Nginx dans votre système.

Maintenant, exécutez la commande dans votre terminal Debian pour installer les dépendances requises :

apt build-dep nginx && sudo apt install uuid-dev -y

Ensuite, vous allez compiler le Connecteur ModSecurity-nginx module uniquement avec le –with-compat indicateur comme suit :

./configure --with-compat --add-dynamic-module=/usr/local/src/ModSecurity-nginx

Maintenant faites (créez) les modules dynamiques avec la commande suivante :

make modules

Ensuite, dans le répertoire source de Nginx, utilisez la commande suivante pour déplacer le module dynamique que vous venez de créer et qui a été enregistré à l'emplacement objs/ngx_http_modsecurity_module.so et copiez-le dans /usr/share/nginx/modules répertoire.

sudo cp objs/ngx_http_modsecurity_module.so /usr/share/nginx/modules/

Vous pouvez stocker le module dynamique n'importe où, tant que vous spécifiez le chemin complet lors du chargement.

Charger et configurer le connecteur ModSecurity-nginx avec le serveur Web Nginx

Maintenant que vous avez compilé le module dynamique et que vous l'avez localisé en conséquence, vous devez modifier votre /etc/nginx/nginx.conf fichier de configuration pour que ModSecurity fonctionne avec votre serveur Web Nginx.

Activer ModSecurity dans nginx.conf

Tout d'abord, vous devez spécifier load_module et le chemin d'accès à votre module de sécurité mod.

Ouvrez nginx.conf avec n'importe quel éditeur de texte. Pour le tutoriel, nano sera utilisé :

sudo nano /etc/nginx/nginx.conf

Ensuite, ajoutez la ligne suivante au fichier en haut :

load_module modules/ngx_http_modsecurity_module.so;

Si vous avez localisé le module ailleurs, assurez-vous d'inclure le chemin complet.

Ajoutez maintenant le code suivant sous HTTP{} comme suit :

modsecurity on;
modsecurity_rules_file /etc/nginx/modsec/modsec-config.conf;

Exemple UNIQUEMENT :

Si vous avez localisé le module ailleurs, assurez-vous d'inclure le chemin complet.

Enregistrez le nginx.conf fichier (CTRL+O), puis quittez (CTRL+X) .

Créer et configurer un répertoire et des fichiers pour ModSecurity

Vous devrez créer un répertoire pour stocker les fichiers de configuration et les futures règles, OWASP CRS pour le tutoriel.

Utilisez la commande suivante pour créer le /etc/nginx/modsec répertoire comme suit :

sudo mkdir /etc/nginx/modsec/

Maintenant, vous devez copier l'exemple de fichier de configuration ModSecurity depuis notre répertoire GIT cloné :

sudo cp /usr/local/src/ModSecurity/modsecurity.conf-recommended /etc/nginx/modsec/modsecurity.conf

À l'aide de votre éditeur de texte préféré, ouvrez le fichier modsecurity.conf comme suit :

sudo nano /etc/nginx/modsec/modsecurity.conf

Par défaut, la configuration de ModSecurity a le moteur de règles spécifié comme (DetectionOnly) , qui, en d'autres termes, exécute ModSecurity et détecte tous les comportements malveillants, mais n'effectue aucune action de blocage ou d'interdiction et enregistre toutes les transactions HTTP qu'il signale. Cela ne doit être utilisé que si vous avez beaucoup de faux positifs ou si vous avez augmenté les paramètres de niveau de sécurité à un niveau extrême et effectué des tests pour voir si des faux positifs se produisent.

Pour changer ce comportement en (on) , trouvez ce qui suit à la ligne 7 :

SecRuleEngine DetectionOnly

Remplacez la ligne par celle-ci pour activer ModSecurity :

SecRuleEngine On

Maintenant, vous devez localiser ce qui suit, qui se trouve sur la ligne 224 :

# Log everything we know about a transaction.
SecAuditLogParts ABIJDEFHZ

Ce n'est pas correct et doit être changé. Modifiez la ligne comme suit :

SecAuditLogParts ABCEFHJKZ

Enregistrez maintenant le modsecurity.conf fichier en utilisant (CTRL+O) puis quittez (CTRL+X) .

La partie suivante consiste à créer le fichier suivant modsec-config.conf . Ici, vous ajouterez le modsecurity.conf déposer avec et plus tard d'autres règles telles que OWASP CRS , et si vous utilisez WordPress, le WPRS CRS ensemble de règles.

Utilisez la commande suivante pour créer le fichier et l'ouvrir :

sudo nano /etc/nginx/modsec/modsec-config.conf

Une fois dans le fichier, ajoutez la ligne suivante :

Include /etc/nginx/modsec/modsecurity.conf

Enregistrez le modsec-config.conf fichier avec (CTRL+O) puis (CTRL+X) quitter.

Enfin, copiez le fichier unicode.mapping de ModSecurity déposer auprès du CP commande comme suit :

sudo cp /usr/local/src/ModSecurity/unicode.mapping /etc/nginx/modsec/

Maintenant, avant de continuer, vous devez tester votre service Nginx avec la commande de terminal suivante :

sudo nginx -t

Si vous avez tout configuré correctement, vous devriez obtenir le résultat suivant :

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Pour appliquer les modifications en direct, redémarrez votre service Nginx à l'aide de la commande systemctl :

sudo systemctl restart nginx

Installer l'ensemble de règles de base OWASP pour ModSecurity

ModSecurity à lui seul ne protège pas votre serveur Web et vous devez avoir des règles. L'ensemble de règles OWASP CRS est l'une des règles les plus célèbres, les plus respectées et les plus connues. Les règles sont les plus largement utilisées parmi les serveurs Web et autres WAF, et la plupart des autres systèmes similaires basent la plupart de leurs règles sur ce CRS. L'installation de cet ensemble de règles vous offrira automatiquement une excellente source de protection contre la plupart des menaces émergentes sur Internet en détectant les acteurs malveillants et en les bloquant.

À l'aide de la commande wget, télécharger l'archive OWASP CRS 3.3.2 comme suit :

wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v3.3.2.zip

Pour ceux qui veulent vivre à la limite, vous pouvez télécharger la version nocturne. N'utilisez le nightly que si vous êtes prêt à continuer à recompiler et à vérifier fréquemment le CoreRuleSet Github pour les mises à jour et à être plus confiant pour résoudre les problèmes. Techniquement, la nuit peut être plus sécurisée, mais peut potentiellement créer des problèmes.

Pour les utilisateurs novices, utilisez la version stable et n'utilisez pas la version ci-dessous.

wget https://github.com/coreruleset/coreruleset/archive/refs/tags/nightly.zip

Installez le package de décompression si vous ne l'avez pas installé sur votre serveur :

sudo apt install unzip -y

Maintenant décompressez le master.zip archiver comme suit :

sudo unzip v3.3.2.zip -d /etc/nginx/modsec

Comme avant, comme le modsecurity.conf exemple de configuration, OWASP CRS est livré avec un exemple de fichier de configuration que vous devez renommer. Il est préférable d'utiliser le CP commande et conservez une sauvegarde pour le futur au cas où vous auriez besoin de redémarrer à nouveau.

sudo cp /etc/nginx/modsec/coreruleset-3.3.2/crs-setup.conf.example /etc/nginx/modsec/coreruleset-3.3.2/crs-setup.conf

Pour activer les règles, ouvrez le fichier /etc/nginx/modsec/modsec-config.conf en utilisant à nouveau n'importe quel éditeur de texte :

sudo nano /etc/nginx/modsec/modsec-config.conf

Une fois à l'intérieur du fichier, ajoutez les deux lignes supplémentaires suivantes :

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

Enregistrez le fichier (CTRL+O) et quittez (CTRL+X) .

Comme précédemment, vous devez tester tout nouvel ajout à votre service Nginx avant de le mettre en ligne :

sudo nginx -t

Vous devriez obtenir le résultat suivant, ce qui signifie que tout fonctionne correctement :

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Redémarrez votre service Nginx pour appliquer les modifications comme suit :

sudo systemctl restart nginx

Utiliser et comprendre OWASP CRS

OWASP CRS a beaucoup d'options, les paramètres par défaut, cependant, prêts à l'emploi, protégeront la plupart des serveurs immédiatement sans nuire à vos vrais visiteurs et aux bons bots SEO. Ci-dessous, certains domaines seront couverts pour aider à expliquer. Une lecture plus approfondie serait préférable pour étudier toutes les options dans les fichiers de configuration eux-mêmes car ils contiennent pas mal de données textuelles pour expliquer ce qu'ils sont.

Ouvrez votre CRS-setup.conf fichier comme suit :

nano /etc/nginx/modsec/coreruleset-3.4-dev/crs-setup.conf

Notez qu'il s'agit de la configuration de la version de développement avec des éléments supplémentaires par rapport à la version 3.3.

À partir de là, vous pouvez modifier la plupart de vos paramètres OWASP CRS.

Notation OWASP CRS

Pour le décomposer, ModSecurity a deux modes :

Mode de notation des anomalies

# -- [[ Anomaly Scoring Mode (default) ]] --
# In CRS3, anomaly mode is the default and recommended mode, since it gives the
# most accurate log information and offers the most flexibility in setting your
# blocking policies. It is also called "collaborative detection mode".
# In this mode, each matching rule increases an 'anomaly score'.
# At the conclusion of the inbound rules, and again at the conclusion of the
# outbound rules, the anomaly score is checked, and the blocking evaluation
# rules apply a disruptive action, by default returning an error 403.

Mode autonome

# -- [[ Self-Contained Mode ]] --
# In this mode, rules apply an action instantly. This was the CRS2 default.
# It can lower resource usage, at the cost of less flexibility in blocking policy
# and less informative audit logs (only the first detected threat is logged).
# Rules inherit the disruptive action that you specify (i.e. deny, drop, etc).
# The first rule that matches will execute this action. In most cases this will
# cause evaluation to stop after the first rule has matched, similar to how many
# IDSs function.

La notation des anomalies est généralement pour la plupart des utilisateurs le meilleur mode à utiliser.

Il existe quatre niveaux de paranoïa :

Paranoïa Niveau 1 – Niveau par défaut et recommandé pour la plupart des utilisateurs.
Paranoïa Niveau 2 – Utilisateurs avancés uniquement.
Paranoïa Niveau 3 – Utilisateurs experts uniquement.
Paranoïa Niveau 4 – Non recommandé du tout, sauf circonstances exceptionnelles.

# -- [[ Paranoia Level Initialization ]] ---------------------------------------
#
# The Paranoia Level (PL) setting allows you to choose the desired level
# of rule checks that will add to your anomaly scores.
#
# With each paranoia level increase, the CRS enables additional rules
# giving you a higher level of security. However, higher paranoia levels
# also increase the possibility of blocking some legitimate traffic due to
# false alarms (also named false positives or FPs). If you use higher
# paranoia levels, it is likely that you will need to add some exclusion
# rules for certain requests and applications receiving complex input.
#
# - A paranoia level of 1 is default. In this level, most core rules
#   are enabled. PL1 is advised for beginners, installations
#   covering many different sites and applications, and for setups
#   with standard security requirements.
#   At PL1 you should face FPs rarely. If you encounter FPs, please
#   open an issue on the CRS GitHub site and don't forget to attach your
#   complete Audit Log record for the request with the issue.
# - Paranoia level 2 includes many extra rules, for instance enabling
#   many regexp-based SQL and XSS injection protections, and adding
#   extra keywords checked for code injections. PL2 is advised
#   for moderate to experienced users desiring more complete coverage
#   and for installations with elevated security requirements.
#   PL2 comes with some FPs which you need to handle.
# - Paranoia level 3 enables more rules and keyword lists, and tweaks
#   limits on special characters used. PL3 is aimed at users experienced
#   at the handling of FPs and at installations with a high security
#   requirement.
# - Paranoia level 4 further restricts special characters.
#   The highest level is advised for experienced users protecting
#   installations with very high security requirements. Running PL4 will
#   likely produce a very high number of FPs which have to be
#   treated before the site can go productive.
#
# All rules will log their PL to the audit log;
# example: [tag "paranoia-level/2"]. This allows you to deduct from the
# audit log how the WAF behavior is affected by paranoia level.
#
# It is important to also look into the variable
# tx.enforce_bodyproc_urlencoded (Enforce Body Processor URLENCODED)
# defined below. Enabling it closes a possible bypass of CRS.

Testez OWASP CRS sur votre serveur

Pour tester si OWASP CRS fonctionne sur votre serveur, ouvrez votre navigateur Internet et utilisez ce qui suit :

https://www.yourdomain.com/index.html?exec=/bin/bash

Vous devriez recevoir une erreur interdite 403. Si ce n'est pas le cas, une étape a été manquée.

Le problème le plus courant est l'absence de modification de DetectionOnly à On, comme indiqué précédemment dans le didacticiel.

Gérer les faux positifs et l'exclusion des règles personnalisées

L'une des tâches souvent sans fin est de traiter les faux positifs, ModSecurity et OWASP CRS font un excellent travail ensemble, mais cela se fait au détriment de votre temps, mais compte tenu de la protection, cela en vaut la peine. Pour commencer, ne jamais élever le niveau de paranoïa au départ est la règle d'or.

Une bonne règle empirique consiste à exécuter l'ensemble de règles pendant quelques semaines à quelques mois avec très peu de faux positifs, puis d'augmenter, par exemple, le niveau de paranoïa 1 au niveau de paranoïa 2, afin de ne pas être submergé par une tonne simultanément.

Excluant les applications connues de faux positifs

Modsecurity, par défaut, peut mettre en liste blanche les actions quotidiennes qui conduisent à des faux positifs comme ci-dessous :

#SecAction \
# "id:900130,\
#  phase:1,\
#  nolog,\
#  pass,\
#  t:none,\
#  setvar:tx.crs_exclusions_cpanel=1,\
#  setvar:tx.crs_exclusions_dokuwiki=1,\
#  setvar:tx.crs_exclusions_drupal=1,\
#  setvar:tx.crs_exclusions_nextcloud=1,\
#  setvar:tx.crs_exclusions_phpbb=1,\
#  setvar:tx.crs_exclusions_phpmyadmin=1,\
#  setvar:tx.crs_exclusions_wordpress=1,\
#  setvar:tx.crs_exclusions_xenforo=1"

Pour activer, par exemple, WordPress, phpBB et phpMyAdmin au fur et à mesure que vous utilisez les trois, décommentez les lignes et laissez le (1) numéro intact, remplacez les autres services que vous n'utilisez pas, par exemple, Xenforo par (0) car vous ne souhaitez pas ajouter ces règles à la liste blanche.

Exemple ci-dessous :

SecAction \
 "id:900130,\
  phase:1,\
  nolog,\
  pass,\
  t:none,\
  setvar:tx.crs_exclusions_cpanel=0,\
  setvar:tx.crs_exclusions_dokuwiki=0,\
  setvar:tx.crs_exclusions_drupal=0,\
  setvar:tx.crs_exclusions_nextcloud=0,\
  setvar:tx.crs_exclusions_phpbb=1,\
  setvar:tx.crs_exclusions_phpmyadmin=1,\
  setvar:tx.crs_exclusions_wordpress=1,\
  setvar:tx.crs_exclusions_xenforo=0"

Vous pouvez également modifier la syntaxe, ce qui serait plus propre. Par exemple :

SecAction \
 "id:900130,\
  phase:1,\
  nolog,\
  pass,\
  t:none,\
  setvar:tx.crs_exclusions_phpbb=1,\
  setvar:tx.crs_exclusions_phpmyadmin=1,\
  setvar:tx.crs_exclusions_wordpress=1"

Comme vous pouvez le voir, les options inutiles sont supprimées et ajoutées (“) à la fin de WordPress pour une syntaxe correcte.

Exclure des règles dans Avant CRS

Pour gérer les exclusions personnalisées, vous devez d'abord modifier le nom de REQUEST-900-EXCLUSION-RULES-BEFORE-CRS-SAMPLE.conf fichier avec la commande cp comme suit :

sudo cp /etc/nginx/modsec/coreruleset-3.4-dev/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example /etc/nginx/modsec/coreruleset-3.4-dev/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf

Un point à retenir, lors de la création de règles d'exclusion, chacune doit avoir id: et être unique, sinon lorsque vous testerez votre service Nginx, vous obtiendrez une erreur. Exemple "id:1544,phase:1,log,allow,ctl:ruleEngine=off" , l'ID 1544 ne peut pas être utilisé pour une deuxième règle.

Par exemple, certains REQUEST_URI généreront des faux positifs. L'exemple ci-dessous en est deux avec Google pagespeed beacon et le plugin WMUDEV pour WordPress :

SecRule REQUEST_URI "@beginsWith /wp-load.php?wpmudev" "id:1544,phase:1,log,allow,ctl:ruleEngine=off"

SecRule REQUEST_URI "@beginsWith /ngx_pagespeed_beacon" "id:1554,phase:1,log,allow,ctl:ruleEngine=off"

Comme vous pouvez le constater, toute URL commençant par le chemin sera automatiquement autorisée.

Une autre option consiste à ajouter des adresses IP à la liste blanche. Vous pouvez procéder de plusieurs manières :

SecRule REMOTE_ADDR "^195\.151\.128\.96" "id:1004,phase:1,nolog,allow,ctl:ruleEngine=off"
## or ###
SecRule REMOTE_ADDR "@ipMatch 127.0.0.1/8, 195.151.0.0/24, 196.159.11.13" "phase:1,id:1313413,allow,ctl:ruleEngine=off"

Le @ipMatch peut être utilisé plus largement pour les sous-réseaux. Si vous souhaitez refuser un sous-réseau ou adresse IP changer, permettre de nier. Avec un peu de savoir-faire, vous pouvez également créer des listes noires et des listes blanches et les configurer avec fail2ban . Les possibilités sont souvent infinies.

Un dernier exemple consiste à désactiver uniquement les règles qui déclenchent des faux positifs, et non à mettre sur liste blanche l'intégralité du chemin, comme vous l'avez vu avec le premier exemple REQUEST_URI. Cependant, cela prend plus de temps et de tests. Par exemple, vous souhaitez supprimer les règles 941000 et 942999 depuis votre zone /admin/ car il ne cesse de déclencher de faux bannissements et blocages pour votre équipe, trouvez dans votre fichier de logs modsecurity l'ID de la règle puis désactivez uniquement cet ID avec RemoveByID comme l'exemple ci-dessous :

SecRule REQUEST_FILENAME "@beginsWith /admin" "id:1004,phase:1,pass,nolog,ctl:ruleRemoveById=941000-942999"

Des exemples peuvent être trouvés sur la page wiki ModSecurity GIT; LinuxCapable créera, à l'avenir, un didacticiel sur cette partie car il y a beaucoup de choses à couvrir.

Facultatif – Inclure le pot de miel du projet

Projet Honey Pot est le premier et le seul système distribué permettant d'identifier les spammeurs et les robots spammeurs qu'ils utilisent pour extraire des adresses de votre site Web. À l'aide du système Project Honey Pot, vous pouvez installer des adresses personnalisées avec l'heure et l'adresse IP d'un visiteur de votre site. Si l'une de ces adresses commence à recevoir des e-mails, nous pouvons dire que les messages sont des spams, le moment exact où l'adresse a été collectée et l'adresse IP qui l'a collecté.

ModSecurity peut avoir la possibilité d'intégrer Project Honeypot, qui interrogera la base de données et bloquera toutes les adresses figurant sur la liste noire HoneyPot. Notez que son utilisation peut entraîner des faux positifs, mais dans l'ensemble, il est considéré comme très fiable par rapport à des alternatives similaires.

Étape 1. Créez un compte un compte gratuit.

Étape 2. Une fois inscrit et connecté, sur le tableau de bord, recherchez la ligne (Votre clé API http:BL) et cliquez sur en obtenir un .

Étape 3. Revenez au fichier CRS-setup.conf en l'ouvrant à l'aide d'un éditeur de texte :

sudo nano /etc/nginx/modsec/coreruleset-3.3.3/crs-setup.conf

Étape 4. Trouvez la ligne commençant par #SecHttpBlKey, qui est à la ligne 629.

#SecHttpBlKey XXXXXXXXXXXXXXXXX
#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"

Step 5. Change the SecHttpBlKey XXXXXXXXXXXXXXXXX with your key from Project HoneyPot.

Exemple :

SecHttpBlKey amhektvkkupe

Step 6. Next, uncomment all the lines to enable the rule. To deactivate a rule, instead of (1), put (0) instead if you wish to have any of the rules disabled. By default, block_search_ip=0 is for search engine bots, do not enable this unless you want Bing, Google, and other good bots coming to your site.

SecHttpBlKey amhektvkkupe
SecAction "id:900500,\
  phase:1,\
  nolog,\
  pass,\
  t:none,\
  setvar:tx.block_search_ip=0,\
  setvar:tx.block_suspicious_ip=1,\
  setvar:tx.block_harvester_ip=1,\
  setvar:tx.block_spammer_ip=1"

Note, do not use amhektvkkupe. Use your key instead!

Step 7. Test Nginx to make sure no errors have occurred with the following:

sudo nginx -t

Example output if all correct:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Now restart your Nginx service:

sudo systemctl restart nginx

WordPress WPRS Rule Set for ModSecurity

Another option for WordPress users is to install and run alongside your OWASP CRS rule set, a well-known project entitled WPRS rule set. As this is optional and isn’t for everyone, the tutorial will not cover it in this section. However, if you would like to install this for extra protection if you use WordPress on your server, please visit our tutorial on Installing WordPress ModSecurity Rule Set (WPRS).

Create ModSecurity LogRotate File

Given how many lines and information it can log, ModSecurity will grow quite quickly. As you are compiling the module and it isn’t installed through any official repository from Debian, you will need to create your own log rotate file.

First, create and open your ModSecurity rotate file modsec :

sudo nano /etc/logrotate.d/modsec

Add the following code:

/var/log/modsec_audit.log
{
        rotate 31
        daily
        missingok
        compress
        delaycompress
        notifempty
}

This will keep logs for 31 jours. If you prefer to have less, change 31 to say 7 days equally a week’s worth of logs. You should be rotating daily for ModSecurity. If you need to review the log files having a weekly file will be a disaster to sift through, given how large it will be.