Introduction
SSH est la méthode par défaut pour se connecter à un serveur cloud. Il est durable et extensible – lorsque de nouvelles normes de cryptage 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 prendre 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 certaines optimisations à votre service SSH pour réduire la probabilité que ces attaques réussissent à près de zéro, telles que désactiver l’authentification par mot de passe en faveur des clés SSH, elles peuvent toujours représenter une responsabilité mineure et 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, de sorte qu’il soit impossible de se connecter directement au port SSH par défaut 22 depuis l’internet extérieur sans abstraction logicielle supplémentaire ou passerelles. Ces solutions VPN sont largement fiables, mais ajoutent de la complexité et peuvent interrompre certaines automatisations ou autres petits accrochages logiciels.
Avant de vous engager dans une configuration VPN complète ou en complément, 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 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 un autre tutoriel, nous avons discuté de Comment protéger SSH avec Fail2ban. Dans ce guide, nous aborderons plus en détail le fonctionnement réel de Fail2ban et comment vous pouvez utiliser cette connaissance pour modifier ou étendre le comportement de ce service.
Les Fondamentaux de Fail2ban
Le but de Fail2ban est de surveiller les journaux des services courants pour repérer les motifs d’échec d’authentification.
Lorsque fail2ban est configuré pour surveiller les journaux d’un service, il examine un filtre qui a été configuré spécifiquement pour ce service. Le filtre est conçu pour identifier les échecs d’authentification pour ce service spécifique grâce à l’utilisation d’expressions régulières complexes. Les expressions régulières sont un langage de modèle courant utilisé pour la correspondance de motifs. Il définit ces motifs d’expressions régulières dans une variable interne appelée failregex.
Par défaut, Fail2ban inclut des fichiers de filtres pour des services courants. Lorsqu’un journal provenant de n’importe quel service, comme un serveur Web, correspond au failregex dans son filtre, une action prédéfinie est exécutée pour ce service. L’action est une variable qui peut être configurée pour faire de nombreuses choses différentes, selon les préférences de l’administrateur.
L’action par défaut consiste à bannir l’hôte/l’adresse IP fautif(e) en modifiant les règles de pare-feu locales. Vous pouvez étendre cette action pour, par exemple, envoyer un e-mail à votre administrateur système.
Par défaut, une action sera entreprise lorsque trois échecs d’authentification ont été détectés en 10 minutes, et le temps de bannissement par défaut est de 10 minutes. Cela est configurable.
Lors de l’utilisation du pare-feu iptables par défaut, fail2ban crée un nouvel ensemble de règles de pare-feu, également appelé chaîne, lorsque le service est démarré. Il ajoute une nouvelle règle à la chaîne INPUT qui envoie tout le trafic TCP dirigé vers le port 22 à la nouvelle chaîne. Dans la nouvelle chaîne, il insère une seule règle qui retourne à la chaîne INPUT. La chaîne et les règles associées sont supprimées si le service Fail2ban est arrêté.
Exploration des paramètres du service Fail2ban
Fail2ban est configuré à travers plusieurs fichiers situés dans une hiérarchie sous le répertoire /etc/fail2ban/.
Le fichier fail2ban.conf configure certains paramètres opérationnels tels que la manière dont le démon enregistre les informations, ainsi que le socket et le fichier PID qu’il utilisera. La configuration principale, cependant, est spécifiée dans les fichiers qui définissent les « jails » par application.
Par défaut, fail2ban est livré avec un fichier jail.conf. Cependant, celui-ci peut être écrasé lors de mises à jour, vous devriez donc copier ce fichier dans un fichier jail.local et effectuer des ajustements là-bas.
Si vous avez déjà un fichier jail.local, ouvrez-le en utilisant nano ou votre éditeur de texte préféré :
Si vous n’avez pas encore de fichier jail.local, ou si le fichier que vous avez ouvert était vide, copiez le fichier jail.conf puis ouvrez le nouveau fichier :
Nous examinerons les options disponibles ici et verrons comment ce fichier interagit avec les autres fichiers de configuration sur le système.
La Section par Défaut
La première partie du fichier définira les valeurs par défaut de la politique fail2ban. Ces options peuvent être remplacées dans la section de configuration de chaque service individuel.
Avec les commentaires supprimés, l’intégralité de la section par défaut ressemble à ceci:
[DEFAULT]
ignoreip = 127.0.0.1/8
bantime = 10m
findtime = 10m
maxretry = 3
backend = auto
usedns = warn
destemail = root@localhost
sendername = Fail2Ban
banaction = iptables-multiport
mta = sendmail
protocol = tcp
chain = INPUT
action_ = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]
action_mw = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]
%(mta)s-whois[name=%(__name__)s, dest="%(destemail)s", protocol="%(protocol)s", chain="%(chain)s", sendername="%(sendername)s"]
action_mwl = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]
%(mta)s-whois-lines[name=%(__name__)s, dest="%(destemail)s", logpath=%(logpath)s, chain="%(chain)s", sendername="%(sendername)s"]
action = %(action_)s
Passons en revue ce que cela signifie:
- ignoreip: Ce paramètre identifie les adresses IP qui doivent être ignorées par le système de bannissement. Par défaut, il est simplement configuré pour ignorer le trafic provenant de la machine elle-même, afin de ne pas remplir vos propres journaux ou de vous verrouiller.
- bantime: Ce paramètre définit la durée d’un bannissement, en secondes. La valeur par défaut est de 10 minutes.
- findtime: Ce paramètre définit la fenêtre sur laquelle Fail2ban va se concentrer lorsqu’il recherche des tentatives d’authentification échouées répétées. La valeur par défaut est fixée à 10 minutes, ce qui signifie que le logiciel comptera le nombre de tentatives d’échec au cours des 10 dernières minutes.
- maxretry: Cela définit le nombre de tentatives d’échec tolérées dans la fenêtre
findtimeavant qu’un bannissement ne soit institué. - backend: Cette entrée spécifie comment Fail2ban va surveiller les fichiers journaux. Le paramètre
autosignifie que fail2ban essaierapyinotify, puisgamin, et ensuite un algorithme de sondage basé sur ce qui est disponible.inotifyest une fonctionnalité intégrée du noyau Linux pour suivre quand les fichiers sont accédés, etpyinotifyest une interface Python àinotify, utilisée par Fail2ban. - usedns: Cela définit si le DNS inverse est utilisé pour aider à mettre en œuvre des interdictions. Le réglage de ceci sur « non » bannira les adresses IP elles-mêmes au lieu de leurs noms de domaine. Le paramètre
warntentera de rechercher un nom d’hôte et de bannir de cette manière, mais enregistrera l’activité pour examen. - destemail: Il s’agit de l’adresse à laquelle sera envoyé le courrier de notification si vous avez configuré votre action pour envoyer des alertes par courrier.
- sendername: Ceci sera utilisé dans le champ expéditeur de l’e-mail pour les e-mails de notification générés
- banaction: Cela définit l’action qui sera utilisée lorsque le seuil est atteint. Il s’agit en fait d’un chemin vers un fichier situé dans
/etc/fail2ban/action.d/appeléiptables-multiport.conf. Cela gère la manipulation réelle du pare-feu iptables pour interdire une adresse IP. Nous examinerons ceci plus tard. - mta: Il s’agit de l’agent de transfert de courrier qui sera utilisé pour envoyer des e-mails de notification.
- protocol: Il s’agit du type de trafic qui sera abandonné lorsqu’une interdiction IP est mise en œuvre. C’est également le type de trafic qui est envoyé à la nouvelle chaîne iptables.
- chain: Il s’agit de la chaîne qui sera configurée avec une règle de saut pour envoyer le trafic vers l’entonnoir fail2ban.
Le reste des paramètres définit différentes actions pouvant être spécifiées. Ils transmettent certains des paramètres que nous avons définis ci-dessus en utilisant une substitution de variables dans des chaînes de texte comme ceci :
%(nom_variable)s
La ligne ci-dessus serait remplacée par le contenu de var_name. En utilisant cela, nous pouvons dire que la variable action est définie par défaut sur la définition action_ (seulement bannissement, pas d’alertes par mail).
Ceci, à son tour, est configuré en appelant l’action iptables-multiport avec une liste de paramètres (nom du service, port, protocole et chaîne) nécessaires pour effectuer le bannissement. Le __name__ est substitué par le nom du service tel que spécifié par les en-têtes de section ci-dessous.
Sections Spécifiques au Service
Sous la section par défaut, il y a des sections pour des services spécifiques qui peuvent être utilisées pour remplacer les paramètres par défaut. Cela suit une convention de modification uniquement des paramètres qui diffèrent des valeurs normales (convention plutôt que configuration).
Chaque en-tête de section est spécifié comme ceci :
[nom_du_service]
Toute section qui a la ligne enabled = true sera lue et activée.
À l’intérieur de chaque section, les paramètres sont configurés, y compris le fichier de filtre qui doit être utilisé pour analyser les journaux (moins l’extension de fichier) et l’emplacement des fichiers journaux eux-mêmes.
En gardant cela à l’esprit, la section qui spécifie les actions pour le service SSH ressemble à ceci :
[SSH]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 6
Cela permet d’activer cette section et définit le port par défaut comme le port « ssh » (port 22). Il indique à Fail2ban de regarder le journal situé à /var/log/auth.log pour cette section et d’analyser le journal en utilisant les mécanismes de filtrage définis dans le répertoire /etc/fail2ban/filters.d dans un fichier appelé sshd.conf.
Toutes les autres informations dont il a besoin sont extraites des paramètres définis dans la section [DEFAULT]. Par exemple, l’action sera définie sur action_ qui bannira l’adresse IP offensante en utilisant l’action de bannissement iptables-multiport, qui fait référence à un fichier appelé iptables-multiport.conf trouvé dans /etc/fail2ban/action.d.
Comme vous pouvez le voir, les actions dans la section [DEFAULT] devraient être générales et flexibles. L’utilisation de la substitution de paramètres avec des paramètres fournissant des valeurs par défaut sensibles rendra possible la substitution des définitions lorsque cela est nécessaire.
Examen du Fichier de Filtre
Pour comprendre ce qui se passe dans notre configuration, nous devons comprendre les fichiers de filtre et d’action, qui font la majeure partie du travail.
Le fichier de filtre déterminera les lignes que fail2ban recherchera dans les fichiers journaux pour identifier les caractéristiques offensantes. Le fichier d’action met en œuvre toutes les actions nécessaires, de la construction d’une structure de pare-feu lorsque le service démarre, à l’ajout et la suppression de règles, et à la démolition de la structure de pare-feu lorsque le service s’arrête.
Examinons le fichier de filtre appelé par notre service SSH dans la configuration ci-dessus:
[INCLUDES]
before = common.conf
[Definition]
_daemon = sshd
failregex = ^%(__prefix_line)s(?:error: PAM: )?[aA]uthentication (?:failure|error) for .* from <HOST>( via \S+)?\s*$
^%(__prefix_line)s(?:error: PAM: )?User not known to the underlying authentication module for .* from <HOST>\s*$
^%(__prefix_line)sFailed \S+ for .*? from <HOST>(?: port \d*)?(?: ssh\d*)?(: (ruser .*|(\S+ ID \S+ \(serial \d+\) CA )?\S+ %(__md5hex)s(, client user ".*", client host ".*")?))?\s*$
^%(__prefix_line)sROOT LOGIN REFUSED.* FROM <HOST>\s*$
^%(__prefix_line)s[iI](?:llegal|nvalid) user .* from <HOST>\s*$
^%(__prefix_line)sUser .+ from <HOST> not allowed because not listed in AllowUsers\s*$
^%(__prefix_line)sUser .+ from <HOST> not allowed because listed in DenyUsers\s*$
^%(__prefix_line)sUser .+ from <HOST> not allowed because not in any group\s*$
^%(__prefix_line)srefused connect from \S+ \(<HOST>\)\s*$
^%(__prefix_line)sUser .+ from <HOST> not allowed because a group is listed in DenyGroups\s*$
^%(__prefix_line)sUser .+ from <HOST> not allowed because none of user's groups are listed in AllowGroups\s*$
ignoreregex =
La section [INCLUDES] spécifie les autres fichiers de filtre qui sont lus avant ou après ce fichier. Dans notre exemple, le fichier common.conf est lu et placé avant les autres lignes de ce fichier. Cela configure certains paramètres que nous utiliserons dans notre configuration.
Ensuite, nous avons une section [Definition] qui définit les règles réelles pour nos correspondances de filtres. Tout d’abord, nous définissons le nom du démon que nous surveillons en utilisant le paramètre _daemon.
Ensuite, nous passons à la définition réelle de failregex, qui définit les modèles qui déclencheront lorsqu’une ligne correspondante dans le fichier journal est trouvée. Ce sont des expressions régulières qui correspondent en fonction des différentes erreurs et des échecs qui peuvent être générés lorsqu’un utilisateur ne s’authentifie pas correctement.
Des portions de la ligne comme %(__prefix_line)s seront substituées par la valeur d’un paramètre configuré dans le fichier common.conf que nous avons inclus. Cela est utilisé pour correspondre aux différentes informations préliminaires que les systèmes d’exploitation écrivent dans les fichiers journaux lorsqu’ils utilisent des méthodes standard. Par exemple, certaines lignes du fichier /var/log/auth.log pourraient ressembler à ceci:
May 6 18:18:52 localhost sshd[3534]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=101.79.130.213
May 6 18:18:54 localhost sshd[3534]: Failed password for invalid user phil from 101.79.130.213 port 38354 ssh2
May 6 18:18:54 localhost sshd[3534]: Received disconnect from 101.79.130.213: 11: Bye Bye [preauth]
La portion surlignée est un modèle standard que le système d’exploitation insère pour fournir plus de contexte. Ensuite, il existe plusieurs façons différentes dont le service pare-feu iptables enregistre les tentatives d’échec dans le journal.
Nous voyons deux échecs distincts dans les deux premières lignes ci-dessus (une erreur d’authentification PAM et une erreur de mot de passe). Les expressions régulières définies dans le filtre sont conçues pour correspondre à l’une quelconque des lignes d’échec possibles. Vous ne devriez pas avoir à ajuster ces lignes, mais vous devez être conscient de la nécessité de capturer toutes les entrées de journal qui indiquent une erreur d’utilisation non autorisée pour l’application que vous essayez de protéger si vous devez jamais créer vous-même un fichier de filtre.
En bas, vous pouvez voir un paramètre ignoreregex, qui est actuellement vide. Cela peut être utilisé pour exclure des modèles plus spécifiques qui correspondraient généralement à une condition d’échec au cas où vous voudriez annuler le déclencheur d’échec pour fail2ban pour certains scénarios. Nous ne modifierons pas cela.
Enregistrez et fermez le fichier lorsque vous avez fini de l’examiner.
Examen du fichier d’action
Maintenant, jetons un coup d’œil au fichier d’action. Ce fichier est responsable de la configuration du pare-feu avec une structure qui permet des modifications pour interdire les hôtes malveillants, et pour ajouter et supprimer ces hôtes si nécessaire.
L’action que notre service SSH invoque s’appelle iptables-multiport. Ouvrez maintenant le fichier associé :
Avec les commentaires supprimés, ce fichier ressemble à ceci :
[INCLUDES]
before = iptables-blocktype.conf
[Definition]
actionstart = iptables -N fail2ban-<name>
iptables -A fail2ban-<name> -j RETURN
iptables -I <chain> -p <protocol> -m multiport --dports <port> -j fail2ban-<name>
actionstop = iptables -D <chain> -p <protocol> -m multiport --dports <port> -j fail2ban-<name>
actioncheck = iptables -n -L <chain> | grep -a 'fail2ban-<name>[ \t]'
actionban = iptables -I fail2ban-<name> 1 -s <ip> -j <blocktype>
actionunban = iptables -D fail2ban-<name> -s <ip> -j <blocktype>
[Init]
name = default
port = ssh
protocol = tcp
chain = INPUT
Le fichier commence par sourcer un autre fichier d’action appelé iptables-blocktype.conf qui définit le paramètre blocktype, qui configure la restriction qui sera définie lorsqu’un client est banni. Par défaut, le blocktype est défini pour rejeter les paquets et répondre aux pings envoyés par les clients bannis avec un message de rejet indiquant que le port est inaccessible. Nous utiliserons cela dans nos règles d’interdiction ci-dessous.
Ensuite, nous arrivons aux définitions de règles elles-mêmes. L’action actionstart configure le pare-feu iptables lorsque le service fail2ban est démarré. Il crée une nouvelle chaîne, ajoute une règle à cette chaîne pour retourner à la chaîne appelante, puis insère une règle au début de la chaîne INPUT qui autorise le trafic correspondant aux destinations de protocole et de port correctes vers la nouvelle chaîne.
Il le fait en utilisant les valeurs que nous avons transmises avec l’action que nous avons définie dans notre fichier jail.local. Le name est pris à partir de l’en-tête de section pour chaque service. Le chain, le protocol et le port sont pris à partir de la ligne action elle-même dans ce fichier.
Ici, tous les paramètres qui sont définis par l’autre fichier sont référencés en incluant le nom du paramètre entre crochets angulaires:
<nom_paramètre>
Lorsque nous descendons à la définition actionstop associée, nous pouvons voir que les commandes pare-feu implémentent une inversion des commandes actionstart. Lorsque le service Fail2ban s’arrête, il supprime proprement toutes les règles de pare-feu qu’il a ajoutées.
Une autre action appelée actioncheck vérifie que la chaîne appropriée a été créée avant de tenter d’ajouter des règles de bannissement.
Ensuite, nous passons à la règle de bannissement réelle, appelée actionban. Cette règle fonctionne en ajoutant une nouvelle règle à notre chaîne créée. La règle correspond à l’adresse IP source du client fautif – ce paramètre est lu à partir des journaux d’autorisation lorsque la limite de maxretry est atteinte. Elle met en place le bloc défini par le paramètre blocktype que nous avons sourcé dans la section [INCLUDE] en haut du fichier.
La règle actionunban supprime cette règle. Cela se fait automatiquement par fail2ban lorsque le temps de bannissement a expiré.
Enfin, nous arrivons à la section [Init]. Cela fournit simplement quelques valeurs par défaut au cas où le fichier d’action serait appelé sans passer toutes les valeurs appropriées.
Comment le service Fail2ban traite les fichiers de configuration pour mettre en œuvre des bannissements
Maintenant que nous avons vu les détails, examinons le processus qui se déroule lorsque fail2ban démarre.
Chargement des fichiers de configuration initiaux
En premier lieu, le fichier principal fail2ban.conf est lu pour déterminer les conditions dans lesquelles le processus principal doit fonctionner. Il crée les fichiers socket, pid et journal si nécessaire et commence à les utiliser.
Ensuite, fail2ban lit le fichier jail.conf pour obtenir les détails de configuration. Il poursuit en lisant, par ordre alphabétique, tous les fichiers trouvés dans le répertoire jail.d se terminant par .conf. Il ajoute les paramètres trouvés dans ces fichiers à sa configuration interne, donnant la préférence aux nouvelles valeurs par rapport aux valeurs décrites dans le fichier jail.conf.
Il recherche ensuite un fichier jail.local et répète ce processus, en adaptant les nouvelles valeurs. Enfin, il recherche à nouveau dans le répertoire jail.d, lisant par ordre alphabétique les fichiers se terminant par .local.
Dans notre cas, nous avons seulement un fichier jail.conf et un fichier jail.local. Dans notre fichier jail.local, nous devons uniquement définir les valeurs qui diffèrent du fichier jail.conf. Le processus fail2ban a maintenant un ensemble de directives chargées en mémoire qui représentent une combinaison de tous les fichiers trouvés.
Il examine chaque section et recherche une directive enabled = true. S’il en trouve une, il utilise les paramètres définis sous cette section pour construire une politique et décider des actions nécessaires. Tous les paramètres qui ne sont pas trouvés dans la section du service utilisent les paramètres définis dans la section [DEFAULT].
Analyse des fichiers d’action pour déterminer les actions de démarrage
Fail2ban recherche une directive action pour savoir quel script d’action appeler pour mettre en œuvre les politiques de bannissement/débannissement. Si aucune n’est trouvée, il se rabat sur l’action par défaut déterminée ci-dessus.
La directive d’action se compose du nom du(des) fichier(s) d’action qui seront lus, ainsi que d’un dictionnaire clé-valeur qui transmet les paramètres nécessaires à ces fichiers. Les valeurs de ces derniers prennent souvent la forme de substitutions de paramètres en référençant les paramètres configurés dans la section du service. La clé « name » reçoit généralement la valeur de la variable spéciale __name__ qui sera définie sur la valeur de l’en-tête de la section.
Fail2ban utilise ensuite ces informations pour trouver les fichiers associés dans le répertoire action.d. Il recherche d’abord le fichier d’action associé se terminant par .conf puis complète les informations trouvées avec les paramètres contenus dans un fichier .local accompagnant également dans le répertoire action.d.
Il analyse ces fichiers pour déterminer les actions qu’il doit entreprendre. Il lit la valeur actionstart pour voir les actions qu’il doit effectuer pour configurer l’environnement. Cela inclut souvent la création d’une structure de pare-feu pour accueillir les règles d’interdiction à l’avenir.
Les actions définies dans ce fichier utilisent les paramètres qui lui sont transmis par la directive action. Il utilisera ces valeurs pour créer dynamiquement les règles appropriées. Si une certaine variable n’a pas été définie, il peut regarder les valeurs par défaut définies dans le fichier d’action pour combler les lacunes.
Analyse des fichiers de filtre pour déterminer les règles de filtrage
Les paramètres pour le service dans les fichiers jail.* incluent également l’emplacement du fichier journal ainsi que le mécanisme de sondage qui devrait être utilisé pour vérifier le fichier (cela est défini par le paramètre backend). Il inclut également un filtre qui devrait être utilisé pour déterminer si une ligne dans le journal représente un échec.
Fail2ban recherche dans le répertoire filter.d le fichier de filtre correspondant qui se termine par .conf. Il lit ce fichier pour définir les motifs qui peuvent être utilisés pour faire correspondre les lignes fautives. Ensuite, il recherche un fichier de filtre correspondant se terminant par .local pour voir si certains des paramètres par défaut ont été modifiés.
Il utilise les expressions régulières définies dans ces fichiers lorsqu’il lit le fichier journal du service. Il essaie chaque ligne failregex définie dans les fichiers filter.d contre chaque nouvelle ligne écrite dans le fichier journal du service.
Si l’expression régulière retourne une correspondance, il vérifie la ligne contre les expressions régulières définies par le ignoreregex. Si cela correspond également, fail2ban l’ignore. Si la ligne correspond à une expression dans le failregex mais ne correspond pas à une expression dans le ignoreregex, un compteur interne est incrémenté pour le client qui a causé la ligne et une horodatage associée est créée pour l’événement.
À mesure que la fenêtre de temps définie par le paramètre findtime dans les fichiers jail.* est atteinte (tel que déterminé par l’horodatage de l’événement), le compteur interne est de nouveau décrémenté et l’événement n’est plus considéré comme pertinent pour la politique de bannissement.
Si, au fil du temps, des échecs d’authentification supplémentaires sont enregistrés, chaque tentative incrémente le compteur. Si le compteur atteint la valeur définie par le paramètre maxretry dans la fenêtre de temps configurée, fail2ban instaure un bannissement en appelant l’action actioncheck pour le service tel que défini dans les fichiers action.d/ pour le service. Cela permet de déterminer si l’action actionstart a configuré la structure nécessaire. Il appelle ensuite l’action actionban pour bannir le client fautif. Il définit également un horodatage pour cet événement.
Lorsque le temps spécifié par le paramètre bantime s’est écoulé, fail2ban débannit le client en appelant l’action actionunban.
Conclusion
À ce stade, vous avez une compréhension assez approfondie du fonctionnement de fail2ban. Lorsque vous vous éloignez de la configuration standard, il est utile de savoir comment fail2ban fonctionne afin de manipuler son comportement de manière prévisible.
Pour en savoir plus sur la protection d’autres services avec fail2ban, vous pouvez lire Comment Protéger un Serveur Nginx avec Fail2Ban sur Ubuntu 22.04.