An Analysis of the DHEat DoS Against SSH in Cloud Environments

Joseph S. Testa II jtesta at positronsecurity.com
Wed Jun 19 10:02:19 AEST 2024


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



More information about the openssh-unix-dev mailing list