Recherche de site Web

Protégez Apache contre les attaques par force brute ou DDoS à l’aide de 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é absolue.

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, fournit des capacités d’évasion lorsqu’il est attaqué, agissant comme un parapluie qui protège les serveurs Web contre de telles menaces.

Dans cet article, nous allons voir comment les installer, les configurer et les mettre en jeu avec Apache sur RHEL/CentOS 8 et 7 ainsi que sur 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 soit installé sur votre système. Si ce n’est pas le cas, veuillez consulter cet article avant de poursuivre.

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

Vous devrez également configurer iptables comme front-end de pare-feu 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 à la fois 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 paquet 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à mis en place une configuration LAMP, vous devrez également activer le référentiel EPEL dans RHEL/CentOS 8/7 afin d’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 à Apache et de les faire 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 au fichier source du module. Vous pouvez vérifier cela (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 de 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 de 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 CRS OWASP 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 convenance.

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

3. Il est maintenant temps de configurer mod_security. Copiez le fichier exemple 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 de mettre à niveau plus facilement les SCR au fur et à mesure que de nouvelles versions sont 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 de mod_security directives de configuration.

Étape 4 : Configuration de Mod_Evasive

mod_evasive est configuré à l’aide des directives de /etc/httpd/conf.d/mod_evasive.conf. Comme il n’y a pas de règles à mettre à jour lors d’une mise à niveau de paquet, 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é sur la base de l’adresse IP. L’augmentation de ce nombre permet d’accélérer la recherche des sites que le client a visités par le passé, mais peut avoir un impact sur les performances globales s’il est défini sur une valeur trop élevée.
  • DOSPageCount : nombre légitime de requêtes identiques adressées à une URI spécifique (par exemple, tout fichier servi par Apache) qui peuvent être effectuées par un visiteur au cours de l’intervalle DOSPageInterval.
  • DOSSiteCount : similaire à DOSPageCount, mais fait référence au nombre total de requêtes pouvant être adressées à l’ensemble du site au cours de l’intervalle DOSSiteInterval.
  • DOSBlockingPeriod : Si un visiteur dépasse les limites définies par DOSSPageCount ou DOSSiteCount, son adresse IP source sera mise sur liste noire pendant la durée de DOSBlockingPeriod. Pendant DOSBlockingPeriod, toutes les requêtes provenant de cette adresse IP rencontreront une erreur 403 Forbidden.

N’hésitez pas à expérimenter avec ces valeurs afin que votre serveur web soit en mesure de gérer la quantité et le type de trafic requis.

Juste 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 :

DOSEmailNotify

Si vous avez 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 défini sur l’application. Vous pouvez le faire en courant

# 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.

CommandeDOS

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é en conjonction avec un script shell qui ajoute une règle de pare-feu pour bloquer les connexions supplémentaires provenant de cette adresse IP.

Écrire 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 allons utiliser le script shell suivant qui effectue ce travail. Créez un répertoire nommé scripts-tecmint (ou 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 détectée par mod_evasive.

Ajouter l’utilisateur apache au fichier sudoers

Notez que tout cela ne fonctionnera pas à moins que vous ne donniez à l’utilisateur Apache les autorisations d’exécuter notre script (et ce script uniquement !) sans terminal ni mot de passe. Comme d’habitude, vous pouvez simplement taper visudo comme 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. Étant donné que 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 : Simulation d’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 au sein de votre propre réseau.

Si vous souhaitez faire la même chose 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 la permission pour qu’un tel afflux de trafic passe par leurs 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 devez 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 visionner la vidéo ci-dessous et suivre les étapes décrites dans l’ordre indiqué pour simuler une attaque DoS simple :

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

Conclusion

Lorsque mod_security et mod_evasive activés, l’attaque simulée entraîne un pic d’utilisation temporaire pendant quelques secondes seulement avant que les adresses IP sources ne soient mises sur liste noire et bloquées par le pare-feu. Sans ces outils, la simulation mettra sûrement le serveur à terre très rapidement et le rendra inutilisable pendant la durée de l’attaque.

Nous serions ravis de savoir si vous prévoyez d’utiliser (ou si vous avez utilisé dans le passé) ces outils. Nous avons toujours hâte 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/

Articles connexes: