RDP security using RD Gateway vs a Win 7 P2P network vs GTMPC

Hi experts,

I apologize as I should know this, but I am trying to make sure. I just purchased Windows Server 2016 Standard, but I have been running a domain on SBS 2008. It is called TS on SBS 2008, but I believe it is now RDS and RD.

I would think that using a client/server domain with a gateway for RDP connections that can then connect to the various clients would eliminate depending on the router, using port 3389 and port redirection. Of course, you can change the default port, but you would still have a port which is open that hackers could attack using brute force.

One person not on EE has told me that by using Group Policy settings locally and apply network authentication, etc, it will be just as secure. He argues that you can use 3389 as long as your security and encryption settings are set up correctly on the local computers, specifically the client encryption level.

I am of the belief that I can use the gateway along with using a certificate that gives me SSL using port 443. Finally, would you have to use a server OS to have a TS or RD Gateway or can one be made on Win 7 or Win 10? And, is a domain more secure than a workgroup on a client/server setup?

Finally, given all that, would GoToMyPC be more secure than either one of the above?


Who is Participating?
Adam BrownSr Solutions ArchitectCommented:
First, Yes, TS was renamed Remote Desktop Services in 2008 R2's release.

The subject of RD Gateway and Group Policy is fairly significant, so I'll try to answer as succinctly as possible...

First, RD Gateway does not remove port forwarding from the equation...it simply moves the forwarding from port 3389 to port 443. The person who told you it is just fine to have port 3389 on the Internet is not correct. Doing that puts a massive target on your network and opens you up for brute force attacks and significantly increases the likelihood of breach. Several years ago it was okay to have 3389 on the Internet, but no longer. Hackers routinely scan the Internet for port 3389 as it's a very easy way to get into a network. In smaller environments without a lot of users it can be easier to control passwords and whatnot, but users will always set passwords that aren't secure and having 3389 will eventually allow someone to take advantage of that fact. Moving RDP to port 443 reduces the likelihood of this occurring because the RD Gateway service doesn't respond like an RDP session, so it's less likely to be attacked via scripts designed to attack RDP. Then there is the fact that if you use an Internal CA to generate your certificate for the RD Gateway server (Yes, it requires a Server OS to have an RD Gateway on your network), only computers that have trusted the CA will be able to connect at all, since RD Gateway refuses connection if the certificate returns an invalid trust for any reason. This is a *much* more secure solution, since you can control who has access to the Root CA Certificate and which devices can install that certificate much more easily than you can control your passwords.

Also, domain is much more secure than workgroup in Windows for a lot of reasons, one of the biggest being that user credentials in a Domain can't be "Cracked" through the use of rainbow tables and other password cracking techniques. There are techniques that can be used to break into a domain and gain administrative access, but password cracking is not generally an effective technique. Group Policy also makes it a lot easier to manage workstations and control access to them. It also provides tools for locking down access to prevent unauthorized use if needed.

GoToMyPC isn't more secure than RD Gateway using an Internal CA certificate as I mentioned, but is potentially more secure than straight RDP. The difficulty in answering this question is that you are dealing with a third party whose security practices are not under your control. If GoToMyPC is compromised in some way, it can cause problems, and other third party remote access applications have had serious vulnerabilities that resulted in session eavesdropping without user knowledge in the past (Teamviewer, specifically, had a problem with this a couple years ago, if I remember correctly).
Bert2005Author Commented:
Thanks Adam,

That is an awesome answer. It is late here, so I want to read it again tomorrow. I may have a couple of follow-up questions if that is OK.
Again, thanks for taking the time.


FYI: You will definitely be getting the points. You answered first, and you answered the question. I am just hoping to clarify a couple of things. It will help me and may help someone else who is as dumb as I am with this stuff.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.