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

On Wed, 2024-06-19 at 09:19 -0400, chris wrote:
> real world example (current snapshot of portable on linux v. dheater)
Thanks for this.  However, much more extensive testing would be needed
to show it is a complete solution.  In my original research article, I
used CPU idle time as the main metric.  Also, I showed that very low-
latency network links could bypass the existing countermeasures.

I suppose in the next few days, I'll try reproducing my original steps
with the new version and see what happens.

  - Joe

On 6/19/24 4:11 PM, Joseph S. Testa II wrote:
> On Wed, 2024-06-19 at 09:19 -0400, chris wrote:
>> real world example (current snapshot of portable on linux v. dheater)
> 
> Thanks for this.  However, much more extensive testing would be needed
> to show it is a complete solution.  In my original research article, I
> used CPU idle time as the main metric.  Also, I showed that very low-
> latency network links could bypass the existing countermeasures.
> 
> I suppose in the next few days, I'll try reproducing my original steps
> with the new version and see what happens.
You may want to try this on IPv6 where you are frequently changing the 
attackers MAC address. If the IP is constructed with EUI-64 then it 
could start to flood the table used to store the penalized IPs. I'd 
really like to see what that looks like, especially in terms of 
CPU/memory utilization.

On Wed, 2024-06-19 at 16:11 -0400, Joseph S. Testa II
wrote:
> I suppose in the next few days, I'll try reproducing my original
> steps
> with the new version and see what happens.
I managed to do some limited testing with a local VM, and the results
are... interesting.

I installed openssh-SNAP-20240626.tar.gz on a fresh and fully-updated
Ubuntu Linux 24.04 LTS VM with 1 vCPU.  While leaving the default sshd
options unchanged, I was able to reduce idle time to 0.0% using "./ssh-
audit.py --dheat=16 target_host".

Next, I increased the vCPUs to 4.  The same ssh-audit command yielded
54% idle time (averaged over 60 seconds).  That's still a lot of strain
on the target, despite the fact that the logs claim that the
PerSourcePenalties noauth:1 restriction was being triggered.

After that, I tried simply flooding the target with open connections
without performing the DHEat attack ("ssh-audit.py --conn-rate-test=16
target_host").  This caused the 60-second average idle time to come all
the way down to 6%!  Additionally, I noticed that the systemd-journal
process was consuming about 50% CPU and /var/log/auth.log grew by
nearly 14MB.  Aside from CPU exhaustion, some may say that causing log
growth at a rate of 14MB/minute would constitute a disk space
exhaustion problem.

Seems like the new PerSourcePenalties implementation/default settings
still allow a denial-of-service by attackers with low-latency network
connections.

   - Joe