Introduction
SSH est la méthode par défaut pour se connecter à un serveur cloud. Elle est durable et extensible – à mesure que de nouvelles normes de chiffrement sont développées, elles peuvent être utilisées pour générer de nouvelles clés SSH, garantissant ainsi que le protocole de base reste sécurisé. Cependant, aucun protocole ou pile logicielle n’est totalement infaillible, et le fait que SSH soit si largement déployé à travers Internet signifie qu’il représente une surface d’attaque très prévisible ou un vecteur d’attaque à travers lequel les gens peuvent essayer de gagner accès.
Tout service exposé au réseau est une cible potentielle de cette manière. Si vous examinez les journaux de votre service SSH fonctionnant sur un serveur à fort trafic, vous verrez souvent des tentatives de connexion répétées et systématiques qui représentent des attaques par force brute de la part des utilisateurs et des bots. Bien que vous puissiez apporter quelques optimisations à votre service SSH pour réduire les chances que ces attaques réussissent à presque zéro, telles que la désactivation de l’authentification par mot de passe en faveur des clés SSH, elles peuvent quand même poser un léger problème, persistant.
Les déploiements de production à grande échelle pour lesquels cette responsabilité est totalement inacceptable mettront généralement en place un VPN tel que WireGuard devant leur service SSH, afin qu’il soit impossible de se connecter directement au port SSH par défaut 22 depuis l’internet sans logiciel d’abstraction supplémentaire ou passerelles. Ces solutions VPN sont largement fiables, mais elles ajouteront de la complexité et peuvent perturber certaines automatisations ou autres petits accroches logiciels.
Avant de s’engager ou en plus de s’engager dans une configuration VPN complète, vous pouvez mettre en place un outil appelé Fail2ban. Fail2ban peut atténuer considérablement les attaques par force brute en créant des règles qui modifient automatiquement la configuration de votre pare-feu pour interdire des adresses IP spécifiques après un certain nombre de tentatives de connexion infructueuses. Cela permettra à votre serveur de se protéger contre ces tentatives d’accès sans intervention de votre part.
Dans ce guide, vous verrez comment installer et utiliser Fail2ban sur un serveur Rocky Linux 8.
Prérequis
Pour accomplir ce guide, vous aurez besoin de :
-
Un serveur Rocky Linux 8 et un utilisateur non root avec des privilèges sudo. Vous pouvez en savoir plus sur la façon de configurer un utilisateur avec ces privilèges dans notre guide Configuration initiale du serveur avec Rocky Linux 8. Vous devriez également avoir
firewalld
en cours d’exécution sur le serveur, ce qui est couvert dans notre guide de configuration initiale du serveur. -
Facultativement, un deuxième serveur auquel vous pouvez vous connecter depuis votre premier serveur, que vous utiliserez pour tester l’obtention d’un bannissement délibéré.
Étape 1 — Installation de Fail2ban
Fail2ban n’est pas disponible dans les dépôts de logiciels par défaut de Rocky. Cependant, il est disponible dans le dépôt EPEL, ou Enhanced Packages for Enterprise Linux, qui est couramment utilisé pour les packages tiers sur Red Hat et Rocky Linux. Si vous n’avez pas déjà ajouté EPEL à vos sources de packages système, vous pouvez ajouter le dépôt en utilisant dnf
, comme vous installeriez n’importe quel autre package:
Le gestionnaire de packages dnf
vérifiera maintenant EPEL en plus de vos sources de packages par défaut lors de l’installation de nouveaux logiciels. Procédez à l’installation de Fail2ban:
Fail2ban configurera automatiquement un service en arrière-plan après avoir été installé. Cependant, il est désactivé par défaut car certains de ses paramètres par défaut peuvent entraîner des effets indésirables. Vous pouvez le vérifier en utilisant la commande systemctl
:
Output○ fail2ban.service - Fail2Ban Service
Loaded: loaded (/lib/systemd/system/fail2ban.service; disabled; vendor preset: disabled
Active: inactive (dead)
Docs: man:fail2ban(1)
Vous pourriez activer Fail2ban immédiatement, mais d’abord, vous examinerez certaines de ses fonctionnalités.
Étape 2 – Configuration de Fail2ban
Le service fail2ban conserve ses fichiers de configuration dans le répertoire /etc/fail2ban
. Il y a un fichier par défaut appelé jail.conf
. Allez dans ce répertoire et affichez les 20 premières lignes de ce fichier en utilisant head -20
:
Output#
# AVERTISSEMENT : fortement refactorisé dans la version 0.9.0. Veuillez vérifier et
# personnaliser les paramètres pour votre configuration.
#
# Changements : dans la plupart des cas, vous ne devriez pas modifier ce
# fichier, mais fournir des personnalisations dans le fichier jail.local,
# ou des fichiers .conf séparés sous le répertoire jail.d/, par exemple :
#
# COMMENT ACTIVER LES JAILS :
#
# VOUS NE DEVRIEZ PAS MODIFIER CE FICHIER.
#
# Il sera probablement écrasé ou amélioré lors d'une mise à jour de la distribution.
#
# Fournissez des personnalisations dans un fichier jail.local ou jail.d/customisation.local.
# Par exemple, pour modifier le bantime par défaut pour tous les jails et activer le
# jail ssh-iptables, les lignes suivantes (décommentées) apparaîtraient dans le fichier .local.
# Voir man 5 jail.conf pour plus de détails.
#
# [DEFAULT]
Comme vous le verrez, les premières lignes de ce fichier sont commentées – elles commencent par des caractères #
indiquant qu’elles doivent être lues comme de la documentation plutôt que comme des paramètres. Comme vous le verrez également, ces commentaires vous indiquent de ne pas modifier directement ce fichier. Au lieu de cela, vous avez deux options : soit créer des profils individuels pour Fail2ban dans plusieurs fichiers à l’intérieur du répertoire jail.d/
, soit créer et collecter tous vos paramètres locaux dans un fichier jail.local
. Le fichier jail.conf
sera périodiquement mis à jour lorsque Fail2ban lui-même sera mis à jour, et sera utilisé comme source de paramètres par défaut pour lesquels vous n’avez pas créé de substitutions.
Dans ce tutoriel, vous allez créer jail.local
. Vous pouvez le faire en copiant jail.conf
:
Maintenant, vous pouvez commencer à apporter des modifications de configuration. Ouvrez le fichier dans vi
ou votre éditeur de texte préféré :
Pendant que vous parcourez le fichier, ce tutoriel passera en revue certaines options que vous voudrez peut-être mettre à jour. Les paramètres situés sous la section [DEFAULT]
près du haut du fichier seront appliqués à tous les services pris en charge par Fail2ban. Ailleurs dans le fichier, il y a des en-têtes pour [sshd]
et pour d’autres services, qui contiennent des paramètres spécifiques au service qui s’appliqueront par-dessus les valeurs par défaut.
[DEFAULT]
. . .
bantime = 10m
. . .
Le paramètre bantime
définit la durée pendant laquelle un client sera banni lorsqu’il a échoué à s’authentifier correctement. Cela est mesuré en secondes. Par défaut, cela est réglé sur 10 minutes.
[DEFAULT]
. . .
findtime = 10m
maxretry = 5
. . .
Les deux paramètres suivants sont findtime
et maxretry
. Ils travaillent ensemble pour établir les conditions selon lesquelles un client est considéré comme un utilisateur illégitime qui devrait être banni.
La variable maxretry
définit le nombre de tentatives qu’un client a pour s’authentifier dans une fenêtre de temps définie par findtime
, avant d’être banni. Avec les paramètres par défaut, le service fail2ban bannira un client qui tente de se connecter de manière infructueuse 5 fois dans une fenêtre de 10 minutes.
[DEFAULT]
. . .
destemail = root@localhost
sender = root@<fq-hostname>
mta = sendmail
. . .
Si vous avez besoin de recevoir des alertes par e-mail lorsque Fail2ban prend des mesures, vous devriez évaluer les paramètres destemail
, sendername
et mta
. Le paramètre destemail
définit l’adresse e-mail qui devrait recevoir les messages de bannissement. Le paramètre sendername
définit la valeur du champ « De » dans l’e-mail. Le paramètre mta
configure le service de messagerie qui sera utilisé pour envoyer des e-mails. Par défaut, il s’agit de sendmail
, mais vous pouvez vouloir utiliser Postfix ou une autre solution de messagerie.
[DEFAULT]
. . .
action = $(action_)s
. . .
Ce paramètre configure l’action que Fail2ban prend lorsqu’il veut instituer un bannissement. La valeur action_
est définie dans le fichier peu de temps avant ce paramètre. L’action par défaut consiste à mettre à jour la configuration de votre pare-feu pour rejeter le trafic provenant de l’hôte incriminé jusqu’à ce que le délai de bannissement expire.
Il existe d’autres scripts action_
fournis par défaut que vous pouvez remplacer $(action_)
par ci-dessous :
…
# bannir & envoyer un e-mail avec le rapport whois à destemail.
action_mw = %(action_)s
%(mta)s-whois[sender="%(sender)s", dest="%(destemail)s", protocol="%(protocol)s", chain="%(chain)s"]
# bannir & envoyer un e-mail avec le rapport whois et les lignes de journal pertinentes
# à destemail.
action_mwl = %(action_)s
%(mta)s-whois-lines[sender="%(sender)s", dest="%(destemail)s", logpath="%(logpath)s", chain="%(chain)s"]
# Voir la note IMPORTANTE dans action.d/xarf-login-attack pour savoir quand utiliser cette action
#
# bannir & envoyer un e-mail xarf au contact d'abus de l'adresse IP et inclure les lignes de journal pertinentes
# à destemail.
action_xarf = %(action_)s
xarf-login-attack[service=%(__name__)s, sender="%(sender)s", logpath="%(logpath)s", port="%(port)s"]
# bannir IP sur CloudFlare & envoyer un e-mail avec le rapport whois et les lignes de journal pertinentes
# à destemail.
action_cf_mwl = cloudflare[cfuser="%(cfemail)s", cftoken="%(cfapikey)s"]
%(mta)s-whois-lines[sender="%(sender)s", dest="%(destemail)s", logpath="%(logpath)s", chain="%(chain)s"]
…
Par exemple, action_mw
prend une action et envoie un email, action_mwl
prend une action, envoie un email et inclut la journalisation, et action_cf_mwl
fait tout cela en plus d’envoyer une mise à jour à l’API Cloudflare associée à votre compte pour bannir également le contrevenant là-bas.
Paramètres de prison individuels
Ensuite, la partie du fichier de configuration qui traite des services individuels. Ceux-ci sont spécifiés par des en-têtes de section, comme [sshd]
.
Chacune de ces sections doit être activée individuellement en ajoutant une ligne enabled = true
sous l’en-tête, avec leurs autres paramètres.
[jail_to_enable]
. . .
enabled = true
. . .
Pour ce tutoriel, vous activerez la prison SSH. Elle devrait être en haut des paramètres de prison individuels. Les paramètres par défaut fonctionneront sinon, mais vous devrez ajouter une ligne de configuration qui dit enabled = true
sous l’en-tête [sshd]
.
#
# JAILS
#
#
# Serveurs SSH
#
[sshd]
# Pour utiliser des modes sshd plus agressifs, définissez le paramètre de filtre "mode" dans jail.local:
# normal (par défaut), ddos, extra ou aggressive (combine tout).
# Voir "tests/files/logs/sshd" ou "filter.d/sshd.conf" pour un exemple d'utilisation et des détails.
#mode = normal
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
Certains autres paramètres définis ici sont le filter
qui sera utilisé pour décider si une ligne dans un journal indique une authentification échouée et le logpath
qui indique à fail2ban où se trouvent les journaux pour ce service particulier.
La valeur du filter
est en fait une référence à un fichier situé dans le répertoire /etc/fail2ban/filter.d
, avec son extension .conf
supprimée. Ces fichiers contiennent des expressions régulières (une abréviation courante pour l’analyse textuelle) qui déterminent si une ligne dans le journal est une tentative d’authentification échouée. Nous n’aborderons pas ces fichiers en détail dans ce guide, car ils sont assez complexes et les paramètres prédéfinis correspondent bien aux lignes appropriées.
Cependant, vous pouvez voir quels types de filtres sont disponibles en regardant dans ce répertoire :
Si vous voyez un fichier qui semble lié à un service que vous utilisez, vous devriez l’ouvrir avec un éditeur de texte. La plupart des fichiers sont assez bien commentés et vous devriez au moins pouvoir déterminer quel type de condition le script était conçu pour protéger contre. La plupart de ces filtres ont des sections appropriées (désactivées) dans le fichier jail.conf
que nous pouvons activer dans le fichier jail.local
si nécessaire.
Par exemple, imaginez que vous servez un site web en utilisant Nginx et réalisez qu’une partie de votre site protégée par mot de passe est bombardée de tentatives de connexion. Vous pouvez dire à fail2ban d’utiliser le fichier nginx-http-auth.conf
pour vérifier cette condition dans le fichier /var/log/nginx/error.log
.
C’est déjà configuré dans une section appelée [nginx-http-auth]
dans votre fichier /etc/fail2ban/jail.conf
. Vous devez simplement ajouter le paramètre enabled
:
. . .
[nginx-http-auth]
enabled = true
. . .
Une fois que vous avez terminé l’édition, enregistrez et fermez le fichier. Si vous utilisez vi
, utilisez :x
pour enregistrer et quitter. À ce stade, vous pouvez activer votre service Fail2ban pour qu’il s’exécute automatiquement à partir de maintenant. Tout d’abord, exécutez systemctl enable
:
Ensuite, démarrez-le manuellement pour la première fois avec systemctl start
:
Vous pouvez vérifier qu’il fonctionne avec systemctl status
:
Output● fail2ban.service - Fail2Ban Service
Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; vendor preset: disabled
Active: active (running) since Mon 2022-06-27 19:25:15 UTC; 3s ago
Docs: man:fail2ban(1)
Main PID: 39396 (fail2ban-server)
Tasks: 5 (limit: 1119)
Memory: 12.9M
CPU: 278ms
CGroup: /system.slice/fail2ban.service
└─39396 /usr/bin/python3.6 -s /usr/bin/fail2ban-server -xf start
Jun 27 19:25:15 fail2ban22 systemd[1]: Started Fail2Ban Service.
Jun 27 19:25:15 fail2ban22 fail2ban-server[39396]: Server ready
Dans la prochaine étape, vous allez démontrer Fail2ban en action.
Étape 3 — Test des politiques de bannissement (Optionnel)
À partir d’un autre serveur, qui n’aura pas besoin de se connecter à votre serveur Fail2ban à l’avenir, vous pouvez tester les règles en faisant bannir ce deuxième serveur. Après vous être connecté à votre deuxième serveur, essayez de vous connecter en SSH au serveur Fail2ban. Vous pouvez essayer de vous connecter en utilisant un nom inexistant :
Entrez des caractères aléatoires dans la fenêtre de mot de passe. Répétez ceci quelques fois. À un moment donné, l’erreur que vous recevez devrait passer de Permission denied
à Connection refused
. Cela signale que votre deuxième serveur a été banni du serveur Fail2ban.
Sur votre serveur Fail2ban, vous pouvez voir la nouvelle règle en vérifiant la sortie de fail2ban-client
. fail2ban-client
est une commande supplémentaire fournie par Fail2ban pour vérifier sa configuration en cours.
OutputStatus
|- Number of jail: 1
`- Jail list: sshd
Si vous exécutez fail2ban-client status sshd
, vous pouvez voir la liste des adresses IP qui ont été bannies de SSH:
OutputStatus for the jail: sshd
|- Filter
| |- Currently failed: 2
| |- Total failed: 7
| `- Journal matches: _SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
|- Currently banned: 1
|- Total banned: 1
`- Banned IP list: 134.209.165.184
Le contenu de la liste des IP bannies devrait refléter l’adresse IP de votre deuxième serveur.
Conclusion
Vous devriez maintenant être capable de configurer des politiques de bannissement pour vos services. Fail2ban est un moyen utile de protéger tout type de service utilisant une authentification. Si vous souhaitez en savoir plus sur le fonctionnement de fail2ban, vous pouvez consulter notre tutoriel sur le fonctionnement des règles et fichiers fail2ban.
Pour des informations sur l’utilisation de fail2ban pour protéger d’autres services, vous pouvez lire sur Comment Protéger un Serveur Nginx avec Fail2Ban et Comment Protéger un Serveur Apache avec Fail2Ban.
Source:
https://www.digitalocean.com/community/tutorials/how-to-protect-ssh-with-fail2ban-on-rocky-linux-8