openssh unix dev - Apr 2024 - An Analysis of the DHEat DoS Against SSH in Cloud Environments

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

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