I’ve just been asked to port=forward a SSH endpoint.
It’s not something I would do for myself: I always start with a VPN. But there is a kind of expectation that I’ll just do it: it’s done that way before and already. It doesn’t strike me as being any different than exposing a RDP endpoint.
What do I do?
Who’s asking you to do it?
SSH with a properly-configured private key is just as secure as a VPN tunnel will be.
I wouldn’t worry about the security of SSH… it’s secure enough. I would worry more about what I expose to hosts on these subnets that I don’t control. Like I’d never do this on OSX or Windows or a similarly unhygeinic environment.
Properly configured, SSH is a lot more secure than an exposed RDP server, as others have said.
But you say you’re being asked to forward a port, which suggests that you don’t directly control the host you’re forwarding to. If the admin for that machine configured its SSH server to accept passwords and allow root logins and used a dictionary-based password, that box will get owned within seconds.
A bad configuration will circumvent the protections of even the world’s most secure protocol.
I could control the host, if I had any idea what I was doing. It’s just a SVN server and doesn’t need to do anything else.
I don’t see how SSH is more secure than RDP, given the OpenSSH roaming bug and the list of other corrected vulnerabilities, but there you are
Anyway, yes, there was an expectation that we would just use a password. I may be able to work out how to require a key instead.
How would you lock down SSH to only allow SVN?
It might be best if I transferred the SVN server to a new instance. It’s on an old copy of OpenBSD at present. Have you got any comments on that?
(Or a better way to expose SVN. I was just asked to port forward SSH so he could use SVN)
Putting any system out on the public internet that is “on an old copy *” is a very serious problem.
Let’s put this in context using a program like Masscan you can scan the entire Internet in less than 5 minutes. Think about that…if you know how to fingerprint a vulnerability you can find every publicly reachable host with that vulnerability if you have a well connected host.
If you care about security, which you seem to care about here you should be running automatic updates and applying security updates as soon as they are available. While not perfect, if security is your concern, you should probably move these repos to a cloud provider who will make these updates for you.
All software will have exploits and the reality is if you don’t know how to limit an SSH instance to a single application or service you probably don’t have the skill set required to minimise the attack surface.
Whitelisting IP’s, using only keys and using tools like fail2ban are some ways of helping mitigating the risk if you must.
Note: that RDP just had CVE-2019-1223, CVE-2019-1224, and CVE-2019-1225 which all leaked private memory data… RDP is harder to secure because the security was added later and some project choices. Any product product having public exploits really relates more to do with how valuable it is to target offers or how popular it is vs saying anything about the security qualities. You should assume that all of these services have holes.
Is it totally out of the question to migrate to a cloud-hosted Git, like github or bitbucket?