Différences

Ci-dessous, les différences entre deux révisions de la page.

--- bloquer_les_attaques_en_force_brute_avec_fail2ban [2026/05/03 10:05] – [Activer une prison] Flaz
+++ bloquer_les_attaques_en_force_brute_avec_fail2ban [2026/05/10 14:16] (Version actuelle) – [Ne pas bannir] Flaz
@@ Ligne 10: / Ligne 10: @@
   * filtre (filter) : type d'événement à surveiller
   * action (action) : action de blocage, de protection ou de notification
-  * prison (jail) : conditions d'engagement d'une //action// sur la base des événements détectés par un //filtre//
+  * prison (jail) : conditions d'engagement d'une //action// sur la base des événements définis 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.
@@ Ligne 20: / Ligne 20: @@
 La plus simple mais pas forcément la meilleure consiste à créer un filtre dans lequel on va copier/coller un filtre existant puis effectuer les modifications voulues.
-La seconde consiste à créer un filtre qui hérite dynamiquement ((En utilisant un mécanisme d'inclusion.)) d'un filtre existant. On surcharge des éléments définis dans le filtre existant et/ou on complète le mécanisme de détection. L'intérêt de cette méthode est qu'elle permet de bénéficier des mises à jour des filtres existants sur lesquels s'appuie le nouveau filtre, notamment lorsqu'il s'agit de filtres installés par la distribution((Paquetage.)). La difficulté tient à la robustesse((Résistance aux mises à jour du filtre existant.)) du type de « surcharge » réalisée.
+La seconde consiste à créer un filtre qui hérite dynamiquement ((En utilisant un mécanisme d'inclusion.)) d'un filtre pré-existant. On surcharge des éléments définis dans le filtre existant et/ou on complète le mécanisme de détection. L'intérêt de cette méthode est qu'elle permet de bénéficier des mises à jour des filtres existants sur lesquels s'appuie le nouveau filtre. La difficulté tient à la robustesse((Résistance aux mises à jour du filtre existant.)) du type de « surcharge » réalisée.
 ===== 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 :
+Pour ce faire, on utilise la commande [[https://manpages.debian.org/trixie/fail2ban/fail2ban-regex.1.en.html|fail2ban-regex]] dont la forme générale est la suivante :
 <code>fail2ban-regex [OPTIONS] LOG REGEX [IGNOREREGEX]</code>
@@ Ligne 53: / Ligne 53: @@
 Par exemple :
 <code>fail2ban-regex --print-all-matched systemd-journal filtre.local filtre.local</code>
-==== Activer une prison ====
+===== Activer une prison =====
 Les prisons prédéfinies figurent dans le fichier //jail.conf//. Elles ne sont pas activées.
@@ Ligne 65: / Ligne 65: @@
 ==== 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 :
+Déclarer une prison dans //jail.local// ne suffit pas à l'activer. Il n'est pas nécessaire de relancer (restart) //fail2ban//. Un simple rechargement (reload) 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>
@@ Ligne 77: / Ligne 77: @@
   * [[https://github.com/fail2ban/fail2ban/discussions/2952|Using fail2ban over longer time spans]]
+===== Idées de filtres =====
+==== apache-badbots ====
+Le filtre fourni avec Fail2ban contient une liste prédéfinie de robots malveillants. Pour compléter cette liste sans qu'elle soit écrasée par les mises à jour du filtre d'origine, j'ai créé un filtre dérivé qui me permet de gérer ma propre liste qui vient compléter la liste prédéfinie :
+<code - apache-badbots-custom.local>
+[INCLUDES]
+before = apache-badbots.conf
+[Definition]
+mybotcustom = Bytespider|MJ12bot|SeekportBot|serpstatbot|Barkrowler|YandexBot|AhrefsBot|DotBot|MojeekBot|ZoominfoBot|PetalBot|serpstatbot|BitSightBot|wpbot|WellKnownBot|BLEXBot|AwarioBot|ImagesiftBot|Dataprovider|Amazonbot|GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|SemrushBot|externalhit_uatext|SERankingBacklinksBot
+failregex = ^<HOST> -.*(GET|POST|HEAD).*HTTP.*(?:%(badbots)s|%(badbotscustom)s|%(mybotcustom)s)
+</code>
+==== apache-ratelimit ====
+L'idée est de détecter des robots qui ne se présentent pas comme tels. Dans ce cas, le filtre //apache-badbots// devient inopérant. Cependant, si une même IP fait 200 requêtes en 5 secondes, c'est louche.
+Attention à l'action qu'on associera à ce filtre car il détectera aussi les robots légitimes que l'on a explicitement autorisés explicitement autorisés ou pas interdits. Personnellement, je m'en sers pour générer un mail d'alerte, sans bannir l'IP.
+Source : [[https://odd.blog/2026/03/26/stopping-web-server-abuse-with-fail2ban/Stopping Web Server Abuse with Fail2Ban]] (en)
+===== Idées d'actions =====
+==== Ne pas bannir ====
+Une des actions envisageable est de signaler un bannissement potentiel sans effectuer le bannissement. C'est tout à fait possible mais le fichier jail.conf ne définit pas le raccourci d'action correspondant.
+Un tel raccourci se déduit facilement d'un raccourci existant. Par exemple :
+<code>
+# ban & send an e-mail with whois report to the destemail.
+action_mw = %(action_)s
+            %(mta)s-whois[sender="%(sender)s", dest="%(destemail)s", protocol="%(protocol)s", chain="%(chain)s"]
+</code>
+devient, par simple suppression de l'action de bannissement,
+<code>
+# send an e-mail with whois report to the destemail.
+action_noban_mw = %(mta)s-whois[sender="%(sender)s", dest="%(destemail)s", protocol="%(protocol)s", chain="%(chain)s"]
+</code>
+que l'on pourra ajouter dans la section //[DEFAULT]// de //jail.local//.