Hacker News Reader

Comment by eropple | Hacker News Reader

A VPN with sshd exposed only inside the private network is a much smarter way of handling remote access. (But it's initially harder, so lots of people don't do it.)

View on HN

You're just trading sshd bugs for VPN bugs, in that case. Which are more likely? From what I know, I think I'll put my lot in with sshd. Perhaps I'm not well informed, though.

Also, sshd + fwknop (port knocking) is a very secure combo, IMO.

PubkeyAuthentication and disabling password logins helps a lot too. I've also been using deny_hosts a lot over the last couple years as an extra layer.

With openvpn (which is just ssl) you can simply not respond when someone presents a bad key.

openssh always responds (unless I've missed a recent feature) thus exposing which port its listening on and that you sent a bad key.

The silent failure is preferable for this application.

Port knocking gives you a roughly equivalent layer.

And both these things you never do in production because it takes little effort to establish there must be a port open, whereas the cumulative time you'll spend tracking down whether its a network issue or bad/wrong keys is just not worth it.

Not to mention: nobody's going to be brute-forcing properly generated keys remotely. And if they're not properly generated, you have much bigger problems.

openvpn, which is just ssl, was vulnerable to heartbleed.

Like the GP said - you're trading VPN bugs for SSH bugs - and experience shows that betting on SSH is generally wiser.

If you only need TCP/DNS and not a full-blown VPN, a program called sshuttle uses ssh+python to provide excellent seamless poor man's VPN. It's not perfect - e.g., you lose the ip src address on the forwarded connections - but it works amazingly well, much better than e.g. openvpn and most other vpn products I've used.

That solution is secure, but I used the word "smarter" to describe the use of a VPN intentionally. You are introducing nonstandard practices (everybody knows what a VPN is and everybody's already able to deal with them) with nonstandard behavior (ever tried to debug fwknop? because I have) and creating an obscure way for your stuff to fail (and it will, at 3AM, and you will not be able to Google your way out of it).

And you're also manually creating SSH tunnels to do anything else inside that network, so you've got that going for you, too.

It's 2015. A VPN is the settled method for accessing sensitive services inside a private network. Doing otherwise may create great nerd cred but doesn't make you do your job better.

sshd would still be authenticated. It's defense in depth.

Why not just do away with port knocking and use keys?

the code for the VPN is better because...?

It's not necessarily better. But now you have two layers of security (VPN + SSH), rather than just one.

And as others have mentioned, either way it's still good practice to disable password auth, so that you can only connect to SSH using a public/private keypair.

Even better don't use default ports. Or have a second ssh that doesn't except any IP address at port 22 and than have your non-standard port with keys and limited user names and if possible a white list of your IP addresses.

Not using default ports will mildly confuse automated scans and do absolutely nothing to a determined attacker. Or somebody with nmap, which is not the same thing.

If you're whitelisting IPs, you may as well run it on port 22.

No it makes it harder and more of a pain. Trust me I have a friend who loves breaking into my personal server. That one trick two ssh running on different ports screwed with him for a long, long time. He is a genius of a hacker and has been doing it for a living for years. When he finally got in he was so pissed that threw him.

You are describing an anecdotal instance of a person whose capabilities are not established being thrown by something that nmap will catch on a normal scan.

Color me skeptical. I shall decline to "trust you."

nmap the whole internet isn't very fast

Scanning the internet isn't that slow

https://www.youtube.com/watch?v=UOWexFaRylM

> Trust me I have a friend who loves breaking into my personal server.

Sterling work establishing your own competence there.

Not my competence it his competence I trust and I got him good with that one since it never occurred to him that one stupid trick messed with him for so long. Lie 5 minutes a month.

One small benefit of using a non default port is that it keeps down the noise from automated scans. So any "real" suspicious activity will now stand out as it is not drowned out by the noise anymore.

If you do this, keep it in the privileged range (< 1024) or you run the risk of your ssh server crashing and some malicious normal user binds to your unprivileged port with a fake sshd and grabs your root password.

If there is a defect with VPN and you gain arbitrary execution then you'd have access on the system as whatever user the VPN was running as. You don't necessarily have to break VPN and SSH.

The machines running your VPN are presumably not the same machines you're trying to access via SSH. A compromise in your VPN should't give anyone execution access to anything interesting.

If VPN is broken, you still need to break SSH

The reason that no one has given yet is that you can monitor more carefully when you have a VPN. With a VPN, you can follow the bastion model; the VPN server runs only the VPN code and nothing else (with as much crap removed as possible), with a really restrictive SELinux policy, every tiny error logged and forwarded.

So now, since any attack has to be through the bastion, and all bastion errors are looked at by a human (because there should be only a few of them), then you're more likely to notice a breach more quickly because it won't become caught up in your general logs.

It should be noted that it's as easily possible to have the bastion server run an SSH server, and allow SSH access to other servers on your network.

Reply on news.ycombinator.com