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

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