6 ms·

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

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 https://www.tarsnap.com/spiped.html [2] https://wiki.archlinux.org/title/nftables https://wiki.archlinux.org/title/nftables [3] https://ruderich.org/simon/notes/systemd-service-hardening https://ruderich.org/simon/notes/systemd-service-hardening [4] https://wiki.archlinux.org/index.php?title=Systemd&oldid=704440#Drop-in_files https://wiki.archlinux.org/index.php?title=Systemd&oldid=704...

iso1631 5y ago
Why use spiped rather than wireguard?
- acatton 5y ago
  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 https://man.openbsd.org/ssh_config#ProxyCommand [2] https://ruderich.org/simon/notes/systemd-service-hardening https://ruderich.org/simon/notes/systemd-service-hardening
  - codetrotter 5y ago
    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 5y ago
  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 5y ago
    Top comment poster here, yes. I use spiped as a 256bit-combination port knocker. The goal is to protect against vulnerabilies in OpenSSH :)
  - spekcular 5y ago
    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?
    - discardedrefuse 5y ago
      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 https://www.tarsnap.com/spiped.html
    - marcosdumay 5y ago
      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.
hnlmorg 5y ago
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)
- bombcar 5y ago
  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.
  - smarx007 5y ago
    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 5y ago
    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 5y ago
      It's nicer when they're browsable. Might spot something you wouldn't have known to grep for.
  - hnlmorg 5y ago
    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.
johnisgood 5y ago
> 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 5y ago
  Agreed and, fundamentally, why not just ssh -L?
tyingq 5y ago
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.
BenjiWiebe 5y ago
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.

iso1631 5y ago

Why use spiped rather than wireguard?

acatton 5y ago
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 https://man.openbsd.org/ssh_config#ProxyCommand [2] https://ruderich.org/simon/notes/systemd-service-hardening https://ruderich.org/simon/notes/systemd-service-hardening
- codetrotter 5y ago
  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 5y ago
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 5y ago
  Top comment poster here, yes. I use spiped as a 256bit-combination port knocker. The goal is to protect against vulnerabilies in OpenSSH :)
- spekcular 5y ago
  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?
  - discardedrefuse 5y ago
    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 https://www.tarsnap.com/spiped.html
  - marcosdumay 5y ago
    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.

hnlmorg 5y ago

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)

bombcar 5y ago
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.
- smarx007 5y ago
  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 5y ago
  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 5y ago
    It's nicer when they're browsable. Might spot something you wouldn't have known to grep for.
- hnlmorg 5y ago
  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.

johnisgood 5y ago

> 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 5y ago
Agreed and, fundamentally, why not just ssh -L?

tyingq 5y ago

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.

BenjiWiebe 5y ago

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.