Hi Matt, El dom, 24 ene 2021 a las 14:30, Matt Johnston (<m...@ucc.asn.au>) escribió: > > On Wed 20/1/2021, at 8:15 pm, Thomas De Schampheleire > <patrickdeping...@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
