search for: dheat

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...

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...

...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 t...

...I modified the logging in sshd.c:627 to always use SYSLOG_LEVEL_DEBUG1 instead of SYSLOG_LEVEL_INFO. Re-running the above test resulted in 73% average idle time and 8KB of log growth. Lastly, from an m7i.2xlarge source EC2 instance in AWS, I targeted an m7i.large instance using "ssh-audit --dheat=4:diffie-hellman-group18- sha512:4 target_host". In my original research article, this caused the average idle time to drop to 0.01%; against openssh-SNAP- 20240628.tar.gz with the log level in sshd.c:627 changed to DEBUG1, the idle time was observed to be 84%. My conclusion is that the defa...

...ming 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? Not explicitly but those attacks would trigger the "grace-exceeded" path, so they should be detectable and penalisable. -d

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...

...tes 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? > > Not explicitly but those attacks would trigger the "grace-exceeded" > path, so they should be detectable and penalisable. > > -d real world example (current snapshot of portable on linux v. dheater) Jun 19 09:09:47 server sshd-session[157401]: Connection res...

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 countermea...

On Tue, 25 Jun 2024, Joseph S. Testa II wrote: >the way down to 6%! Additionally, I noticed that the systemd-journal You should test without that thing as well. It?s reportedly a known bottleneck (someone on, I think, IRC said that regarding a different problem some days ago, incidentally). Just use a real syslogd (inetutils-syslogd is nice, for example, and rsyslogd and syslog-ng both have

On Wed, 2024-06-26 at 02:58 +0200, Thorsten Glaser wrote: > On Tue, 25 Jun 2024, Joseph S. Testa II wrote: > > > the way down to 6%! Additionally, I noticed that the systemd- > > journal > > You should test without that thing as well. It?s reportedly a > known bottleneck (someone on, I think, IRC said that regarding > a different problem some days ago,

On Tue, 25 Jun 2024, Joseph S. Testa II wrote: >I'm primarily interested in the performance of the default case, since >the overwhelming majority of sysadmins don't modify any options in sshd >nor syslog. If they get under attack, they?d better do. And if you?re ignoring a known bottleneck, the results will probably not be very useful? besides, not everyone is systemd-infested.

On Wed, 2024-06-26 at 04:32 +0200, Thorsten Glaser wrote: > If they get under attack, they?d better do. And if you?re ignoring > a known bottleneck, the results will probably not be very useful? > besides, not everyone is systemd-infested. The primary responsibility falls on system designers to choose reasonable default settings.

On 6/26/24 7:56 AM, Joseph S. Testa II wrote: > On Wed, 2024-06-26 at 04:32 +0200, Thorsten Glaser wrote: >> If they get under attack, they?d better do. And if you?re ignoring >> a known bottleneck, the results will probably not be very useful? >> besides, not everyone is systemd-infested. > > > The primary responsibility falls on system designers to choose >

On Thu, 27 Jun 2024, Chris Rapier wrote: > I think it's really important to get this right. The problem, from my Yes, but if the reason behaviour under DoS is that logging is too slow and/or uses too much CPU, the fix is not to remove logging in the default configuration. bye, //mirabilos -- Infrastrukturexperte ? Qvest Digital AG Am Dickobskreuz 10, D-53121 Bonn ?