====== Bloquer les attaques en force brute avec fail2ban ======

<note important>En cours de rédaction</note>

Sources :
  * [[https://www.it-connect.fr/filtres-et-actions-personnalises-dans-fail2ban/|Filtres et actions personnalisés dans Fail2ban]] (fr) (it-connect.fr)
  * [[https://www.the-art-of-web.com/system/fail2ban-filters/|Optimising your Fail2Ban filters]] (en) (the-art-of-web.com)

===== Terminologie =====
  * 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

===== Ajouter un filtre personnalisé =====
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.
==== Filtre dérivé ====
===== Tester un filtre =====
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 :

<code>fail2ban-regex [OPTIONS] LOG REGEX [IGNOREREGEX]</code>

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//:
<code>fail2ban-regex systemd-journal /etc/fail2ban/filter.d/filtre.local /etc/fail2ban/filter.d/filtre.local</code>
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 :

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

systemd-journal
==== Affichage des résultats ====
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 :
<code>fail2ban-regex --print-all-matched systemd-journal filtre.local filtre.local</code>
==== Activer une prison ====
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).
===== Ajouter une prison =====

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.

==== Activer une prison ====

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 :

<code>service fail2ban reload</code>

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

<code>service fail2ban status</code>
===== Bannissement incrémental =====
Sources :
  * [[https://visei.com/2020/05/incremental-banning-with-fail2ban/|Incremental banning with Fail2Ban]] (en)
  * [[https://github.com/fail2ban/fail2ban/discussions/2952|Using fail2ban over longer time spans]]