From: | Craig James <cjames(at)emolecules(dot)com> |
---|---|
To: | Lukasz Brodziak <lukasz(dot)brodziak(at)gmail(dot)com> |
Cc: | Craig Ringer <craig(at)2ndquadrant(dot)com>, Frank Cavaliero <fcavalie(at)us(dot)ibm(dot)com>, pgsql-admin(at)postgresql(dot)org |
Subject: | Re: Failed Login Attempts parameter |
Date: | 2012-11-15 16:24:30 |
Message-ID: | CAFwQ8reC+efJpQMhOB0n-BM1LJZy9=X4fgXTG44AUbbtgiubQA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Thu, Nov 15, 2012 at 1:32 AM, Lukasz Brodziak
<lukasz(dot)brodziak(at)gmail(dot)com>wrote:
> 2012/11/15 Craig Ringer <craig(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Ronit Allen | 2012-11-15 19:35:04 | Re: Date range for pg_stat_all_tables? |
Previous Message | Ravi Kumar | 2012-11-15 10:18:22 | How to restore backup |