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
|
Список | 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 по дате отправления: