Comment Fail2Ban fonctionne pour protéger les services sur un serveur Linux

Introduction

Tout service exposé à Internet est susceptible d'être attaqué par des parties malveillantes. Si votre service nécessite une authentification, des utilisateurs et des robots illégitimes tenteront de s'introduire dans votre système en essayant à plusieurs reprises de s'authentifier à l'aide de différentes informations d'identification.

Un exemple courant de ceci est avec SSH, qui fera l'objet d'attaques de robots qui tentent de forcer brutalement les noms de compte communs. Heureusement, des services comme fail2ban ont été créés pour nous aider à atténuer ces attaques.

Fail2ban fonctionne en modifiant dynamiquement les règles du pare-feu pour interdire les adresses qui ont tenté de se connecter sans succès un certain nombre de fois. Dans un guide précédent, nous avons expliqué comment faire en sorte que fail2ban soit opérationnel sur Ubuntu 14.04.

Dans ce guide, nous discuterons plus en détail du fonctionnement réel de fail2ban et de la manière dont vous pouvez utiliser ces connaissances pour modifier ou étendre le comportement de ce service.

Le concept de base

L'idée de base derrière fail2ban est de surveiller les journaux des services communs pour repérer les modèles d'échecs 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. Il définit ces modèles d'expressions régulières dans une variable appelée failregex.

Heureusement, fail2ban inclut des fichiers de filtre pour les services communs. Lorsqu'une ligne du fichier journal du service correspond au failregex dans son filtre, l'action définie est exécutée pour ce service. Le action est une variable qui peut être configurée pour faire beaucoup de choses différentes, selon les préférences de l'administrateur.

L'action par défaut consiste à bannir l'hôte/l'adresse IP incriminé en modifiant les règles de pare-feu iptables. Vous pouvez étendre cette action pour envoyer également un e-mail à l'administrateur avec le rapport whois de l'attaquant ou les lignes de journal qui ont déclenché l'action.

Vous pouvez également modifier la cible de l'action pour qu'elle soit différente de l'habituel iptables. Cela peut être aussi complexe ou aussi simple que vous le souhaitez et de nombreuses options de fichiers de configuration et de notification de pare-feu sont disponibles.

Par défaut, une action sera entreprise lorsque trois échecs d'authentification ont été détectés en 10 minutes, et la durée d'interdiction par défaut est de 10 minutes. Le nombre par défaut d'échecs d'authentification nécessaires pour déclencher une interdiction est remplacé dans la partie SSH du fichier de configuration par défaut pour autoriser 6 échecs avant que l'interdiction n'ait lieu. Ceci est entièrement paramétrable par l'administrateur.

Lors de l'utilisation de la cible par défaut iptables pour le trafic SSH, fail2ban crée une nouvelle chaîne au démarrage du service. Il ajoute une nouvelle règle à la chaîne INPUT qui envoie tout le trafic TCP dirigé vers le port 22 vers la nouvelle chaîne. Dans la nouvelle chaîne, il insère une seule règle qui revient à la chaîne INPUT.

Cela fait simplement sauter le trafic vers la nouvelle chaîne, puis revient tout de suite. Cela n'a aucun effet sur le trafic au départ. Cependant, lorsqu'une adresse IP atteint le seuil d'échecs d'authentification, une règle est ajoutée au sommet de la nouvelle chaîne pour supprimer le trafic de l'adresse IP incriminée. Cela prend soin de l'interdiction réelle. Lorsque la période d'interdiction a expiré, la règle iptables est supprimée. La chaîne et les règles associées sont supprimées lorsque le service fail2ban se termine.

Explorer les paramètres du service Fail2ban

Fail2ban est configuré via une variété de fichiers situés dans une hiérarchie sous le répertoire /etc/fail2ban/.

Le fichier fail2ban.conf configure certains paramètres opérationnels de base comme la façon dont le démon enregistre les informations, et le fichier socket et pid qu'il utilisera. La configuration principale a cependant lieu dans les fichiers qui définissent les "jails".

Par défaut, fail2ban est livré avec un fichier jail.conf. Cependant, cela peut être écrasé dans les mises à jour, les utilisateurs sont donc encouragés à copier ce fichier dans un fichier jail.local et à y apporter des modifications.

Si vous avez déjà un fichier jail.local, ouvrez-le maintenant pour suivre :

sudo nano /etc/fail2ban/jail.local

Si vous n'avez pas encore de fichier jail.local, ou si le fichier que vous avez ouvert était vierge, copiez le fichier jail.conf, puis ouvrez le nouveau fichier :

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

Nous allons examiner les options disponibles ici et voir comment ce fichier interagit avec d'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.

Une fois les commentaires supprimés, l'intégralité de la section par défaut ressemble à ceci :

[DEFAULT]

ignoreip = 127.0.0.1/8
bantime = 600
findtime = 600
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 réellement :

ignoreip : ce paramètre identifie l'adresse IP qui doit être ignorée par le système de bannissement. Par défaut, ceci est simplement configuré pour ignorer le trafic provenant de la machine elle-même, ce qui est un très bon paramètre à avoir.
bantime : ce paramètre définit la durée d'un bannissement, en secondes. La valeur par défaut est de 600 secondes ou 10 minutes.
findtime : ce paramètre définit la fenêtre à laquelle fail2ban prêtera attention lors de la recherche d'échecs répétés d'authentification. La valeur par défaut est définie sur 600 secondes (10 minutes à nouveau), ce qui signifie que le logiciel comptera le nombre de tentatives infructueuses au cours des 10 dernières minutes.
maxretry : Ceci définit le nombre de tentatives infructueuses qui seront tolérées dans la fenêtre findtime avant qu'une interdiction ne soit instituée.
backend : cette entrée spécifie comment fail2ban surveillera les fichiers journaux. Le réglage de auto signifie que fail2ban essaiera pyinotify, puis gamin, puis un algorithme d'interrogation basé sur ce qui est disponible.
usedns : Cela définit si le DNS inverse est utilisé pour aider à mettre en œuvre les interdictions. Définir ceci sur "non" interdira les adresses IP elles-mêmes au lieu des noms d'hôtes. Le paramètre "warn" tentera d'utiliser le reverse-DNS pour rechercher le nom d'hôte et l'interdire de cette façon, mais enregistrera l'activité pour examen.
destemail : il s'agit de l'adresse à laquelle sera envoyé l'e-mail de notification si votre action est configurée pour envoyer des alertes par e-mail.
sendername : ceci sera utilisé dans le champ e-mail de pour les e-mails de notification générés
banaction : Ceci définit l'action qui sera utilisée lorsque le seuil sera atteint. Il y a en fait le nom d'un fichier situé dans /etc/fail2ban/action.d/ appelé iptables-multiport.conf. Cela gère la manipulation réelle iptables pour interdire une adresse IP. Nous verrons cela plus tard.
mta : il s'agit de l'agent de transfert de courrier qui sera utilisé pour envoyer les e-mails de notification.
protocole : il s'agit du type de trafic qui sera abandonné lorsqu'une interdiction d'IP est mise en œuvre. C'est également le type de trafic qui est envoyé à la nouvelle chaîne iptables.
chaîne : 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.

Les autres paramètres définissent différentes actions pouvant être spécifiées. Ils transmettent certains des paramètres que nous avons définis ci-dessus en utilisant une interpolation de chaîne comme ceci :

%(var_name)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 sur la définition action_ par défaut (interdiction uniquement, pas d'alertes par courrier).

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 l'interdiction. Le __name__ est remplacé par le nom du service tel que spécifié par les en-têtes de section ci-dessous.

Sections spécifiques aux services

Sous la section par défaut, il existe des sections pour des services spécifiques qui peuvent être utilisées pour remplacer les paramètres par défaut. Cela suit une convention consistant à ne modifier que les paramètres qui s'écartent des valeurs normales (convention plutôt que configuration).

Chaque en-tête de section est spécifié comme ceci :

[ nom_service ]

Toute section contenant cette ligne sera lue et activée :

enabled = true

Dans 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 du fichier journal lui-même.

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 active cette section et définit le port sur le port "ssh" (port 22). Il indique à fail2ban de consulter le journal situé dans /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_, ce qui bannira l'adresse IP incriminée à l'aide de l'interdiction iptables-multiport, qui fait référence à un fichier appelé iptables-multiport.conf trouvé dans [X175X ].

Comme vous pouvez le voir, les actions de la section [DEFAULT] doivent être générales et flexibles. Une utilisation intensive de la substitution de paramètres avec des paramètres qui fournissent des valeurs par défaut raisonnables rendra les définitions faciles à remplacer si nécessaire.

Examen du fichier de filtre

Afin de comprendre ce qui se passe dans notre configuration, nous devons comprendre les fichiers de filtre et d'action, qui font l'essentiel du travail.

Le fichier de filtre déterminera les lignes que fail2ban recherchera dans les fichiers journaux pour identifier les caractéristiques incriminées. Le fichier d'action implémente toutes les actions requises, depuis la création d'une structure de pare-feu au démarrage du service, jusqu'à l'ajout et la suppression de règles, et la suppression de la structure du pare-feu lorsque le service s'arrête.

Examinons le fichier de filtre que notre service SSH a appelé dans la configuration ci-dessus :

sudo nano /etc/fail2ban/filter.d/sshd.conf

[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 =

Cela s'annonce très compliqué. C'est parce que c'est assez compliqué. Décomposons un peu cela.

L'en-tête de section [INCLUDES] spécifie d'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 définit 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 filtre. Tout d'abord, nous définissons le nom du démon que nous surveillons en utilisant le paramètre _daemon.

Après cela, nous passons en revue la définition réelle failregex, qui définit les modèles qui se 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 échecs qui peuvent être générés lorsqu'un utilisateur ne s'authentifie pas correctement.

Des parties de la ligne comme %(__prefix_line)s seront remplacées par la valeur d'une configuration de paramètre dans le fichier common.conf que nous avons fourni. Ceci est utilisé pour faire correspondre les différentes informations principales que les systèmes d'exploitation écrivent dans les fichiers journaux lorsqu'ils utilisent des méthodes standard. Par exemple, certaines lignes du /var/log/auth.log pourraient ressembler à ceci :

 6 mai 18:18:52 localhost sshd[3534] : pam_unix(sshd:auth) : échec de l'authentification ;  logname= uid=0 euid=0 tty=ssh ruser= rhost=101.79.130.213 6 mai 18:18:54 localhost sshd[3534] : Échec du mot de passe pour l'utilisateur invalide phil du port 101.79.130.213 38354 ssh2 6 mai 18:18 : 54 localhost sshd[3534] : Déconnexion reçue de 101.79.130.213 : 11 : Bye Bye [preauth]

La partie en rouge est un modèle standard que le système d'exploitation insère pour fournir plus de contexte. Après cela, il existe plusieurs façons différentes pour le service iptables d'écrire 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 des lignes d'échec possibles. Vous ne devriez pas avoir à ajuster l'une de ces lignes, mais vous devez être conscient de la nécessité d'intercepter toutes les entrées de journal qui signifient une erreur d'utilisation non autorisée pour l'application que vous essayez de protéger si jamais vous devez 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 n'ajusterons pas cela.

Enregistrez et fermez le fichier lorsque vous avez terminé de l'examiner.

Examen du fichier d'action

Examinons maintenant le fichier d'action. Ce fichier est responsable de la configuration du pare-feu avec une structure qui permet des modifications faciles pour interdire les hôtes malveillants, et pour ajouter et supprimer ces hôtes si nécessaire.

Comme vous vous en souvenez, l'action invoquée par notre service SSH s'appelle iptables-multiport. Ouvrez maintenant le fichier associé :

sudo nano /etc/fail2ban/action.d/iptables-multiport.conf

Une fois 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 rechercher un autre fichier d'action appelé iptables-blocktype.conf qui définit simplement le paramètre blocktype qui configure la restriction qui sera définie lorsqu'un client est banni. Par défaut, le blocktype est configuré pour rejeter les paquets et répondre aux pings envoyés par les clients interdits avec un message de rejet indiquant que le port est inaccessible. Nous l'utiliserons dans nos règles d'interdiction ci-dessous.

Ensuite, nous arrivons aux définitions de règles elles-mêmes. Les actions sont assez simples. L'action actionstart configure le pare-feu iptables au démarrage du service fail2ban. Il crée une nouvelle chaîne, ajoute une règle à cette chaîne pour revenir à la chaîne d'appel, puis insère une règle au début de la chaîne INPUT qui transmet le trafic correspondant au protocole et aux destinations de port corrects vers la nouvelle chaîne.

Pour ce faire, il utilise les valeurs que nous avons transmises avec le action que nous avons défini dans notre fichier jail.local. Le name est tiré de l'en-tête de section pour chaque service, le chain, protocol et port sont tirés de la ligne action lui-même dans ce fichier.

Vous vous souviendrez peut-être que ceux-ci, à leur tour, ont été ajoutés à la ligne d'action en interpolant les paramètres other définis dans les emplacements other de ce fichier. Vous réalisez peut-être à ce stade que fail2ban transmet et convertit de nombreux paramètres entre les différentes parties de ses fichiers de configuration.

Ici, tous les paramètres définis par l'autre fichier sont référencés en incluant le nom du paramètre entre crochets :

< nom_param >

Lorsque nous passons à la définition du compagnon actionstop, nous pouvons voir que les commandes du pare-feu implémentent simplement une inversion des commandes actionstart. Nous détruisons la structure du pare-feu que nous avons créée lorsque nous avons arrêté le service fail2ban.

Une autre action appelée actioncheck s'assure que la chaîne appropriée a été créée avant de tenter d'ajouter des règles d'interdiction.

Ensuite, nous arrivons à la règle d'interdiction 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 incriminé (ce paramètre est lu à partir des journaux d'autorisation lorsque la limite maxretry est atteinte) et institue le blocage défini par le paramètre blocktype que nous avons sourcé dans la section [INCLUDE] en haut du fichier.

La règle actionunban supprime simplement cette règle. Ceci est fait automatiquement par fail2ban lorsque le temps d'interdiction s'est écoulé.

Enfin, nous arrivons à la section [Init]. Cela fournit simplement quelques valeurs par défaut au cas où le fichier d'action serait appelé sans transmettre toutes les valeurs appropriées.

Comment le service Fail2ban traite les fichiers de configuration pour implémenter les interdictions

Maintenant que nous avons vu les détails, passons en revue le processus qui se produit lorsque fail2ban démarre.

Chargement des fichiers de configuration initiale

Tout d'abord, 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 log si nécessaire et commence à les utiliser.

Ensuite, fail2ban lit le fichier jail.conf pour les détails de configuration. Il suit en lisant, par ordre alphabétique, tous les fichiers trouvés dans le répertoire jail.d qui se terminent 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 le répertoire jail.d, en lisant par ordre alphabétique les fichiers se terminant par .local.

De cette façon, nous pouvons voir que fail2ban a un grand nombre de fichiers qui peuvent être utilisés pour manipuler le comportement final du processus. Dans notre cas, nous n'avons qu'un fichier jail.conf et un fichier jail.local. Dans notre fichier jail.local, il suffit de 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 qu'il a trouvés.

Il examine chaque section et recherche une directive enabled = true. S'il en trouve une, il utilise les paramètres définis dans cette section pour créer une stratégie et décider des actions requises. Tous les paramètres qui ne se trouvent pas 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 déterminer quel script d'action appeler pour implémenter les politiques de bannissement/débannissement. S'il n'en trouve pas, il retombe sur l'action par défaut déterminée ci-dessus.

La directive d'action se compose du nom du ou des fichiers d'action qui seront lus, ainsi que d'un dictionnaire clé-valeur qui transmet les paramètres nécessaires à ces fichiers. Les valeurs de ceux-ci prennent souvent la forme de substitutions de paramètres en faisant référence aux paramètres configurés dans la section du service. La clé "nom" 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 modifie les informations qui s'y trouvent avec tous les paramètres contenus dans un fichier d'accompagnement .local également trouvé dans le répertoire action.d.

Il analyse ces fichiers pour déterminer les actions qu'il doit prendre maintenant. Il lit la valeur actionstart pour voir les actions qu'il doit entreprendre pour configurer l'environnement. Cela inclut souvent la création d'une structure de pare-feu pour s'adapter aux règles d'interdiction à l'avenir.

Les actions définies dans ce fichier utilisent les paramètres qui lui sont passés depuis 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, elle peut consulter les valeurs par défaut définies dans le fichier d'action pour remplir les blancs.

Analyse des fichiers de filtre pour déterminer les règles de filtrage

Les paramètres du service dans les fichiers jail.* incluent également l'emplacement du fichier journal ainsi que le mécanisme d'interrogation qui doit être utilisé pour vérifier le fichier (ceci est défini par le paramètre backend) . Il inclut également un filtre qui doit être utilisé pour déterminer si une ligne du journal représente un échec.

Fail2ban regarde dans le répertoire filter.d pour trouver le fichier de filtre correspondant qui se termine par .conf. Il lit ce fichier pour définir les modèles qui peuvent être utilisés pour faire correspondre les lignes incriminées. Il recherche ensuite un fichier de filtre correspondant se terminant par .local pour voir si l'un des paramètres par défaut a été écrasé.

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 par rapport à chaque nouvelle ligne écrite dans le fichier journal du service.

Si l'expression régulière renvoie une correspondance, elle vérifie la ligne par rapport aux expressions régulières définies par ignoreregex. Si cela correspond également, fail2ban l'ignore. Si la ligne correspond à une expression dans failregex mais que pas correspond à une expression dans ignoreregex, un compteur interne est incrémenté pour le client qui a provoqué la ligne et un l'horodatage est créé pour l'événement.

Lorsque la fenêtre de temps définie par le paramètre findtime dans les fichiers jail.* est atteinte (telle que déterminée par l'horodatage de l'événement), le compteur interne est à nouveau décrémenté et l'événement n'est plus considéré comme pertinent pour la politique d'interdiction.

Si, au fil du temps, des échecs d'authentification supplémentaires sont consigné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 institue une interdiction en appelant l'action actioncheck pour le service tel que défini dans le action.d/ fichiers pour le service. Il s'agit de déterminer si l'action actionstart a mis en place la structure nécessaire. Il appelle ensuite l'action actionban pour bannir le client incriminé. Il définit également un horodatage pour cet événement.

Lorsque la durée spécifiée par le paramètre bantime s'est écoulée, fail2ban débanni le client en appelant l'action actionunban.

Lorsque le service fail2ban est arrêté, il tente de supprimer l'une des règles de pare-feu qu'il a créées en appelant l'action actionstop. Cela supprime généralement la chaîne qui contient les règles fail2ban et supprime les règles de la chaîne INPUT qui ont fait sauter le trafic vers cette chaîne.

Conclusion

J'espère que vous avez maintenant une compréhension assez approfondie du fonctionnement de fail2ban. Le service lui-même est incroyablement facile pour la plupart des utilisateurs car la plupart des configurations difficiles ont été prises en charge pour vous.

Cependant, lorsque vous vous écartez de la configuration standard, il est utile de savoir comment fonctionne fail2ban afin de manipuler son comportement de manière prévisible.

Pour savoir comment protéger d'autres services avec fail2ban, consultez ces liens :