Fail2ban

Le
andre_debian
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é
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
andre_debian
Le #26380051
Bonjour,

J'avais lancé un help sur ce sujet et modifié jail.conf et jail.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@
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é
Philippe Gras
Le #26380052
Le 1 déc. 2015 à 14:17, 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@


Cette adresse IP est-elle rapportée dans Logwatch d'un jour à l'autre ?

La période de ban peut être augmentée (> 1 mois c'est bien ;-))

Sinon, les requêtes peuvent avoir été envoyées en même temps, et en

masse, c'est une technique utilisée pour passer les filtres fail2ban.

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é

Bernard Schoenacker
Le #26380053
Le Tue, 1 Dec 2015 14:17:43 +0100,
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@
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é




bonjour,


serait il possible de comparer avec cet exemple :

http://wiki.dovecot.org/HowTo/Fail2Ban

ensuite, serait il possible de donner la version de dovecot installée ?


et de lire ceci : /usr/share/doc/fail2ban/run-rootless.txt



slt
bernard
Bernard Schoenacker
Le #26380054
Le Tue, 1 Dec 2015 14:43:12 +0100,
Bernard Schoenacker
Le Tue, 1 Dec 2015 14:17:43 +0100,
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@ >
> 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é
>

bonjour,


serait il possible de comparer avec cet exemple :

http://wiki.dovecot.org/HowTo/Fail2Ban

ensuite, serait il possible de donner la version de dovecot
installée ?


et de lire ceci : /usr/share/doc/fail2ban/run-rootless.txt



slt
bernard




bonjour,

j'ai oublié un lien :

http://www.fail2ban.org/wiki/index.php/Talk:Dovecot

slt
bernard
andre_debian
Le #26380058
On Tuesday 01 December 2015 14:28:18 Philippe Gras wrote:
Le 1 déc. 2015 à 14:17, a écrit :
> 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@ > 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 confi gs.
> (je l'avais bien relancé).

Cette adresse IP est-elle rapportée dans Logwatch d'un jour à l'autre ? :



Les IP intrusives changent d'un jour à l'autre.

La période de ban peut être augmentée (> 1 mois c'est bien) :



Quelle est la ligne à ajouter/ configurer dans les fichiers jail.conf
et .local ?

Sinon, les requêtes peuvent avoir été envoyées en même temps, e t en
masse, c'est une technique utilisée pour passer les filtres fail2ban :



Comment contourner la technique des ? :
"requêtes envoyées en même temps et en masse".

André
Philippe Gras
Le #26380059
Le 1 déc. 2015 à 15:56, a écrit :

On Tuesday 01 December 2015 14:28:18 Philippe Gras wrote:
Le 1 déc. 2015 à 14:17, a écrit :
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@ 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é).





Cette adresse IP est-elle rapportée dans Logwatch d'un jour à l'autre ? :



Les IP intrusives changent d'un jour à l'autre.



Bon, ben alors c'est normal. Quand tu auras banni toutes les IP du pirate ça
va se tasser, mais ça prend évidemment plusieurs jours


La période de ban peut être augmentée (> 1 mois c'est bien) :



Quelle est la ligne à ajouter/ configurer dans les fichiers jail.conf
et .local ?



bantime = nombre de secondes en nombre entier

Sinon, les requêtes peuvent avoir été envoyées en même temps, et en
masse, c'est une technique utilisée pour passer les filtres fail2ban :



Comment contourner la technique des ? :
"requêtes envoyées en même temps et en masse".



À ma connaissance ce n'est pas possible. Par contre tu peux filtrer le nombre
de connections simultanées sur ton serveur ou avec iptables.

André


Jean-Jacques Doti
Le #26380073
Le 01/12/2015 14:17, 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@
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@ 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
Philippe Gras
Le #26380071
Le 1 déc. 2015 à 17:40, Jean-Jacques Doti
Le 01/12/2015 14:17, 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@
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@ 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.
Jean-Jacques Doti
Le #26380072
Le 01/12/2015 17:50, Philippe Gras a écrit :
Le 1 déc. 2015 à 17:40, Jean-Jacques Doti
Le 01/12/2015 14:17, 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@
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@ 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…
Philippe Gras
Le #26380078
Le 1 déc. 2015 à 17:53, Jean-Jacques Doti
Le 01/12/2015 17:50, Philippe Gras a écrit :
Le 1 déc. 2015 à 17:40, Jean-Jacques Doti
Le 01/12/2015 14:17, 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@
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@ 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 !=
Publicité
Poster une réponse
Anonyme