Re: contrib: auth_delay module

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: contrib: auth_delay module
Дата
Msg-id AANLkTikw=YPZjjjODypZZ=SwW4Q7NtjJwj_Gx=5dz8B2@mail.gmail.com
обсуждение исходный текст
Ответ на Re: contrib: auth_delay module  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: contrib: auth_delay module  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Thu, Nov 4, 2010 at 6:35 AM, Stephen Frost <sfrost@snowman.net> wrote:
> * Jan Urbański (wulczer@wulczer.org) wrote:
>> On 04/11/10 14:09, Robert Haas wrote:
>> > Hmm, I wonder how useful this is given that restriction.
>>
>> As KaiGai mentined, it's more to make bruteforcing difficult (read: tmie
>> consuming), right?
>
> Which it would still do, since the attacker would be bumping up against
> max_connections.  max_connections would be a DOS point, but that's no
> different from today.  Other things could be put in place to address
> that (max # of connections from a given IP or range could be implemented
> using iptables, as an example).
>
> 5 second delay w/ max connections at 100 would mean max of 20 attempts
> per second, no?  That's alot fewer than 100*(however many attempts can
> be done in a second).  Doing a stupid while true; psql -d blah; done
> managed to get 50 successful ident auths+no-db-found errors done in a
> second on one box here.  5000 >> 20, and I wasn't even trying.

OK.  I was just asking.  I don't object to it if people think it's
useful, especially if they are looking at it as "I would actually use
this on my system" rather than "I can imagine a hypothetical person
using this".

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


В списке pgsql-hackers по дате отправления:

Предыдущее
От: KaiGai Kohei
Дата:
Сообщение: Re: contrib: auth_delay module
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Alter column to type serial