Re: contrib: auth_delay module

On Sun, Nov 28, 2010 at 3:57 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Sun, Nov 28, 2010 at 5:41 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>> On Sun, Nov 28, 2010 at 5:38 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> On Sat, Nov 27, 2010 at 2:44 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>>
>>>> I haven' t thought of a way to test this, so I guess I'll just ask.
>>>> If the attacking client just waits a few milliseconds for a response
>>>> and then drops the socket, opening a new one, will the server-side
>>>> walking-dead process continue to be charged against max_connections
>>>> until it's sleep expires?
>>>
>>> I'm not sure, either.  I suspect the answer is yes.  I guess you could
>>> test this by writing a loop like this:
>>>
>>> while true; do psql <connection parameters that will fail authentication>; done
>>>
>>> ...and then hitting ^C every few seconds during execution.  After
>>> doing that for a bit, run select * from pg_stat_activity or ps auxww |
>>> grep postgres in another window.
>>
>> Right, I didn't think of using psql, I thought I'd have to wrangle my
>> own socket code.
>>
>> I wrote up a perl script that spawns psql and immediately kills it.  I
>> quickly start getting "psql: FATAL:  sorry, too many clients already"
>> errors.  And that condition doesn't clear until the sleep expires on
>> the earliest ones spawned.
>>
>> So it looks like the max_connections is charged until the auth_delay expires.
>
> Yeah.  Avoiding that would be hard, and it's not clear that there's
> any demand.  The demand for doing this much seems a bit marginal too,
> but there were several people who seemed to think it worth committing,
> so I did.
>

Oh, I wasn't complaining. I think that having max_connections be
charged for the duration even if the socket is dropped is the only
reasonable thing to do, and wanted to verify that it did happen.
Otherwise the module wouldn't do a very good job at its purpose, the
attacker would simply wait a few milliseconds and then assume it got
the wrong password and kill the connection and start new one.
Preventing the brute force password attack by shunting it into a DOS
attack instead seems reasonable.

Cheers,

Jeff