Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Protecting sshd behind a VPN just moves your 0day risk from sshd to the VPN server.

Choosing between exposing sshd or a VPN server is just a bet on which of these services is most at risk of a 0day.

If you need to defend against 0days then you need to do things like leveraging AppArmor/Selinux, complex port knocking, and/or restricting VPN/SSH access only to whitelisted IP blocks.



Except you don't assume that just because someone is on the VPN you're secure.

If the VPN server has a 0day, they now have... only as much access as they had before when things were public facing. You still need there to be a simultaneous sshd 0day.

I'll take my chances on there being a 0day for wireguard at the same time there's a 0day for sshd.

(I do also use selinux and think that you should for reasons far beyond just ssh security)


A remote code execution 0day in your VPN server doesn't give an attacker an unauthorized VPN connection, it gives them remote code execution inside the VPN server process, which gives the attacker whatever access rights the VPN server has on the host. At this point, connecting to sshd is irrelevant.

Worse, since Wireguard runs in kernel space, if there's an RCE 0day in Wireguard, an attacker would be able to execute hostile code within the kernel.

One remote code exploit in a public-facing service is all it takes for an attacker to get a foothold.


I do not run my VPNs on the same systems I am running other services on, so an RCE at most compromises the VPN concentrator and does not inherently give them access to other systems. Access to SSH on production systems is only available through a jumphost which has auditing of all logins sent to another system, and requires 2FA. There are some other services accessible via VPN, but those also require auth and 2FA.

If you are running them all on the same system, then yes, that is a risk.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: