Protégez Apache contre les attaques de force brute ou DDOS à l'aide de modules MOD_SECURITY et MOD_EVASIV

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

mod_security (Moteur de détection et de prévention des intrusions open source 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 la force brute ou (d) les attaques DOS.

Article associé: Comment installer des logiciels malveillants Linux détecter avec Clamav comme moteur antivirus

mod_evasive, Comme son nom l'indique, fournit des capacités évasives pendant l'attaque, agissant comme un parapluie qui protège les serveurs Web de ces menaces.

Installez mod_security et mod_evasive pour protéger Apache

Dans cet article, nous discuterons de la façon d'installer, les configurer et les mettre en jeu avec Apache sur Rhel/ /Centos 8 et 7 ainsi que Feutre. De plus, nous simulerons les attaques afin de vérifier que le serveur réagit en conséquence.

Cela suppose que vous avez un serveur de lampe installé sur votre système. Sinon, veuillez consulter cet article avant de poursuivre.

• Comment installer le serveur de lampes sur Centos 8
• Comment installer la pile de lampe dans RHEL / CENTOS 7

Vous devrez également configurer iptables comme le pare-feu par défaut frontal au lieu du pare-feu si vous courez RHEL / CENTOS 8/7 ou Feutre. Nous le faisons pour utiliser le même outil dans les deux Rhel/ /Centos 8/ /7 et Feutre.

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

Pour commencer, s'arrêter et désactiver pare-feu:

# SystemCTL Stop Firewalld # SystemCTL Désactiver Firewalld 

Désactiver le service de tout le monde

Puis installez le services iptables package avant d'activer iptables:

# yum Update && yum install iptables-Services # systemctl activer iptables # systemctl start iptables # systemctl status iptables 

Installer le pare-feu iptables

Étape 2: Installation de mod_security et mod_evasive

En plus d'avoir une configuration de lampe déjà en place, 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 un dépôt, car EPEL fait déjà partie du projet Fedora.

# yum Update && yum install mod_security mod_evasive --------------- Centos / Rhel 8 --------------- # DNF Installer https: // pkgs.dyn.su / el8 / base / x86_64 / raven-lien-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 pour les deux outils dans / etc / httpd / confre.d.

# ls -l / etc / httpd / confille.d 

Configurations MOD_SECURITY + MOD_EVASIVE

Maintenant, afin d'intégrer ces deux modules avec Apache et le faire charger quand il commence, assurez-vous que les lignes suivantes apparaissent dans la section supérieure de mod_evasive.confli et mod_security.confli, respectivement:

Modules chargemodules evasive20_module / mod_evasive24.So chargemodule security2_module modules / mod_security2.donc 

Noter que modules / mod_security2.donc et modules / mod_evasive24.donc sont les chemins relatifs, de la / etc / httpd Répertoire du fichier source du module. Vous pouvez le vérifier (et le modifier, si nécessaire) en répertoriant le contenu du / etc / httpd / modules annuaire:

# cd / etc / httpd / modules # pwd # ls -l | grep -ei '(évasif | sécurité)' 

Vérifiez les modules MOD_SECURITY + MOD_EVASIVE

Puis redémarrez Apache et vérifiez qu'il se charge mod_evasive et mod_security:

# SystemCTL Redémarrer HTTPD 

Vider une liste de modules statiques et partagés chargés.

# httpd -m | grep -ei '(évasif | sécurité)' 

Vérifiez les modules MOD_SECURITY + MOD_EVASIV

Étape 3: Installation d'un ensemble de règles de base et configurer 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 firme de développeur de mod_security fournit un gratuit CRS appelé Owasp (Open Web Application Security Project) MODSECURITY CRS qui peut être téléchargé et installé comme suit.

1. Télécharger le OWASP CRS à 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.le goudron.GZ -O Maître 

Télécharger les règles de base mod_security

2. Non le CRS déposer et modifier le nom du répertoire pour l'une de nos commodité.

# TAR XZF MASTER # MV OWASP-MODSECURY-CRS-3.2.0 owasp-modsecurity-crs 

3. Il est maintenant temps de configurer MOD_SECURITY. Copiez l'exemple de fichier avec des règles (owasp-modsecurity-crs / modsecurity_crs_10_setup.confli.exemple) dans un autre fichier sans le .exemple extension:

# cd owasp-modsecurity-crs / # cp crs-setup.confli.Exemple CRS-Settup.confli 

et de dire Apache Pour 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.confli déposer. Si vous avez choisi de déballer le tarball dans un autre répertoire, vous devrez modifier les chemins en suivant les directives incluées:

 Inclure CRS-Tecmint / Owasp-Modsecurity-CRS / CRS-Settup.confe CRS-Tecmint / Owasp-Modsecurity-Crs / Rules / *.confli  

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

 Secruleengine sur secRequestbodyAccess sur secResponseBodyAccess sur SecResponseBodyBodyMimeType Text / Text brut / HTML Text / XML Application / OCTET-Stream Secdatadir / TMP  

Vous pouvez vous référer au référentiel GitHub de 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 de directives dans / etc / httpd / confre.d / mod_evasive.confli. Puisqu'il n'y a pas de règles à mettre à jour lors d'une mise à niveau du package, nous n'avons pas besoin d'un fichier séparé pour ajouter des directives personnalisées, par opposition à mod_security.

Le défaut mod_evasive.confli Le fichier 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):

 DoshashTableSize 3097 DospageCount 2 DossiteCount 50 DospageInterval 1 DossiteInterval 1 Dosblockingperiod 10  

Explication des directives:

• DoshashtableSize: Cette directive spécifie la taille de la table de hachage utilisée pour garder une trace de l'activité sur une base d'adresse Per-IP. L'augmentation de ce nombre fournira une recherche plus rapide des sites que le client a visités dans le passé, mais peut avoir un impact sur les performances globales si elle est trop élevée.
• Compte-count: Nombre légitime de demandes identiques à un URI spécifique (par exemple, tout fichier servi par Apache) qui peut être effectué par un visiteur sur l'intervalle DosageInterval.
• DossiteCount: Similaire à DospageCount, mais fait référence au nombre de demandes globales peut être faite sur l'ensemble du site sur 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 de Dosblockingperiod. Pendant DOSBlockingPeriod, toutes les demandes provenant de cette adresse IP rencontreront une erreur interdite 403.

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

Seulement une petite mise en garde: Si ces valeurs ne sont pas réglées correctement, 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 coulant

# setSebool -p httpd_can_sendmail 1 

Ensuite, ajoutez cette directive dans le mod_evasive.confli dossier avec le reste des autres directives:

DosemailNotify [Protégé par e-mail] 

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 deviendra la liste noire.

Dossystemcomand

Cela a besoin d'une commande système valide comme argument,

Dossystemcomand  

Cette directive spécifie une commande à exécuter chaque fois qu'une adresse IP devient liste noire. Il est souvent utilisé en conjonction 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 IP au niveau du pare-feu

Lorsqu'une adresse IP devient liste noire, nous devons bloquer les connexions futures en provenant. Nous utiliserons le script shell suivant qui effectue ce travail. Créer un répertoire nommé scripts-tecmint (ou quel que soit le nom de votre choix) / usr / local / bac et un fichier appelé ban_ip.shot Dans ce répertoire.

#!/ bin / sh # ip qui sera bloqué, comme détecté par mod_evasive ip = 1 1 # chemin complet vers iptables iptables = "/ sbin / iptables" # mod_evasive mettez le répertoire mod_evasive_logdir = / var / log / mod_evasive # Ajouter la règle de pare-feu suivante ( Bloquer tout le trafic provenant de $ ip) $ iptables -i entrée -s $ ip -j dépôt # supprimer le fichier de verrouillage pour les chèques futures rm -f "$ mod_evasive_logdir" / dos - "$ ip" 

Notre Dossystemcomand La directive doit se lire comme suit:

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

Dans la ligne au-dessus, % s représente la propriété intellectuelle incriminée telle que détectée par mod_evasive.

Ajouter l'utilisateur Apache dans le fichier sudoers

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

apache all = nopasswd: / usr / local / bin / scripts-tecmint / ban_ip.sh par défaut: apache !exigence 

Ajouter un utilisateur Apache aux sudoers

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

#Defaults BesoinTty 

Désactiver le tty pour sudo

Enfin, redémarrez le serveur Web:

# SystemCTL Redémarrer 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 Google pour "Outils pour simuler les attaques DDOS«Pour en trouver plusieurs.

Notez que vous et seul vous 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 dans 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 une permission à une telle inondation de la circulation pour passer par leurs réseaux. Tecmint.com 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 Centos 7 serveur [IP 192.168.0.17] et un hôte Windows à partir de laquelle nous lancerons l'attaque [IP 192.168.0.103]::

Confirmer l'iPaddress hôte

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 offensée est bloquée par les iptables:

IP d'attaquant bloqué

Conclusion

Avec mod_security et mod_evasive activé, l'attaque simulée provoque le CPU et RAM pour expérimenter avec un pic d'utilisation temporaire pendant seulement quelques secondes avant que les IP source ne soient sur liste noire et bloqués par le pare-feu. Sans ces outils, la simulation fera sûrement abattre le serveur très rapidement et la rendre inutilisable pendant la durée de l'attaque.

Nous aimerions savoir si vous prévoyez d'utiliser (ou d'avoir utilisé dans le passé ces outils. Nous avons toujours hâte de vous entendre, 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 /