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é à 7 (+5/-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é à 6 (+4/-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é à 7 (+7/-2).
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é à 3 (+1/-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é à 6 (+4/-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é à 6 (+4/-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 Zatalyz (site web personnel) . Évalué à 5 (+3/-0).
Je plussoie particulièrement ce passage : il y a toujours un risque qu'un compte aie été mal sécurisé. L'option "AllowUsers" ou "AllowGroups" dans la config ssh est vraiment utile pour compléter, afin que seules les administrateurs soient réellement autorisés à utiliser ssh.
[^] # Re: Fail2ban ne remplace pas une bonne sécurité
Posté par Andre Rodier (site web personnel) . Évalué à 4 (+2/-0).
Exactement. C'est pour cela que préfère suivre le journal de systemd avec un script Rust ou Python et le module journald.
Oui pour le constat, non pour "juste pour rassurer" (en tout cas pour moi).
L'utilisation d'un logiciel comme fail2ban permet de :
Réduire la bande passante et les ressources énergétiques consommées. Lorsqu'une adresse IP est bloquée, c'est autant de trafic en moins.
Réduire le "bruit" pour se concentrer sur le signal. Si j'ai 10k entrées de bots de log de mon serveur web, j'aurais du mal à voir les entrées qui m'intéressent et qui demanderont une attention particulière.
Mais sinon, je suis d'accord avec le constat général, fail2ban n'augmente pas la sécurité.
[^] # Re: Fail2ban ne remplace pas une bonne sécurité
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 7 (+4/-0).
J'ai eu des problèmes de bot, non pas pour de la sécurité, mais des crawlers mal fichus qui ignorent le robots.txt et saturent ma connexion internet et mes logs avec beaucoup de requêtes.
J'ai mis en place un ban au niveau du serveur web (qui retourne une erreur HTTP spécifique pour les plages d'IP bannies) et fail2ban entre en jeu si le bot continue d'insister. Comme il y a peu de risque de faux positifs, la règle fail2ban peut être très peu tolérante (ban au bout de 2 détections pour une très longue durée).
Le résultat est que le traffic sur le serveur est fortement réduit et que je peux analyser les logs (avec awstats par exemple) pour voir de vraies choses (pics de traffic quand un lien a été beaucoup partagé, liste d'erreurs 404 qui méritent que je vérifie des choses, …).
Du côté du ssh, j'avais des gens essayant de bruteforcer des mots de passes depuis longtemps, fail2ban a l'air d'avoir pas mal calmé les choses, les bots dans ce cas semblent peu insistants et ne reviennent pas quand ils sont bannis.
Je peux surveiller la liste des bans fail2ban de temps en temps et décider si je peux retirer une plage d'IP bloquée de la config de mon serveur web de temps en temps, une fois que les bots ne l'utilisent plus.
[^] # Re: Fail2ban ne remplace pas une bonne sécurité
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 5 (+3/-0).
Pas du tout. Il négocie les protocoles d'identifications possibles entre client et serveur. Si le mot de passe est désactivé, le client ne se voit pas proposer cette méthode, mais uniquement les autres méthodes autorisées.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Fail2ban ne remplace pas une bonne sécurité
Posté par flan (site web personnel) . Évalué à 4 (+2/-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.
[^] # Re: Fail2ban ne remplace pas une bonne sécurité
Posté par barmic 🦦 . Évalué à 4 (+2/-0).
Comment fai2ban va bloquer quelque chose qui ne serait pas bloqué par l’interdiction de l’authentification par mot de passe ? Le cas d’un bot qui brute force des clefs ? Pour les mots de passe, le brute force en ligne n’existe pas, le coût réseau le rend prohibitif, ce qui existe c’est des tentatives avec des mots de passes connu ou cohérent avec ton domaine. Du brute force de clefs en ligne, même les États ne l’envisagent pas, ils utilisent les faiblesses qu’ils connaissent. Donc il font très peu de tentatives.
C’est pas de la sécurité mais de l’obfuscation.
Ça n’a aucun intérêt si tu n’a qu’un seul serveur ou que les serveurs sont sur un réseau publique.
La sécurité ce n’est pas mettre des couches en se disant que plus il y a de couches moins tu as de problèmes. Prendre du temps pour configurer correctement SSH est plus important qu’ajouter fail2ban par exemple. Au contraire virer des couches peut améliorer la sécurité par exemple en retirant SSH.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Fail2ban ne remplace pas une bonne sécurité
Posté par Psychofox (Mastodon) . Évalué à 6 (+3/-0).
fail2ban n'est pas dédié à ssh.
Comme d'autre l'ont déjà dit, ça peut aider à supprimer du traffic inutile qui génère des logs non pertiments (et dans certains cas de la bande passante).
[^] # Re: Fail2ban ne remplace pas une bonne sécurité
Posté par Pol' uX (site web personnel) . Évalué à 4 (+2/-0).
(et des processus, et de la mémoire, etc.)
Adhérer à l'April, ça vous tente ?
[^] # Re: Fail2ban ne remplace pas une bonne sécurité
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
Oui mais je répondais à un commentaire qui parlait de son usage pour ssh. Plus généralement c’est la pratique du "j’ajoute une couche ça peut pas faire de mal" qui n’est pas une vérité générale.
Si c’est le problème une bonne configuration du firewall (sans autre chose) résous presque systématiquement les choses.
Si le problème c’est le log, alors ce qu’il faut corriger c’est probablement les logs, par exemple il est possible de définir des conditions sur les logs de nginx. Si c’est pour de la sécurité un WAF comme OWASP ModSecurity élèvera de beaucoup le niveau de sécurité.
fail2ban c’est un hack qui se veut flexible, mais je n’ai pas encore trouvé de situation où configurer correctement les composants déjà existant ne fait pas largement mieux avec moins de ressources.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Fail2ban ne remplace pas une bonne sécurité
Posté par Psychofox (Mastodon) . Évalué à 8 (+5/-0). Dernière modification le 23 juin 2025 à 19:33.
Fail2ban est pratique pour un hobbyiste qui justement n'est pas forcément un ingénieur système. Il existe parce que justement les configs par défaut peuvent ėtre très verbeuse et très généralistes.
Ça peut aussi avoir du sens de vouloir logger des erreurs http mais de filtrer ce qui est généré par des botnets. Accessoirement si je n'ai pas wordpress mais que des bots cherchent à accéder à un wp-login.php sur mon serveur web, je ne veux pas juste supprimer les logs vers wp-login.php, je ne veux tout simplement plus que cette ip touche à mon infra. Il y a plusieurs manière de le faire, mais fail2ban c'est juste un apt install sur le petit vpn que Manon ou Nathan Michu vient de commander pour y installer yunohost pour que leurs parents soient libérés en attendant qu'ils aient leur certification DevSecOps une fois qu'ils auront terminé leurs études.
[^] # Re: Fail2ban ne remplace pas une bonne sécurité
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Un WAF fera ça de manière bien plus rigoureuse parce qu’il va permettre de blacklist tout un tas de tentatives d’injection de code par exemple.
Ce n’est qu’une question de packaging et la manière de présenter fail2ban comme l’état de l’art n’aide pas à pousser des solutions plus efficaces en presque tout point.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Fail2ban ne remplace pas une bonne sécurité
Posté par Psychofox (Mastodon) . Évalué à 5 (+2/-0).
Merci je sais ce qu'est un WAF. Mais comme son nom l'indique, un Web Application Firewall n'est pas généraliste comme l'est fail2ban.
ModSecurity ne va pas sécuriser ton serveur imap et toutes les solutions les plus complètes que j'ai utilisé s'installent en amont du flux des connections sur ton réseau sur une machine dédiée, on est très loin du cas de figure "petit vps unique ouvert au web".
[^] # Re: Fail2ban ne remplace pas une bonne sécurité
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Tu va passer au crible tous les protocoles comme ça ? Tu aura toujours les même limitations, tu n’es pas au bon endroit pour gérer ce que tu souhaite. En IMAP tu peut tenter plusieurs login sur la même connexion TCP et fail2ban ne sera pas en mesure de cut la connexion déjà établi. Bien sûr tu peut configurer ton serveur pour limiter le nombre de tentatives et bien sûr il faut loguer chaque tentatives et limiter la durée de la connexion non authentifiée (même non idle). Bref il faut prendre le temps de regarder sérieusement les protocoles et la configuration de chaque protocole et fail2ban est une option parmi d’autres. Mais si l’ensemble serveur applicatif/fail2ban ne sont pas correctement adaptés (en fonction de chaque protocole) il ne sécurise pas forcément grand chose.
Je ne comprends pas l’argument ? Les solutions les plus complètes auquel j’ai eu accès avait des firewall sur des machines dédiées, c’est une raison pour ne pas en configurer sur un VPS ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Fail2ban ne remplace pas une bonne sécurité
Posté par Psychofox (Mastodon) . Évalué à 5 (+3/-1).
oui depuis le début je dis que c'est un outil unique qui peut être utile pour n protocoles.
D'où l'intérêt dans le cadre serveur unique / autohébergement où les utilisateurs ne sont pas forcément des spécialistes de chaque composant.
Non mais ça ne se met pas en place aussi simplement.
Après tu peut controller à troller pendant des heures, ce n'est pas parce que l'état de l'art dans un environnement professionnel est différent qu'un outil ne peut pas être avoir un intérêt pour des plus petits environnement. Un peu de pragmatisme ne fait pas de mal.
[^] # Re: Fail2ban ne remplace pas une bonne sécurité
Posté par barmic 🦦 . Évalué à 1 (+1/-2).
C’est ce que je réfute, il ne sert à rien pour ssh, il est très limité pour http, il faut faire extrêmement attention avec avec IMAP,…
Et donc c’est bien de se dire de le mettre face à un ssh où il ne sert à rien par exemple ?
J’explique à la fois que d’autres solutions ne sont pas nécessairement plus complexe et que s’assurer que fail2ban est pertinent n’est pas si trivial.
On est pas sur du pragmatisme. On dit joyeusement qu’une solution ferait tout toute seule alors que pour ssh c’est plus simple de configurer correctement son serveur, que pour http la protection qu’il offre est parcellaire et que pour imap ce n’est pas aussi simple.
Si tu considère que c’est troller de dire ça tu va me voir troller longtemps. Le fait que ce soit un VPS n’y change rien. C’est comme si tu disais que pour un serveur perso franchement mettre du TLS c’est chiant c’est un truc de pro.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Fail2ban ne remplace pas une bonne sécurité
Posté par Pol' uX (site web personnel) . Évalué à 6 (+4/-0).
Je ne suis pas sûr de comprendre où tu veux en venir, puisque fail2ban est parfaitement pratique pour un ingénieur système qui souhaiterait que toute ip cherchant à accéder à un wp-login.php ne puisse plus toucher à l'infra.
Adhérer à l'April, ça vous tente ?
# protection par fail2ban
Posté par err404 (site web personnel) . Évalué à 5 (+4/-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é à 4 (+2/-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
[^] # Re: protection par fail2ban
Posté par err404 (site web personnel) . Évalué à 4 (+3/-0).
en effet, je n'ai pas encore testé webdav et autre.
par contre quand j'ai (en erreur 400):
ça veut dire quoi?
en tout cas ça n'a rien à faire chez moi
[^] # Re: protection par fail2ban
Posté par Voltairine . Évalué à 3 (+2/-1).
La requête envoyée ressemble au début d'une transaction TLS.
Il est possible que ce soit une mauvaise configuration sur ton système qui laisse les clients faire des requêtes HTTPS en HTTP (par exemple un routeur ou un proxy qui redirige mal les requêtes).
[^] # Re: protection par fail2ban
Posté par Andre Rodier (site web personnel) . Évalué à 5 (+3/-0).
Possible, mais il a raison de bloquer. C'est bloqué pour moi aussi.
Source: https://www.joshwieder.net/2015/11/an-explanation-of-webserver-logs-that.html
[^] # Re: protection par fail2ban
Posté par Voltairine . Évalué à 1 (+1/-2).
Ah ? Des bots cherchent à vérifier la présence d'une faille corrigée depuis plus de 10 ans ? De toute façon utiliser SSLv3 en 2025 relève aussi d'une grossière erreur de configuration.
Encore un fois avant de bloquer les requêtes pour la moindre ligne de log que l'on ne comprend pas mieux vaut vérifier sa configuration.
# Retour d'expérience
Posté par Zatalyz (site web personnel) . Évalué à 6 (+4/-0).
Déjà, merci pour le partage.
J'ai toujours galéré avec Fail2ban… pas la configuration de base, qui se met en place assez facilement et est efficace, mais l'ajout de regex m'a souvent donné des résultats foireux. Je ne suis pas très bonne en regex, et Failban imbrique des trucs dans certains filtres par défaut si bien que je m'y perds complètement. Malgré tout, ça filtre quand même tout une base et c'est utile.
J'ai découvert Reaction en alternative, ou plutôt dans mon cas précis, en complément… Avec Reaction, ajouter des motifs pour bannir m'a été carrément plus simple, par contre le logiciel étant jeune, il ne couvre pas autant de cas que Fail2ban dans ses exemples. Ce qui demande de "traduire" les règles fail2ban qui me sont utiles dans la syntaxe de Reaction. C'est faisable, c'est sur ma todolist, mais ce n'est pas encore fait pour tout. Avoir Reaction et Fail2ban en même temps, c'est redondant, hein. Mais je bénéficie d'un côté de l'énorme base de filtre de Fail2ban, et quand je détecte un comportement foireux, j'ajoute mes règles sur Reaction plus facilement. À terme je compte utiliser uniquement Reaction, qui est merveilleusement versatile :)
Dans mon cas c'est surtout avec Postfix que c'est devenu vital. Il y a des domaines/des types de demandes en particulier qui sont liés à des pratiques foireuses, dès que ça arrive dans les logs, je bannis. Je ne fais pas dans la dentelle, mais jusque là ça ne semble avoir touché aucun utilisateur légitime.
Un bon logiciel en complément est Logwatch. Cela peut aider à voir quand de nouvelles attaques apparaissent, qui ne sont pas assez filtrées. Logwatch ne fait rien en lui même, c'est juste un outil d'analyse des logs, mais il prémâche bien le travail.
Là où je cherche encore le bon outil, c'est quand il y a plusieurs ip qui se succèdent, toutes avec un comportement problématique. Elles ne déclenchent pas les bans aussi vite, et ne sont pas forcément sur un comportement à bannir à la première occurrence. Quand on commence à analyser, elles sont généralement sur une même plage d'ipv4, venant sans doute de fermes de serveurs ; d'ailleurs quand je piste un peu, je tombe souvent sur des datacenters dans un coin du monde ou l'autre. Je n'ai pas trop de scrupule à bannir des plages d'ip mais je n'ai pas encore trouvé un outil qui permette d'analyser les ip bannies et d'en déduire la plage à bannir au besoin. Il y a quelques outils qui partagent des listes d'ip à bannir, mais je n'ai pas envie de faire confiance à autrui sur qui/quoi bannir, je préfère gérer ça avec mes propres politiques. Jusqu'ici, ce n'est pas trop un problème non plus. J'ai eu droit à un SYN flood qui utilisait ce genre de tactique, mais le SYN flood se combat autrement (ça reste une bonne galère). Dans le cas des DOS sur forge, bannir grâce aux "honeypot" a aussi suffit pour le moment. En gros il y a une adresse qu'ils vont demander et qu'aucun humain ne demande dans notre cas, dès qu'elle passe dans les logs, l'ip est bannie un bon moment. Ce n'est qu'un pansement léger qui ne fonctionnera pas éternellement et surtout qui est possible parce qu'on a peu de traffic, mais il faut que je monte en compétence et que je trouve du temps pour faire mieux (comme mettre Anubis ou équivalent en place).
Par rapport à ta configuration, c'est assez bien vu de filtrer sur les codes. Mais pourquoi sur 301 et 302 ? Et j'aurais tendance à spécifier un retry un peu plus élevé sur les 4* ; un utilisateur humain peut faire une coquille assez facilement et se retrouver au moins sur une 404.
Si tu arrive à quelque chose avec les regex de Fail2ban, tu peux essayer d'adapter ce genre de filtre : https://reaction.ppom.me/filters/web-crawlers.html, évidement si tu n'as pas de pages qui correspond aux motifs. Là, bannir à la première occurence n'est pas un souci, puisqu'il n'y a aucune raison pour un utilisateur légitime de chercher ces adresses.
Tu peux mettre l'ip de ton routeur en allow liste (ignoreip = 192.168.1.1) ; cependant, si elle se retrouve bannie, c'est sans doute que son adresse transite au mauvais endroit, ce qui est peut-être lié à ta config nginx. Tu parle de reverse proxy, c'est peut-être là. Quand tu fais une recherche dans les logs sur l'ip, tu trouve les lignes qui ont déclenché son bannissement ? J'ai passé du temps de mon côté à comprendre que quand j'avais un proxy, les services derrière récupéraient l'adresse du proxy et non du visiteur initial, à moins de mettre la bonne configuration dans nginx… je ne sais pas si c'est ça, là, mais c'est une piste.
[^] # Re: Retour d'expérience
Posté par err404 (site web personnel) . Évalué à 3 (+2/-0).
merci pour Réaction, je vais voir ça.
je filtre sur les 301 et 302 parce que comme j'ai un yunohost, un requette qui n'a pas la bonne url va avoir une redirection vers le portail yunohost
seul le code retour 400 donne un ban immédiat (et de longue durée), pour les autres code de retour il faut quand même pas mal insister avant de se faire bannir.
pour les erreur 404 c'est du genre:
(il y a du 400 dans le tas)
un utilisateur légitime qui se trompe il est redirigé vers le portail yunohost ou vers la page d'accueil du service web (code 301 et 302) et il chargera donc la page normalement (code 200)
[^] # Re: Retour d'expérience
Posté par Tony Flow . Évalué à 4 (+3/-0).
C'est délicat d'agir sur du 404 car ce n'est pas forcément la faute du visiteur !
Par exemple des personnes peuvent avoir suivi des liens obsolètes, trouvés depuis des sites externes…
Et même avec le critère de répétition ce n'est pas évident, par exemple :
- un site web a dans sa charte graphique un picto (affiché sur toutes les pages, par ex dans le footer)
- un jour quelqu'un édite le site et sans faire attention supprime/déplace/renomme ce fichier image
- alors chaque page visitée va générer une erreur 404 en essayant d'afficher ce picto manquant
- en plus ça peut durer longtemps comme ça, sans que personne ne remarque et remonte l'absence du picto
Je suis toujours très prudent avec les faux-positifs (comme avec les règles antispams) qui peuvent être très facheux ou gacher l'utilité de la protection, surtout dès qu'il s'agit de services accessibles au public.
Dans le cas présent, je vais préférer utiliser des règles plus précises sur des URL vraiment douteuses.
Par exemple sur les requêtes qui tentent de trouver des fichiers sensibles (
.htpasswd,.env,auth.json…) je configure mon serveur web pour les bloquer (accès interdit 403) et je rajoute un fail2ban sur les accès interdits à répétition (histoire de limiter le bruit dans mes logs web, réduire la charge du serveur et empêcher d'autres tentatives d'attaque peut-être moins infructueuses).[^] # Re: Retour d'expérience
Posté par Tony Flow . Évalué à 3 (+2/-0).
Et là vous allez me parler des fermes de bots et que ça sert à rien puisqu'ils changent d'IP…
Alors oui et non : certes on en là, mais pas toujours ! Je vois encore beaucoup d'attaques très bêtes et méchantes, qui ne s'embarrassent pas à être subtiles (pas de temporisation, pas d'IP multiples), donc on va au moins être efficace sur ces cas là.
Ensuite on peut être plus dur sur le délai du ban et la taille de la fenêtre de répétition. Je ne saurais pas dire si ces vains ou pas, je me dis naïvement que les IP ne sont pas non plus infinies… Alors même si elles changent on doit finir par les retrouver !
Sinon je ne vois qu'une solution face aux attaques subtiles qui ne font par exemple qu'une tentative par IP par heure voire jour : la mutualisation des bans. Donc devoir faire appel à un service qui recense toutes les IP bannies… j'avoue ne pas avoir cherché plus que ça ce que donne de telles RBL, j'ai encore du mal à confier aveuglément de telles décisions de blocage à des services tiers, qui pourraient être parfois trop sévères (encore mon soucis d'éviter les faux-positifs, avec une sensation de perte de contrôle).
Quand il ne s'agit pas d'un simple serveur, mais qu'on gère une infra exposant de multiples services, je trouve intéressant de pouvoir au moins mutualiser tous nos bans. Mais à ma connaissance fail2ban ne permet pas ce fonctionnement collaboratifs entre plusieurs serveurs… Par contre comme on peut faire ses propres filtres et actions, je suppose qu'on peut se bricoler un truc dans le genre…
Mais la bricole ça va 5mn, je n'ai plus 20 ans et je préfère du standard et du maintenable, surtout si ça concerne la sécurité de toute mon infra ! Et puis je me souviens avoir lu la news sur reaction qui m'avait intéressé, surtout la fin qui évoquait une version 2 avec fonctionnement en grappe !
Du coup j'en suis resté là, en me disant que le jour où je voudrais améliorer mes fail2ban il faudra surtout que j'aille voir si reaction existe toujours et a évolué en ce sens (encore un truc qui encombre ma TODO list ')
[^] # Re: Retour d'expérience
Posté par Walter . Évalué à 3 (+2/-0). Dernière modification le 22 juin 2025 à 08:25.
Une solution pour centraliser les blocages :
- Tu fais un service web qui enregistre les ip que tu lui donnes
- Tu utilises fail2ban/reaction pour publier l'ip vers le service web
- Tu publies cette liste d'ip
- Tu fais un script pour ton firewall pour qu'il bloque cette liste d'ip
[^] # Re: Retour d'expérience
Posté par ppom . Évalué à 7 (+6/-0).
Le fonctionnement en grappe pour reaction est toujours prévu !
J'ai même reçu une subvention de NLnet pour pouvoir l'implémenter.
J'espère pouvoir proposer ça début 2026 🗓️
[^] # Re: Retour d'expérience
Posté par Tony Flow . Évalué à 6 (+5/-0).
Enfin un autre concept que je trouve intéressant (simple et efficace) dans cette volonté de détecter des attaques au milieu d'un flot de requêtes légitimes : le pot de miel. Je vais prendre un exemple, qui n'est pas purement du honeypot, mais cela m'a fait réfléchir sur la tactique à adopter…
J'ai donc dû me pencher sur la protection de sites WordPress, avec beaucoup de tentatives de connexions par brute-force, soit via le
wp-login.phpou aussi lexmlrpc.php. Si j'ai bien compris ce dernier permet d'effectuer des actions d'admin externe (en particulier créer des posts depuis d'autres sites ou outils desktop sans doute), donc généralement je sais qu'il n'est pas utilisé légitimement.Au début j'avais pour habitude de le supprimer (une porte d'entrée inutile, autant la dégager), mais :
- le fichier peut facilement réapparaitre suite à des mises à jour, sans qu'on pense à le retirer à nouveau
- les attaques deviennent des 404 moins identifiables et l'attaquant n'insiste pas
Du coup j'ai préféré laisser le fichier en place, mais en ajoutant une mini extension custom pour le hooker :
- je commence par alimenter un fichier de log
- et puis quelque soit la demande réelle, je retourne une réponse bidon (l'air de rien) et exit !
Comme ça je rends le script inoffensif, mais sans faire fuir les attaquants et sans me priver d'alimenter ma liste d'IP à bannir (avec bien sûr un filtre fail2ban sur le fichier de log généré).
Voilà mes pistes de reflexions… si vous avez des remarques ou d'autres solutions n'hésitez pas ;)
[^] # Re: Retour d'expérience
Posté par ppom . Évalué à 4 (+3/-0).
Une autre idée de honeypot que j'ai mais que je n'ai pas encore mise en place, c'est de rajouter une entrée comme ça dans le robots.txt d'un site :
User-agent: *
Disallow: /forbidden-if-you-go-there-youll-be-banned.html
Puis de bannir les agents qui essaient de s'y connecter.
Je ne sais pas à quel point les outils de détection de failles etc. lisent le robots.txt, mais ça ne peut pas faire de mal je suppose !
Une autre version plus bourrine serait d'ajouter un lien similaire mais invisible dans le pied de page des sites web, avec un titre du style "Ne cliquez pas sur ce lien, ou l'accès au site vous sera coupé" pour les personnes utilisant un lecteur d'écran.
Les scrapers légitimes comme ceux des indexeurs de moteur de recherche devraient l'éviter, tant que le lien est interdit dans le robots.txt.
[^] # Re: Retour d'expérience
Posté par Zatalyz (site web personnel) . Évalué à 4 (+2/-0).
Cette proposition est assez fun, facile à mettre en place et sans doute bien efficace sur tous les bots malpolis. Cela peut aussi rediriger vers du Iocaïne, suivant comment on veut s'amuser. J'adore !
[^] # Re: Retour d'expérience
Posté par Psychofox (Mastodon) . Évalué à 9 (+6/-0). Dernière modification le 23 juin 2025 à 07:45.
Tu peux aussi configurer ton serveur web pour servir une bombe zip à ceux qui cherchent à accéder à un wp-login.php.
Ça va probablement faire planter tous les appareils IoT et ordis mal sécurisés intégrés à des bot nets et peut-être motiver leurs propriétaires à les débrancher pour de bon.
[^] # Re: Retour d'expérience
Posté par Voltairine . Évalué à 3 (+1/-0).
Avec Postfix il vaut mieux utiliser postscreen ou postgrey pour filtrer le plus tôt possible les clients non légitimes.
De manière générale il est préférable de filtrer en amont(*), dès la tentative de connexion en se basant sur des liste noires / blanches fiables par exemple, plutôt qu'après coup.
[^] # Re: Retour d'expérience
Posté par eric gerbier (site web personnel) . Évalué à 1 (+0/-0).
Dans la panoplie des outils disponibles, il y a aussi crowdsec (https://www.crowdsec.net/).
Son avantage par rapport à fail2ban est la mutualisation des ip des attaquants : un bot qui a déjà attaqué des machines sera bloqué avant d’accéder au service.
[^] # Re: Retour d'expérience
Posté par ppom . Évalué à 6 (+5/-0).
Merci Zataliz de citer Reaction ! Ici sa mainteneuse. J'ai prévu d'ajouter bientôt (disons d'ici septembre, j'espère) un mécanisme qui permette de détecter des trucs louches sur des ranges d'IP. Avec comme objectif de pouvoir ban des IPv4/24 par exemple, et aussi des IPv6/64 : bannir une IPv6 n'est pas une mesure efficace, vu le stock disponible.
Hors-sujet : je remarque sur les serveurs que j'administre qu'il y a très peu d'attaques via IPv6, et ça m'étonne beaucoup, vu le potentiel pour passer à travers les mailles. À ma connaissance, fail2ban ne permet pas non plus de bannir un range IPv6/64.
[^] # Re: Retour d'expérience
Posté par Voltairine . Évalué à 4 (+2/-0).
Bannir des plages entières d'IP c'est le plus sûr moyen empêcher des utilisateurs légitimes d'accèder aux services.
Cela n'a rien d'étonnant. C'est tout à fait logique vu d'une part le temps et la difficulté nécessaire pour trouver les services en écoute en IPv6, d'autre part tous les réseaux ne sont pas en IPv6.
C'est même une bonne manière d'éviter d'avoir des logs qui se remplissement inutilement de tentatives vouées à l'échec d'avoir un service (SSH par exemple) uniquement accessible en IPv6 si c'est possible.
[^] # Re: Retour d'expérience
Posté par Zatalyz (site web personnel) . Évalué à 3 (+2/-1).
Ça dépend un peu de comment et sur quoi tu bannis, non ?
Bannir sur la localisation des ip (genre : bannir tous les USA), c'est sûr que c'est pas forcément idéal. Encore que, si tu as un petit site franco-français (petit trafic, sur un sujet limité), il est peu probable qu'un utilisateur légitime d'un pays lointain passe là par hasard. Mais là dessus, je suis d'accord : je n'aime pas bannir aussi largement, parce qu'on ne sais jamais, parce que les ip sont réattribuées, parce qu'on peut utiliser un vpn pour naviguer, parce que bannir un pays ça reste du racisme primaire, etc.
Par contre quand tu as un rang d'ip qui a de nombreuses occurrences qui t'ont posé souci, je ne vois pas trop le souci à bannir ce qui ressemble très fortement à un acteur dont soit le réseau est infecté, soit est volontairement malveillant. L'idée n'étant pas non plus de bannir éternellement (les ip seront sans doute réattribuées à un moment), ni de bannir trop largement. Mais je suis curieuse : dans ce genre de cas précis, tu vois des usages légitimes qui pourraient être touchés par effet de bord, et qui sont statistiquement suffisament signifiants pour être pris en compte ?
[^] # Re: Retour d'expérience
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6 (+4/-1).
c'est là aussi un avantage des solutions de type fail2ban: le banissement est temporaire, quelques secondes au début puis ça augmente si l'adresse ip (ou le range) en question insiste. Mais ça finit toujours par expirer.
Donc dans les cas "normaux" (pas quelqu'un de déterminé à faire un ddos ou à rentrer à tout prix sur un serveur spécifique), ça va décourager l'attaquant, mais le blocage pour les victimes collatérales ne devrait pas durer trop longtemps.
En tout cas sur mon serveur j'ai plutôt des attaquants opportunistes: qui essaient de rentrer sur tous les serveurs qui exposent du ssh, qui cherchent des wordpress mal configurés, des caméras ip non sécurisées, et des robots de scrapping qui ne respectent pas le robots.txt. Souvent dans ces cas, un ban temporaire suffit à les convaincre qu'il n'y a plus rien à cette adresse.
[^] # Re: Retour d'expérience
Posté par Voltairine . Évalué à 1 (+0/-1).
Tu fait comme tu veux sur ta machine où le blog de tonton Pierrot est auto-hébergé, cela n'aura effectivement pas de conséquences visibles.
Par contre si tu es prestataire pour des services professionnels tu ne peux absolument pas te permettre de bloquer des plages entières d'adresses IP, même temporairement.
[^] # Re: Retour d'expérience
Posté par Zatalyz (site web personnel) . Évalué à 6 (+4/-0).
Ho, ça fait envie, ça. Je suis curieuse de voir comment tu vas aborder le truc. Je me creuse la tête depuis un moment, j'ai quelques idées mais c'est tellement flou que je n'ai encore rien fait. Déjà rien que de détecter proprement les comportements problématiques liés à un range est pas forcément simple… et ensuite éviter d'avoir des faux positifs et de bannir trop largement des utilisateurs légitimes.
Ça fait vraiment plaisir de voir comme Reaction évolue. Encore merci pour ton super logiciel, qui devient de plus en plus génial. Ouais, je suis fan, j'assume :P
# nginx / json / systemd / nftables
Posté par Andre Rodier (site web personnel) . Évalué à 4 (+2/-0).
[^] # Re: nginx / json / systemd / nftables
Posté par Andre Rodier (site web personnel) . Évalué à 3 (+1/-0).
Si quelqu'un peut corriger la mise en page, merci :-)
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.