7 ms·
> First, with IPv4 this will have the potential to increasingly penalize innocent bystanders... Worst case, this will give bad actors the option to lock the ori
by TacticalCoder 2y ago
> First, with IPv4 this will have the potential to increasingly penalize innocent bystanders... Worst case, this will give bad actors the option to lock the original owner out of their own server if they have a botnet host in the same network.
So instead of looking, like the author of these new options, for ways to make life for the bad guys harder we do nothing?
Your concerned are addressed in TFA:
> ... and to shield specific clients from penalty
> A PerSourcePenaltyExemptList option allows certain address ranges to be exempt from all penalties.
It's easy for the original owner to find the list of all the IP blocks the three or four ISPs he's legitimately be connecting from to that exemption list.
I don't buy your argument nor all the variation on the same theme: "There's a minuscule risk of X, so we absolutely nothing but saying there's nothing to do and we let bad guys roam free!".
There's nothing more depressing than that approach.
Kudos to the author of that new functionality: there may be issues, it may not be the panacea, but at least he's trying.
- usrbinbash 2y ago> So instead of looking, like the author of these new options, for ways to make life for the bad guys harder we do nothing? The thing is, we have tools to implement this without changing sshd's behavior. `fail2ban` et. al. exist for a reason.
- sleepybrett 2y agoSure but if I only used fail2ban for sshd why should I install two separate pieces of software to handle the problem which the actual software I want to run has it built in?
- pixl97 2y agoTurning every piece of software into a kitchen sink increases its security exposure in other ways.
- fragmede 2y agoa system where sshd outputs to a log file then someone else picks it up and then pokes at iptables, seems much more of hacky than having sshd supporting that natively, imo. Sshd is already tracking connection status, having it set the status to deny seems like less of a kitchen sink and more just about security. the S in ssh for secure, and this is just improving that.
- hnlmorg 2y agoNormally I would agree with you, but fail2ban is a Python routine which forks processes based on outcomes from log parsing via regex. There’s so many ways that can go wrong…and has gone wrong, from one or two experiences I’ve had in the past. This is exactly the sort of thing that should be part of the server. In exactly the same way that some protocol clients have waits between retries to avoid artificial rate limiting from the server.
- 1oooqooq 2y agostill better trying to improve fail2ban than to add a (yet another) kitchen sink on sshd
- hot_gril 2y agofail2ban has been around for so long, people get impatient at some point
- usrbinbash 2y agoImpatient about what exactly? fail2ban is battle tested for well over a decade. It is also an active project with regular updates: https://github.com/fail2ban/fail2ban/commits/master/ https://github.com/fail2ban/fail2ban/commits/master/
- hot_gril 2y agoWhat hnlmorg said a few comments up
- usrbinbash 2y ago> why should I install two separate pieces of software to handle the problem https://alanj.medium.com/do-one-thing-and-do-it-well-a-unix-philosophy-8f56ed4c29ae https://alanj.medium.com/do-one-thing-and-do-it-well-a-unix-...
- sleepybrett 2y agogenerally i agree with this principle, but fail2ban is kind of a hacky pos.
- usrbinbash 2y ago> but fail2ban is kind of a hacky pos. It's battle-tested for well over a decade, has accumulated 10.8k stars and 1.2k forks on github, so it seems to do something right no? Not to mention that even if it were otherwise, that's not a reason to ignore UNIX philosopies that have served the FOSS world well for over half a century at this point. Last but not least, there are any number of alternative solutions.
- sleepybrett 2y agoJust because it's 'battle tested' and has stars and is useful does not preclude it from being a hacky pos. Reading logs using regexps and then twiddling IP tables is not the cleanest method of achieving this result. I would much prefer if this functionality were either handled like ssh or if there was some kind of standardized messaging (dbus?) that was more purposeful and didn't rely on regex. It's useful because you can hook it up to anything that produces logs, it's hacky because that means you are using regexp. If the log format changes, you're likely fucked, not to mention that regexps are notoriously hard to make 'air tight' and often screwed up by newbies. Add to that in a case where your regexes start missing fail2ban will stop doing it's job silently.. not great my friend. It's been a useful hack for a very long time, but I'd like to see us move on from it.
- dfox 2y agoThe issue is that the log parsing things like fail2ban work asynchronously. It is probably of only theoretical importance, but on the other hand the meaningful threat actors are usually surprisingly fast.
- hnlmorg 2y agoYeah, they exist because nothing better was available at that time. It doesn’t hurt to have this functionality in openssh too. If you still need to use fail2ban, denyhosts, or whatever, then don’t enable the openssh behaviour feature. It’s really that simple.
- usrbinbash 2y agoHow is baking this into sshd "better"? UNIX Philosophy: "Do one thing, and do it well". An encrypted remote shell protocol server should not be responsible for fending off attackers. That's the job of IDS and IPS daemons. Password-based ssh is an anachronism anyway. For an internet-facing server, people should REALLY use ssh keys instead (and preferably use a non-standard port, and maybe even port knocking).
- hnlmorg 2y agoIt’s better if you want an out of the box secure experience. This might be quite a nice default for some VPSs. If you have a IDS and IPS set up then you’re already enterprise enough that you want your logs shipped and managed by a single pane of glass. This new SSH feature isn’t intended to solve enterprise-level problems. Plus if you want to argue about “unix philosophy” with regards to SSH then why aren’t you kicking off about SOCKS, file transfer, port forwarding, and the countless other features SSH has that aren’t related to “shell” part of SSH? The change you’re moaning about has more relevance than most of the other extended features people love SSH for.
- usrbinbash 2y ago> This new SSH feature isn’t intended to solve enterprise-level problems. But service level security features have the potential to cause enterprise-level problems. Sure, in an ideal world, all admins would always make zero mistakes. And so would the admins of all of our clients, and their interns, and their automated deployment scripts. Also in that perfect world, service level security features would never be on by default, have the same default configuration across all distros, and be easy to configure. But, alas, we don't live in a perfect world. And so I have seen more than one service-level security feature, implemented with the best of intentions, causing a production system to grind to a halt.
- unhingedcrouton 2y ago[flagged]
- deleted 2y ago[deleted]
- cubesnooper 2y agoAccording to the commit message, the motivation is also to detect certain kinds of attacks against sshd itself, not just bruteforced login attempts.
- singpolyma3 2y agoDon't use fail2ban Use keys
- DaSHacka 2y agoAlternatively: Use both
- hartator 2y agoIt would be frustrating to be denied access to your own servers because you are traveling and are on a bad IP for some reason. Picture the amount of Captchas you already getting from a legitimate Chrome instance, but instead of by-passable annoying captchas, you are just locked out.
- grepfru_it 2y agoI have fail2ban configured on one of my servers for port 22 (a hidden port does not have any such protections on it) and I regularly lock out my remote address because I fat finger the password. I would not suggest doing this for a management interface unless you have secondary access
- bartekrutkowski 2y agoWhy would you use password based auth instead of priv/pub key auth? You'd avoid this and many other security risks.
- fragmede 2y agowhat do you if you get mugged and you laptop and phone and keys are taken or stolen from you? or lost? After this party, this guy needed help, he lost his wallet and his phone, his sister also went to the party and gave him a ride there but had left. he didn't know her number to call her, and she'd locked down her socials so we couldn't use my phone to contact her. we were lucky that his socials weren't super locked down and managed to find someone that way, but priv keys are only good so long as you have them.
- akira2501 2y agoI use a yubikey. You need a password to use the key. It has it's own brute force management that is far less punishing than a remote SSH server deciding to not talk to me anymore.
- 2y ago
- janosdebugs 2y agoThere is nothing wrong with this approach if enabled as an informed decision. It's the part where they want to enable this by default I have a problem with. Things that could be done is making password auth harder to configure to encourage key use instead, or invest time into making SSH CAs less of a pain to use. (See the linked paper, it's not a long read.)
- benchaney 2y ago> So instead of looking, like the author of these new options, for ways to make life for the bad guys harder we do nothing? Random brute force attempts against SSH are already a 100% solved problem, so doing nothing beyond maintaining the status quo seems pretty reasonable IMO. > I don't buy your argument nor all the variation on the same theme: "There's a minuscule risk of X, so we absolutely nothing but saying there's nothing to do and we let bad guys roam free!". Setting this up by default (as is being proposed) would definitely break a lot of existing use cases. The only risk that is minuscule here is the risk from not making this change. I don't see any particularly reason to applaud making software worse just because someone is "trying".
- linuxftw 2y ago> So instead of looking, like the author of these new options, for ways to make life for the bad guys harder we do nothing? Yes, because as soon as the security clowns find out about these features, we have to start turning it on to check their clown boxes.