[hnlmorg]

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

[usrbinbash]

> There’s so many ways that can go wrong

There are a lot of ways a builtin facility of one service can go wrong, especially if it ends up being active by default on a distro.

`fail2ban` is common, well known, battle-tested. And its also [not without alternatives][1].

[1]: https://alternativeto.net/software/fail2ban/

[hnlmorg]

As I’ve already posted, I’ve ran into bugs with fail2ban too.

Also adding firewalling to SSH is hardly “kitchen sinking” (as another commenter described it). You’re literally just adding another layer of security into something that’s literally meant to be used as an out of the box solution for creating secure connections.

If you want to take issue with the “kitchen sink” mentality of SSH then complain about its file transfer features or SOCKS support. They are arguably better examples of feature creep than literally just having the server own what connections it should allow.

[usrbinbash]

> Also adding firewalling to SSH is hardly “kitchen sinking”

sshd is a service. It may be one among dozens of other services running on a host.

Now imagine for a moment, if EVERY service on the host took that approach. Every backend service, every network-facing daemon, every database, every webserver, voip servers, networked logging engines, userspace network file systems, fileservers...they all now take security into their own hands.

Every single one of them has its own fail2ban-ish mechanism, blocklists it manages, rules for what to block and how long, what triggers a block, if and when a block will be lifted...

Oh, and of course, there is still also a firewall and other centralized systems in place, on top of all that.

How fun would such a system be to administer do you think? As someone with sysadmin experience, I can confidently say that I would rather join an arctic expedition than take care of that mess.

There is a REASON why we have things like WAFs and IDS, instead of building outward-facing-security directly into every single webservice.

[hnlmorg]

If you’ve been a sysadmin as long as I have then you’ll remember when services didn’t even manage their own listener and instead relied on a system-wide daemon that launched and managed those services (inetd). Whereas now you have to manage each listener individually.

That was additional initial effort but the change made sense and we sysadmins coped fine.

Likewise, there was a time when server side website code had to be invoked via a httpd plugin or CGI, now every programming language will have several different web frameworks, each with their own HTTP listener and each needing to be configured in its own unique way.

Like with inetd, the change made sense and we managed just fine.

Tech evolves — it’s your job as a sysadmin to deal with it.

Plus, if you’re operating at an enterprise level where you need a holistic view of traffic and firewalling across different distinct services then you’d disable this. It’s not a requirement to have it enabled. A point you keep ignoring.

[usrbinbash]

> Likewise, there was a time when server side website code had to be invoked via a httpd plugin or CGI, now every programming language will have several different web frameworks, each with their own HTTP listener and each needing to be configured in its own unique way.

And still we keep all those webservices, be they in Java, Go, node, C# or Python, behind dedicated webservers like nginx or apache.

Why? Because we trust them, and they provide a Single-Point-Of-Entry.

> Tech evolves — it’s your job as a sysadmin to deal with it.

Single-Point-Of-Entry is still prefered over having to deal with a bag of cats of different services each having their own ideas about how security should be managed. And when a single point of entry exists, it makes sense to focus security there as well.

This has nothing to do with evolving tech, this is simple architectural logic.

And the first of these points that every server has, is the kernels packet filter. Which is exactly what tools like fail2ban manage.

> A point you keep ignoring.

Not really. Of course an admin should deactivate svc-individual security in such a scenario, and I never stated otherwise.

The point is: That's one more thing that can go wrong.

[hnlmorg]

> And still we keep all those webservices, be they in Java, Go, node, C# or Python, behind dedicated webservers like nginx or apache.

Not really no. They might sit behind a load balancer but that's to support a different feature entirely. Some services might still be invoked via nginx or apache (though the latter has fallen out of fashion in recent years) if nginx has a better threading model. But even there, that's the exception rather than the norm. Quite often those services will be stand alone and any reverse proxying is just to support orchestration (eg K8s) or load balancing.

> Single-Point-Of-Entry is still prefered over having to deal with a bag of cats of different services each having their own ideas about how security should be managed.

Actually no. What you're describing is the castle-and-Moat architecture and that's the old way of managing internal services. These days it's all about zero-trust.

https://www.cloudflare.com/en-gb/learning/security/glossary/...

But again, we're talking enterprise level hardening there and I suspect this openssh change is more aimed at hobbyists running things like Linux VPS

> > A point you keep ignoring.

> Not really. Of course an admin should deactivate svc-individual security in such a scenario, and I never stated otherwise. The point is: That's one more thing that can go wrong.

The fact that you keep saying that _is_ missing the point. This is one more thing that can harden the default security of openssh.

In security, it's not about all or nothing. It's a percentages game. You choose a security posture based on your the level of risk you're willing to accept. For enterprise, that will be using an IDP to manage auth (including but not specific to SSH). A good IDP can be configured to accept requests from non-blacklisted IP, eg IPs from countries where employees are known not to work in), and even only accept logins from managed devices like corporate laptops. But someone running a VPS for their own Minecraft server, or something less wholesome like Bit-Torrent, aren't usually the type to invest in a plethora of security tools. They might not even have heard of fail2ban, denyhosts, and so on. So having openssh support auto-blacklisting on those servers is a good thing. Not just for the VPS owners but us too because it reduces the number of spam and bot servers.

If your only concern is that professional / enterprise users might forget to disable it, as seems to be your argument here, then it's an extremely weak argument to make given you get paid to know this stuff and hobbyists don't.

[1oooqooq]

still better trying to improve fail2ban than to add a (yet another) kitchen sink on sshd

[hot_gril]

fail2ban has been around for so long, people get impatient at some point

[usrbinbash]

Impatient 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/

[hot_gril]

What hnlmorg said a few comments up