Le 1 déc. 2015 à 17:53, Jean-Jacques Doti <b...@doti.fr> a écrit :
> Le 01/12/2015 17:50, Philippe Gras a écrit : >> Le 1 déc. 2015 à 17:40, Jean-Jacques Doti <b...@doti.fr> a écrit : >> >>> Le 01/12/2015 14:17, andre_deb...@numericable.fr a écrit : >>>> Bonjour, >>>> >>>> J'avais lancé un help sur ce sujet et modifié >>>> jail.conf et fail.local >>>> >>>> Malgré, j'ai toujours ce type de message dans mon logwatch quotidien, >>>> (tentatives de connexions sur des comptes mail) : >>>> >>>> "authentication failure; logname= uid=0 euid=0 tty=dovecot >>>> ruser=pascal.b@<domain.net> rhost=212.83.40.56 : 66 Times" >>>> >>>> Une personne qui n'est pas le propriétaire du mail, >>>> tente de se connecter 66 fois alors que le "maxretry=3" >>>> >>>> Ici, fail2ban ne joue pas son rôle, il reste insensible à ses configs. >>>> (je l'avais bien relancé). >>>> >>>> André >>>> >>> Salut, >>> >>> En fait, le soucis se situe directement dans la façon dont fail2ban >>> fonctionne. >>> Le principe est que fail2ban scrute des fichiers de logs à la recherche de >>> certaines chaînes de caractères. Pour dovecot, c'est le fichier >>> /var/log/mail.log qui est examiné (cf /etc/fail2ban/jail.conf section >>> [dovecot]). La chaîne "authentication failure" est normalement bien repérée >>> et l'adresse IP du client récupérée (cf >>> /etc/fail2ban/filter.d/dovecot.conf). Cette adresse IP es bloquée (via >>> iptables) si elle apparaît plus d'un certains nombre de fois pendant un >>> certain laps de temps (par défaut 3 apparitions en 600 secondes). >>> Or dovecot a tendance à indiquer les erreurs de connexions ainsi : >>> authentication failure; logname= uid=0 euid=0 tty=dovecot >>> ruser=pascal.b@<domain.net> rhost=212.83.40.56 : 66 Times >>> c'est à dire avec une seule ligne indiquant de nombreux échecs >>> d'authentification (il s'agit peut-être du nombre d'echec au cours d'une >>> même connexion TCP). Du coup, fail2ban n'enregistre, dans ce cas, qu'une >>> seule tentative (une seule ligne) et l'IP du client n'est pas immédiatement >>> bloquée. >>> >>> Je ne vois pas trop comment changer ce comportement facilement. >>> Il doit être possible d'arriver à quelque chose d'accpetable en indiquant >>> "auth_verbose=yes" dans /etc/dovecot/conf.d/10-logging.conf et en modifiant >>> ou en ajoutant un filtre fai2ban spécifique (les tentatives >>> d'authentification sont alors toutes loggées, mais le format est différent >>> de ce que fail2ban recherche en standard avec la configuration Debian). >>> >>> J'espère que je n'ai pas été trop confus dans mes explications et je suis >>> désolé de ne pas pouvoir fournir une solution clé en main… >>> >>> A+ >>> Jean-Jacques >>> >> Ah, ouais :-( C'est pas glop comme fonctionnement ! >> >> Dans ce cas, on peut mettre le 'maxretry' à 0, comme >> >> ça l'IP est bannie après une première série de fails. >> > Oui mais non ! > Tu ne veux pas forcément bannir l'utilisateur qui paramètre sa connexion (sur > une nouvelle machine ou un nouveau smartphone) et qui fait une faute de > frappe lors de la saisie du mot de passe… > > Sans doute, mais tu ne paramètres pas ta connexion tous les jours sur un nouveau bidule… Le cas échéant, il vaut mieux penser à modifier sa règle 5 min. Pas pratique j'en conviens ;-) mais une mauvaise solution est parfois meilleure que pas de solution du tout !
