| From: | Lukasz Brodziak <lukasz(dot)brodziak(at)gmail(dot)com> |
|---|---|
| To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
| Cc: | 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 09:32:21 |
| Message-ID: | CAGWYGjXvgiCJGZbjadzkTj-TuFLD=izSQe3ehuMAgpjOfntWYg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
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 this can be done 'on user's demand' at any point. I
admit that I wasn't specific in my solution with REVOKE as I didn't
say which rights should be revoked I of course mean revoke connect
command as Craig was kind to mention.
Regards
--
Łukasz Brodziak
"Do you bury me when I'm gone
Do you teach me while I'm here
Just as soon I belong
Then it's time I disappear"
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Albe Laurenz | 2012-11-15 09:59:24 | Re: Query Stuck in running server |
| Previous Message | Craig Ringer | 2012-11-15 09:21:47 | Re: Failed Login Attempts parameter |