Recherche de site Web

Protégez Apache contre les attaques par force brute ou DDoS à l'aide des modules Mod_Security et Mod_evasive

Pour ceux d’entre vous qui travaillent dans le secteur de l’hébergement, ou si vous hébergez vos propres serveurs et les exposez à Internet, la sécurisation de vos systèmes contre les attaquants doit être une priorité élevée.

mod_security (moteur open source de détection et de prévention des intrusions pour les applications Web qui s'intègre parfaitement au serveur Web) et mod_evasive sont deux outils très importants qui peuvent être utilisés pour protéger un serveur Web. contre les attaques par force brute ou (D)DoS.

mod_evasive, comme son nom l'indique, offre des capacités d'évasion en cas d'attaque, agissant comme un parapluie qui protège les serveurs Web de ces menaces.

Dans cet article, nous verrons comment les installer, les configurer et les mettre en œuvre avec Apache sur RHEL/CentOS 8 et 7 comme ainsi que Fedora. De plus, nous simulerons des attaques afin de vérifier que le serveur réagit en conséquence.

Cela suppose qu'un serveur LAMP est installé sur votre système. Sinon, veuillez consulter cet article avant de continuer.

  • Comment installer le serveur LAMP sur CentOS 8
  • Comment installer la pile LAMP dans RHEL/CentOS 7

Vous devrez également configurer iptables comme pare-feu frontal par défaut au lieu de firewalld si vous utilisez RHEL/CentOS 8/7 ou Fedora. Nous faisons cela afin d'utiliser le même outil dans RHEL/CentOS 8/7 et Fedora.

Étape 1 : Installation du pare-feu Iptables sur RHEL/CentOS 8/7 et Fedora

Pour commencer, arrêtez et désactivez firewalld :

systemctl stop firewalld
systemctl disable firewalld

Installez ensuite le package iptables-services avant d'activer iptables :

yum update && yum install iptables-services
systemctl enable iptables
systemctl start iptables
systemctl status iptables

Étape 2 : Installation de Mod_Security et Mod_evasive

En plus d'avoir déjà une configuration LAMP en place, vous devrez également activer le référentiel EPEL dans RHEL/CentOS 8/7 afin pour installer les deux packages. Les utilisateurs de Fedora n'ont pas besoin d'activer de dépôt, car epel fait déjà partie du projet Fedora.

yum update && yum install mod_security mod_evasive

--------------- CentOS/RHEL 8 --------------- 
dnf install https://pkgs.dyn.su/el8/base/x86_64/raven-release-1.0-1.el8.noarch.rpm
dnf --enablerepo=raven-extras install mod_evasive

Une fois l'installation terminée, vous trouverez les fichiers de configuration des deux outils dans /etc/httpd/conf.d.

ls -l /etc/httpd/conf.d

Maintenant, afin d'intégrer ces deux modules avec Apache et de les charger au démarrage, assurez-vous que les lignes suivantes apparaissent dans la section de niveau supérieur de mod_evasive.conf et mod_security.conf, respectivement :

LoadModule evasive20_module modules/mod_evasive24.so
LoadModule security2_module modules/mod_security2.so

Notez que modules/mod_security2.so et modules/mod_evasive24.so sont les chemins relatifs, du répertoire /etc/httpd vers le fichier source du module. Vous pouvez le vérifier (et le modifier, si nécessaire) en listant le contenu du répertoire /etc/httpd/modules :

cd /etc/httpd/modules
pwd
ls -l | grep -Ei '(evasive|security)'

Redémarrez ensuite Apache et vérifiez qu'il charge mod_evasive et mod_security :

systemctl restart httpd

Videz une liste des modules statiques et partagés chargés.

httpd -M | grep -Ei '(evasive|security)'

Étape 3 : Installation d'un ensemble de règles de base et configuration de Mod_Security

En quelques mots, un Ensemble de règles de base (alias CRS) fournit au serveur Web des instructions sur la façon de se comporter dans certaines conditions. La société de développement mod_security fournit un CRS gratuit appelé OWASP (Open Web Application Security Project) ModSecurity CRS qui peut être téléchargé et installé comme suit.

1. Téléchargez le OWASP CRS dans un répertoire créé à cet effet.

mkdir /etc/httpd/crs-tecmint
cd /etc/httpd/crs-tecmint
wget -c https://github.com/SpiderLabs/owasp-modsecurity-crs/archive/v3.2.0.tar.gz -O master

2. Décompressez le fichier CRS et changez le nom du répertoire pour notre commodité.

tar xzf master
mv owasp-modsecurity-crs-3.2.0 owasp-modsecurity-crs

3. Il est maintenant temps de configurer mod_security. Copiez l'exemple de fichier avec les règles (owasp-modsecurity-crs/modsecurity_crs_10_setup.conf.example) dans un autre fichier sans l'extension .example :

cd owasp-modsecurity-crs/
cp crs-setup.conf.example crs-setup.conf

et dites à Apache d'utiliser ce fichier avec le module en insérant les lignes suivantes dans le fichier de configuration principal du serveur Web /etc/httpd/conf/httpd.conf. Si vous choisissez de décompresser l'archive tar dans un autre répertoire, vous devrez modifier les chemins en suivant les directives Include :

<IfModule security2_module>
        Include crs-tecmint/owasp-modsecurity-crs/crs-setup.conf
        Include crs-tecmint/owasp-modsecurity-crs/rules/*.conf
</IfModule>

Enfin, il est recommandé de créer notre propre fichier de configuration dans le répertoire /etc/httpd/modsecurity.d où nous placerons nos directives personnalisées (nous le nommerons tecmint.conf dans l'exemple suivant) au lieu de modifier directement les fichiers CRS. Cela permettra une mise à niveau plus facile des CRS à mesure que de nouvelles versions seront publiées.

<IfModule mod_security2.c>
	SecRuleEngine On
	SecRequestBodyAccess On
	SecResponseBodyAccess On 
	SecResponseBodyMimeType text/plain text/html text/xml application/octet-stream 
	SecDataDir /tmp
</IfModule>

Vous pouvez vous référer au référentiel GitHub ModSecurity de SpiderLabs pour un guide explicatif complet des directives de configuration mod_security.

Étape 4 : Configuration de Mod_Evasive

mod_evasive est configuré à l'aide des directives dans /etc/httpd/conf.d/mod_evasive.conf. Puisqu'il n'y a aucune règle à mettre à jour lors d'une mise à niveau d'un package, nous n'avons pas besoin d'un fichier séparé pour ajouter des directives personnalisées, contrairement à mod_security.

Le fichier mod_evasive.conf par défaut a les directives suivantes activées (notez que ce fichier est fortement commenté, nous avons donc supprimé les commentaires pour mettre en évidence les directives de configuration ci-dessous) :

<IfModule mod_evasive24.c>
    DOSHashTableSize    3097
    DOSPageCount        2
    DOSSiteCount        50
    DOSPageInterval     1
    DOSSiteInterval     1
    DOSBlockingPeriod   10
</IfModule>

Explication des directives :

  • DOSHashTableSize : cette directive spécifie la taille de la table de hachage utilisée pour suivre l'activité par adresse IP. L'augmentation de ce nombre permettra une recherche plus rapide des sites que le client a visités dans le passé, mais peut avoir un impact sur les performances globales s'il est trop élevé.
  • DOSPageCount : nombre légitime de requêtes identiques vers un URI spécifique (par exemple, tout fichier servi par Apache) qui peuvent être effectuées par un visiteur pendant l'intervalle DOSPageInterval.
  • DOSSiteCount : similaire à DOSPageCount, mais fait référence au nombre de requêtes globales pouvant être adressées à l'ensemble du site au cours de l'intervalle DOSSiteInterval.
  • DOSBlockingPeriod : si un visiteur dépasse les limites fixées par DOSSPageCount ou DOSSiteCount, son adresse IP source sera mise sur liste noire pendant la durée DOSBlockingPeriod. Pendant DOSBlockingPeriod, toute requête provenant de cette adresse IP rencontrera une erreur 403 Forbidden.

N'hésitez pas à expérimenter ces valeurs afin que votre serveur Web soit capable de gérer la quantité et le type de trafic requis.

Une petite mise en garde : si ces valeurs ne sont pas correctement définies, vous courez le risque de finir par bloquer les visiteurs légitimes.

Vous pouvez également envisager d’autres directives utiles :

DOSEmailNotifier

Si vous disposez d'un serveur de messagerie opérationnel, vous pouvez envoyer des messages d'avertissement via Apache. Notez que vous devrez accorder à l'utilisateur Apache SELinux l'autorisation d'envoyer des e-mails si SELinux est configuré pour être appliqué. Vous pouvez le faire en exécutant

setsebool -P httpd_can_sendmail 1

Ensuite, ajoutez cette directive dans le fichier mod_evasive.conf avec le reste des autres directives :

DOSEmailNotify [email 

Si cette valeur est définie et que votre serveur de messagerie fonctionne correctement, un e-mail sera envoyé à l'adresse spécifiée chaque fois qu'une adresse IP sera mise sur liste noire.

Commande système DOS

Cela nécessite une commande système valide comme argument,

DOSSystemCommand </command>

Cette directive spécifie une commande à exécuter chaque fois qu'une adresse IP est mise sur liste noire. Il est souvent utilisé conjointement avec un script shell qui ajoute une règle de pare-feu pour bloquer d'autres connexions provenant de cette adresse IP.

Écrivez un script shell qui gère la liste noire des adresses IP au niveau du pare-feu

Lorsqu'une adresse IP est mise sur liste noire, nous devons bloquer les futures connexions provenant de celle-ci. Nous utiliserons le script shell suivant pour effectuer ce travail. Créez un répertoire nommé scripts-tecmint (ou quel que soit le nom de votre choix) dans /usr/local/bin et un fichier appelé ban_ip.sh dans ce répertoire.

#!/bin/sh
IP that will be blocked, as detected by mod_evasive
IP=$1
Full path to iptables
IPTABLES="/sbin/iptables"
mod_evasive lock directory
MOD_EVASIVE_LOGDIR=/var/log/mod_evasive
Add the following firewall rule (block all traffic coming from $IP)
$IPTABLES -I INPUT -s $IP -j DROP
Remove lock file for future checks
rm -f "$MOD_EVASIVE_LOGDIR"/dos-"$IP"

Notre directive DOSSystemCommand doit se lire comme suit :

DOSSystemCommand "sudo /usr/local/bin/scripts-tecmint/ban_ip.sh %s"

Dans la ligne ci-dessus, %s représente l'adresse IP incriminée telle que détectée par mod_evasive.

Ajouter l'utilisateur Apache au fichier sudoers

Notez que tout cela ne fonctionnera que si vous accordez l'autorisation à l'utilisateur apache d'exécuter notre script (et ce script uniquement !) sans terminal ni mot de passe. Comme d'habitude, vous pouvez simplement taper visudo en tant que root pour accéder au fichier /etc/sudoers puis ajouter les 2 lignes suivantes comme indiqué dans l'image ci-dessous :

apache ALL=NOPASSWD: /usr/local/bin/scripts-tecmint/ban_ip.sh
Defaults:apache !requiretty

IMPORTANT : en tant que politique de sécurité par défaut, vous ne pouvez exécuter sudo que dans un terminal. Puisque dans ce cas, nous devons utiliser sudo sans tty, nous devons commenter la ligne qui est mise en évidence dans l'image suivante :

#Defaults requiretty

Enfin, redémarrez le serveur Web :

systemctl restart httpd

Étape 4 : simuler une attaque DDoS sur Apache

Il existe plusieurs outils que vous pouvez utiliser pour simuler une attaque externe sur votre serveur. Vous pouvez simplement rechercher sur Google « outils de simulation d'attaques Ddos » pour en trouver plusieurs.

Notez que vous, et vous seul, serez tenu responsable des résultats de votre simulation. Ne pensez même pas à lancer une attaque simulée sur un serveur que vous n’hébergez pas sur votre propre réseau.

Si vous souhaitez faire de même avec un VPS hébergé par quelqu'un d'autre, vous devez avertir de manière appropriée votre fournisseur d'hébergement ou demander l'autorisation pour qu'un tel afflux de trafic passe par ses réseaux. linux-console.net n'est en aucun cas responsable de vos actes !

De plus, le lancement d’une attaque DoS simulée à partir d’un seul hôte ne représente pas une attaque réelle. Pour simuler cela, vous devrez cibler votre serveur à partir de plusieurs clients en même temps.

Notre environnement de test est composé d'un serveur CentOS 7 [IP 192.168.0.17] et d'un hôte Windows à partir duquel nous lancerons l'attaque [IP 192.168.0.103] :

Veuillez lire la vidéo ci-dessous et suivre les étapes décrites dans l'ordre indiqué pour simuler une simple attaque DoS :

Ensuite, l'IP incriminée est bloquée par iptables :

Conclusion

Avec mod_security et mod_evasive activés, l'attaque simulée amène le CPU et la RAM à expérimenter un pic d'utilisation temporaire pour seulement quelques secondes avant que les adresses IP sources ne soient mises sur liste noire et bloquées par le pare-feu. Sans ces outils, la simulation va sûrement faire tomber le serveur très rapidement et le rendre inutilisable pendant toute la durée de l'attaque.

Nous serions ravis de savoir si vous envisagez d’utiliser (ou avez utilisé dans le passé) ces outils. Nous sommes toujours impatients d’avoir de vos nouvelles, alors n’hésitez pas à laisser vos commentaires et questions, le cas échéant, en utilisant le formulaire ci-dessous.

Liens de référence

https://www.modsecurity.org/