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@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
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@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev