K A
asked on
Connecting through VPN then through RDP
Isn't VPN access just as susceptible to hackers as RDP access? Consider that we are trying to solve very frequent attempts from an outsider to connect to a user's workstation using RDP. We are seeing Windows Event 4625 about every 5 seconds. The user connects successfully from home quite often, but the "brute-force" attacks have become too much for us to stand. It's been recommended that we deploy a VPN for the user to connect to, then allow them to connect to their workstation using RDP.
Wouldn't establishing VPN capability through the firewall just expose different ports to the internet? How is this safer than an RDP connection?
Wouldn't establishing VPN capability through the firewall just expose different ports to the internet? How is this safer than an RDP connection?
VPN, if setup correctly, it much more secure than simply opening RDP up to the outside world. At a minimum, you would want to restrict the RDP ports to the remote users IP / IP range at the very least.
Using VPN with encrypted tunneling and certificate(s) is vastly more secure than direct RDP port access.
VPN (if setup correctly) will establish a secure, encrypted, certificate based pathway into the network hosting the RDP server, which the remote user can then connect to. If the remote user does not have the corresponding certificate for that user, then no access is granted. Depending on which VPN tech you choose, more safe guards can be added, including 2FA, restricting from IP addresses, etc.
The VPN field is simply so vast, it would be impossible to give all the options here, but to answer your question, yes, secured VPN would be much better than what you are doing now.
Using VPN with encrypted tunneling and certificate(s) is vastly more secure than direct RDP port access.
VPN (if setup correctly) will establish a secure, encrypted, certificate based pathway into the network hosting the RDP server, which the remote user can then connect to. If the remote user does not have the corresponding certificate for that user, then no access is granted. Depending on which VPN tech you choose, more safe guards can be added, including 2FA, restricting from IP addresses, etc.
The VPN field is simply so vast, it would be impossible to give all the options here, but to answer your question, yes, secured VPN would be much better than what you are doing now.
Just thinking logically, would already put you on the VPN path. Bruteforcing TWO things (VPN + RDP) takes longer and is MORE difficult than bruteforcing ONE thing (RDP only). Heck, if you don't like your VPN solution, just buy a new router, and voila, new VPN solution.
ASKER
Thank you all for your responses. We have deployed a hardware-based security appliance (i.e. firewall with VPN capability), and we very much like the additional security features that are included. However, our question still remains... perhaps we are missing something obvious.
To connect an outside user through the VPN to the internal network, and then to a desktop using RDP, still only requires a free downloaded VPN client, a username, and a password. Granted, once the connection is made it is encrypted, but still, all that has essentially been required is a username and password - no different than the old straight, port-forwarded, RDP method. Would someone please elaborate on how this is, in and of itself, more secure than straight RDP?
To connect an outside user through the VPN to the internal network, and then to a desktop using RDP, still only requires a free downloaded VPN client, a username, and a password. Granted, once the connection is made it is encrypted, but still, all that has essentially been required is a username and password - no different than the old straight, port-forwarded, RDP method. Would someone please elaborate on how this is, in and of itself, more secure than straight RDP?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks all... it appears certificates are the key. We'll put that in place. Thanks for all of your helpful comments.
hope it helps.