Bonjour tout le monde.
J'ai peu d'expérience avec fail2ban, mais j'ai pu observer que certaines valeurs ou réglages par défaut me semblaient assez laxistes ou inefficaces.
Par exemple j'ai pu constater sur mes serveurs web perso de nombreuses tentatives d'extraction de données confidentielles vers des fichiers qui n'existent pas sur mes machines, ce qui renvoi suivant les cas des erreur 404 ou des erreur 302.
je peux comprendre qu'on ne va pas bannir sur ce genre d'erreur, mais quand ça se répète c'est vraisemblablement une attaque (ou un robot indexeur mal conçu).
Je me suis déjà retrouvé avec 5Go de logs en quelques jours parce que des robots indexeurs avaient abusés de mon serveur et que je n'avais pas encore filtré sur les répétitions d'erreur.
actuellement j'utilise le paquet fail2ban de Yunohost, donc j'ai une redirection 302 sur les nombreuses tentatives. mais sur mon reverse proxy SNI c'est un fail2ban de Debian.
voici mes fichiers:
les prisons
extrait de /etc/fail2ban/jail.local (qui est une copie de /etc/fail2ban/jail.conf):
[nginx-3xx]
enabled = true
port = http,https
logpath = /var/log/nginx/access.log
backend = polling
bantime = 180000
[nginx-4xx]
enabled = true
port = http,https
logpath = /var/log/nginx/access.log
backend = polling
bantime = 180000
[nginx-400]
enabled = true
port = http,https
logpath = /var/log/nginx/access.log
backend = polling
bantime = 180000
maxretry = 0
les filtres
fichier complet pour /etc/fail2ban/filter.d/nginx-3xx.conf
[Definition]
failregex = ^<HOST>.*"(GET|POST|HEAD).*" (301|302) .*$
ignoreregex =
fichier complet pour /etc/fail2ban/filter.d/nginx-4xx.conf
[Definition]
failregex = ^<HOST>.*"(GET|POST|HEAD).*" (404|444|403|405) .*$
ignoreregex =
fichier complet pour /etc/fail2ban/filter.d/nginx-400.conf
[Definition]
failregex = ^<HOST>.*".*" (400) .*$
ignoreregex =
Ce journal est une copie de https://err404.numericore.com/wiki/Divers/fail2ban/ (d'ou le tag autopromotion), mais linuxfr est un moyen d'avoir un retour que je ne peux pas avoir sur mon site web qui n'est pas ouvert aux commentaires.
Résultat:
je peux facilement voir ce qui est banni avec la commande:
watch "fail2ban-client status nginx-3xx | grep Banned && fail2ban-client status nginx-400 | grep Banned && fail2ban-client status nginx-4xx | grep Banned && fail2ban-client status recidive | grep Banned"sur mon réverse proxy sni (qui va attraper les requêtes en ipv4 seulement):
- Banned IP list:
- Banned IP list: 167.94.146.50 206.168.34.37 80.82.77.202 92.255.57.58 93.174.93.12 185.242.226.99 79.124.58.198 45.131.155.254 190.60.4.138 193.46.255.235 162.142.125.33 205.210.31.52 165.232.57.178 199.45.155.93 185.194.204.246 16.176.192.135 206.168.34.91 45.140.17.107 117.48.157.75 162.142.125.218 206.168.34.40 178.79.129.239 167.94.138.205 3.132.23.201 173.212.223.233 167.94.138.186 167.94.138.51 199.45.154.148 162.142.125.221 199.45.154.138 167.94.138.179 46.186.234.127 83.222.191.94 206.168.34.45 162.142.125.201 167.71.10.54 167.94.138.125 206.168.34.127 185.91.69.5 129.146.4.238 109.199.96.191 204.76.203.220 20.127.200.74 188.243.188.142 45.43.33.218 167.94.145.100 205.210.31.96 3.131.215.38 78.153.140.151 3.130.96.91 185.189.182.234 78.153.140.177
- Banned IP list: 175.206.113.91 95.167.133.150 51.159.102.237 165.232.57.178 194.50.16.252 82.102.18.116 167.71.10.54 148.153.45.235 85.204.70.98
- Banned IP list: 164.90.193.142 172.105.246.139 213.55.247.234 35.216.163.43 45.148.10.34 45.148.10.35 68.183.14.33 80.82.77.202 93.174.93.12 165.232.57.178 167.71.10.54 78.153.140.151 78.153.140.177
sur mon serveur web (qui va attraper les requêtes en ipv4 et ipv6):
- Banned IP list: 192.168.1.1
- Banned IP list: 2a03:b0c0:2:d0::1713:9001
- Banned IP list:
- Banned IP list:
on peut constater que c'est bien plus paisible en ipv6 (j'ai bien plus de requêtes légitimes en ipv6 qu'en ipv4, les bots par contre c'est surtout de l'ip4)
on observe que l'ip de mon routeur (192.168.1.1) est bannie, je ne sais pas comment ni pourquoi ça arrive directement sans passer par le reverse proxy sni en ipv4.
Quelle est votre expérience avec Fail2ban?
# Fail2ban ne remplace pas une bonne sécurité
Posté par chimrod (site web personnel) . Évalué à 4 (+2/-0). Dernière modification le 21 juin 2025 à 13:24.
Pour m'être penché il y a quelques années sur fail2ban, je trouvait la solution inadaptée face aux fermes de bot :
en suivant les logs je voyais une IP prendre le relais dès lors que le blocage s'activait sur la précédente.
au final, je prèfère prndre le problème à la source, ne pas autoriser l'authentification par mdp sur ssh par exemple, et considérer fail2ban comme un petit complèment mais je ne repose pas ma sécurité dessus
[^] # Re: Fail2ban ne remplace pas une bonne sécurité
Posté par moi1392 . Évalué à 3 (+1/-0).
Pour ma part, c'est un aussi un complément, mais j'ai rendu un peu plus violent le ban : au bout de 2 erreurs en moins d'une heure, je banni 1 semaine.
[^] # Re: Fail2ban ne remplace pas une bonne sécurité
Posté par Zatalyz (site web personnel) . Évalué à 2 (+1/-1).
En fait, une bonne sécurité, ce n'est pas un seul mur qu'on croit solide. C'est un labyrinthe de murs qu'on espère aussi solide que possible. Donc, non, Fail2ban seul n'est pas suffisant, mais rien "seul" ne l'est. Par contre c'est un outil parmi les autres qui réduit la pression, et qui n'a rien d'inutile.
De bonnes pratiques (comme la connexion ssh uniquement par clé, avec une robustesse suffisante, comme tu l'indique) sont une base nécessaire, mais à compléter, parce que les attaquants type bot essaient de rentrer par un peu tous les trous possibles. Je parle bien des bots, c'est à dire des attaques non ciblés qui concerne la majorité de nos serveurs ; si on doit faire face à une menace qui nous cible précisément, ça devient un autre niveau de complexité. Mais bon, sur les bots, on a des tas d'outils et de méthodes, trop pour se décider sur quoi mettre en place quand on n'y connait rien, et dire "Fail2ban ne remplace pas une bonne sécurité" c'est comme de dire "le sel ne fait pas les bons plats" : ouais, y'a du vrai mais c'est simpliste, c'est un élément qui y participe, et faut pas se priver de l'utiliser. L'erreur serait d'écarter l'outil parce qu'on a seulement entendu "ça ne sert pas à grand chose". Si si, ça sert. Ça ne fait pas tout, mais ça sert.
Techniquement, on pourrait par exemple se croire protégé sur la partie ssh parce qu'on a une clé pour se connecter. Sauf qu'il y a des protocoles pourris, qui sont encore utilisés, des configs pourries aussi, et des gens qui suivent des tutos qui ont 20 ans d'âge, et donc la protection peut être assez relative. Si le débutant qui a mis ça en place a quand même aussi mis en place fail2ban paramétré à peu près potablement, il ajoute une couche qui limite énormément le débordement. Il améliore encore ses chances en passant sur un port non standard, en autorisant uniquement certaines ip, en utilisant un bastion, etc. Rien de tout ça, seul, n'est suffisant non plus.
Fail2ban est un bon complément à un pare-feu qui doit, par ailleurs, être bien paramétré. Le pare-feu va laisser des trucs, c'est obligatoire. Certains seront arrêtés par Fail2ban. Qui va aussi laisser passer des trucs. Qui seront arrêtés par d'autres mécanismes, suivant les services ouverts. Et avec un peu de chance, on aura ajouté assez de couches dans la lasagne pour qu'aucun problème n'arrive à notre serveur. Bref, c'est toujours cool de voir des cas d'usage de Fail2ban.
[^] # Re: Fail2ban ne remplace pas une bonne sécurité
Posté par Voltairine . Évalué à 2 (+0/-0).
C'est justement sur les attaques ciblées que fail2ban pourrait avoir un rôle en terme de sécurité.
Pour les botnets ce n'est guère utile puisque les IP changent sans arrêt et qu'il cherchent pour la plupart des failles béantes ou des combinaisons d'identifiants triviales (voir les différentes recherches menées avec des honeypots à ce sujet). L'utilité est surtout de réduire un peu la taille des logs et éventuellement de centraliser les adresses IP des machines vérolées (abuseipdb ou autre).
Dans le cas du demandeur l'usage est pour limiter les tentatives de connexions sur son serveur HTTP et je ne suis pas sûr que ce soit une bonne idée de bannir systématiquement les IP qui produisent des erreurs 4xx (surtout l'erreur 400) sauf si le nombre de tentatives est vraiment important, donc avec maxretry=10 au moins.
[^] # Re: Fail2ban ne remplace pas une bonne sécurité
Posté par moi1392 . Évalué à 3 (+1/-0).
Dans ma tête il est plutôt là pour bloquer les attaques en brute force, dont en particulier celles des bots.
Et je me pose une question, les gens ici préconisent de désactiver la connexion à ssh par mot de passe.
À priori (je ne suis pas allé voir le protocole, donc n'hésitez pas à me corriger), ssh réponds la même chose que le mot de passe soit faux ou que la connexion par mot de passe soit désactivée, donc impossible (sauf effet de bord) pour l'attaquant de savoir que sa tentative de connexion à échoué à cause d'un mot de passe invalide ou de la désactivation de la connexion par mot de passe.
Qu'est ce qui change vraiment alors ? Si j'ai un mot de passe suffisament robute, une règle fail2ban assez violente (comme je l'ai dit, au bout de 2 erreurs -> 1 semaine de ban), le brute force de mot de passe est aussi difficile que le brute force de clé sur mon serveur non ?
L'argument des ip qui changent, je le trouve pas très fort, si on reste en ipv4, il y en a au max 4 milliard (2³32) et je doute qu'un attanquant puisse toutes les exploiter, même s'il arrive à en avoir 1 million de disponibles, ça réduit d'environ 2²20 la complexité à casser le mot de passe en brute force.
[^] # Re: Fail2ban ne remplace pas une bonne sécurité
Posté par Voltairine . Évalué à 2 (+0/-0).
Cela ne les bloque pas puisque les IP changent, au mieux cela ralenti un peu. Et n'oublie pas que fail2ban agit après coup en analysant les logs. Le temps qu'il réagisse il peut y avoir eu des dizaines de tentatives provenant de la même IP.
Quant aux attaques par force brute des bots elles ne consistent pas à « casser » les mots de passe mais à essayer des combinaisons triviales utilisateurs/mot de passe (je l'ai déjà mentionné et c'est facile à vérifier). Casser un mot de passe à distance un tant soit peu solide prendrait un temps infini en raison du temps entre deux tentatives.
Donc si ton service est bien configuré avec des mots de passe solide ces attaques n'aboutiront jamais et fail2ban est souvent là juste pour rassurer.
Pour le SSH un mot de passe très solide ou une connexion par clés peut sembler équivalent d'un point de vue sécurité. Dans l'absolu une clé ED25519 ou sera toujours beaucoup plus difficile à casser (est-ce seulement déjà arrivé ?) qu'un mot de passe. Et là encore il faudrait un temps et une puissance de calcul phénoménaux.
En Outre une configuration excluant la connexion par mot de passe par défaut peut éviter une étourderie de l'administrateur système qui a créé un compte test, mot de passe test pour tester (situation similaire déjà vue en vrai).
[^] # Re: Fail2ban ne remplace pas une bonne sécurité
Posté par flan (site web personnel) . Évalué à 2 (+0/-0).
Tu peux ajouter les URL wordpress qui ne devraient pas être appelées (toutes si ce n'est pas un wordpress, ou celles qui sont utilisées lors de l'installation), ainsi que les requêtes HTTP avec le mauvais nom de serveur. Ça fait pas mal de ménage dans les logs.
# protection par fail2ban
Posté par err404 (site web personnel) . Évalué à 1 (+0/-0).
il est clair que pour protéger ssh, il vaut mieux des trucs plus adaptés que fail2ban. (authentification par clef: pas par mot de passe, et seulement depuis un vpn: pas public), mais ce n'est pas vraiment le sujet de mon journal.
moi je parlais surtout de protéger mes services web.
je banni systématiquement les erreur 400 car c'est systématiquement des agressions. (des url forgées pour faire planter le serveur par exemple).
[^] # Re: protection par fail2ban
Posté par Voltairine . Évalué à 2 (+0/-0).
Il serait intéressant de voir les logs du serveur web avec ces erreurs.
L'erreur 400 peut par exemple être très présente avec un serveur ou des clients WebDav mal configuré ou bogués. Ce n'est pas forcément une agression et suivant les services que tu héberges tu risques de bloquer des utilisateurs légitimes
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.