Re: Failed Login Attempts parameter

Поиск
Список
Период
Сортировка
От Craig James
Тема Re: Failed Login Attempts parameter
Дата
Msg-id CAFwQ8reC+efJpQMhOB0n-BM1LJZy9=X4fgXTG44AUbbtgiubQA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Failed Login Attempts parameter  (Lukasz Brodziak <lukasz.brodziak@gmail.com>)
Ответы Re: Failed Login Attempts parameter
Список pgsql-admin


On Thu, Nov 15, 2012 at 1:32 AM, Lukasz Brodziak <lukasz.brodziak@gmail.com> wrote:
2012/11/15 Craig Ringer <craig@2ndquadrant.com>
> Another option would be to monitor syslog or the csvlog and lock the
> user out by changing their password or revoking CONNECT rights if they
> trip the threshold. It wouldn't be as responsive to high-rate brute
> forcing attempts but your IDS should be handing those already.
>
> --
>  Craig Ringer                   http://www.2ndQuadrant.com/
>  PostgreSQL Development, 24x7 Support, Training & Services
>

I wouldn't go with password change approach, at least not
automatically...

Or never.  Locking users out invites denial-of-service attacks.  All you have to do is figure out someone's username and you can lock them out of the system by deliberately failing login.

A far better approach is an escalating delay. Check the number of failed login attempts N and delay (for example) N^2 seconds before responding again.  Legitimate users are mildly inconvenienced, and hackers are severely hampered.

Craig

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

Предыдущее
От: Ravi Kumar
Дата:
Сообщение: How to restore backup
Следующее
От: Ronit Allen
Дата:
Сообщение: Re: Date range for pg_stat_all_tables?