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.
# Retour d'expérience
Posté par Zatalyz (site web personnel) . En réponse au journal Fail2ban, ajustement des valeurs par defaut. Évalué à 6.
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.