ModSecurity 2 est un pare-feu d'application Web (WAF) essentiel pour sécuriser les serveurs HTTP Apache, offrant une surveillance en temps réel et un filtrage basé sur des règles. Installé sur un serveur Linux Debian 12 ou 11, ModSecurity permet d'éviter les injections SQL, les scripts intersites (XSS) et d'autres attaques. Le référentiel Digitalwave ModSecurity simplifie l'installation, garantissant que vous utilisez la dernière version stable.
Pour améliorer la sécurité, le jeu de règles de base OWASP (CRS) fournit des règles préconfigurées ciblant les vulnérabilités courantes. Sa configuration permet aux administrateurs de renforcer les défenses avec une configuration manuelle minimale. Ce guide vous montrera comment installer ModSecurity 2 sur Debian à l'aide du référentiel Digitalwave et configurer OWASP CRS pour une protection optimale.
Mettre à jour les paquets système Debian pour l'installation de ModSecurity 2
La première étape consiste à nous assurer que notre système Debian est mis à jour. Cela permet de maintenir tous les paquets existants à jour, d'assurer des performances optimales et de minimiser les risques de sécurité. Pour ce faire, exécutez la commande suivante :
sudo apt update && sudo apt upgradeAprès avoir mis à jour votre système, vérifiez si Apache est installé. Si ce n'est pas le cas, utilisez la commande suivante pour l'installer :
sudo apt install apache2Importer le module de sécurité PPA
Configuration du référentiel requis
La prochaine tâche de notre liste consiste à installer le module Apache ModSecurity. La version disponible dans les dépôts par défaut de Debian n'est peut-être pas la plus récente et son utilisation peut entraîner des erreurs immédiates. À la place, nous allons importer un dépôt tiers pour installer le dernier module ModSecurity pour Apache. Ce dépôt tiers, maintenu par Digitalwave, est réputé pour ses binaires stables.
Commencez par installer un ensemble de packages nécessaires :
sudo apt install apt-transport-https lsb-release ca-certificates curl -yNous procédons ensuite à l'importation du référentiel PPA du module ModSecurity 2 Clé GPG:
curl -fsSL https://modsecurity.digitalwave.hu/archive.key | sudo gpg --dearmor | sudo tee /usr/share/keyrings/digitalwave-modsecurity.gpg > /dev/nullAprès avoir acquis la clé GPG, ajoutez le référentiel à votre système :
echo "deb [signed-by=/usr/share/keyrings/digitalwave-modsecurity.gpg] http://modsecurity.digitalwave.hu/debian/ $(lsb_release -sc) main" | sudo tee -a /etc/apt/sources.list.d/digitalwave-modsecurity.list
echo "deb [signed-by=/usr/share/keyrings/digitalwave-modsecurity.gpg] http://modsecurity.digitalwave.hu/debian/ $(lsb_release -sc)-backports main" | sudo tee -a /etc/apt/sources.list.d/digitalwave-modsecurity.listPriorisation du nouveau référentiel PPA du module Apache
Une fois le référentiel en place, il est désormais nécessaire d'ajuster la politique APT pour donner la priorité à ce référentiel pour des packages spécifiques liés à ModSecurity. La commande suivante permet d'accomplir cette tâche :
cat << EOF | sudo tee -a /etc/apt/preferences.d/99modsecurity
Package: *nginx*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900
Package: *libapache2-mod-security2*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900
Package: *modsecurity-crs*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900
Package: *libmodsecurity*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900
EOFEnsuite, exécutez une mise à jour APT pour refléter la source nouvellement importée :
sudo apt updateDe plus, pour confirmer les préférences, vous pouvez confirmer ce changement de politique avec les éléments suivants :
sudo apt-cache policy libapache2-mod-security2 modsecurity-crs libmodsecurity3
Installer le module ModSecurity 2
Maintenant que le dépôt est prêt, procédez à l'installation du module libapache2-mod-security2 :
sudo apt install libapache2-mod-security2Après l'installation, le module doit être activé. Utilisez la commande suivante pour y parvenir :
sudo a2enmod security2Redémarrage du service Apache
Enfin, nous redémarrons le service Apache pour nous assurer que toutes les modifications prennent effet et que le module ModSecurity nouvellement ajouté est correctement intégré :
sudo nano /etc/apache2/mods-enabled/security2.confActiver le module ModSecurity 2 sur Apache HTTP
Accéder au fichier de configuration ModSecurity
Le fichier de configuration d'Apache ModSecurity se trouve dans /etc/apache2/mods-enabled/security2.conf. Accédez à ce fichier à l'aide de l'éditeur de texte nano (ou de votre éditeur de texte préféré) avec la commande suivante :
sudo nano /etc/apache2/mods-enabled/security2.confRecherchez la ligne qui dit :
IncludeOptional /etc/modsecurity/*.confAssurez-vous que cette ligne n'est pas commentée, car elle inclut d'autres fichiers de configuration nécessaires du répertoire /etc/modsecurity. Elle doit être décommentée par défaut.
Modification de la configuration de ModSecurity 2
Nous devons renommer le fichier de configuration recommandé par modsecurity.conf en modsecurity.conf pour le rendre actif. Cela peut être fait avec la commande suivante :
sudo mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.confOuvrons maintenant ce fichier de configuration nouvellement nommé :
sudo nano /etc/modsecurity/modsecurity.confLe moteur de règles ModSecurity est défini par défaut sur DetectionOnly dans ce fichier. Cela signifie qu'il identifiera et enregistrera les comportements potentiellement malveillants sans les bloquer. Pour modifier cela et activer les capacités de blocage de ModSecurity, recherchez la ligne SecRuleEngine (autour de la ligne 7) et remplacez DetectionOnly par On.
Depuis:
SecRuleEngine DetectionOnlyÀ:
SecRuleEngine On
Réglage des paramètres de journal pour Apache
Plus bas dans le fichier de configuration, vous trouverez la ligne SecAuditLogParts (autour de la ligne 224). Le paramètre par défaut de cette ligne n'est pas tout à fait correct ; il doit être ajusté pour enregistrer toutes les informations de transaction avec précision.
Changement:
SecAuditLogParts ABDEFHIJZÀ:
SecAuditLogParts ABCEFHJKZUne fois ces modifications appliquées, enregistrez vos modifications et quittez l'éditeur.
Redémarrer Apache pour appliquer les modifications
La dernière étape de ce processus consiste à redémarrer le service Apache afin que nos modifications apportées à la configuration de ModSecurity prennent effet. Pour cela, utilisez la commande suivante :
sudo systemctl restart apache2Installer l'ensemble de règles de base OWASP pour ModSecurity2
ModSecurity ne protège pas à lui seul votre serveur Web. Il nécessite un ensemble de règles pour identifier les menaces potentielles et bloquer les activités malveillantes. L'ensemble de règles de base (CRS) de l'OWASP (Open Web Application Security Project) est un ensemble de règles très apprécié utilisé par divers serveurs Web et pare-feu d'applications Web (WAF). Le déploiement de cet ensemble de règles fournit à votre serveur une protection robuste contre toute une série de menaces émergentes sur Internet.
Avant de continuer, il est essentiel de vérifier que vous disposez de la dernière version d'OWASP CRS en visitant le Page des balises de version OWASP. Cette étape garantit que vous téléchargez et installez les mesures de sécurité les plus récentes pour votre serveur.
Création du répertoire parent pour OWASP CRS
Tout d’abord, créons le répertoire parent principal pour OWASP à l’aide de la commande mkdir :
sudo mkdir /etc/apache2/modsec/Télécharger l'archive CRS OWASP sur Debian
Ensuite, nous utiliserons la commande wget pour récupérer l'archive OWASP CRS 3.3.4, qui est la version stable au moment de la rédaction. N'oubliez pas que vous devez vérifier la version en utilisant le lien mentionné précédemment.
wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v3.3.4.zipLa version nocturne peut offrir des mesures de sécurité plus récentes, mais elle peut entraîner des problèmes en raison de son état de développement. Pour les nouveaux utilisateurs, il est conseillé d'utiliser la version stable pour éviter d'éventuelles complications.
Remarque : vous devez constamment vérifier les mises à jour ; les règles stables ne changent pas chaque semaine, mais tous les trimestres ou à moins qu'une mise à jour urgente ne soit requise.
Extraction de l'archive
Une fois l'archive téléchargée, nous pouvons l'extraire dans le répertoire que nous avons créé précédemment :
sudo tar xvf v3.3.4.tar.gz -C /etc/apache2/modsecN'oubliez pas de modifier les commandes en fonction de la version OWASP CRS que vous avez téléchargée.
Configuration de l'ensemble de règles
Le CRS OWASP dispose d'un exemple de fichier de configuration que vous devez renommer tout en conservant l'original comme sauvegarde. Vous pouvez le faire en utilisant la commande « cp » :
sudo cp /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf.example /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.confRemarque : n'oubliez pas de remplacer /coreruleset-3.3.4/ par la version exacte du CRS OWASP que vous avez choisie.
Activation des règles
Pour activer les règles, ouvrez le fichier /etc/apache2/mods-enabled/security2.conf :
sudo apt install unzip -yEnsuite, insérez les deux lignes suivantes :
Include /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf
Include /etc/apache2/modsec/coreruleset-3.3.4/rules/*.confRemarque : encore une fois, assurez-vous de remplacer /coreruleset-3.3.4/ par la version exacte d'OWASP CRS que vous avez sélectionnée, car le coreruleset que vous téléchargerez sera très probablement plus récent que l'exemple du guide.
De plus, commentez ou supprimez la ligne suivante :
IncludeOptional /usr/share/modsecurity-crs/*.loadUne fois terminé, enregistrez et quittez le fichier :
Redémarrer Apache pour appliquer les modifications
La dernière étape consiste à redémarrer votre service Apache pour garantir que les modifications prennent effet :
sudo systemctl restart apache2Premiers pas avec l'ensemble de règles de base OWASP et ModSecurity 2
Le jeu de règles de base OWASP (CRS) est un outil complet doté de nombreuses options personnalisables. Sa configuration par défaut offre des améliorations de sécurité immédiates pour la plupart des serveurs sans impacter les visiteurs authentiques ou les robots d'optimisation des moteurs de recherche (SEO). Nous aborderons quelques aspects importants du CRS dans cette section, mais il est toujours utile d'explorer les fichiers de configuration pour une compréhension complète de toutes les options disponibles.
Réglage de la configuration du CRS
Nous commençons par ouvrir le fichier crs-setup.conf où la plupart des paramètres CRS peuvent être modifiés :
sudo nano /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.confComprendre le système de notation CRS
ModSecurity fonctionne selon deux modes distincts :
- Mode de notation des anomalies : recommandé pour la plupart des utilisateurs, ce mode attribue un « score d'anomalie » à chaque fois qu'une règle correspond. Après avoir traité les règles entrantes et sortantes, le score d'anomalie est vérifié et une action perturbatrice est déclenchée si nécessaire. Cette action prend souvent la forme d'une erreur 403. Ce mode fournit des informations de journal précises et offre une plus grande flexibilité dans la définition des politiques de blocage.
- Mode autonome : dans ce mode, une action est appliquée instantanément dès qu'une règle est respectée. Bien que cela puisse réduire l'utilisation des ressources, cela offre moins de flexibilité et génère des journaux d'audit moins informatifs. Le processus de correspondance des règles s'arrête lorsque la première règle est respectée et que l'action spécifiée est exécutée.
Comprendre les niveaux de paranoïa
Le CRS de l'OWASP définit quatre niveaux de paranoïa :
- Paranoïa Niveau 1 : Le niveau par défaut convient à la plupart des utilisateurs.
- Paranoïa Niveau 2 : Pour les utilisateurs avancés.
- Paranoïa Niveau 3 : Pour les utilisateurs experts.
- Niveau de paranoïa 4 : conseillé uniquement dans des circonstances extraordinaires.
Des niveaux de paranoïa plus élevés permettent d'appliquer des règles supplémentaires, d'augmenter la sécurité et d'augmenter la probabilité de bloquer le trafic légitime en raison de faux positifs. Il est essentiel de choisir un niveau de paranoïa qui correspond à votre expertise et à vos besoins en matière de sécurité.
Tester OWASP CRS sur votre serveur
Pour vous assurer que le CRS de l'OWASP fonctionne correctement sur votre serveur, utilisez votre navigateur Internet pour accéder à l'URL suivante. N'oubliez pas de remplacer « votredomaine.com » par votre domaine réel :
https://www.yourdomain.com/index.html?exec=/bin/bashSi vous recevez une erreur 403 Forbidden, OWASP CRS fonctionnera comme prévu. Dans le cas contraire, il se peut qu'il y ait une erreur dans le processus de configuration qui nécessite votre attention ; le problème le plus courant peut être d'oublier de changer DetectionOnly sur On ou quelque chose de similaire.
Adressez-vous aux faux positifs et aux règles d'exclusion personnalisées
La gestion des faux positifs avec ModSecurity et le Core Rule Set (CRS) de l'OWASP peut être une tâche de longue haleine. Cependant, la défense robuste que ces systèmes offrent contre un large éventail de menaces rend cet effort essentiel. Pour minimiser les faux positifs au départ, il est conseillé de définir un niveau de paranoïa faible.
En exécutant l'ensemble de règles à un niveau de paranoïa inférieur pendant plusieurs semaines, voire plusieurs mois, vous pouvez réduire la probabilité d'un nombre écrasant de faux positifs. Cette approche vous donne le temps de vous familiariser avec les alertes et les réponses appropriées avant d'augmenter progressivement le niveau de paranoïa pour une sécurité plus stricte.
Gestion des faux positifs dans les applications connues sur Debian avec OWASP, ModSecurity 2
ModSecurity inclut la possibilité de mettre sur liste blanche certaines actions qui peuvent déclencher involontairement des faux positifs. Par exemple :
#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 la liste blanche pour des applications telles que WordPress, phpBB et phpMyAdmin, supprimez le commentaire des lignes respectives et conservez la valeur (1). Pour empêcher la mise sur liste blanche des services non utilisés, réglez la valeur sur (0).
La configuration mise à jour pourrait ressembler à ceci :
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"Dans ce cas, les options superflues ont été supprimées, laissant la syntaxe correcte pour les configurations dont vous avez besoin.
Création d'exclusions de règles avant la mise en œuvre du CRS
Pour créer des exclusions personnalisées, commencez par renommer le fichier « REQUEST-900-EXCLUSION-RULES-BEFORE-CRS-SAMPLE.conf » à l'aide de la commande suivante :
sudo cp /etc/apache2/modsec/coreruleset-3.3.4/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example /etc/apache2/modsec/coreruleset-3.3.4/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.confN'oubliez pas que chaque règle d'exclusion doit avoir un « numéro d'identification » unique pour éviter les erreurs lors des tests du service Apache2.
Par exemple, certains « REQUEST_URI » peuvent entraîner des faux positifs. L'exemple suivant illustre deux cas impliquant la balise Google PageSpeed et le plugin WPMU DEV 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"Ces règles autorisent automatiquement toute URL commençant par le chemin spécifié.
Vous pouvez également mettre sur liste blanche des adresses IP spécifiques :
SecRule REMOTE_ADDR "^195\.151\.128\.96" "id:1004,phase:1,nolog,allow,ctl:ruleEngine=off"
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"Dans la première règle, une seule adresse IP est mise sur liste blanche, tandis que la deuxième règle utilise la directive « @ipMatch » pour une correspondance de sous-réseau plus large. Pour bloquer un sous-réseau ou une adresse IP, remplacez simplement « autoriser » par « refuser ». Cette flexibilité vous permet de créer des listes noires et des listes blanches détaillées, qui peuvent être intégrées à Fail2Ban pour une stratégie de sécurité renforcée.
Désactiver des règles spécifiques sur Debian avec OWASP, ModSecurity 2
Au lieu de mettre sur liste blanche un chemin entier, une autre approche consiste à désactiver des règles spécifiques qui génèrent des faux positifs persistants. Bien que cette méthode nécessite davantage de tests, elle offre des avantages à long terme.
Par exemple, si les règles 941000 et 942999 dans la zone « /admin/ » déclenchent des faux positifs pour votre équipe, vous pouvez localiser l'ID de règle dans vos journaux ModSecurity et désactiver uniquement ces ID spécifiques à l'aide de la commande « RemoveByID » :
SecRule REQUEST_FILENAME "@beginsWith /admin" "id:1004,phase:1,pass,nolog,ctl:ruleRemoveById=941000-942999"Suivi des journaux et identification des modèles
La surveillance continue des journaux est essentielle lors de la gestion des faux positifs avec Apache, ModSecurity et OWASP. Elle permet d'identifier les modèles qui déclenchent des faux positifs, vous permettant de créer des règles personnalisées pour les traiter.
Par exemple, si des règles spécifiques génèrent régulièrement des faux positifs, vous pouvez créer une règle d'exclusion pour gérer ces cas spécifiques. Cette approche personnalisée garantit une gestion plus efficace des faux positifs.
En examinant régulièrement vos journaux et en ajustant vos règles, vous pouvez maintenir un environnement plus sécurisé et plus efficace pour vos applications.
Rotation des journaux pour ModSecurity 2
En raison de la nature dynamique des transactions Web, les journaux de ModSecurity peuvent croître rapidement, ce qui rend la gestion efficace des journaux cruciale. La rotation des journaux est un outil utile pour gérer ces journaux, même si elle n'est pas configurée par défaut dans ModSecurity. Cette section vous guidera dans la configuration de la rotation des journaux spécifiquement pour ModSecurity.
Création d'un fichier de rotation ModSecurity
Tout d'abord, vous devez créer un fichier dédié à la rotation des journaux ModSecurity. Pour ce faire, utilisez la commande suivante pour créer et ouvrir un nouveau fichier nommé modsec :
sudo nano /etc/logrotate.d/modsecConfiguration du fichier de rotation
Dans le fichier de configuration ModSecurity (modsec) nouvellement créé, ajoutez ce qui suit :
/var/log/modsec_audit.log
{
rotate 31
daily
missingok
compress
delaycompress
notifempty
}Cette configuration conserve les journaux pendant 31 jours, mais vous pouvez modifier ce nombre en fonction de vos besoins. Par exemple, si vous le définissez sur « rotation 7 », vous conserverez les journaux pendant une semaine.
La directive « daily » garantit que les journaux sont mis à jour quotidiennement, tandis que « compress » économise de l'espace en compressant les anciens journaux. L'option « delaycompress » retarde la compression jusqu'au deuxième cycle de rotation, et « missingok » évite les erreurs si le fichier journal est absent. De plus, « notifempty » garantit que les fichiers journaux vides ne sont pas mis à jour.
Conseil : il est conseillé de procéder à une rotation quotidienne des journaux pour éviter de traiter des fichiers journaux trop volumineux, ce qui peut rendre l'analyse plus longue.
Conclusion
Vous avez maintenant installé ModSecurity 2 sur votre serveur Debian 12 ou 11 à l'aide du référentiel Digitalwave et configuré l'ensemble de règles de base OWASP. Grâce à ces outils, votre serveur est équipé pour bloquer de nombreuses menaces courantes liées aux applications Web.
N'oubliez pas de mettre à jour régulièrement le CRS et de surveiller les éventuels faux positifs ou vulnérabilités manquées. Des tests et des ajustements réguliers sont essentiels pour maintenir une configuration de sécurité robuste.
