[acatton]

Even for 2013, this is not very good advice. fail2ban makes your iptables dynamic, which is a nightmare to audit.

This is what I do in 2021:

* Set up spiped[1] in front of SSH

* Install and setup nftables[2].

* Lock down every service as much as possible in systemd[3]. (If the service is built-in the distro, just use drop in files[4])

[1] https://www.tarsnap.com/spiped.html

[2] https://wiki.archlinux.org/title/nftables

[3] https://ruderich.org/simon/notes/systemd-service-hardening

[4] https://wiki.archlinux.org/index.php?title=Systemd&oldid=704...

[hnlmorg]

I wouldn't say fail2ban is bad advice per se. The kind of companies running deployments that do auditing on iptables are going to be very different to the types of companies that benefit from dynamic rules created by services like fail2ban.

There is a gulf of difference between hardening a Linux server for an independent web shop vs running Linux at Google. And this article very much feels like it's aimed at sysadmins of the former rather than SRE's of the latter (the fact that they're not even running configuration management like Puppet is a dead give away of that fact)

[acatton]

> I wouldn't say fail2ban is bad advice per se. The kind of companies running deployments that do auditing on iptables are going to be very different to the types of companies that benefit from dynamic rules created by services like fail2ban. […] There is a gulf of difference between hardening a Linux server for an independent web shop vs running Linux at Google.

I agree that there is a difference between running Linux at a FAANG and running Linux for an independent web-shop.

However, my advice was targeted at the hobbyists like me who likes to run their own webserver. (Independently from my employer) And I think it is appropriate for independent web-shop as well.

Auditing is not just reserved to bigcorps, I personally like to log diffs between "nft list ruleset" and "cat /etc/nftables.conf" on my personal servers. If you run fail2ban this becomes impossible.

Also, IMHO, fail2ban doesn't really solve the problem, a botnet attack could try to bruteforce your SSH. All it does is try to prevent one person from trying too much, it can also lock you out during an emergency. spiped is, IMHO, easier to setup and cheaper to maintain. It also provides a higher degree of protection. (As I explained before, it is a 256bit combination port knocker)

I personally think that fail2ban is a cargo-cult.

[ozim]

Everyone should do key based auth anyway - so I don't even see use for fail2ban anymore in context of SSH.

[UI_at_80x24]

Yes everyone should use key-based authentication. What fail2ban and other firewall styled security measures do is to move the point of contact on your network.

1 - You want to limit the number of times that SSHD initializes the connection handshake, this initialization period is when/where 0-day exploits can get through.

2 - With active auditing you can add the banned IP's to your edge device. Odds are that a legitimate IP won't be trying to SSH into your systems so block everything from them. I go one step further and share that banned IP list on all my edge devices.

[acatton]

spiped is not an exclusive or to key based auth. I advise to use spiped + key based authentication.

spiped allows also for circumventing zero-day attacks on openssh.

[handrous]

On smallish servers it can keep the logs human-browsable without filtering. Not necessary, but nice.

[hnlmorg]

Since we're talking about two different points in time that are nearly a decade apart, lets be clear about the context here. spiped didn't exist when that article was written (or if it did, it certainly wasn't mature). Back then fail2ban was a pretty good recommendation for the domain in question. Which was my point.

If we shift the focus to 2021 then I'm more inclined to agree with you that it's less important. However I still disagree that it is "bad" advise and think you're overstating the reasons why it should be considered "bad advise". I'm not going to discount the problems you raise but I believe them to be less significant than the benefits fail2ban brings. To be clear, I do also agree that the benefits it brings are also small, however the risks are smaller.

The problem with the discussion here is you're focusing just on SSH. There are clearly a number of ways one can protect SSH without fail2ban. Much better ways in fact. But fail2ban isn't an SSH firewall, it's a log watch. If you have a machine exposed on the internet with no other firewalls between the internet and your server (eg no AWS security groups, router firewalls, etc) or even if you do have other firewalls in place but have several services running off the same host, fail2ban can protect you against some of the more casual directed attacks. eg you can set it up as a WAF and have all services blocked if your Apache/nginx logs detect suspicious activities.

Also your point about botnets are true but the point of security is to slow down attacks in the hope of preventing them. There isn't a silver bullet, only layering hurdles. fail2ban does slow down the smaller scale bot net attacks.

Let's also remember that there is a fair amount of bots out there that aren't part of botnets but rather just scripts run by opportunists. fail2ban can cut down on that annoyance as well.

Going back to your point about auditing, most independent hosts wouldn't even think to run auditing. The fact you do only demonstrates your enterprise background. And I'm not even convinced your example even adds any value since if nftables.conf is on the same host as iptables then it's not unreasonable to assume any successful penetration that has rewritten your iptables rules might also rewrite your nftables.conf too. In fact the first thing they'd do would be to check what agents are running for auditing and configuration management; and then kill them. I also think you're overstating the difficulty of working around dynamic deny lists -- it wouldn't take a complex script to filter out the rules added by fail2ban and frankly the rules you'd be more interested in auditing would be the allow rules anyway.

That all said, I don't disagree with your point about fail2ban (in 2021) being cargo-cult. I do disagree with your point that it is bad and your reasons for why it is bad. But I do agree that it's benefits are largely marginal in most cases.

[acatton]

> Since we're talking about two different points in time that are nearly a decade apart, lets be clear about the context here. spiped didn't exist when that article was written (or if it did, it certainly wasn't mature). Back then fail2ban was a pretty good recommendation for the domain in question. Which was my point.

That is simply not true. spiped 1.0 was released in 2011, 2 years before the article was written. And it was used in production on tarsnap's infrastructure since it is the same author. It had 4 minor releases by the time the article was written. [1] And it was in debian by the end of the year 2013. [2]

[1] https://www.tarsnap.com/spiped.html

[2] https://metadata.ftp-master.debian.org/changelogs//main/s/sp...

[hnlmorg]

> > spiped didn't exist when that article was written (or if it did, it certainly wasn't mature).

> it was used in production on tarsnap's infrastructure since it is the same author. It had [3 minor] releases+ by the time the article was written. And [the initial release] was in debian [unstable] by the end of the year 2013 [after the article was written].

You're not exactly making a strong case there but fine, I'll concede it did exist and had some undefined degree of maturity that we're never going to prove nor disprove. :)

+ it was 3 minor releases not 4. The 4th was released in April, the article in March. But in fairness to yourself there were also 2 patch releases you didn't count.

[handrous]

fail2ban works for a lot more than just SSH.

[bombcar]

fail2ban basically just cleans log files for you - and gives someone else control over your iptables. And in the days of botnet attacks, it doesn’t do as much as someone might think.

Moving the ssh port (even without port knocking) does a lot more to cut out log messages.

Or make ssh IPv6 only.

[hnlmorg]

fail2ban isn't just for SSH.

Anyway, I'm not here to advocate that everyone should install fail2ban tomorrow. My point was just that fail2ban wasn't bad advice in 2013 and isn't really bad advice even now. Sure, there are better tools out there for hardening services but at least fail2ban doesn't break those other tools. So there's nothing stopping you having a layered approach if you want.

And that's the crux of it for me. "Bad advice" would be something that hinders security whereas fail2ban does add to it. What is in contention is the significance it adds and this is where people have gotten hung up on SSH. For example fail2ban can work really effectively when you have multiple services running off the same host (eg HTTP(S), SMTP, and SSH).

The problem is most people just look at the default config and say "there's better tools for SSH" -- which is true but it also overlooks a lot of what fail2ban offers.

But as I said, I'm not an advocate for fail2ban. I just think some of the comments here against it are overstated. If someone wants to run fail2ban it wont harm their security. It might even enhance it depending on how they've set it up.

[smarx007]

Somehow, it never occurred to me to have both IPv4 and IPv6 for the regular services and only binding SSH daemon to an IPv6 address only. Thanks for the idea!

[thesuitonym]

I never understood why people get so upset over having a lot of messages in their logs. Just grep for whatever you're looking for.

[handrous]

It's nicer when they're browsable. Might spot something you wouldn't have known to grep for.

[johnisgood]

> The simplicity of the code — about 6000 lines of C code in total, of which under 2000 are specific to spiped (the rest is library code originating from kivaloo and Tarsnap) — makes it unlikely that spiped has any security vulnerabilities.

spiped might be great, but I found the above on their website. The fact that it has 6k lines of code does not mean that it lacks security vulnerabilities... at all. It does not make it that unlikely either. You still have to audit it. Less LOC just means it will consume less time to do that, but it is of no guarantee that it is more unlikely to have security vulnerabilities.

Plus they could have used better crypto.

[matthewaveryusa]

Agreed and, fundamentally, why not just ssh -L?

[tyingq]

There are also pam modules that can dynamically block repeated failed ssh login attempts. Pam_shield, for example defaults to blocking by null routing the ip, but you can drop in whatever action you want. There are other similar pam modules as well. I like a pam based approach since it isn't trolling log files, but directly controlling the auth.

[iso1631]

Why use spiped rather than wireguard?

[acatton]

Wireguard is also a good alternative. But you need to connect to a VPN every time you want to SSH.

Here is my personal reasons why I use spiped:

* spiped is transparent by using ProxyCommand[1]. This allow me to do "ssh host" and thanks to my ssh_config, it just connects.

* spiped can be run in a very hardened way.[2] It just needs to listen() to a socket, connect to another one, and access a key file. Wireguard needs complex network access, it needs to create interfaces and open raw sockets.

* spiped is much simple to manage, just run a daemon. With wireguards there are two possibilites:

** Every host runs wireguard, you might need to connect to multiple hosts at the time, you need to manage internal IP conflicts, etc...

** One central wireguard server, you have a single point of failure, and can't ssh anywhere if this host is down.

Don't get me wrong, I love wireguard, use it all the time as a VPN, but I don't think it's appropriate as a layer of protection in front of my SSH server.

Both Wireguard and Spiped are written by very smart people.

[1] https://man.openbsd.org/ssh_config#ProxyCommand

[2] https://ruderich.org/simon/notes/systemd-service-hardening

[codetrotter]

I use WireGuard and ssh together.

On my two VPSes I have one of them run a WireGuard server, and both of the VPSes have their sshd bound to the WireGuard interface only.

At home I have a computer running a WireGuard server. Two of the other computers at home are clients of both the WireGuard server at home and of the WireGuard server VPS. I can connect directly to the WireGuard VPN at home from anywhere and ssh into the other machines on their WireGuard interfaces of that VPN, but if the WireGuard server at home is down I can connect via the WireGuard VPN that runs on my VPS and still ssh into the other machines at home that way.

I also have WireGuard running on a physical server in a data center that I manage. On that server I use WireGuard only because it makes connections much more stable than connecting via ssh directly.

My three different WireGuard servers all use different private range IP address subnet ranges, so there is no conflict. I use WireGuard for communication between my own hosts but not for tunneling other traffic.

WireGuard is great and the perfect solution for a small number of machines at least. And I am sure that if you have a lot of machines you could come up with some suitable setup using WireGuard even then.

[discardedrefuse]

Not OP, but I was wondering why use spiped instead of simply sshd with passwords disabled. If anyone else was curious, this is what I found on the spiped website:

"You can also use spiped to protect SSH servers from attackers: Since data is authenticated before being forwarded to the target, this can allow you to SSH to a host while protecting you in the event that someone finds an exploitable bug in the SSH daemon -- this serves the same purpose as port knocking or a firewall which restricts source IP addresses which can connect to SSH."

[acatton]

Top comment poster here, yes. I use spiped as a 256bit-combination port knocker. The goal is to protect against vulnerabilies in OpenSSH :)

[spekcular]

Since that explanation is somewhat terse, and I don't know anything about security, let me ask a few questions.

Am I right that the failure mode spiped protects against is someone finding an exploit that allows them to bypass ssh logins that are set to (for example) public key authentication? So if one is not worried about this, there is no point?

Further, am I correct that what spiped does in this scenario is add a second layer of encryption, so that one must first bypass spiped in order to attempt an exploit against the ssh daemon? Then, in effect, spiped acts as a small, isolated, and auditable "condom" that can be used with any public-facing service?

[marcosdumay]

What I read from that paragraph is "Spipe will block unknown computers from accessing your server's SSH (like a firewall). This provides an extra layer of security (equivalent to such a firewall) in case somebody finds a flaw on ssh."

I didn't dig into it enough to be sure, but it looks to me that spipe uses the same encryption as ssh. So, it won't protect you against crypto attacks, just restrict what computers those may come from.

For any other kind of service, spipe will tunnel it under a layer of encryption. Quite like you can do with bare ssh, but spipe is built for it and thus is more usable on that task.

[spekcular]

If I'm reading correctly, spiped uses Diffie–Hellman for public key cryptography, while contemporary best practices suggest using elliptic curve crypto with shh (e.g. see [0]). So, for the truly paranoid, it might also provide some protection against crypto attacks too?

Note that the NSA can break 1028-bit DH [1], but spiped uses 2048-bit.

[0] https://docs.github.com/en/authentication/connecting-to-gith... [1] https://blog.securegroup.com/did-the-nsa-really-break-diffie...

[discardedrefuse]

I am also not a security expert. But you seem to be correct in both cases. The spiped website also has an example of encrypting SMTP traffic between two servers in an spiped condom.

https://www.tarsnap.com/spiped.html

[BenjiWiebe]

I wrote a small tool that's similar to fail2ban. I had it put the IPs into an ipset, and had my firewall rules static. Just had a rule to match the ipset.