OpenSSH introduces options to penalize undesirable behavior:
In a recent commit, Damien Miller (djm@) introduced the new sshd(8) configurations options, PerSourcePenalties and PerSourcePenaltyExemptList, to provide a built in facility in sshd(8) itself to penalize undesirable behavior, and to shield specific clients from penalty, respectively.
The commit message reads,
List: openbsd-cvs Subject: CVS: cvs.openbsd.org: src From: Damien Miller <djm () cvs ! openbsd ! org Date: 2024-06-06 17:15:26 CVSROOT: /cvs Module name: src Changes by: djm@cvs.openbsd.org 2024/06/06 11:15:26 Modified files: usr.bin/ssh : misc.c misc.h monitor.c monitor_wrap.c servconf.c servconf.h srclimit.c srclimit.h sshd-session.c sshd.c sshd_config.5 Log message: Add a facility to sshd(8) to penalise particular problematic client behaviours, controlled by two new sshd_config(5) options: PerSourcePenalties and PerSourcePenaltyExemptList.
When PerSourcePenalties are enabled, sshd(8) will monitor the exit status of its child pre-auth session processes. Through the exit status, it can observe situations where the session did not authenticate as expected. These conditions include when the client repeatedly attempted authentication unsucessfully (possibly indicating an attack against one or more accounts, e.g. password guessing), or when client behaviour caused sshd to crash (possibly indicating attempts to exploit sshd). When such a condition is observed, sshd will record a penalty of some duration (e.g. 30 seconds) against the client's address. If this time is above a minimum threshold specified by the PerSourcePenalties, then connections from the client address will be refused (along with any others in the same PerSourceNetBlockSizeCIDR range). Repeated offenses by the same client address will accrue greater penalties, up to a configurable maximum. A PerSourcePenaltyExemptList option allows certain address ranges to be exempt from all penalties. We hope these options will make it significantly more difficult for attackers to find accounts with weak/guessable passwords or exploit bugs in sshd(8) itself. PerSourcePenalties is off by default, but we expect to enable it automatically in the near future.
This new facility comes in addition to the already well known and loved pf.confstate tracking options, and is for now available only in OpenBSD-current, but is almost certainly to be available in the upcoming OpenBSD 7.6 release.
At first we were wondering whether these options would be enabled by default before the new release. We did not have to wait long. This subsequent commit settled the issue:
List: openbsd-cvs Subject: CVS: cvs.openbsd.org: src From: Damien Miller <djm () cvs ! openbsd ! org Date: 2024-06-06 20:25:48 CVSROOT: /cvs Module name: src Changes by: djm@cvs.openbsd.org 2024/06/06 14:25:48 Modified files: usr.bin/ssh : servconf.c Log message: enable PerSourcePenalties by default. ok markus NB. if you run a sshd that accepts connections from behind large NAT blocks, proxies or anything else that aggregates many possible users behind few IP addresses, then this change may cause legitimate traffic to be denied. Please read the PerSourcePenalties, PerSourcePenaltyExemptList and PerSourceNetBlockSize options in sshd_config(5) for how to tune your sshd(8) for your specific circumstances.
So now we know: starting with OpenBSD 7.6, PerSourcePenalties will be enabled by default, and admins who do not themselves run PF or other network translation mechanisms will need to keep the consequences of inconsiderate NAT use in mind.
(Score: 4, Insightful) by GloomMower on Tuesday June 11 2024, @12:01PM (8 children)
I've had the issue where there was so many login attempts because of a brute force attack it was preventing legitimate people from logging in. The brute force attack was causing a DOS.
To resolve this I have used fail2ban or iptables rules.
Having it built in could be nice.
(Score: 2) by canopic jug on Tuesday June 11 2024, @12:07PM (5 children)
Having it built in could be nice.
It seems from here to look more like a solution in search of a problem. All the log files I have seen for the last five or so years show distributed attacks over a while range of account names, an attack pattern which is not addresses by these new options.
However, the plural of anecdote is not data. So if there is a real world use case for these new options, it would be very interesting to know.
Money is not free speech. Elections should not be auctions.
(Score: 4, Interesting) by shrewdsheep on Tuesday June 11 2024, @12:24PM
What I have seen is that as fail2ban reads the logs, a client can still make up to 100 login attempts even if 3 attempts is the ban limit because of the lag in writing out the logs. A properly engineered solution should guarantee the ban after 3 tries exactly which probably has to be implemented in sshd itself, or a plugin.
(Score: 3, Interesting) by GloomMower on Tuesday June 11 2024, @12:53PM (3 children)
> It seems from here to look more like a solution in search of a problem. All the log files I have seen for the last five or so years show distributed attacks over a while range of account names, an attack pattern which is not addresses by these new options.
It says it can block address blocks. Not isolate to account.
(Score: 3, Informative) by canopic jug on Tuesday June 11 2024, @01:23PM (2 children)
Isolating an account can be done dynamically by using the AllowGroups and DenyGroups directives and then adding or removing the offending accounts to the group(s) pointed to by DenyGroups. Addresses can be dealt with directly in the packet filter, by adding or removing the offending address or even whole netblocks from sets [nftables.org] in NFTables or tables [openbsd.org] in PF.
shrewdsheep mentioned log lag elsewhere in this discussion. I presume that is on a GNU/Linux system with systemd, in which case one has to pipe output from journalctl instead of reading the logs. Also, although not feasible on all systems, turning off password authentication in favor of keys or certificates makes big difference too. Many of the bots can figure out that there are no passwords to guess and move on.
Money is not free speech. Elections should not be auctions.
(Score: 2) by GloomMower on Tuesday June 11 2024, @01:40PM
> Also, although not feasible on all systems, turning off password authentication in favor of keys or certificates makes big difference too. Many of the bots can figure out that there are no passwords to guess and move on.
Yes, I love the people that refuse to try to understand key auth. They are so great!
(Score: 2) by zocalo on Tuesday June 11 2024, @02:14PM
Or maybe it's kind of like SPF for mail; as long as you can set "-all" then spammers seem to realise they can't use that as a spoofed from address and your backscatter from such things drops to zero almost overnight. But nooo... it's not the FUSSP it's commonly misunderstood to be, so why bother getting it right? I think enough of us did get it right to make Joe Jobs a thing of the past though, so there's that at least, and maybe the same will apply here. I, for one, will definitely be playing with this once it reaches stable.
UNIX? They're not even circumcised! Savages!
(Score: 5, Interesting) by GloomMower on Tuesday June 11 2024, @12:55PM
I found the tables rule I've used before.
(Score: 4, Insightful) by bart9h on Tuesday June 11 2024, @02:16PM
I just changed the port it listens to to something other than the default.
(Score: 4, Insightful) by canopic jug on Tuesday June 11 2024, @12:03PM (3 children)
All serious systems already come with system logs, simple (or complex) scripting languages, and packet filters. It is trivial to whip up an AWK/Perl/Python script to monitor the logs and trigger PF/IPTables/NFTables. Perl, AWK, and even Python are available by default for the Linuxes and the BSD, including MacOS in the latter. NFTables and, on older distros, IPTables are available for the Linuxes, especially the GNU/Linuxes. With NFTables you have sets which can be used here. All the BSDs have PF these days, which has tables which can be used here. So even in the base system you already have all the tools needed.
If you'd rather spend a few hours configuring off-the-shelf software instead of a few hours polishing your own script, then you have SSH Guard [sshguard.net] among other options. It's even in the OpenBSD package repository, which is the host distro for OpenSSH development. And if SSHGuard is not your thing, then there is Fail2Ban plus a few others. Despite the name SSHGuard covers a lot of other protocols too. However, in this case the name is a clue.
Either way, the changes being introduced into a very sensitive, secure code base are both adding complexity and duplicating the functionality already found both in the base system and in third party packages. Complexity and bloat reduce security. Duplication of effort, well if you're going to reinvent the wheel at least invent a better one, and that's not happening. Furthermore, if the last five years of various server logs are anything to go by, then the attacks are not only distributed but cover a wide spray of account names.
I hope the development team wises up and rolls back these changes or else is able to explain them in a way that makes these changes look less stupid and unnecessary. I've been a big fan of OpenSSH due to its utility and clean, relatively small code base. This is the first change that feels outright wrong. It may possibly be indicative of the original developers losing control to or being steered by m$ which has lately taken an interest against the project.
tldr; feeping creaturism in OpenSSH
Money is not free speech. Elections should not be auctions.
(Score: 2, Interesting) by Anonymous Coward on Tuesday June 11 2024, @12:36PM (1 child)
Did you even read the article? This works just like those packet filtering tools you mentioned, based on addresses, not account names. Looking at the new code, it's all fairly straightforward and doesn't touch anything that could be a security issue other than the mentioned caveat that many users sharing an address could trigger a penalty, possibly leading to an availability issue.
(Score: 2) by canopic jug on Tuesday June 11 2024, @01:00PM
I saw the post on Undeadly there quite a few days ago. So yes I read it, on the first day, even I have not looked at the diff in context. With your own scripts you can filter on addresses or account names or both. Thus the question about what problem this really solves remains unanswered, especially as to why this capability of basic system functions and/org third party utilities ought to be duplicated inside the OpenSSH code base. I guess one could raise a similar question about the use-cases for some of the other newer options as well, such as StreamLocalBindMask and StreamLocalBindUnlink.
In contrast, features like keystroke timing obfuscation, support for LibreSSL, and options like SessionType or Tag seem immediately useful.
Money is not free speech. Elections should not be auctions.
(Score: 0) by Anonymous Coward on Tuesday June 11 2024, @07:52PM
I was going to post something similar. I don't need them screwing around with something as critical as ssh access to my remote machines just to pander to people who can't be assed to use key auth. If you use password auth on something that matters, you deserve to be compromised, b/c you have no business hosting anything that matters.
(Score: 4, Insightful) by bart9h on Tuesday June 11 2024, @02:22PM
My access.log is full of requests to non-existing things like:
/phpmyadmin/index.php
/axis2/axis2-admin/
/systembc/password.php
/bundle.js
/password.php
/info.php
/.env
It would be nice to get those ip banned.
(Ok, I know I could hack up a script for that, but I have tons of other stuff to take care of.)
(Score: 4, Interesting) by fliptop on Wednesday June 12 2024, @12:31AM
It's quite simple to grep for the prefix in the logs and block the offending IP. Additionally, I usually use an alternate port for sshd to listen on and only allow connections from a particular IP.
And I agree w/ GloomMower [soylentnews.org] in that ssh attacks are usually widely distributed and don't always focus on one account. In this scenario the proposed patch seems almost useless.
Interesting side note: when using nftables-restore-translate to convert iptables rules the throttling lines get commented out, even though throttling is entirely possible [redhat.com] in nftables.
Our Constitution was made only for a moral and religious people. It is wholly inadequate to the government of any other.