[HS] Totem et Freebox: vous y arrivez?

2015-12-01 Par sujet didier gaumet
Salut,

C'est hors-sujet parce que je n'ai pas eu le problème que sur Debian,
mais bon, histoire de ne pas mourir idiot: arrivez-vous à lire des
enregistrements vidéos faits par une Freebox ou à regarder une chaîne de
télévision Freebox au moyen de Totem?

De mémoire, Totem me demande un greffon H264, j'ai le son mais pas
d'image. En installant toutes les bibliothèques h264&5 qui m'avaient
l'air disponibles ça n'avait rien changé, en installant le greffon
gstreamer pour packagekit pour qu'il télécharge le codec adapté, Totem
n'en trouvait pas...

Ceci sous Wheezy (stable) avec le dépôt deb-multimedia Marillat dans mon
sources.list.

Merci.



Re: [HS] Totem et Freebox: vous y arrivez?

2015-12-01 Par sujet Bernard Schoenacker
Le Tue, 01 Dec 2015 21:05:08 +0100,
didier gaumet  a écrit :

> Salut,
> 
> C'est hors-sujet parce que je n'ai pas eu le problème que sur Debian,
> mais bon, histoire de ne pas mourir idiot: arrivez-vous à lire des
> enregistrements vidéos faits par une Freebox ou à regarder une chaîne
> de télévision Freebox au moyen de Totem?
> 
> De mémoire, Totem me demande un greffon H264, j'ai le son mais pas
> d'image. En installant toutes les bibliothèques h264&5 qui m'avaient
> l'air disponibles ça n'avait rien changé, en installant le greffon
> gstreamer pour packagekit pour qu'il télécharge le codec adapté, Totem
> n'en trouvait pas...
> 
> Ceci sous Wheezy (stable) avec le dépôt deb-multimedia Marillat dans
> mon sources.list.
> 
> Merci.
> 

bonjour,

essayes vlc avec freeplayer ...

https://packages.debian.org/fr/wheezy/freeplayer

rmadison freeplayer

freeplayer | 20070531+dfsg.1-3 | oldoldstable| source, all
freeplayer | 20070531+dfsg.1-3 | oldstable   | source, all
freeplayer | 20070531+dfsg.1-3 | stable  | source, all
freeplayer | 20070531+dfsg.1-3 | stable-kfreebsd | source, all

depuis quelques temps la saveur wheezy est passée en oldstable


pour les dépots oldstable de marillat :

deb http://www.deb-multimedia.org wheezy main
or
deb ftp://ftp.deb-multimedia.org wheezy main
or
deb http://www.deb-multimedia.org oldstable main
or
deb ftp://ftp.deb-multimedia.org oldstable main

origine :  http://www.deb-multimedia.org/


slt
bernard



Re: Fail2ban

2015-12-01 Par sujet Philippe Gras

Le 1 déc. 2015 à 17:40, Jean-Jacques Doti  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@ 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@ 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.



Re: Fail2ban

2015-12-01 Par sujet Philippe Gras

Le 1 déc. 2015 à 17:53, Jean-Jacques Doti  a écrit :

> Le 01/12/2015 17:50, Philippe Gras a écrit :
>> Le 1 déc. 2015 à 17:40, Jean-Jacques Doti  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@ 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@ 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 !


Re: Fail2ban

2015-12-01 Par sujet Jean-Jacques Doti

Le 01/12/2015 17:50, Philippe Gras a écrit :

Le 1 déc. 2015 à 17:40, Jean-Jacques Doti  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@ 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@ 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…





Re: Fail2ban

2015-12-01 Par sujet Philippe Gras

Le 1 déc. 2015 à 18:57, andre_deb...@numericable.fr a écrit :

>> et  en modifiant ou en ajoutant un filtre fail2ban spécifique 
>> (les tentatives d'authentification sont alors toutes loggées, 
>> mais le format est  différent de ce que fail2ban recherche :
> 
>> 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 
> 
> Merci, pas confus mais pas d'infos sur :
> "comment ajouter un filtre fail2ban spécifique" :-)

Ce n'est pas super compliqué, en fait. Il n'existe pas de tuto parce que
chaque nouveau filtre est spécifique à des besoins personnels.

Personnellement, j'ai procédé comme suit.

D'abord, je me suis fait envoyer les bans par mail (une option à ajouter
qui est décrite dans le haut du fichier jail.{conf | local})

J'ai été regarder mes logs litigieux et j'ai créé une regex dessus.

Puis, j'ai mv un filtre lambda.conf en avotboncoeur.conf

J'ai remplacé sa regex par la mienne et je l'ai testée :

/usr/bin/fail2ban-regex /var/log/nginx/monfichier.access.log 
/etc/fail2ban/filter.d/nginx-login.conf

J'y ai été contraint, parce que je n'ai pas trouvé de filtre sympa sur nginx
et j'ai pas mal d'exploits sur Wordpress.

> 
> La crainte est qu'un jour une intrusion découvre
> le mot de passe d'un compte mail.

C'est clair que ça vaut le coup de se creuser la cervelle pour trouver une
+/- bonne solution avec un maximum d'efficacité.

> 
> Bonne  soirée.
> 
> André
> 



Re: Fail2ban

2015-12-01 Par sujet andre_debian
On Tuesday 01 December 2015 17:40:24 Jean-Jacques Doti wrote:
[cut]
> 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  :

Fait.

> et  en modifiant ou en ajoutant un filtre fail2ban spécifique 
> (les tentatives d'authentification sont alors toutes loggées, 
> mais le format est  différent de ce que fail2ban recherche :

> 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 

Merci, pas confus mais pas d'infos sur :
"comment ajouter un filtre fail2ban spécifique" :-)

La crainte est qu'un jour une intrusion découvre
le mot de passe d'un compte mail.

Bonne  soirée.

André



Re: [HS] Totem et Freebox: vous y arrivez?

2015-12-01 Par sujet didier gaumet
oui, toutes mes excuses, je suis bien en stable, donc "jessie" et pas
"wheezy" (la force de l'habitude).

sinon effectivement accéder aux contenus (enregistrements ou chaînes tv)
de la freebox via vlc (pas besoin du freeplayer, il suffit d'explorer le
réseau local dans la "liste de lecture" et le serveur freebox apparaît)
ou mplayer ne me pose pas de problème.

merci pour ta réponse :-) , mais la question reste posée: y en a-t-il
qui accèdent aux contenus freebox via totem?



[Résolu][Montage usb téléphone]Pas accès aux données de la carte SD

2015-12-01 Par sujet Grégory Bulot

Avant de chercher plus loin, il faudrait écarter un point tout bête
mais qui m'a fait galérer un petit moment… Depuis quelques version
d'Android, lorsque l'on branche le téléphone en USB, il est nécessaire
de le déverrouiller pour que les données soit accessible via le
protocole MTP et que le téléphone puisse être monté.



rhaa, c'est évident quand ont sait  merc



[Montage usb téléphone]Pas accès aux données de la carte SD

2015-12-01 Par sujet Grégory Bulot

Le 2015-12-01 11:35, Grégory Bulot a écrit :

Avant de chercher plus loin, il faudrait écarter un point tout bête
mais qui m'a fait galérer un petit moment… Depuis quelques version
d'Android, lorsque l'on branche le téléphone en USB, il est 
nécessaire

de le déverrouiller pour que les données soit accessible via le
protocole MTP et que le téléphone puisse être monté.


En fait pas résolu, je m'étais trompé de téléphone 

toujours pas de volume disponible




--
Cordialement,

--
Grégory Bulot



Re: Fail2ban

2015-12-01 Par sujet Philippe Gras

Le 1 déc. 2015 à 15:56, andre_deb...@numericable.fr a écrit :

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



Nettoyage du spam : novembre 2015

2015-12-01 Par sujet jean-pierre giraud
Bonjour,
Comme nous sommes en décembre, il est désormais possible de
traiter les archives du mois de novembre 2015 des listes francophones.

N'oubliez bien sûr pas d'ajouter votre nom à la liste des relecteurs
pour que nous sachions où nous en sommes.

Détails du processus de nettoyage du spam sur :

https://wiki.debian.org/I18n/FrenchSpamClean



Re: [Montage usb téléphone]Pas accès aux données de la carte SD

2015-12-01 Par sujet steve

Le 01-12-2015, à 11:40:01 +0100, Grégory Bulot a écrit :


En fait pas résolu, je m'étais trompé de téléphone 
 
 Elle est belle celle-là :) 



Re: Fail2ban

2015-12-01 Par sujet andre_debian
On Tuesday 01 December 2015 14:28:18 Philippe Gras wrote:
> Le 1 déc. 2015 à 14:17, andre_deb...@numericable.fr 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@ 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é).

> 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, 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".

André




Re: Fail2ban

2015-12-01 Par sujet andre_debian
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@ 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é
 



Re: Fail2ban

2015-12-01 Par sujet Philippe Gras

Le 1 déc. 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@ rhost=212.83.40.56 : 66 Times"

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é
> 



Re: Fail2ban

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

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



Re: Fail2ban

2015-12-01 Par sujet Bernard Schoenacker
Le Tue, 1 Dec 2015 14:43:12 +0100,
Bernard Schoenacker  a écrit :

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



Fail2ban

2015-12-01 Par sujet 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@ 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é



Re: Fail2ban

2015-12-01 Par sujet Jean-Jacques Doti

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@ 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@ 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