Je comprends. C’est en effet intéressant quand tu gères une ferme de serveurs.
Avec Pyruse, il suffirait de créer un gestionnaire de compteurs alternatif adossé à une base de données (copier-coller de l’existant, avec juste un backend différent), puis d’implémenter les actions triviales +/−/reset.
La base de données pourrait être un PostgreSQL/MySQL... pour une grosse installation, ou peut-être un fichier SQLite sur partage réseau (quid des accès concurrents ?)...
Une autre solution, peut-être plus proche de ton idée, serait d’avoir un petit dæmon qui écoute en IP-Multicast : lorsqu’il reçoit une notification d’attaque, il la logue dans systemd. La conf. peut alors donner à cette « attaque » autant de poids qu’une véritable attaque locale. Et bien sûr, il y aurait une action à développer qui diffuse en IP-Multicast les attaques locales.
[^] # Re: Message
Posté par Yves (site web personnel) . En réponse à la dépêche Pyruse 1.0 : pour remplacer Fail2ban et autres « scruteurs » de journaux sur un GNU/Linux moderne. Évalué à 3.
Je comprends. C’est en effet intéressant quand tu gères une ferme de serveurs.
Avec Pyruse, il suffirait de créer un gestionnaire de compteurs alternatif adossé à une base de données (copier-coller de l’existant, avec juste un backend différent), puis d’implémenter les actions triviales +/−/reset.
La base de données pourrait être un PostgreSQL/MySQL... pour une grosse installation, ou peut-être un fichier SQLite sur partage réseau (quid des accès concurrents ?)...
Une autre solution, peut-être plus proche de ton idée, serait d’avoir un petit dæmon qui écoute en IP-Multicast : lorsqu’il reçoit une notification d’attaque, il la logue dans systemd. La conf. peut alors donner à cette « attaque » autant de poids qu’une véritable attaque locale. Et bien sûr, il y aurait une action à développer qui diffuse en IP-Multicast les attaques locales.
Bref... C’est possible :-)