From: | "Wolff, Ken L" <ken(dot)l(dot)wolff(at)lmco(dot)com> |
---|---|
To: | pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Failed Login Attempts in PostgreSQL |
Date: | 2020-11-13 14:44:25 |
Message-ID: | 6a2ead5b51f54d149d4127fe453616d7@lmco.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
You can use fail2ban for example. See for example this thread here https://www.postgresql.org/message-id/flat/61463e206b7c4c0ca17b03a59e890b78%40lmco.com,
and the config on https://github.com/rc9000/postgres-fail2ban-lockout.
(probably needs some small adaptations, but as a base it should work).
--
Magnus Hagander
Work: https://www.redpill-linpro.com/
Having been down this road myself, these are the options I eventually identified. Each obviously has its benefits and drawbacks:
* Change the Postgres source code and deploy a new version. Believe there are examples of how to do this in Git.
* Disable/disallow local accounts and rely on LDAP. Be aware passwords would be passed in clear text across the network unless your DCs require SSL.
* Disable/disallow local accounts and rely on PKI certificates. I don’t know that this would necessarily limit failed login attempts but is definitely much more secure.
* Procure a vendor-supported version of PostgreSQL which offers this functionality.
* Fail2ban, as Magnus observed.
* Leverage something like Splunk monitoring to identify failed logins and then reach back into the database to lock accounts when appropriate.
Hope this is of some help.
Ken
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2020-11-13 14:58:02 | Re: Issue upgrading from 9.5 to 13 with pg_upgrade: "connection to database failed: FATAL: database "template1" does not exist" |
Previous Message | Jeremy Wilson | 2020-11-13 14:32:34 | Issue upgrading from 9.5 to 13 with pg_upgrade: "connection to database failed: FATAL: database "template1" does not exist" |