"Protecting your SSH port is a critical part of any good Linux security policy. While the list of things to do is well documented across the internet, I wanted to give an alternative to the standard SSH protections. Why not only expose the SSH port via a Wireguard Tunnel? The steps are fairly straight forward, especially if you’ve setup a Wireguard server before. However, there are one or two unforeseen pitfalls which could trip up even more experienced users."
I agree with the sentiment. It would be more difficult to attack an SSH port when it's only accessible through an agreed upon Wireguard tunnel.
However, if you use pubkey and not password authentication, is there still any real risk? If I post to the public internet "my <hostname> is listening on port 22" and it's pubkey auth only, is anyone ever going to get in even if I allow unlimited bruteforce attempts? You'll have to steal my laptop to get the key, by which point you have my Wireguard config and keys as well.
Not at all to say defense in depth isn't worthwhile, of course it is, but I don't think ssh with pubkey is inherently vulnerable.
I use Wireguard and already implement the suggested topology. Just food for thought.
Crypto-in-crypto seems kind of wasteful... Something like fail2ban would be preferable--block assholes from the entire network for hours (or days) so they can't hammer other ports for vulnerabilities. Between LocalForward and ProxyJump, I hardly ever need my WireGuard tunnel.
If it's this one (https://nvd.nist.gov/vuln/detail/CVE-2021-32749), I think that's kind of a reach--especially for the typical use case, which uses neither mail nor whois, and only adds an ephemeral block rule to the firewall.
My beef with fail2ban is that it only checks logs on a (non-configurable) 1 second interval, which allows an attacker to make several attempts (> N) from the same IP in parallel inside of that second, even when the f2b configuration is set to block at the Nth failure.
>Preferrably, I should be using an SSH key, but for the sake of simplicity in this article I am sticking with simple password authentication.
I prefer to see something that improves over current best practices.
I accidently had a setup like that. But it turned that wireguard had/have the ability to get stuck. Probably problem with the implementation from mikrotik.
A watchdog of some kind is needed for this kind of setup.
6 comments
[ 3.3 ms ] story [ 27.0 ms ] thread"Protecting your SSH port is a critical part of any good Linux security policy. While the list of things to do is well documented across the internet, I wanted to give an alternative to the standard SSH protections. Why not only expose the SSH port via a Wireguard Tunnel? The steps are fairly straight forward, especially if you’ve setup a Wireguard server before. However, there are one or two unforeseen pitfalls which could trip up even more experienced users."
However, if you use pubkey and not password authentication, is there still any real risk? If I post to the public internet "my <hostname> is listening on port 22" and it's pubkey auth only, is anyone ever going to get in even if I allow unlimited bruteforce attempts? You'll have to steal my laptop to get the key, by which point you have my Wireguard config and keys as well.
Not at all to say defense in depth isn't worthwhile, of course it is, but I don't think ssh with pubkey is inherently vulnerable.
I use Wireguard and already implement the suggested topology. Just food for thought.
- If the IP has an established port 22 connection, pass any new connections
- Otherwise, meter connections from each /24 to one per 21 seconds
I think ControlMaster would keep this from gumming up Ansible too much?
If it's this one (https://nvd.nist.gov/vuln/detail/CVE-2021-32749), I think that's kind of a reach--especially for the typical use case, which uses neither mail nor whois, and only adds an ephemeral block rule to the firewall.
My beef with fail2ban is that it only checks logs on a (non-configurable) 1 second interval, which allows an attacker to make several attempts (> N) from the same IP in parallel inside of that second, even when the f2b configuration is set to block at the Nth failure.
I prefer to see something that improves over current best practices.
I accidently had a setup like that. But it turned that wireguard had/have the ability to get stuck. Probably problem with the implementation from mikrotik.
A watchdog of some kind is needed for this kind of setup.