Re: Failed Login Attempts in PostgreSQL

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

Me: https://www.hagander.net/

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

Browse pgsql-general by date

  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"