Recherche de site Web

Comment protéger SSH avec Fail2Ban sur Rocky Linux 9

Vous n'utilisez pas Rocky Linux 9 ?Choisissez une autre version ou distribution.

Introduction

SSH est la méthode de facto pour se connecter à un serveur cloud. Il est durable et extensible — à mesure que de nouveaux standards de cryptage sont développés, ils peuvent être utilisés 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 qu'SSH soit déployé si largement sur Internet signifie qu'il représente une surface d'attaque ou un vecteur d'attaque très prévisible par lequel les gens peuvent essayer d'accéder.

Tout service qui est 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 très fréquenté, 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 d'utilisateurs et de bots. Bien que vous puissiez apporter certaines optimisations à votre service SSH pour réduire la probabilité de succès de ces attaques à presque zéro, comme désactiver l'authentification par mot de passe en faveur des clés SSH, elles peuvent toujours constituer une responsabilité mineure, continue.

Les déploiements de production à grande échelle pour lesquels cette responsabilité est complètement inacceptable vont généralement mettre en place un VPN tel que WireGuard devant leur service SSH, de sorte qu'il soit impossible de se connecter directement au port SSH par défaut 22 depuis l'extérieur d'internet sans abstraction de logiciel supplémentaire ou passerelles. Ces solutions VPN sont largement fiables, mais elles vont ajouter de la complexité et peuvent casser certaines automatisations ou autres petites intégrations logicielles.

Avant de s'engager dans la mise en place d'un VPN complet, vous pouvez mettre en œuvre 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 IP spécifiques après un certain nombre de tentatives de connexion infructueuses. Cela permettra à votre serveur de se renforcer 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 9.

Conditions préalables

Pour compléter ce guide, vous aurez besoin de :

  • Un serveur Rocky Linux 9 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 de configuration initiale du serveur avec Rocky Linux 9. Vous devez également avoir firewalld en cours d'exécution sur le serveur, ce qui est couvert dans notre guide de configuration initiale du serveur.

  • En option, un deuxième serveur auquel vous pouvez vous connecter depuis votre premier serveur, que vous utiliserez pour tester le fait d'être délibérément banni.

Étape 1 — Installer Fail2ban

Fail2ban n'est pas disponible dans les dépôts logiciels par défaut de Rocky. Cependant, il est disponible dans le EPEL, ou Enhanced Packages for Enterprise Linux, qui est couramment utilisé pour les paquets tiers sur Red Hat et Rocky Linux. Si vous n'avez pas encore ajouté EPEL à vos sources de paquets système, vous pouvez ajouter le dépôt en utilisant dnf, comme vous le feriez pour installer tout autre paquet :

  1. sudo dnf install epel-release -y

Le gestionnaire de paquets dnf vérifiera désormais EPEL en plus de vos sources de paquets par défaut lors de l'installation de nouveaux logiciels. Procédez à l'installation de Fail2ban :

  1. sudo dnf install fail2ban -y

Fail2ban configurera automatiquement un service en arrière-plan après son installation. Cependant, il est désactivé par défaut, car certains de ses paramètres par défaut peuvent provoquer des effets indésirables. Vous pouvez le vérifier en utilisant la commande systemctl :

  1. systemctl status fail2ban.service



○ 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 tout de suite, mais d'abord, vous allez passer en revue 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 avec les paramètres par défaut appelé jail.conf. Allez dans ce répertoire et imprimez les 20 premières lignes de ce fichier en utilisant head -20 :

  1. cd /etc/fail2ban

  2. head -20 jail.conf



#
WARNING: heavily refactored in 0.9.0 release.  Please review and
         customize settings for your setup.
#
Changes:  in most of the cases you should not modify this
          file, but provide customizations in jail.local file,
          or separate .conf files under jail.d/ directory, e.g.:
#
HOW TO ACTIVATE JAILS:
#
YOU SHOULD NOT MODIFY THIS FILE.
#
It will probably be overwritten or improved in a distribution update.
#
Provide customizations in a jail.local file or a jail.d/customisation.local.
For example to change the default bantime for all jails and to enable the
ssh-iptables jail the following (uncommented) would appear in the .local file.
See man 5 jail.conf for details.
#
[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 dirigent à ne pas modifier ce fichier directement. Au lieu de cela, vous avez deux options : soit créer des profils individuels pour Fail2ban dans plusieurs fichiers au sein du répertoire jail.d/, soit créer et rassembler tous vos paramètres locaux dans un fichier jail.local. Le fichier jail.conf sera régulièrement mis à jour à mesure que Fail2ban lui-même est mis à jour, et sera utilisé comme source de paramètres par défaut pour lesquels vous n'avez créé aucun remplacement.

Dans ce tutoriel, vous allez créer jail.local. Vous pouvez le faire en copiant jail.conf:

  1. sudo cp jail.conf jail.local

Maintenant, vous pouvez commencer à apporter des modifications à la configuration. Ouvrez le fichier dans vi ou dans votre éditeur de texte préféré :

  1. sudo vi jail.local

Alors que vous faites défiler le fichier, ce tutoriel examinera certaines options que vous voudrez peut-être mettre à jour. Les paramètres situés sous la section [DEFAULT] près du sommet 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 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 s'il a échoué à s'authentifier correctement. Cela est mesuré en secondes. Par défaut, cela est défini sur 10 minutes.

[DEFAULT]
. . .
findtime = 10m
maxretry = 5
. . .

Les deux paramètres suivants sont findtime et maxretry. Ils fonctionnent ensemble pour établir les conditions dans 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 période 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 sans succès 5 fois dans un délai 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 devez évaluer les paramètres destemail, sendername et mta. Le paramètre destemail définit l'adresse e-mail qui doit recevoir les messages de bannissement. Le sendername définit la valeur du champ “De” dans l'e-mail. Le paramètre mta configure quel service de messagerie 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 souhaite instituer une interdiction. La valeur action_ est définie dans le fichier juste avant ce paramètre. L'action par défaut est de mettre à jour votre configuration de pare-feu pour rejeter le trafic provenant de l'hôte en infraction jusqu'à ce que le temps de ban expire.

Il existe d'autres scripts action_ fournis par défaut que vous pouvez remplacer par $ (action_) ci-dessus :

…
ban & send an e-mail with whois report to the destemail.
action_mw = %(action_)s
            %(mta)s-whois[sender="%(sender)s", dest="%(destemail)s", protocol="%(protocol)s", chain="%(chain)s"]

ban & send an e-mail with whois report and relevant log lines
to the destemail.
action_mwl = %(action_)s
             %(mta)s-whois-lines[sender="%(sender)s", dest="%(destemail)s", logpath="%(logpath)s", chain="%(chain)s"]

See the IMPORTANT note in action.d/xarf-login-attack for when to use this action
#
ban & send a xarf e-mail to abuse contact of IP address and include relevant log lines
to the destemail.
action_xarf = %(action_)s
             xarf-login-attack[service=%(__name__)s, sender="%(sender)s", logpath="%(logpath)s", port="%(port)s"]

ban IP on CloudFlare & send an e-mail with whois report and relevant log lines
to the 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 e-mail, action_mwl prend une action, envoie un e-mail et inclut la journalisation, et action_cf_mwl fait tout ce qui précède en plus d'envoyer une mise à jour à l'API Cloudflare associée à votre compte pour bannir l'auteur de l'infraction également.

Paramètres de prison individuels

Ensuite, voici la section du fichier de configuration qui concerne les 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 le titre, avec leurs autres paramètres.

[jail_to_enable]
. . .
enabled = true
. . .

Pour ce tutoriel, vous allez activer la prison SSH. Elle devrait être en haut des paramètres de la prison individuelle. Les paramètres par défaut fonctionneront autrement, mais vous devrez ajouter une ligne de configuration qui dit enabled=true sous l'en-tête [sshd].

#
JAILS
#

#
SSH servers
#

[sshd]

To use more aggressive sshd modes set filter parameter "mode" in jail.local:
normal (default), ddos, extra or aggressive (combines all).
See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode   = normal
enabled = true
port    = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s

D'autres paramètres qui sont 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 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 (un raccourci courant pour l'analyse de texte) qui déterminent si une ligne dans le journal est une tentative d'authentification échouée. Nous ne couvrirons pas ces fichiers en profondeur dans ce guide, car ils sont assez complexes et les réglages prédéfinis correspondent bien aux lignes appropriées.

Cependant, vous pouvez voir quels types de filtres sont disponibles en consultant ce répertoire :

  1. ls /etc/fail2ban/filter.d

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 être en mesure de savoir au moins quel type de condition le script était conçu pour protéger. 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 nous le souhaitons.

Par exemple, imaginez que vous servez un site web en utilisant Nginx et que vous réalisez qu'une partie protégée par mot de passe de votre site est inondé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 en fait 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
. . .

Lorsque vous avez terminé de modifier, enregistrez et fermez le fichier. Si vous utilisez vi, utilisez :x pour enregistrer et quitter. À ce stade, vous pouvez activer votre service Fail2ban afin qu'il fonctionne automatiquement à partir de maintenant. D'abord, exécutez systemctl enable :

  1. sudo systemctl enable fail2ban

Ensuite, démarrez-le manuellement pour la première fois avec systemctl start :

  1. sudo systemctl start fail2ban

Vous pouvez vérifier qu'il fonctionne avec systemctl status :

  1. sudo systemctl status fail2ban



● fail2ban.service - Fail2Ban Service
     Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; vendor preset: disabled
     Active: active (running) since Wed 2022-09-14 20:48:40 UTC; 2s 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

Sep 14 20:48:40 rocky9-tester systemd[1]: Starting Fail2Ban Service...
Sep 14 20:48:40 rocky9-tester systemd[1]: Started Fail2Ban Service.
Sep 14 20:48:41 rocky9-tester fail2ban-server[39396]: Server ready

Dans la prochaine étape, vous démontrerez Fail2ban en action.

Étape 3 — Test des politiques d'interdiction (facultatif)

Depuis un autre serveur, un 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 :

  1. ssh blah@your_server

Entrez des caractères aléatoires dans l'invite de mot de passe. Répétez cela 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.

  1. sudo fail2ban-client status



Status
|- Number of jail:      1
`- Jail list:   sshd

Si vous exécutez fail2ban-client status sshd, vous pouvez voir la liste des IP qui ont été interdites d'accès SSH :

  1. sudo fail2ban-client status sshd



Status 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 doit refléter l'adresse IP de votre deuxième serveur.

Conclusion

Vous devriez maintenant être en mesure de configurer des politiques de bannissement pour vos services. Fail2ban est un moyen utile de protéger tout type de service qui utilise 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 des fichiers fail2ban.

Pour des informations sur la façon d'utiliser fail2ban pour protéger d'autres services, vous pouvez lire comment protéger un serveur Nginx avec Fail2Ban.