Re: Failed Login Attempts parameter
| От | Lukasz Brodziak |
|---|---|
| Тема | Re: Failed Login Attempts parameter |
| Дата | |
| Msg-id | CAGWYGjXvgiCJGZbjadzkTj-TuFLD=izSQe3ehuMAgpjOfntWYg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Failed Login Attempts parameter (Craig Ringer <craig@2ndQuadrant.com>) |
| Ответы |
Re: Failed Login Attempts parameter
|
| Список | pgsql-admin |
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 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"
В списке pgsql-admin по дате отправления: