Introduction
SSH est la méthode de facto pour se connecter à un serveur cloud. Il est robuste 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 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 un 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 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 des utilisateurs et des robots. Bien que vous puissiez apporter certaines 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 toujours représenter une petite responsabilité continue.
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 Internet sans abstraction logicielle supplémentaire ou passerelles. Ces solutions VPN sont largement fiables, mais elles ajoutent de la complexité et peuvent perturber certaines automatisations ou autres petits crochets logiciels.
Avant de vous engager dans la mise en place complète d’un VPN, 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 bannir 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 Debian 11.
Prérequis
Pour suivre ce guide, vous aurez besoin de :
-
Un serveur Debian 11 et un utilisateur non-root avec des privilèges sudo. Vous pouvez en savoir plus sur la manière de configurer un utilisateur avec ces privilèges dans notre guide Configuration initiale du serveur avec Debian 11.
-
Facultativement, un deuxième serveur auquel vous pouvez vous connecter depuis votre premier serveur, que vous utiliserez pour tester le bannissement délibéré.
Étape 1 — Installation de Fail2ban
Fail2ban est disponible dans les dépôts logiciels de Debian. Commencez par exécuter les commandes suivantes en tant qu’utilisateur non root pour mettre à jour vos listes de paquets et installer Fail2ban :
Fail2ban configurera automatiquement un service en arrière-plan après son installation. Vous pouvez vérifier son statut en utilisant la commande systemctl :
Output● fail2ban.service - Fail2Ban Service
Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; vendor preset: enabled
Active: active (running) since Tue 2022-06-28 16:23:14 UTC; 17s ago
Docs: man:fail2ban(1)
Process: 1942 ExecStartPre=/bin/mkdir -p /run/fail2ban (code=exited, status=0/SUCCESS
Main PID: 1943 (fail2ban-server)
Tasks: 5 (limit: 1132)
Memory: 15.8M
CPU: 280ms
CGroup: /system.slice/fail2ban.service
└─1943 /usr/bin/python3 /usr/bin/fail2ban-server -xf start
Vous pouvez continuer à utiliser Fail2ban avec ses paramètres par défaut, 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 existe un fichier avec des valeurs par défaut appelé jail.conf. Allez dans ce répertoire et affichez les 20 premières lignes de ce fichier en utilisant la commande head -20 :
Output#
# AVERTISSEMENT : fortement refondu dans la version 0.9.0. Veuillez passer en revue et
# personnaliser les paramètres pour votre configuration.
#
# Modifications : dans la plupart des cas, vous ne devriez pas modifier ce
# fichier, mais fournir des personnalisations dans le fichier jail.local,
# ou dans des fichiers .conf distincts 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 dans un jail.d/customisation.local.
# Par exemple, pour changer le bantime par défaut pour tous les jails et activer le
# jail ssh-iptables, la ligne suivante (décommentée) apparaîtrait 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 interprétées comme de la documentation plutôt que comme des paramètres. Comme vous le verrez également, ces commentaires vous dirigent pour 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 à l’intérieur 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 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 remplacements.
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 nano ou votre éditeur de texte préféré :
Pendant que vous parcourez le fichier, ce tutoriel passera en revue quelques 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 défini à 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 devant ê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 réglages 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 agit, 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 en provenance de l’hôte fautif jusqu’à ce que le délai de bannissement expire.
Il existe d’autres scripts action_ fournis par défaut que vous pouvez remplacer $(action_) avec ci-dessus :
…
# bannir et envoyer un e-mail avec un rapport whois à l'adresse destemail.
action_mw = %(action_)s
%(mta)s-whois[sender="%(sender)s", dest="%(destemail)s", protocol="%(protocol)s", chain="%(chain)s"]
# bannir et envoyer un e-mail avec un rapport whois et des lignes de journal pertinentes
# à l'adresse 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 et envoyer un e-mail xarf au contact d'abus de l'adresse IP et inclure des lignes de journal pertinentes
# à l'adresse destemail.
action_xarf = %(action_)s
xarf-login-attack[service=%(__name__)s, sender="%(sender)s", logpath="%(logpath)s", port="%(port)s"]
# bannir l'IP sur CloudFlare et envoyer un e-mail avec un rapport whois et des lignes de journal pertinentes
# à l'adresse 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 des mesures et envoie un e-mail, action_mwl prend des mesures, 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 également le fraudeur là-bas.
Paramètres de Prison Individuels
Ensuite, voici 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
. . .
Par défaut, le service SSH est activé et tous les autres sont désactivés.
.
D’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 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 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 dire contre quel type de condition le script a été conçu pour se prémunir. 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 désiré.
Par exemple, imaginez que vous servez un site web en utilisant Nginx et que vous réalisez qu’une partie de votre site protégée par mot de passe est attaquée par des 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.
Ceci est en fait déjà configuré dans une section appelée [nginx-http-auth] dans votre fichier /etc/fail2ban/jail.conf. Vous auriez juste besoin d’ajouter le paramètre enabled:
. . .
[nginx-http-auth]
enabled = true
. . .
Lorsque vous avez fini d’éditer, enregistrez et fermez le fichier. Si vous avez apporté des modifications, vous pouvez redémarrer le service Fail2ban en utilisant systemctl :
À l’étape suivante, vous allez démontrer Fail2ban en action.
Étape 3 — Tester les politiques de bannissement (optionnel)
À partir d’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 :
Entrez des caractères aléatoires dans le prompt de mot de passe. Répétez cela quelques fois. À un moment donné, l’erreur que vous recevez devrait changer 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 votre sortie iptables. iptables est une commande pour interagir avec les règles de port et de pare-feu de bas niveau sur votre serveur. Si vous avez suivi le guide de configuration initiale du serveur de DigitalOcean, vous utiliserez ufw pour gérer les règles de pare-feu à un niveau supérieur. L’exécution de iptables -S vous montrera toutes les règles de pare-feu que ufw a déjà créées :
Output-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-N f2b-sshd
-N ufw-after-forward
-N ufw-after-input
-N ufw-after-logging-forward
-N ufw-after-logging-input
-N ufw-after-logging-output
-N ufw-after-output
-N ufw-before-forward
-N ufw-before-input
-N ufw-before-logging-forward
-N ufw-before-logging-input
-N ufw-before-logging-output
…
Si vous dirigez la sortie de iptables -S vers grep pour rechercher dans ces règles la chaîne f2b, vous pouvez voir les règles qui ont été ajoutées par fail2ban:
Output-N f2b-sshd
-A INPUT -p tcp -m multiport --dports 22 -j f2b-sshd
-A f2b-sshd -s 134.209.165.184/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -j RETURN
La ligne contenant REJECT --reject-with icmp-port-unreachable aura été ajoutée par Fail2ban et devrait refléter l’adresse IP de votre deuxième serveur.
Conclusion
Vous devriez maintenant être en mesure de configurer quelques politiques de bannissement pour vos services. Fail2ban est un moyen utile de protéger tout type de service qui utilise une authentification. Si vous voulez en savoir plus sur le fonctionnement de fail2ban, vous pouvez consulter notre tutoriel sur comment fonctionnent les règles et les fichiers fail2ban.
Pour des informations sur la manière d’utiliser 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-debian-11