Pas plus que ça en ce qui me concerne, car je n’utilise pas fail2ban “en production”.
J’étais déjà conscient de sa sensibilité à la qualité des expressions rationnelles qui filtrent les messages de log, car il y a déjà eu des failles permettant à un attaquant distant de bannir une adresse arbitraire en l’injectant dans le login par exemple.
Ne connaissant pas particulièrement le système de log, je ne savais pas que n’importe quel utilisateur local pouvait envoyer n’importe quoi dans n’importe quel fichier de log.
A mon avis la methode donnée dans le premier lien consistant à modifier les permissions d’exécution de /usr/bin/logger est bidon : un utilisateur peut le recopier dans son home et lui donner les droits qu’il veut, ou bien écrire directement dans /dev/log.
Concernant la seconde, il ne suffit évidemment pas de créer un groupe log, l’affecter à /dev/log et modifier les permissions de ce dernier. Au passage le contenu de /dev est recréé dynamiquement à chaque démarrage, il faut donc s’assurer que cette modification est persistante. Il faut aussi déterminer les processus qui ont besoin d’écrire dans les logs, sous quels utilisateurs système ils tournent et ajouter ceux-ci au groupe log (si c’est root il n’y a rien à faire).
Et je ne suis même pas sûr que ce soit suffisant. Si je reprends l’exemple donné dans le second lien de l’utilisateur malveillant qui pourrait écrire via la fonction openlog()/syslog() de PHP vers le syslog, sous quel utilisateur les scripts PHP sont-ils exécutés ? Si c’est l’utilisateur sous lequel tourne le serveur web (ex: www-data), comme on doit bien lui permettre d’écrire dans les logs alors l’utilisateur le pourra aussi, à moins d’interdire cette fonction PHP ou de faire en sorte que les logs qu’elle génère soient identifiables, par exemple avec un préfixe défini.
