Bloquer un compte après un certain nombre d'essais d'authentifications ratées.

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Bloquer un compte après un certain nombre d'essais d'authentifications ratées.

Mxher
Bonjour à tous.

Savez-vous s'il existe un moyen d’empêcher l'authentification d'un
utilisateur après un certain nombre d'essais (attaque de type bruteforce) ?

Dans l'idée c'est donc d’empêcher un utilisateur X de se connecter sur
le compte de Y (avec su par exemple) en brute-forçant le mot de passe.
Il faudrait donc automatiquement désactiver le compte de Y pour éviter
cela (et ensuite, en analysant les logs, aller taper sur X mais ça c'est
une autre histoire :).

Avec pam sous Linux je vois comment faire mais je n'ai pour le moment
rien trouvé pour bsdauth.

Merci.


Maxime

NB: je parle bien d'authentifications locales au serveur, bloquer les
IPs sources n'est donc pas possible.

________________________________
French OpenBSD mailing list
[hidden email]
http://www.openbsd-france.org/communaute.php

Reply | Threaded
Open this post in threaded view
|

Re: Bloquer un compte après un certain nombre d'essais d'authentifications ratées.

michael chlon
Bonsoir Maxime,


Peut-être que: fail2ban, répondra à tes attentes.

Rgds,
Michaël Chlon


On 30/11/2013 18:04, Maxime wrote:

> Bonjour à tous.
>
> Savez-vous s'il existe un moyen d’empêcher l'authentification d'un
> utilisateur après un certain nombre d'essais (attaque de type bruteforce) ?
>
> Dans l'idée c'est donc d’empêcher un utilisateur X de se connecter sur
> le compte de Y (avec su par exemple) en brute-forçant le mot de passe.
> Il faudrait donc automatiquement désactiver le compte de Y pour éviter
> cela (et ensuite, en analysant les logs, aller taper sur X mais ça c'est
> une autre histoire :).
>
> Avec pam sous Linux je vois comment faire mais je n'ai pour le moment
> rien trouvé pour bsdauth.
>
> Merci.
>
>
> Maxime
>
> NB: je parle bien d'authentifications locales au serveur, bloquer les
> IPs sources n'est donc pas possible.
>
> ________________________________
> French OpenBSD mailing list
> [hidden email]
> http://www.openbsd-france.org/communaute.php
>


________________________________
French OpenBSD mailing list
[hidden email]
http://www.openbsd-france.org/communaute.php

Reply | Threaded
Open this post in threaded view
|

Re: Bloquer un compte après u n certain nombre d'essais d'authentificatio ns ratées.

Mxher
Salut Michaël.

On Sat, 30 Nov 2013 19:29:05 +0100 Chlon Michaël <[hidden email]>
wrote

> Bonsoir Maxime,
>
>
> Peut-être que: fail2ban, répondra à tes attentes.
>
> Rgds,
> Michaël Chlon
>
>

Oui, je pense devoir tenter de ce coté là.
Je vais quand même tenter ma chance sur la mailing-list EN avant.

Si je trouve quelque chose je posterai probablement mes résultats ici.

Merci.


Maxime

> On 30/11/2013 18:04, Maxime wrote:
> > Bonjour à tous.
> >
> > Savez-vous s'il existe un moyen d’empêcher l'authentification d'un
> > utilisateur après un certain nombre d'essais (attaque de type bruteforce)
?

> >
> > Dans l'idée c'est donc d’empêcher un utilisateur X de se connecter sur
> > le compte de Y (avec su par exemple) en brute-forçant le mot de passe.
> > Il faudrait donc automatiquement désactiver le compte de Y pour éviter
> > cela (et ensuite, en analysant les logs, aller taper sur X mais ça c'est
> > une autre histoire :).
> >
> > Avec pam sous Linux je vois comment faire mais je n'ai pour le moment
> > rien trouvé pour bsdauth.
> >
> > Merci.
> >
> >
> > Maxime
> >
> > NB: je parle bien d'authentifications locales au serveur, bloquer les
> > IPs sources n'est donc pas possible.
> >
> > ________________________________
> > French OpenBSD mailing list
> > [hidden email]
> > http://www.openbsd-france.org/communaute.php
> >



________________________________
French OpenBSD mailing list
[hidden email]
http://www.openbsd-france.org/communaute.php

Reply | Threaded
Open this post in threaded view
|

Re: Bloquer un compte après un certain nombre d'essais d'authentifications ratées.

ilyes aiouaz - gmail
In reply to this post by Mxher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bonjour Maxime,
Voir l'article suivant :

http://www.cyberciti.biz/tips/linux-unix-bsd-openssh-server-best-practices.html

#16: Thwart SSH Crackers (Brute Force Attack)

J’espère que ca t’aidera.

A bientôt,

Le 30/11/2013 18:04, Maxime a écrit :

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSnIrmAAoJEFpXoRH1BIf3mbMP/1XbfY75lCSyRptl+bMPeeGK
at9ifB+bf4HEBzrdpeeMU8ahwV6ZqBN82munv/0Q7c/MPrU+d3ZitB+nhDNCkv6f
gcrgHUXA9SOyVzOanF0r04sK/NIzRSvIJHaXvhKly9Hxyigmt/BR0JiXuJuNaZR2
jIiosweaQA0f2vZ487wyoHkYbq2mm97nKlOmVz2NSIfedh9oVZW1gm92/eNSaZY+
wdhWBYAfnSbOTbzC5cBAnlUHA7D3OXOaV8XLbmHmwyNwxvMBTPFq5PaRt2nVB0FG
FSjGUP0lf/ZsdOLboObj3p6o48+fz0J/klNUwvpt5gYhC8cjIN+gqy9Dkxy1IW+b
0Gv8dDNNlV3KTooi8HXHD9d8GwxdjjwM09nZsTePmsSAPCfmDIotO0MFaIQNGLfv
Hii2KQslR5ZR3i9rlTWHW6x98mrtW3z62P1qpIw42WPAg7BE+KAQoISBW6OmTS4F
ibHe4i0D4r92LgB9tgVeDGjfFAb389KnAPINpmiHX4lEnjCqB5gwleDUMDEmrEub
z9r3oJ/1vXgkvcRlfybmVvYxU16gUKL8aH3padaodYWqH67qtJzGHPhrDZYzht+J
dTy7aJRy9GjyasLb5EeIBi0kn+kyxS0IKnzv5TDpDZ0bF+wRbjBz75vcqKeya0Fo
S6g+zlSPIzYcLRr/zPXv
=ljue
-----END PGP SIGNATURE-----

________________________________
French OpenBSD mailing list
[hidden email]
http://www.openbsd-france.org/communaute.php

Reply | Threaded
Open this post in threaded view
|

Re: Bloquer un compte après u n certain nombre d'essais d'authentificatio ns ratées.

Gilles Cafedjian
In reply to this post by Mxher
 

Le 2013-12-02 12:43, Maxime a écrit :

> Salut Michaël.
>
> On Sat, 30 Nov 2013 19:29:05 +0100 Chlon Michaël <[hidden email]>
> wrote
>
>> Bonsoir Maxime, Peut-être que: fail2ban, répondra à tes attentes. Rgds, Michaël Chlon
>
> Oui, je pense devoir tenter de ce coté là.
> Je vais quand même tenter ma chance sur la mailing-list EN avant.
>
> Si je trouve quelque chose je posterai probablement mes résultats ici.
>
> Merci.
>
> Maxime
> On 30/11/2013 18:04, Maxime wrote: Bonjour à tous. Savez-vous s'il existe un moyen d'empêcher l'authentification d'un utilisateur après un certain nombre d'essais (attaque de type bruteforce)

?

>> Dans l'idée c'est donc d'empêcher un utilisateur X de se connecter sur le compte de Y (avec su par exemple) en brute-forçant le mot de passe. Il faudrait donc automatiquement désactiver le compte de Y pour éviter cela (et ensuite, en analysant les logs, aller taper sur X mais ça c'est une autre histoire :). Avec pam sous Linux je vois comment faire mais je n'ai pour le moment rien trouvé pour bsdauth. Merci. Maxime NB: je parle bien d'authentifications locales au serveur, bloquer les IPs sources n'est donc pas possible. ________________________________ French OpenBSD mailing list [hidden email] http://www.openbsd-france.org/communaute.php [1]

________________________________
French OpenBSD mailing list
[hidden email]
http://www.openbsd-france.org/communaute.php [1]

Bonjour,
Je n'ai pas de réponse à ce que tu veux faire, mais peut être que tu
peut prendre le problème à l'envers : Interdire les utilisateurs de
changer d'utilisateur avec su, et mettre en place une policy avec sudo.
Pour le bruteforce SSH, tu peu le faire tres simplement avec pf par
contre:

http://bsdly.blogspot.fr/2013/10/the-hail-mary-cloud-and-lessons-learned.html

> Traditional Anti-Bruteforce Rules

> Rapid-fire bruteforce attacks are easy to head off. I tend to use OpenBSD on internet facing hosts, so first we present the technique as it has been available in OpenBSD since version 3.5 (released in 2005), where state tracking options are used to set limits we later act on:

> In your /etc/pf.conf, you add a table to store addresses, block access for all traffic coming from members of that table, and finally amend your typical pass rule with some state tracking options. The result looks something like this:

> table <bruteforce> persist

> block quick from <bruteforce>

> pass inet proto tcp to $int_if:network port $tcp_services

> keep state (max-src-conn 100, max-src-conn-rate 15/5,

> overload <bruteforce> flush global)

> Here, max-src-conn is the maximum number of concurrent connections allowed from one host

> max-src-conn-rate is the maximum allowed rate of new connections, here 15 connections per 5 seconds.

> overload <bruteforce> means that any hosts that exceed either of these limits are have their adress added to this table

> and, just for good measure, flush global means that for host that is added to our overload table, we kill all existing connections too.

 

Links:
------
[1] http://www.openbsd-france.org/communaute.php
Reply | Threaded
Open this post in threaded view
|

Re: Bloquer un compte après u n certain nombre d'essais d'authentificatio ns ratées.

ilyes aiouaz - gmail
Est ce que quelqu'un peut si il lui plait m'expliquer la notion de brute
force en local ???

Le 02/12/2013 17:36, Gilles Cafedjian a écrit :

>  
>
> Le 2013-12-02 12:43, Maxime a écrit :
>
>> Salut Michaël.
>>
>> On Sat, 30 Nov 2013 19:29:05 +0100 Chlon Michaël <[hidden email]>
>> wrote
>>
>>> Bonsoir Maxime, Peut-être que: fail2ban, répondra à tes attentes. Rgds, Michaël Chlon
>>
>> Oui, je pense devoir tenter de ce coté là.
>> Je vais quand même tenter ma chance sur la mailing-list EN avant.
>>
>> Si je trouve quelque chose je posterai probablement mes résultats ici.
>>
>> Merci.
>>
>> Maxime
>> On 30/11/2013 18:04, Maxime wrote: Bonjour à tous. Savez-vous s'il existe un moyen d'empêcher l'authentification d'un utilisateur après un certain nombre d'essais (attaque de type bruteforce)
>
> ?
>
>>> Dans l'idée c'est donc d'empêcher un utilisateur X de se connecter sur le compte de Y (avec su par exemple) en brute-forçant le mot de passe. Il faudrait donc automatiquement désactiver le compte de Y pour éviter cela (et ensuite, en analysant les logs, aller taper sur X mais ça c'est une autre histoire :). Avec pam sous Linux je vois comment faire mais je n'ai pour le moment rien trouvé pour bsdauth. Merci. Maxime NB: je parle bien d'authentifications locales au serveur, bloquer les IPs sources n'est donc pas possible. ________________________________ French OpenBSD mailing list [hidden email] http://www.openbsd-france.org/communaute.php [1]
>
> ________________________________
> French OpenBSD mailing list
> [hidden email]
> http://www.openbsd-france.org/communaute.php [1]
>
> Bonjour,
> Je n'ai pas de réponse à ce que tu veux faire, mais peut être que tu
> peut prendre le problème à l'envers : Interdire les utilisateurs de
> changer d'utilisateur avec su, et mettre en place une policy avec sudo.
> Pour le bruteforce SSH, tu peu le faire tres simplement avec pf par
> contre:
>
> http://bsdly.blogspot.fr/2013/10/the-hail-mary-cloud-and-lessons-learned.html
>
>> Traditional Anti-Bruteforce Rules
>
>> Rapid-fire bruteforce attacks are easy to head off. I tend to use OpenBSD on internet facing hosts, so first we present the technique as it has been available in OpenBSD since version 3.5 (released in 2005), where state tracking options are used to set limits we later act on:
>
>> In your /etc/pf.conf, you add a table to store addresses, block access for all traffic coming from members of that table, and finally amend your typical pass rule with some state tracking options. The result looks something like this:
>
>> table <bruteforce> persist
>
>> block quick from <bruteforce>
>
>> pass inet proto tcp to $int_if:network port $tcp_services
>
>> keep state (max-src-conn 100, max-src-conn-rate 15/5,
>
>> overload <bruteforce> flush global)
>
>> Here, max-src-conn is the maximum number of concurrent connections allowed from one host
>
>> max-src-conn-rate is the maximum allowed rate of new connections, here 15 connections per 5 seconds.
>
>> overload <bruteforce> means that any hosts that exceed either of these limits are have their adress added to this table
>
>> and, just for good measure, flush global means that for host that is added to our overload table, we kill all existing connections too.
>
>  
>
> Links:
> ------
> [1] http://www.openbsd-france.org/communaute.php
>

________________________________
French OpenBSD mailing list
[hidden email]
http://www.openbsd-france.org/communaute.php

Reply | Threaded
Open this post in threaded view
|

Re: Bloquer un compte après un certain nombre d'essais d'authentifications ratées.

Txomin Astrain
Bonjour Ilyes,
Pour être bref, ce que j'ai compris de ce sujet : Tu te log avec ssh et
ensuite tu essaies de changer d'utilisateur( avec $su ). Je pense que ce que
Maxime entend par local c'est que le programme est exécuté sur le serveur.
Donc y'a un type qui se log en ssh et depuis sa session lance un bruteforce
sur le mdp d'un utilisateur et tout cela se passe sur le serveur et pas avec
ssh.
J'espère que ca te sera utile.



Est ce que quelqu'un peut si il lui plait m'expliquer la notion de brute
force en local ???

Le 02/12/2013 17:36, Gilles Cafedjian a écrit :

>
>
> Le 2013-12-02 12:43, Maxime a écrit :
>
>> Salut Michaël.
>>
>> On Sat, 30 Nov 2013 19:29:05 +0100 Chlon Michaël
>> <[hidden email]>
>> wrote
>>
>>> Bonsoir Maxime, Peut-être que: fail2ban, répondra à tes attentes. Rgds,
>>> Michaël Chlon
>>
>> Oui, je pense devoir tenter de ce coté là.
>> Je vais quand même tenter ma chance sur la mailing-list EN avant.
>>
>> Si je trouve quelque chose je posterai probablement mes résultats ici.
>>
>> Merci.
>>
>> Maxime
>> On 30/11/2013 18:04, Maxime wrote: Bonjour à tous. Savez-vous s'il existe
>> un moyen d'empêcher l'authentification d'un utilisateur après un certain
>> nombre d'essais (attaque de type bruteforce)
>
> ?
>
>>> Dans l'idée c'est donc d'empêcher un utilisateur X de se connecter sur
>>> le compte de Y (avec su par exemple) en brute-forçant le mot de passe.
>>> Il faudrait donc automatiquement désactiver le compte de Y pour éviter
>>> cela (et ensuite, en analysant les logs, aller taper sur X mais ça c'est
>>> une autre histoire :). Avec pam sous Linux je vois comment faire mais je
>>> n'ai pour le moment rien trouvé pour bsdauth. Merci. Maxime NB: je parle
>>> bien d'authentifications locales au serveur, bloquer les IPs sources
>>> n'est donc pas possible. ________________________________ French OpenBSD
>>> mailing list [hidden email]
>>> http://www.openbsd-france.org/communaute.php [1]
>
> ________________________________
> French OpenBSD mailing list
> [hidden email]
> http://www.openbsd-france.org/communaute.php [1]
>
> Bonjour,
> Je n'ai pas de réponse à ce que tu veux faire, mais peut être que tu
> peut prendre le problème à l'envers : Interdire les utilisateurs de
> changer d'utilisateur avec su, et mettre en place une policy avec sudo.
> Pour le bruteforce SSH, tu peu le faire tres simplement avec pf par
> contre:
>
> http://bsdly.blogspot.fr/2013/10/the-hail-mary-cloud-and-lessons-learned.html
>
>> Traditional Anti-Bruteforce Rules
>
>> Rapid-fire bruteforce attacks are easy to head off. I tend to use OpenBSD
>> on internet facing hosts, so first we present the technique as it has
>> been available in OpenBSD since version 3.5 (released in 2005), where
>> state tracking options are used to set limits we later act on:
>
>> In your /etc/pf.conf, you add a table to store addresses, block access
>> for all traffic coming from members of that table, and finally amend your
>> typical pass rule with some state tracking options. The result looks
>> something like this:
>
>> table <bruteforce> persist
>
>> block quick from <bruteforce>
>
>> pass inet proto tcp to $int_if:network port $tcp_services
>
>> keep state (max-src-conn 100, max-src-conn-rate 15/5,
>
>> overload <bruteforce> flush global)
>
>> Here, max-src-conn is the maximum number of concurrent connections
>> allowed from one host
>
>> max-src-conn-rate is the maximum allowed rate of new connections, here 15
>> connections per 5 seconds.
>
>> overload <bruteforce> means that any hosts that exceed either of these
>> limits are have their adress added to this table
>
>> and, just for good measure, flush global means that for host that is
>> added to our overload table, we kill all existing connections too.
>
>
>
> Links:
> ------
> [1] http://www.openbsd-france.org/communaute.php
>

________________________________
French OpenBSD mailing list
[hidden email]
http://www.openbsd-france.org/communaute.php 


________________________________
French OpenBSD mailing list
[hidden email]
http://www.openbsd-france.org/communaute.php

Reply | Threaded
Open this post in threaded view
|

Re: Bloquer un compte après un certain nombre d'essais d'authentifications ratées.

ilyes aiouaz - gmail
Merci Txomin,
Nous parlons donc d'un brute force ssh, c'est ce que je pensais.

A+


Le 03/12/2013 15:50, Txomin Astrain a écrit :

> Bonjour Ilyes,
> Pour être bref, ce que j'ai compris de ce sujet : Tu te log avec ssh et
> ensuite tu essaies de changer d'utilisateur( avec $su ). Je pense que ce
> que Maxime entend par local c'est que le programme est exécuté sur le
> serveur. Donc y'a un type qui se log en ssh et depuis sa session lance
> un bruteforce sur le mdp d'un utilisateur et tout cela se passe sur le
> serveur et pas avec ssh.
> J'espère que ca te sera utile.
>
>
>
> Est ce que quelqu'un peut si il lui plait m'expliquer la notion de brute
> force en local ???
>
> Le 02/12/2013 17:36, Gilles Cafedjian a écrit :
>>
>>
>> Le 2013-12-02 12:43, Maxime a écrit :
>>
>>> Salut Michaël.
>>>
>>> On Sat, 30 Nov 2013 19:29:05 +0100 Chlon Michaël
>>> <[hidden email]>
>>> wrote
>>>
>>>> Bonsoir Maxime, Peut-être que: fail2ban, répondra à tes attentes.
>>>> Rgds, Michaël Chlon
>>>
>>> Oui, je pense devoir tenter de ce coté là.
>>> Je vais quand même tenter ma chance sur la mailing-list EN avant.
>>>
>>> Si je trouve quelque chose je posterai probablement mes résultats ici.
>>>
>>> Merci.
>>>
>>> Maxime
>>> On 30/11/2013 18:04, Maxime wrote: Bonjour à tous. Savez-vous s'il
>>> existe un moyen d'empêcher l'authentification d'un utilisateur après
>>> un certain nombre d'essais (attaque de type bruteforce)
>>
>> ?
>>
>>>> Dans l'idée c'est donc d'empêcher un utilisateur X de se connecter
>>>> sur le compte de Y (avec su par exemple) en brute-forçant le mot de
>>>> passe. Il faudrait donc automatiquement désactiver le compte de Y
>>>> pour éviter cela (et ensuite, en analysant les logs, aller taper sur
>>>> X mais ça c'est une autre histoire :). Avec pam sous Linux je vois
>>>> comment faire mais je n'ai pour le moment rien trouvé pour bsdauth.
>>>> Merci. Maxime NB: je parle bien d'authentifications locales au
>>>> serveur, bloquer les IPs sources n'est donc pas possible.
>>>> ________________________________ French OpenBSD mailing list
>>>> [hidden email] http://www.openbsd-france.org/communaute.php
>>>> [1]
>>
>> ________________________________
>> French OpenBSD mailing list
>> [hidden email]
>> http://www.openbsd-france.org/communaute.php [1]
>>
>> Bonjour,
>> Je n'ai pas de réponse à ce que tu veux faire, mais peut être que tu
>> peut prendre le problème à l'envers : Interdire les utilisateurs de
>> changer d'utilisateur avec su, et mettre en place une policy avec sudo.
>> Pour le bruteforce SSH, tu peu le faire tres simplement avec pf par
>> contre:
>>
>> http://bsdly.blogspot.fr/2013/10/the-hail-mary-cloud-and-lessons-learned.html
>>
>>
>>> Traditional Anti-Bruteforce Rules
>>
>>> Rapid-fire bruteforce attacks are easy to head off. I tend to use
>>> OpenBSD on internet facing hosts, so first we present the technique
>>> as it has been available in OpenBSD since version 3.5 (released in
>>> 2005), where state tracking options are used to set limits we later
>>> act on:
>>
>>> In your /etc/pf.conf, you add a table to store addresses, block
>>> access for all traffic coming from members of that table, and finally
>>> amend your typical pass rule with some state tracking options. The
>>> result looks something like this:
>>
>>> table <bruteforce> persist
>>
>>> block quick from <bruteforce>
>>
>>> pass inet proto tcp to $int_if:network port $tcp_services
>>
>>> keep state (max-src-conn 100, max-src-conn-rate 15/5,
>>
>>> overload <bruteforce> flush global)
>>
>>> Here, max-src-conn is the maximum number of concurrent connections
>>> allowed from one host
>>
>>> max-src-conn-rate is the maximum allowed rate of new connections,
>>> here 15 connections per 5 seconds.
>>
>>> overload <bruteforce> means that any hosts that exceed either of
>>> these limits are have their adress added to this table
>>
>>> and, just for good measure, flush global means that for host that is
>>> added to our overload table, we kill all existing connections too.
>>
>>
>>
>> Links:
>> ------
>> [1] http://www.openbsd-france.org/communaute.php
>>
>
> ________________________________
> French OpenBSD mailing list
> [hidden email]
> http://www.openbsd-france.org/communaute.php
>
> ________________________________
> French OpenBSD mailing list
> [hidden email]
> http://www.openbsd-france.org/communaute.php
>

________________________________
French OpenBSD mailing list
[hidden email]
http://www.openbsd-france.org/communaute.php

Reply | Threaded
Open this post in threaded view
|

Re: Bloquer un compte après un certain nombre d'essais d'authentifications ratées.

ilyes aiouaz - gmail
Pardon j'écris n'importe quoi, je viens de relire à tète reposée et j'ai
compris le problème.

Le 03/12/2013 17:12, ilyes aiouaz - gmail a écrit :

> Merci Txomin,
> Nous parlons donc d'un brute force ssh, c'est ce que je pensais.
>
> A+
>
>
> Le 03/12/2013 15:50, Txomin Astrain a écrit :
>> Bonjour Ilyes,
>> Pour être bref, ce que j'ai compris de ce sujet : Tu te log avec ssh et
>> ensuite tu essaies de changer d'utilisateur( avec $su ). Je pense que ce
>> que Maxime entend par local c'est que le programme est exécuté sur le
>> serveur. Donc y'a un type qui se log en ssh et depuis sa session lance
>> un bruteforce sur le mdp d'un utilisateur et tout cela se passe sur le
>> serveur et pas avec ssh.
>> J'espère que ca te sera utile.
>>
>>
>>
>> Est ce que quelqu'un peut si il lui plait m'expliquer la notion de brute
>> force en local ???
>>
>> Le 02/12/2013 17:36, Gilles Cafedjian a écrit :
>>>
>>>
>>> Le 2013-12-02 12:43, Maxime a écrit :
>>>
>>>> Salut Michaël.
>>>>
>>>> On Sat, 30 Nov 2013 19:29:05 +0100 Chlon Michaël
>>>> <[hidden email]>
>>>> wrote
>>>>
>>>>> Bonsoir Maxime, Peut-être que: fail2ban, répondra à tes attentes.
>>>>> Rgds, Michaël Chlon
>>>>
>>>> Oui, je pense devoir tenter de ce coté là.
>>>> Je vais quand même tenter ma chance sur la mailing-list EN avant.
>>>>
>>>> Si je trouve quelque chose je posterai probablement mes résultats ici.
>>>>
>>>> Merci.
>>>>
>>>> Maxime
>>>> On 30/11/2013 18:04, Maxime wrote: Bonjour à tous. Savez-vous s'il
>>>> existe un moyen d'empêcher l'authentification d'un utilisateur après
>>>> un certain nombre d'essais (attaque de type bruteforce)
>>>
>>> ?
>>>
>>>>> Dans l'idée c'est donc d'empêcher un utilisateur X de se connecter
>>>>> sur le compte de Y (avec su par exemple) en brute-forçant le mot de
>>>>> passe. Il faudrait donc automatiquement désactiver le compte de Y
>>>>> pour éviter cela (et ensuite, en analysant les logs, aller taper sur
>>>>> X mais ça c'est une autre histoire :). Avec pam sous Linux je vois
>>>>> comment faire mais je n'ai pour le moment rien trouvé pour bsdauth.
>>>>> Merci. Maxime NB: je parle bien d'authentifications locales au
>>>>> serveur, bloquer les IPs sources n'est donc pas possible.
>>>>> ________________________________ French OpenBSD mailing list
>>>>> [hidden email] http://www.openbsd-france.org/communaute.php
>>>>> [1]
>>>
>>> ________________________________
>>> French OpenBSD mailing list
>>> [hidden email]
>>> http://www.openbsd-france.org/communaute.php [1]
>>>
>>> Bonjour,
>>> Je n'ai pas de réponse à ce que tu veux faire, mais peut être que tu
>>> peut prendre le problème à l'envers : Interdire les utilisateurs de
>>> changer d'utilisateur avec su, et mettre en place une policy avec sudo.
>>> Pour le bruteforce SSH, tu peu le faire tres simplement avec pf par
>>> contre:
>>>
>>> http://bsdly.blogspot.fr/2013/10/the-hail-mary-cloud-and-lessons-learned.html
>>>
>>>
>>>> Traditional Anti-Bruteforce Rules
>>>
>>>> Rapid-fire bruteforce attacks are easy to head off. I tend to use
>>>> OpenBSD on internet facing hosts, so first we present the technique
>>>> as it has been available in OpenBSD since version 3.5 (released in
>>>> 2005), where state tracking options are used to set limits we later
>>>> act on:
>>>
>>>> In your /etc/pf.conf, you add a table to store addresses, block
>>>> access for all traffic coming from members of that table, and finally
>>>> amend your typical pass rule with some state tracking options. The
>>>> result looks something like this:
>>>
>>>> table <bruteforce> persist
>>>
>>>> block quick from <bruteforce>
>>>
>>>> pass inet proto tcp to $int_if:network port $tcp_services
>>>
>>>> keep state (max-src-conn 100, max-src-conn-rate 15/5,
>>>
>>>> overload <bruteforce> flush global)
>>>
>>>> Here, max-src-conn is the maximum number of concurrent connections
>>>> allowed from one host
>>>
>>>> max-src-conn-rate is the maximum allowed rate of new connections,
>>>> here 15 connections per 5 seconds.
>>>
>>>> overload <bruteforce> means that any hosts that exceed either of
>>>> these limits are have their adress added to this table
>>>
>>>> and, just for good measure, flush global means that for host that is
>>>> added to our overload table, we kill all existing connections too.
>>>
>>>
>>>
>>> Links:
>>> ------
>>> [1] http://www.openbsd-france.org/communaute.php
>>>
>>
>> ________________________________
>> French OpenBSD mailing list
>> [hidden email]
>> http://www.openbsd-france.org/communaute.php
>>
>> ________________________________
>> French OpenBSD mailing list
>> [hidden email]
>> http://www.openbsd-france.org/communaute.php
>>

________________________________
French OpenBSD mailing list
[hidden email]
http://www.openbsd-france.org/communaute.php

Reply | Threaded
Open this post in threaded view
|

Re: Bloquer un compte après un certain nombre d'essais d'authentificatio ns ratées.

Mxher
In reply to this post by Gilles Cafedjian
Bonjour Gilles,

En fait j'utilise l'authentification bsdauth pour plusieurs services
(dont webmail, pop, imap, smtp) donc l'exemple de "su" était plus un
raccourci qu'autre chose de ma part.
L'idée c'était de vraiment bloquer l'authentification "à la source".

Cependant ton idée est clairement bonne pour tous les services distants.
Surtout combinée à une politique de changement de mots de passe "agressive".

Merci bien.

Maxime


Le 02/12/2013 17:36, Gilles Cafedjian a écrit :

> Bonjour,
> Je n'ai pas de réponse à ce que tu veux faire, mais peut être que tu
> peut prendre le problème à l'envers : Interdire les utilisateurs de
> changer d'utilisateur avec su, et mettre en place une policy avec sudo.
> Pour le bruteforce SSH, tu peu le faire tres simplement avec pf par
> contre:
>
> http://bsdly.blogspot.fr/2013/10/the-hail-mary-cloud-and-lessons-learned.html
>
>> Traditional Anti-Bruteforce Rules
>
>> Rapid-fire bruteforce attacks are easy to head off. I tend to use OpenBSD on internet facing hosts, so first we present the technique as it has been available in OpenBSD since version 3.5 (released in 2005), where state tracking options are used to set limits we later act on:
>
>> In your /etc/pf.conf, you add a table to store addresses, block access for all traffic coming from members of that table, and finally amend your typical pass rule with some state tracking options. The result looks something like this:
>
>> table <bruteforce> persist
>
>> block quick from <bruteforce>
>
>> pass inet proto tcp to $int_if:network port $tcp_services
>
>> keep state (max-src-conn 100, max-src-conn-rate 15/5,
>
>> overload <bruteforce> flush global)
>
>> Here, max-src-conn is the maximum number of concurrent connections allowed from one host
>
>> max-src-conn-rate is the maximum allowed rate of new connections, here 15 connections per 5 seconds.
>
>> overload <bruteforce> means that any hosts that exceed either of these limits are have their adress added to this table
>
>> and, just for good measure, flush global means that for host that is added to our overload table, we kill all existing connections too.
>
>  
>
> Links:
> ------
> [1] http://www.openbsd-france.org/communaute.php
>


________________________________
French OpenBSD mailing list
[hidden email]
http://www.openbsd-france.org/communaute.php

Reply | Threaded
Open this post in threaded view
|

Re: Bloquer un compte après un certain nombre d'essais d'authentifications ratées.

Mxher
In reply to this post by ilyes aiouaz - gmail
Bonjour Ilyes,

Le 02/12/2013 14:28, ilyes aiouaz - gmail a écrit :

> Bonjour Maxime,
> Voir l'article suivant :
>
> http://www.cyberciti.biz/tips/linux-unix-bsd-openssh-server-best-practices.html
>
> #16: Thwart SSH Crackers (Brute Force Attack)
>
> J’espère que ca t’aidera.
>
> A bientôt,
>
> Le 30/11/2013 18:04, Maxime a écrit :
>
>
> ________________________________
> French OpenBSD mailing list
> [hidden email]
> http://www.openbsd-france.org/communaute.php
>

Ce n'est pas directement lié à ma problématique mais il y a quelques
rappels sympa que je n'ai pas encore appliqué (timeout, list
d'utilisateurs, etc) ;)


Maxime

________________________________
French OpenBSD mailing list
[hidden email]
http://www.openbsd-france.org/communaute.php

Reply | Threaded
Open this post in threaded view
|

Re: Bloquer un compte après un certain nombre d'essais d'authentifications ratées.

Samuel TAILLET
Bonsoir,

je viens plutôt du monde du manchot mais as tu regardé du côté de pam avec
le module libcrack et/ou pam_wheel ?
Sinon dans tous les cas tu peux coupler cela à fail2ban.

A++



2013/12/3 Maxime <[hidden email]>

> Bonjour Ilyes,
>
> Le 02/12/2013 14:28, ilyes aiouaz - gmail a écrit :
> > Bonjour Maxime,
> > Voir l'article suivant :
> >
> >
> http://www.cyberciti.biz/tips/linux-unix-bsd-openssh-server-best-practices.html
> >
> > #16: Thwart SSH Crackers (Brute Force Attack)
> >
> > J’espère que ca t’aidera.
> >
> > A bientôt,
> >
> > Le 30/11/2013 18:04, Maxime a écrit :
> >
> >
> > ________________________________
> > French OpenBSD mailing list
> > [hidden email]
> > http://www.openbsd-france.org/communaute.php
> >
>
> Ce n'est pas directement lié à ma problématique mais il y a quelques
> rappels sympa que je n'ai pas encore appliqué (timeout, list
> d'utilisateurs, etc) ;)
>
>
> Maxime
>
> ________________________________
> French OpenBSD mailing list
> [hidden email]
> http://www.openbsd-france.org/communaute.php
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Bloquer un compte après un certain nombre d'essais d'authentifications ratées.

Gil Andre
In reply to this post by Mxher

Bonjour,

On 30 Nov 2013, at 18:04, Maxime <[hidden email]> wrote:

> Bonjour à tous.
>
> Savez-vous s'il existe un moyen d’empêcher l'authentification d'un
> utilisateur après un certain nombre d'essais (attaque de type bruteforce) ?
>
> Dans l'idée c'est donc d’empêcher un utilisateur X de se connecter sur
> le compte de Y (avec su par exemple) en brute-forçant le mot de passe.
> Il faudrait donc automatiquement désactiver le compte de Y pour éviter
> cela (et ensuite, en analysant les logs, aller taper sur X mais ça c'est
> une autre histoire :).
>
> Avec pam sous Linux je vois comment faire mais je n'ai pour le moment
> rien trouvé pour bsdauth.
>
> Merci.

A première vue, rien de bien difficile : il suffit d’écrire un petit script
qui passe régulièrement sur les logs de la machine et verrouille le compte de
X (en mettant son shell sur ‘nologin’) si celui-ci fait un peu trop le malin.

Tous les échecs de su sont enregistrés en /var/log/authlog, sous la forme :

Dec  3 23:41:08 minus su: BAD SU alice to bob on /dev/ttyp2
Dec  3 23:41:19 minus last message repeated 2 times

Dans l’exemple ci-dessus, alice a essayé 3 fois de suite de se connecter en
tant que bob, sans succès.

Il est donc tout à fait possible de faire un grep -i bad.su sur le fichier
de log, suivi d’un chsh pour bloquer le premier compte au bout d’un certain
nombre de tentatives - le tout en vérifiant, par exemple, que ‘’alice’’ ne
fait partie des administrateurs (ou de toute autre white-list possible).

J’avais écrit, pour le manchot, un petit script qui faisait grosso-modo
la même chose, mais pour bloquer des IP qui faisait du brute-force sur du
vsftpd. L’adapter pour bloquer ce genre d’attaques locales sur du poisson
qui pique ne devrait pas demander trop de temps.

Maintenant, il existe peut-être déjà une solution avec des outils plus
propres et plus sophistiqués qu’un simple script. Si quelqu’un les
connaît, je suis preneur !

— Gil.


________________________________
French OpenBSD mailing list
[hidden email]
http://www.openbsd-france.org/communaute.php

Reply | Threaded
Open this post in threaded view
|

Re: Bloquer un compte après un certain nombre d'essais d'authentifications ratées.

Samuel TAILLET
Bonjour,

De ma fenêtre c'est exactement ce que fait fail2ban.

A++


2013/12/3 Gil André <[hidden email]>

>
> Bonjour,
>
> On 30 Nov 2013, at 18:04, Maxime <[hidden email]> wrote:
>
> > Bonjour à tous.
> >
> > Savez-vous s'il existe un moyen d’empêcher l'authentification d'un
> > utilisateur après un certain nombre d'essais (attaque de type
> bruteforce) ?
> >
> > Dans l'idée c'est donc d’empêcher un utilisateur X de se connecter sur
> > le compte de Y (avec su par exemple) en brute-forçant le mot de passe.
> > Il faudrait donc automatiquement désactiver le compte de Y pour éviter
> > cela (et ensuite, en analysant les logs, aller taper sur X mais ça c'est
> > une autre histoire :).
> >
> > Avec pam sous Linux je vois comment faire mais je n'ai pour le moment
> > rien trouvé pour bsdauth.
> >
> > Merci.
>
> A première vue, rien de bien difficile : il suffit d’écrire un petit script
> qui passe régulièrement sur les logs de la machine et verrouille le compte
> de
> X (en mettant son shell sur ‘nologin’) si celui-ci fait un peu trop le
> malin.
>
> Tous les échecs de su sont enregistrés en /var/log/authlog, sous la forme :
>
> Dec  3 23:41:08 minus su: BAD SU alice to bob on /dev/ttyp2
> Dec  3 23:41:19 minus last message repeated 2 times
>
> Dans l’exemple ci-dessus, alice a essayé 3 fois de suite de se connecter en
> tant que bob, sans succès.
>
> Il est donc tout à fait possible de faire un grep -i bad.su sur le fichier
> de log, suivi d’un chsh pour bloquer le premier compte au bout d’un certain
> nombre de tentatives - le tout en vérifiant, par exemple, que ‘’alice’’ ne
> fait partie des administrateurs (ou de toute autre white-list possible).
>
> J’avais écrit, pour le manchot, un petit script qui faisait grosso-modo
> la même chose, mais pour bloquer des IP qui faisait du brute-force sur du
> vsftpd. L’adapter pour bloquer ce genre d’attaques locales sur du poisson
> qui pique ne devrait pas demander trop de temps.
>
> Maintenant, il existe peut-être déjà une solution avec des outils plus
> propres et plus sophistiqués qu’un simple script. Si quelqu’un les
> connaît, je suis preneur !
>
> — Gil.
>
>
> ________________________________
> French OpenBSD mailing list
> [hidden email]
> http://www.openbsd-france.org/communaute.php
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Bloquer un compte après un certain nombre d'essais d'authentifications ratées.

Gil Andre
Bonsoir,

On 04 Dec 2013, at 18:18, Ml Alasta <[hidden email]> wrote:

> Bonjour,
>
> De ma fenêtre c'est exactement ce que fait fail2ban.
>
> A++

Mais est-ce que fail2ban est capable de travailler uniquement en local ?

Je pensais que sa concentration était surtout les connexions à distance ?
(ssh, ftp, etc…)

Et, après un petit coup de Google, je constate que j’avais tort :

<< Generally Fail2Ban then used to update firewall rules to reject the
IP addresses for a specified amount of time, although any arbitrary
other action (e.g. sending an email, or ejecting CD-ROM tray) could
also be configured. >>

On en apprends tous les jours !   ;-)

— Gil.


________________________________
French OpenBSD mailing list
[hidden email]
http://www.openbsd-france.org/communaute.php

Reply | Threaded
Open this post in threaded view
|

Re: Bloquer un compte après un certain nombre d'essais d'authentifications ratées.

Samuel TAILLET
Bonjour,

Dans les grandes lignes il est beaucoup utiliser pour protéger des serveurs
sur le réseau, mais c'est en fin de compte un parser de log via des
patterns et ensuite tu lui appliques une action genre une règle iptables,
un mail, un script .... c'est un vrai couteau Suisse, perso en plus de
d'actions iptables j'avais un script qui loggué dans une base mysql pour
faire des stats et graph.

A++


2013/12/4 Gil André <[hidden email]>

> Bonsoir,
>
> On 04 Dec 2013, at 18:18, Ml Alasta <[hidden email]> wrote:
>
> > Bonjour,
> >
> > De ma fenêtre c'est exactement ce que fait fail2ban.
> >
> > A++
>
> Mais est-ce que fail2ban est capable de travailler uniquement en local ?
>
> Je pensais que sa concentration était surtout les connexions à distance ?
> (ssh, ftp, etc…)
>
> Et, après un petit coup de Google, je constate que j’avais tort :
>
> << Generally Fail2Ban then used to update firewall rules to reject the
> IP addresses for a specified amount of time, although any arbitrary
> other action (e.g. sending an email, or ejecting CD-ROM tray) could
> also be configured. >>
>
> On en apprends tous les jours !   ;-)
>
> — Gil.
>
>
> ________________________________
> French OpenBSD mailing list
> [hidden email]
> http://www.openbsd-france.org/communaute.php
>
>