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…
