From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | 成之焕 <zhcheng(at)ceresdata(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: contrib: auth_delay module |
Date: | 2022-11-18 07:13:01 |
Message-ID: | 20221118071301.d3m4s3s7x33f6q5i@jrouhaud |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Nov 17, 2022 at 05:37:51PM -0500, Tom Lane wrote:
> =?UTF-8?B?5oiQ5LmL54SV?= <zhcheng(at)ceresdata(dot)com> writes:
> > The attached patch is a contrib module to set login restrictions on users with
> > too many authentication failure. The administrator could manage several GUC
> > parameters to control the login restrictions which are listed below.
> > - set the wait time when password authentication fails.
> > - allow the wait time grows when users of the same IP consecutively logon failed.
> > - set the maximum authentication failure number from the same user. The system
> > will prevent a user who gets too many authentication failures from entering the
> > database.
>
> I'm not yet forming an opinion on whether this is useful enough
> to accept.
I'm not sure that doing that on the backend side is really a great idea, an
attacker will still be able to exhaust available connection slots.
If your instance is reachable from some untrusted network (which already sounds
scary), it's much easier to simply configure something like fail2ban to provide
the same feature in a more efficient way. You can even block access to other
services too while at it.
Note that there's also an extension to log failed connection attempts on an
alternate file with a fixed simple format if you're worried about your regular
logs are too verbose.
From | Date | Subject | |
---|---|---|---|
Next Message | John Naylor | 2022-11-18 07:48:49 | Re: [PoC] Improve dead tuple storage for lazy vacuum |
Previous Message | Peter Smith | 2022-11-18 07:03:20 | Re: Perform streaming logical transactions by background workers and parallel apply |