0

I am about to push hard against the powers that be and strongly recommend that we shift our many (20+) consultants from direct public access to RDP & SSH to VPN clients (connecting to a VLAN/subnet that has restricted access to only necessary resources).

Given that we have a third-party SOC managing an IDS and monitoring connections, what are the risks of exposing RDP and SSH to the internet that forcing remote access via VPN will solve?

msuozzo
  • 268
  • 2
  • 7
mbrownnyc
  • 333
  • 2
  • 8

1 Answers1

2

There are two risks that immediately occur to me that would be reduced by using a VPN

  • You're avoiding the risk that a single vulnerability provides access to your systems. With straight SSH/RDP a remote code execution vulnerability in the service could allow complete compromise of your environment. With a VPN which then allows access to the service, the attacker would need to compromise the VPN service and the remote access service.

  • Username/password guessing. Most base RDP access (and SSH unless you're using key based authentication) is done using username/password combinations. If you expose this directly on the Internet you run the risk of someone either getting access to the system directly by guessing the creds (and there are lots of bots out their doing password guessing attacks these days) or locking out your users (assuming you have account lockout in place). VPNs tend to have better support for 2FA, so it's likely to be easier to implement that control with a VPN in use. Also if you de-couple the logins, at least if they attack the VPN accounts it may not affect the underlying OS logins.

Rory McCune
  • 60,923
  • 14
  • 136
  • 217
  • Thank you. In this case, our third-party SOC managed IDS will alert on brute force activity; however, `TFA` is a huge advantage. – mbrownnyc Jul 11 '14 at 13:33