August 14th, 2024

Some thoughts on OpenSSH 9.8's PerSourcePenalties feature

OpenSSH 9.8 introduces PerSourcePenalties to block malicious SSH sources, allowing targeted blocking. The default penalty duration is one second, minimizing health check disruptions. Users should monitor experiences before adjusting settings.

Read original articleLink Icon
Some thoughts on OpenSSH 9.8's PerSourcePenalties feature

OpenSSH 9.8 introduces a new security feature called PerSourcePenalties, designed to mitigate certain types of attacks by blocking client addresses that repeatedly fail authentication or crash the server. This feature allows for more targeted blocking of malicious SSH sources, as opposed to the broader approach taken by perimeter firewalls, which can only block based on total connection volume. The PerSourcePenalties setting is expected to be included in the next OpenBSD release and subsequently in Fedora. While this feature is beneficial for enhancing security, it may pose challenges for systems that rely on health checks that do not complete authentication, as these could be mistakenly penalized. However, the default penalty duration is only one second, which should minimize disruptions for most health checks. Users are advised to monitor practical experiences with this feature before making adjustments to penalty durations, as the documentation does not clearly outline how penalty times accumulate. Overall, the rollout of OpenSSH 9.8 and its PerSourcePenalties feature is anticipated to provide improved security against SSH attacks while requiring careful consideration of its implications for system health checks.

- OpenSSH 9.8 introduces PerSourcePenalties to block malicious SSH sources.

- The feature allows for targeted blocking rather than broad connection volume-based blocking.

- Default penalty duration is one second, minimizing impact on health checks.

- Users are encouraged to observe practical experiences before adjusting penalty settings.

- The feature will be available in the next OpenBSD release and later in Fedora.

Link Icon 11 comments
By @mdtancsa - 8 months
I suspect the distributed cracking will move to the same pattern as the SMTP/pop3 brute force guys did and use one IP per x+1 seconds where x=the ssh penalty window. We have seen this on our customer facing smtp server where we have hundreds of remote compromised IPs trying each one password per 30-60min. Still, I welcome this change as there are enough single prick attackers out there where this will help cut down on the size of the logs to process / digest.
By @mscdex - 8 months
For what it's worth if you have control over both client and server and don't want to limit access using a strict IP whitelist, an alternative solution that will keep your logs quieter and add additional protection is to use good old fashioned port knocking. knockd on Linux helps with automating this on the server side. Client side you can use anything (although knockd does include a dedicated client) to send your sequence of packets before actually connecting.
By @catkitcourt - 8 months
What’s the difference between fail2ban? Though I feel neither of those two works now.
By @bbayles - 8 months
How about a service that lets bruteforcers "in" after some number of failed attempts, but what they get is just a fake command prompt that accepts all of their commands? I'm sure hackers would eventually adapt, but it would annoy them for a while.
By @djbusby - 8 months
This thread has some mentions of memory-safe issues. Has anyone tried a Go or Rust sshd in their production?

I've had some dreams of a "tighter" sshd for my universe and have toyed (unsuccessfully) with a Go one.

Anyone want to share their experience?

By @kkfx - 8 months
Hem... There is PerSourcePenaltyExemptList to whitelist specific hosts so while I agree it might create a bit more complexity (not much different than handling fail2ban and co) it's not "blocking" like described.
By @jijji - 8 months
I usually just IP whitelist inbound sshd connections and then drop all other packets
By @jms703 - 8 months
If you must expose SSH to the internet, this can be a helpful feature.
By @PreInternet01 - 8 months
PerSourcePenalties-like abuse mitigations are not very subtle, but often very effective.

My own experience with this is not as much with SSH as with SMTP. If your particular IP emits a single non-deliverable message every 30 minutes or so, that's fine.

But: more than a handful of SPF failures for the same sender/recipient combo within 10 minutes or so? Yeah, you're now on the general-deny-list. And persisting even then? Automagically tar-pitted on the firewall, and have fun...

By @mmsc - 8 months
the future is bleak: Attackers can just rent a /48 ipv6 block for a few dollars and have a billion IPs at their disposal.
By @WhatIsDukkha - 8 months
I wish the openssh folks would implement a UDP based "whole auth key or no talk at all" protocol.

ie Single Packet Authorization

Wrapping your ssh with wireguard (because wireguard doesn't respond without a full key) doesn't feel too good.