[PATCH] Introduce extra delay before closing unauthenticated sessions

[Thomas De Schampheleire]

Hi Matt,

El dom, 24 ene 2021 a las 14:30, Matt Johnston (<matt at ucc.asn.au>) escribió:
>
> On Wed 20/1/2021, at 8:15 pm, Thomas De Schampheleire <patrickdepinguin at gmail.com> wrote:
> >
> >> # HG changeset patch
> >> Introduce extra delay before closing unauthenticated sessions
> >
> > Any comments on this patch?
> >
>
> Hi Thomas,
>
> Sorry for the delay getting back to you. I've applied the patch, it seems like it could be good as a simple brute force countermeasure. I'm sure a lot of the SSH bots are using varying source IPs from botnets etc, but there doesn't seem much harm in an extra delay.

For batch login attempts from multiple IPs, there are already some
existing options:

/* Specify the number of clients we will allow to be connected but
 * not yet authenticated. After this limit, connections are rejected */
/* The first setting is per-IP, to avoid denial of service */
#define MAX_UNAUTH_PER_IP 5

/* And then a global limit to avoid chewing memory if connections
 * come from many IPs */
#define MAX_UNAUTH_CLIENTS 30

So per IP, you have only 5 simultaneous attempts. Globally there is a
max of 30, meaning 6 clients can attempt 5 simultaneous attempts.
With the new extra delay, this means that these 30 connection slots
will be held for 30 seconds, which should reduce the effectiveness of
an attack greatly.
It does mean that legitimate attempts may also be blocked for a while,
but I think this basically already happens today although that block
is shorter.
Would you agree?

>
> I'll add an option to disable it at runtime just in case it ends up causing problems (resource usage of waiting connections would be my concern).

Sure, thanks.

Best regards,
Thomas