The change is also by putting a delay in the connection close it is going to work against you. Suppose this happens constantly, will you be able to make a valid connection ?
I use a different approach, allow only a fix src ip access and drop any other connection. You can do that with iptables, so dropbear gets only connection request from valid ip's Hans On Tue, Jan 26, 2021 at 11:38 AM Thomas De Schampheleire <patrickdeping...@gmail.com> wrote: > > 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
