Je t'en félicite (premier dégré !)
Moi, je m'y perds.
existe-t-il une bdd pour les ban en cours, pour les réappliquer en cas de redémarrage du service ?
Comme a dit Zatalyz, yep, il y en a une ! Pour la petite histoire, elle fonctionne un peu comme celle de Redis : C'est juste un log (dans un format binaire) des matches et des actions exécutées. Il est réécrit périodiquement pour ne pas dépasser les quelques Mo, en ne gardant que les logs encore d'actualité.
même genre de question pour les ban issue du bannissement fait avec recidive sur fail2ban, qui j'imagine serais fait avec un autre stream avec ta solution
Actuellement, il y aurait besoin de faire :
- soit un second filter avec les mêmes regexes sur le même stream (un peu dommage car ça testera plusieurs fois la même regex, ça pourrait être plus opti)
- soit un stream qui lit les logs de reaction pour voir les bans, et qui ferait des bans plus longs quand il voit plusieurs fois une IP se faire ban (ce qui est un peu crado, et qui nécessite d'avoir le loglevel à INFO au minimum).
En fait j'ai pas encore implémenté de feature de ce type parce que je ne vois pas comment écrire ça de manière élégante dans la configuration. Si vous avez des idées de ce côté, ça m'intéresse vraiment.
le fait d'avoir aucun module pour Apache m'avais refroidi
La configuration d'Apache est assez versatile, et ses logs aussi il me semble. Même chose pour NGINX, comme les logs sont très configurables, peuvent changer selon les distros, le module risque d'être inadapté.
C'est aussi à cause de ce genre de problématiques que je n'ai pas envie de maintenir une configuration officielle des services, mais plutôt d'avoir un wiki qui recense des configurations et des bonnes pratiques.
[^] # Re: Nftables à la place de iptables ?
Posté par ppom . En réponse à la dépêche reaction, remplaçant de fail2ban. Évalué à 3.
cf mes autres réponses à ce sujet !
Je t'en félicite (premier dégré !)
Moi, je m'y perds.
Comme a dit Zatalyz, yep, il y en a une ! Pour la petite histoire, elle fonctionne un peu comme celle de Redis : C'est juste un log (dans un format binaire) des matches et des actions exécutées. Il est réécrit périodiquement pour ne pas dépasser les quelques Mo, en ne gardant que les logs encore d'actualité.
Actuellement, il y aurait besoin de faire :
- soit un second filter avec les mêmes regexes sur le même stream (un peu dommage car ça testera plusieurs fois la même regex, ça pourrait être plus opti)
- soit un stream qui lit les logs de reaction pour voir les bans, et qui ferait des bans plus longs quand il voit plusieurs fois une IP se faire ban (ce qui est un peu crado, et qui nécessite d'avoir le loglevel à INFO au minimum).
En fait j'ai pas encore implémenté de feature de ce type parce que je ne vois pas comment écrire ça de manière élégante dans la configuration. Si vous avez des idées de ce côté, ça m'intéresse vraiment.
La configuration d'Apache est assez versatile, et ses logs aussi il me semble. Même chose pour NGINX, comme les logs sont très configurables, peuvent changer selon les distros, le module risque d'être inadapté.
C'est aussi à cause de ce genre de problématiques que je n'ai pas envie de maintenir une configuration officielle des services, mais plutôt d'avoir un wiki qui recense des configurations et des bonnes pratiques.