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 articleOpenSSH 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.
Related
RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
A vulnerability in OpenSSH's server on glibc-based Linux systems (CVE-2024-6387) allows remote code execution. Exploiting this flaw requires precise timing. The advisory discusses exploitation details, success rates, and contacting developers for related issues.
OpenSSH Race condition resulting in potential remote code execution
OpenSSH 9.8, released on July 1, 2024, addresses critical security issues like ObscureKeystrokeTiming vulnerabilities in sshd(8) and ssh(1), plans to deprecate DSA support, and introduces penalties for failed authentications. Various improvements included.
Remote Unauthenticated Code Execution in OpenSSH Server
Qualys found regreSSHion, a critical RCE flaw in OpenSSH on glibc-based Linux systems. Over 14 million servers are at risk, with potential root access. Qualys created an exploit but delays release for patching.
The Wild West of Proof of Concept Exploit Code (PoC)
CVE-2024-6387 is a serious unauthenticated remote code execution vulnerability in OpenSSH, with complex exploitation requiring knowledge of system architecture. The exploit code contains malicious elements, emphasizing risks of untrusted code.
macOS Sequoia makes it harder to run not notarized or signed apps
macOS Sequoia enhances security by restricting unsigned or unnotarized applications, removing the Control-click bypass option, and requiring users to adjust settings to allow such software execution.
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?
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...
ie Single Packet Authorization
Wrapping your ssh with wireguard (because wireguard doesn't respond without a full key) doesn't feel too good.
Related
RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
A vulnerability in OpenSSH's server on glibc-based Linux systems (CVE-2024-6387) allows remote code execution. Exploiting this flaw requires precise timing. The advisory discusses exploitation details, success rates, and contacting developers for related issues.
OpenSSH Race condition resulting in potential remote code execution
OpenSSH 9.8, released on July 1, 2024, addresses critical security issues like ObscureKeystrokeTiming vulnerabilities in sshd(8) and ssh(1), plans to deprecate DSA support, and introduces penalties for failed authentications. Various improvements included.
Remote Unauthenticated Code Execution in OpenSSH Server
Qualys found regreSSHion, a critical RCE flaw in OpenSSH on glibc-based Linux systems. Over 14 million servers are at risk, with potential root access. Qualys created an exploit but delays release for patching.
The Wild West of Proof of Concept Exploit Code (PoC)
CVE-2024-6387 is a serious unauthenticated remote code execution vulnerability in OpenSSH, with complex exploitation requiring knowledge of system architecture. The exploit code contains malicious elements, emphasizing risks of untrusted code.
macOS Sequoia makes it harder to run not notarized or signed apps
macOS Sequoia enhances security by restricting unsigned or unnotarized applications, removing the Control-click bypass option, and requiring users to adjust settings to allow such software execution.