Absolutely. Unlike you, your mother made a massive one giving birth to you. I can only begin to imagine her devastation when she sees the nasty goblin she produced
And they spell it like that literally all the time, even on Wikipedia! I don’t know if it’s just a common typo, but it could really mislead people to believe that his name isn’t Gay Oldman.
I have wireguard for other purposes but I also have ssh open on a different port. I don’t much understand the argument of exchanging ssh for wireguard. In the end, we’re just trading an attack vector for another.
My ssh only allows connections from my user. If I’m using password auth, I also request a 2FA.
Tail scale is also a good idea but I don’t like having my control plane under someone else’s control.
The reason a VPN is better to expose than SSH, is the feedback.
If someone tries connecting to your SSH with the wrong key or password, they get a nice and clear permission denied. They now know that you have SSH, and which version. Which might allow them to find a vulnerability.
If someone connects to your wireguard with the wrong key, they get zero response. Exactly as if the port had not been open in the first place. They have no additional information, and they don’t even know that the port was even open.
Try running your public IP through shodan.io, and see what ports and services are discovered.
There is quite a significant difference. An ssh server - even when running on a non-default port - is easily detectable by scanning for it. With a properly configured Wireguard setup this is not the case. As someone scanning from the outside, it is impossible to tell if there is Wireguard listening or not, since it simply won't send any reply to you if you don't have the correct key. Since it uses UDP it isn't even possible to tell if there is any service running on a given UDP port.
If someone finds a 0day in your SSH server and goes on drive-by attacking the whole internet you’re toast.
Already moving off port 22 reduces much of the risk, essentially reducing the attack surface for drive-by attacks to zero while still being susceptible to targeted attacks – that is, still susceptible to attackers bothering to scan the whole range. Anything that makes you unscannable (VPN, portknockd, doesn’t matter) mitigates that. Even state-level actors would have to be quite determined to get through that one.
Yes it’s security through obscurity. Yes it’s a good idea: There’s a difference between hiding your unlocked front door and hiding your military-grade front door lock, one of them is silly the other isn’t.
Honest question, is there a good default config available somewhere or is what apt install fail2ban does good to go? All the tutorials I’ve found have left it to the reader to configure their own rules.
Honestly the default config is good enough to prevent brute force attacks on ssh. Just installing it and forgetting about it is a definite option.
I think the default block time is 10 minutes after 5 failed login attempts in 10 minutes. Not enough to ever be in your way but enough to fustrate any automated attacks. And it’s got default config for a ton of services by default. Check your /etc/fail2ban/jail.conf for an overview.
I see that a recidive filter that bans repeat offenders for a week after 10 fail2ban bans in one day is also default now. So I’d say that the results are perfect unless you have some exotic or own service you need fail2ban for.
If Fail2Ban is so important, why the h*** does it not come installed and enabled as standard?!
Security is the number-1 priority for any OS, and yet stock SSHD apparently does not have Fail2Ban-level security built in. My conclusion is that Fail2Ban cannot therefore be that vital.
lemmy.world
Newest