1

By configuring ssh, only set IP can log in over ssh. I found this important since I'm going to provide public-facing web services which would expose my IP. Moreover, I can't use a CDN for some reason I prefer not to share. Furthermore, I need to protect against zero-days in sshd. (Credits: @mti2935 )

However, I don't have a static public IP and do not have control of the network environment. People on the network I'm using are potential attackers and I can't move to a new network. Plus the VPS provider does not provide a console application (or something that can change the configuration) in its web interface. For some other reason, I prefer not to pick another provider.

Thus, it is infeasible for me to whitelist my current public IP in the target server.

Thus, I decided to rent another VPS and use it as the midpoint. On this VPS, I follow the best practices for ssh without setting up IP whitelisting. On the target server, I only whitelist the midpoint. Then I ssh to the target server using the midpoint. Both VPS are of one provider. The midpoint is not going to be used for anything else.

Does it improve the security of the target server, or does it pose additional risks to it?

Is this problem better solved using other methods?

Improve this question

3 Answers 3

Reset to default
3

By allowing SSH connections to the midpoint VPS from any source IP, then allowing SSH connections from the midpoint VPS to the target VPS, you are just moving the security hole from one location to another. At best, this is 'security by obscurity'.

I would suggest you scrap the idea of the midpoint VPS, and try to harden security on the target VPS as much as possible. First, you might be surprised that the IP address dynamically assigned to you by your ISP changes less frequently than you think. The IP address assigned to me by my residential ISP provider (Comcast) has not changed in over a year. So, allowing SSH connections only from your ISP-assigned IP address may be feasible. If your IP changes, you can always access the console of your VPS via your VPS provider's web interface, and update that firewall rule with your new IP.

If your IP changes too frequently, and this gets to be a hassle, then you might want to use a dynamic DNS service, like DynDNS, which will create a hostname that will always point to your current IP address. Then, you could create a cron job on your server to update the firewall rule automatically, when your IP changes.

Last but not least, you might want to disable password-based authentication, and only enable public key based authentication, on the SSH server. I think if you do this, and only allow connections from your (current) IP, you should be able to sleep reasonably well.

Edit 3/1/2022: To harden your SSH authentication even further, you may want to consider implementing FIDO2 authentication, using a Yubikey or similar device. See https://www.stavros.io/posts/u2f-fido2-with-ssh/ and https://cryptsus.com/blog/how-to-configure-openssh-with-yubikey-security-keys-u2f-otp-authentication-ed25519-sk-ecdsa-sk-on-ubuntu-18.04.html for more info.

Improve this answer
6
  • Agree. Even whitelisting IP address is not always necessary. Using public key authentication, disabling password-based authentication, and making sure your server is up-to-date are more than sufficient to secure SSH on your standard server.
    – Conor Mancone
    Commented Feb 7, 2020 at 15:47
  • Conor, Good point about keeping the server up-to-date. Thank you for including this in your comment. I try to restrict access based on whitelisted IPs whenever possible, in case of any zero-day vulnerabilities in sshd.
    – mti2935
    Commented Feb 7, 2020 at 16:26
  • Indeed, I'm definitely not saying that an IP whitelist is a bad idea. I've got some servers for my personal use where I don't bother because the value is low and I don't want to worry about the inconvenience of managing the white list. With public key authentication, the risk of break in is already low, so the extra layer of security provided by an IP whitelist is not worth the effort. That doesn't change the fact that in many cases an IP whitelist is worth the effort (or in fact you may disable public ssh all together!).
    – Conor Mancone
    Commented Feb 7, 2020 at 16:49
  • Hi! Thanks. I further clarified the constraints. People on this network are potential attackers; the VPS provider does not provide console application in their web interface; I need to protect against sshd zero-days.; I already use pub-key auth with a security key. Sorry about that.
    – freezable
    Commented Feb 8, 2020 at 16:39
  • In that case, I would definitely use iptables to restrict incoming ssh connections to only those originating from your source ip; and use the solution that I described in my answer to update your source ip in the iptables rule whenever your source ip changes.
    – mti2935
    Commented Feb 8, 2020 at 17:04
0

No, IMHO, this is still a chain, a "consistent" way to build security. This scheme are still vulnerable to the same MiTM attacks with or without midpoint. Instead, try to add "parallel" security, like MFA. This will protect you from MiTM, however you will still be susceptible if someone will have a physical access to your computer. In order to protect against that, think about adding additional layer, like non-persistent VM which uses for example a hardware ID (HWID will be based on something static, there are ways to do it) to generate certificate, and a USB token and USB stick with settings.

This is just an example, there I am sure better ways to do it, and there should be a reasoning behind them, like not everything needs to be secured like Fort Knox.

Improve this answer
2
  • Hi! Thanks. I already use pub-key auth. As for the MiTM attack, are you referring to ssh-mitm? If so, I would consider it breached if the host key is changed.
    – freezable
    Commented Feb 8, 2020 at 16:47
  • Ah, sorry then, I failed to notice that. Pub key authentication is more secure than using password based authentication, but considere "strong authentication" not "MFA". Again, mostly this model are susceptible to MiTM attacks that impersonate wifi, or any internet access points. I would have tried to create a hardened VM with JS disabled and encrypted disks and accessed the target server from it. But it's true only if you travel a lot and use various internet APs. If not, hardening your own PC is enough.
    – Rashad Novruzov
    Commented Feb 8, 2020 at 20:24
0

After having read the answers, I think I have developed a model that is sufficiently secure for my threat model.

I get three VPS.

I allow my IPs in the first VPS. I allow only the first VPS's IP in the second VPS's configuration. I allow only the second VPS's IP in the third VPS's configuration.

  • I use the first VPS as a SSH tunnel.

  • I login to the second VPS via the tunnel and use it to access the third VPS.

  • I provide public-facing web service on the third VPS.

This way, when a zero-day is found in sshd: (assume the attack takes a little time, somewhere around 1 minute; the attack doesn't break the functionality of IP address whitelisting)

  • If attackers decide to attack the third VPS directly, it is reasonably secure since it only allows IP from the second VPS.

  • If attackers use the network I'm using to get into the first VPS, they would likely to try the third VPS first, thus they would not be able to find out the second VPS before I delete the machines from my VPS provider.

    This process can be made automatic.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .