Sources :

• Filtres et actions personnalisés dans Fail2ban (fr) (it-connect.fr)
• Optimising your Fail2Ban filters (en) (the-art-of-web.com)

• filtre (filter) : décrit un événement à détecter
• action (action) :
• prison (jail) : engage une action plus ou moins complexe sur la base des événements détectés par un filtre

On peut créer un filtre personnalisé entièrement nouveau ou dérivé d'un filtre existant. On ne modifie jamais un filtre installé automatiquement par le paquetage.

Un filtre personnalisé doit impérativement être enregistré dans un fichier “.local” et ajouté au répertoire “/etc/fail2ban/filter.d”. L'ajout d'un filtre est sans conséquence tant qu'une prison ne l'exploite pas.

Avant d'utiliser un filtre dans une prison, il faut impérativement tester ce filtre pour s'assurer qu'il détecte correctement les événements souhaités et eux seuls !

Pour ce faire, on utilise la commande fail2ban-regex dont la forme générale est la suivante :

fail2ban-regex [OPTIONS] LOG REGEX [IGNOREREGEX]

Si le filtre contient une définition, même vide, de la variable “ignoreregex” (très fréquent), il faut impérativement indiquer le fichier de filtre en tant que IGNOREREGEX; sinon la commande ne fonctionne pas !

Par exemple, si les logs concernés sont fournis par journald:

fail2ban-regex systemd-journal /etc/fail2ban/filter.d/filtre.local /etc/fail2ban/filter.d/filtre.local

Pour que cela fonctionne, le filtre doit contenir une déclaration du service (unit) de journald concerné, par exemple “journalmatch = _SYSTEMD_UNIT=dovecot.service”.

Si les logs sont dans un fichier :

fail2ban-regex /var/log/fichier.log /etc/fail2ban/filter.d/filtre.local /etc/fail2ban/filter.d/filtre.local

systemd-journal

Par défaut, fail2ban-regex n'affiche que des résultats partiels. On dispose des options suivantes pour forcer l'affichage :

• --print-no-ignored
• --print-no-missed
• --print-all-matched
• --print-all-ignored
• --print-all-missed

Par exemple :

fail2ban-regex --print-all-matched systemd-journal filtre.local filtre.local

Les prisons prédéfinies figurent dans le fichier jail.conf. Elle ne sont pas activées.

Leur activation se fait de manière sélective en les déclarant dans le fichier jail.local en fixant la valeur du paramètre enabled de la prison à true (enabled = true).

Les prisons personnalisées doivent être ajoutées dans le fichier “/etc/fail2ban/jail.local”.

Par défaut, une prison exploite le filtre de même nom figurant dans “/etc/fail2ban/filter.d. Si le nom est différent, on précise le paramètre filter dans la déclaration de la prison. On peut ainsi créer plusieurs prisons exploiter le même filtre de manières différenciées.

Une fois définie dans jail.local, la nouvelle prison n'est pas active. Il n'est pas nécessaire de relancer (restart) fail2ban. Un simple rechargement suffit à déclencher la relecture des fichiers de configuration et la prise en compte des modifications qu'on y a faites :

service fail2ban reload

Je recommande de vérifier aussitôt l'état de fail2ban :

service fail2ban status

Sources :

• Incremental banning with Fail2Ban (en)
• Using fail2ban over longer time spans