search for: persourcepenalties

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

...lly, lock out valid users (especially in attack scenarios) > I'm somewhat hesitant to deploy in production without understanding > this mechanism and testing results in a little more detail if > available. I suggest reading the documentation then: https://man.openbsd.org/sshd_config.5#PerSourcePenalties > overflow:mode > Controls how the server behaves when max-sources4 or max-sources6 > is exceeded. There are two operating modes: deny-all, which > denies all incoming connections other than those exempted via > PerSourcePenaltyExemptList until a penalty expires, and per...

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

On Tue, 18 Jun 2024, Joseph S. Testa II wrote: > 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? 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.

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

On 6/17/2024 22:46, Damien Miller wrote: > This release contains mostly bugfixes. > > New features > ------------ > > * sshd(8): add the ability to penalise client addresses that, for > various reasons, do not successfully complete authentication. > sshd(8) will now identify situations where the session did not > authenticate as expected. These

...eph S. Testa II wrote: > > > 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? > > 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) Ju...

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

...* all: as mentioned above, the DSA signature algorithm is now disabled at compile time. * sshd(8): the server will now block client addresses that repeatedly fail authentication, repeatedly connect without ever completing authentication or that crash the server. See the discussion of PerSourcePenalties below for more information. Operators of servers that accept connections from many users, or servers that accept connections from addresses behind NAT or proxies may need to consider these settings. * sshd(8): the server has been split into a listener binary, sshd(8), and a per-sessio...