An Analysis of the DHEat DoS Against SSH in Cloud Environments

Steffen Nurpmeso steffen at sdaoden.eu
Wed Jun 26 09:20:24 AEST 2024


Joseph S. Testa II wrote in
 <700cf304a8e24450e5e6e32d7a0020f5516cea3d.camel at positronsecurity.com>:
 |On Wed, 2024-06-19 at 16:11 -0400, Joseph S. Testa II wrote:
 ...
 |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.

You mean without any otherwise assisting firewall settings, and
without "a plan" for log partition spacing and/or log rotation
and/or rotated log storage (partition).
I have not looked at the feature yet, and if it allows "hooks"
that can be used to run shell snippets or what to adjust firewall,
but despite that, how likely is the first condition?
I would *guess* that the new feature is meant as / thought for
being one more tunable tool in the fight against malicious
players that adds "onto existing infrastructure", not as a fully
satisfying standalone does it all thing.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


More information about the openssh-unix-dev mailing list