In the upcoming v9.8 release notes I see "the server will now block client addresses that repeatedly fail authentication, repeatedly connect without ever completing authentication or that crash the server." Has this new PerSourcePenalties config directive been tested against the DHEat attack? - Joe On Thu, 2024-04-25 at 18:09 -0400, Joseph S. Testa II wrote: > A few days ago, I published an article analyzing the susceptibility > of > the DHEat denial-of-service vulnerability against default OpenSSH > settings in cloud environments. I thought those on this list might > be > interested: > https://www.positronsecurity.com/blog/2024-04-23-an-analysis-of-dheat-dos-against-ssh-in-cloud-environments/ > > A short summary: the default MaxStartup setting is fully ineffective > in > fixing the problem in low-latency network conditions; it is very easy > to force a target to hit 100% CPU utilization in that case. > Furthermore, the PerSourceMaxStartups setting is only effective when > set to 1, which would only allow one unauthenticated connection at a > time from any given source. This works poorly in use cases where a > burst of new connects is normal. Hence, connection throttling at the > kernel level seems a bit better to use in the general case (for > example, allowing up to 10 connections every 10 seconds from a single > source; this would block the denial-of-service condition while also > allowing small, legitimate bursts of connections). > > Also interesting is how little traffic (~15KB/s) can cause idle time > across multiple vCPUs to drop to zero. And how relatively easy it is > to flood a compute-optimized AWS instance with 32 vCPUs (!). > > - Joe > -- Joseph S. Testa II Founder & Principal Security Consultant Positron Security _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
