Re: [PATCH] Exponential backoff for auth_delay

Hi,

On Wed, Mar 06, 2024 at 09:34:37PM +0100, Tomas Vondra wrote:
> On 3/6/24 19:24, Jacob Champion wrote:
> > On Wed, Mar 6, 2024 at 8:10 AM Nathan Bossart <nathandbossart@gmail.com> wrote:
> >> Assuming you are referring to the case where we run out of free slots in
> >> acr_array, I'm not sure I see that as desirable behavior.  Once you run out
> >> of slots, all failed authentication attempts are now subject to the maximum
> >> delay, which is arguably a denial-of-service scenario, albeit not a
> >> particularly worrisome one.
> > 
> > Maybe I've misunderstood the attack vector, but I thought the point of
> > the feature was to deny service when the server is under attack. If we
> > don't deny service, what does the feature do?

I think there are two attack vectors under discussion:

1. Somebody tries to brute-force a password. The original auth_delay
delays auth for a bit everytime authentication fails. If you configure
the delay to be very small, maybe it does not bother the attacker too
much. If you configure it to be long enough, legitimate users might be
annoyed when typoing their password. The suggested feature tries to help
here by initially delaying authentication just a bit and then gradually
increasing the delay.

2. Somebody tries to denial-of-service a server by exhausting all
(remaining) available connections with failed authentication requests
that are being delayed. For this attack, the suggested feature is
hurting more than doing good as it potentially keeps a failed
authentication attempt's connection hanging around longer than before
and makes it easier to denial-of-service a server in this way.

In order to at least make case 2 not worse for exponential backoff, we
could maybe disable it (and just wait for auth_delay.milliseconds) once
MAX_CONN_RECORDS is full. In addition, maybe MAX_CONN_RECORDS should be
some fraction of max_connections, like 25%?

> > And I may have introduced a red herring in talking about the number of
> > hosts, because an attacker operating from a single host is under no
> > obligation to actually wait for the authentication delay. Once we hit
> > some short timeout, we can safely assume the password is wrong,
> > abandon the request, and open up a new connection.

That is a valid point.

Maybe this could be averted if we either outright deny even a successful
authentication request if the host it originates from has a
max_milliseconds delay on file (i.e. has been trying to brute-force the
password for a while) or at least delay a successful authentication
request for some delay, if the host it originates on has a
max_milliseconds delay on file (assuming it will close the connection
beforehand as it thinks the password guess was wrong)?

> > It seems like the thing limiting our attack is the number of
> > connection slots, not MAX_CONN_RECORDS. Am I missing something
> > crucial?
> 
> Doesn't this mean this approach (as implemented) doesn't actually work
> as a protection against this sort of DoS?
> 
> If I'm an attacker, and I can just keep opening new connections for each
> auth request, am I even subject to any auth delay?

Yeah, but see above.

> ISTM the problem lies in the fact that we apply the delay only *after*
> the failed auth attempt. Which makes sense, because until now we didn't
> have any state with information for new connections. But with the new
> acr_array, we could check that first, and do the delay before trying to
> athenticate, no?

I don't think we have a hook for that yet, do we?


Michael