Solved

Is RDP and RDS the same?

Posted on 2014-11-09
18
74 Views
Last Modified: 2015-07-09
We all know RDP open to the world, or for that matter open at all, on the firewall is a security no-no, but is deploying RDS servers include the same vulnerabilities?
0
Comment
Question by:Peter Wilson
  • 8
  • 6
  • 2
  • +1
18 Comments
 
LVL 56

Expert Comment

by:Cliff Galiher
ID: 40431536
RDS is the service. RDP is the protocol. They are intertwined.
1
 
LVL 2

Author Comment

by:Peter Wilson
ID: 40431565
But I'm confused on the difference of having a gateway server and having 3389 open. The gateway uses 443 and because so doesn't have the same vulnerabilities, correct?
0
 
LVL 56

Accepted Solution

by:
Cliff Galiher earned 167 total points
ID: 40431672
The gateway has extended policies that can be set as well as APIs for 3rd parties for 2FA. If all you did was have a gateway with default policies forwarding traffic to a single RDSH server then the risk assessment is essentially the same.
1
 
LVL 24

Assisted Solution

by:VB ITS
VB ITS earned 167 total points
ID: 40432044
Hi Peter, I would recommend you have a look at this article from Microsoft which answers some of your questions above.

In a nutshell you can better secure remote RDP access to your environment by using the Network Access Protection (or NAP for short) feature that the RD Gateway utilizes compared to enabling direct RDP access (i.e. forward port 3389) to your server. See this article for further information regarding how RD Gateway works with NAP: http://blogs.msdn.com/b/rds/archive/2009/08/17/deploying-rd-gateway-r2-server-with-nap.aspx
0
 
LVL 4

Assisted Solution

by:HostOne
HostOne earned 166 total points
ID: 40432166
As Cliff said, RDP is the protocol (Remote Desktop Protocol) and RDS is the implementation of that protocol. So yeah, they're the same thing and in terms of terminology, both are often used to mean the same thing.

Most people use the gateway server to assist with load balancing between the multiple remote desktop servers (RDS) in a farm or to work around restrictions on accessing port 3389 remotely, where port 443 is usually allowed for outbound connections. Not for enhanced security. I'm not saying you can't make things more secure using a RDS Gateway - you most certainly can - just that most people don't use it for that purpose.

I wouldn't say it doesn't have the same vulnerabilities - certainly not by default - because in large, it does have the same vulnerabilities. If you allow users to RDP straight to port 3389 on your remote desktop server / terminal server or you ask them to connect via a gateway, and in both cases they have a rubbish password, you're still pretty much in the same place.

For example, simply saying the gateway uses 443 offers no enhanced security whatsoever. RDP natively uses a certificate to encrypt the traffic in any case. Try it - go connect to an RDS that's configured "out of the box" and you'll see a message about the certificate not being able to be verified (http://support2.microsoft.com/kb/186607 - data is encrypted by default over RDP). Simply changing the port to 443 instead of 3389 and tunnelling over TLS isn't going to make this process more secure.

Sniffing traffic is not your concern with RDP. Crappy username/passwords are. Simply having an Active Directory policy in place to enforce complex passwords unfortunately doesn't stop people using things like, literally, Password1. It just says they need to be 7 characters, upper/lower and a numeric.

NAP is probably the last thing you need to worry about (not saying don't worry about it - just that there are other things you need to get done first!). If you control all endpoints in the process, the RDS and the people connecting to it, NAP can help but if not, then I'd recommend you simply deny users the ability to map their local drives and just try to focus on people having genuinely strong passwords and minimising the damage they can do, if connected to the RDS. However if you already control all endpoints in the network, then frankly NAP security is a little bit redundant because you already (largely) trust the people and devices connecting to you and already have control policies over them. You'd be better off limiting the IP addresses that you allow to connect, if you can.

If you're opening up RDP from the world, you're opening up a risk. First things first - work on minimising the risk by controlling what people can do, once connected to the RDS, rather than trying to worry about if they have up to date AV on their home computer. If your concern is malicious attackers gaining access, your #1 concern is password strength because all the other policies are useless if you allow someone with permissions to copy or delete data to login with the username fred and the password TrustNo1.
1
 
LVL 2

Author Comment

by:Peter Wilson
ID: 40449148
Thanks for all the insight and info.

So the scenario is that we do open it to the world...it is not using 3389 but rather 443 for remote users (externally) and thin client users (internally) to access network resources. On top of which we have user with local share access to their C drive and other network share access plus one application.

After reviewing everything, it seems like we are not in good shape. I was thinking of implementing 2FA via

Since GP doesn't handle password policies very well as you have pointed out does this seem like the best course of action for us?

Thanks!
0
 
LVL 4

Expert Comment

by:HostOne
ID: 40449168
HI Peter,

I hate to answer it such, but "it depends".

It really depends on what you're doing, what you're exposing, what your budget is, how much you are prepared to put into this, etc. I know all data is important and needs to be secure but spending $20k on setting up a high security system is out of the budget for many small businesses.

I know this is not the "high security" answer - but if you have a simple remote desktop environment in place, with a bunch of fairly static, reliable users who don't do much out of the ordinary, you can probably just leave things as they are and make put your effort into making sure that passwords are not completely retarded (you'd be surprised what some people get away with, with just default "strong passwords" enabled in AD). That will probably suffice for many smaller businesses.

RDS is not an inherently insecure protocol. Traffic is encrypted by default (you do not need to tunnel this over HTTPS because it's already encrypted at the same level). Since version 6 or 7 (I forget which) it forces initial handshaking, encryption channels and so on to be established before the password is transmitted, so I don't see a lot of benefit in using HTTPS to establish the connection.

The weakness in RDP comes from that fact that all that prevents a user from gaining access is a simple password challenge. There's no by default IP restriction, or remote party restrictions - just a simple password challenge, so if the password isn't great, you're in trouble. The thing is, I'm willing to bet your Exchange Server (should you have one) is in the same boat with the same username and passwords protecting it. It's got basically no more or less security than RDP does.

2 Factor authentication will go a long way to helping with that issue and a long way to making your life miserable. Forcing users who used to be able to "just log on" to suddenly need their phone to log on, without a strong justification (unfortunately, the kind of user who uses "Awesome1" as a password isn't going to be on board with this) isn't going to be the best experience of your life.

I think a much cheaper and probably more effective option would be to get a 3rd party strong password enforcement tool. Sure, it'll annoy users just as much as anything else but it will actually be useful, too. Oh - and make sure you keep the TS patched.

Sorry to be so down on it - what you're trying to do is laudable and I wish you all the best. I've just been through these exercises many times and I can tell you, the initial discussion of "we need to be more secure" might get a lot of head nodding and agreement - but the implementation of said security rarely involves the same level of end user enthusiasm.
1
 
LVL 2

Author Comment

by:Peter Wilson
ID: 40449177
Excellent points!

Here is some perspective, we are a ~300 user environment and users are exactly as you described...a bunch of babies...it's really baby sitting from 9-5. And I completely see and agree with your point about management agreeing to tighten security but users hating it and ultimately ending up in my lap.

Anyway, what 3rd party password enforcement apps do you recommend without busting the bank?
0
 
LVL 4

Expert Comment

by:HostOne
ID: 40449193
I think if you set people to get locked out for 15 minutes if they get their password wrong 7 times in 10 minutes (which I believe is the default AD setting for password lockout policies) then this will go a long way to stopping brute force attacks.

I have heard that http://www.l0phtcrack.com/ is very good but I have not used it.
1
IT, Stop Being Called Into Every Meeting

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

 
LVL 2

Author Comment

by:Peter Wilson
ID: 40449194
Ok, thanks! So it looks like l0phtcrack is kind of hands on and post care, right? It seems like you scan and it finds bad passwords that you then need to take care of if I understand it.

We are also going to implement password rotation...I think every 60 days.
0
 
LVL 24

Expert Comment

by:VB ITS
ID: 40449867
Hi HostOne, whilst you make some very, very excellent points regarding passwords and the overall inherent secure nature of RDP, I think you may have misinterpreted what I was trying to say. I'm mostly at fault though for not elaborating further as I typed that reply while I was in a rush.

I was merely trying to point out that from a manager's point of view, RD Gateway has a number of security benefits as opposed to opening port 3389 externally.

When you open up port 3389 to the world, one of the main issues is that you cannot easily control with any granularity which of your staff members can log in to the Terminal Servers remotely. Whoever that already has access to your Terminal Servers internally will be able to access it externally by default. There's also the risk of staff stealing company data if you don't have the necessary settings to disable printer/local drive redirection.

This is where something like RD Gateway comes in. Provided you set up the necessary policies beforehand, you can mitigate a lot of  the vulnerabilities present in direct access over port 3389. This article sums up what I'm trying to say quite nicely: http://technet.microsoft.com/en-us/magazine/hh708743.aspx

I do 100% agree with you about the above points though. Weak passwords can be your downfall.
0
 
LVL 2

Author Comment

by:Peter Wilson
ID: 40450561
Thank you for the clarification. Great points as well!

I also downloaded http://www.l0phtcrack.com/ and it is good at finding passwords that violate policies aka are weak but I'm looking for something with more automation.

Does anyone know of any good password enforcement utilities?
0
 
LVL 4

Expert Comment

by:HostOne
ID: 40451450
Thanks VB ITS - your points are all great, as well.

AS there's no additional licensing implications for using the RD Gateway, I would agree that you should implement it in the near future, as well.
1
 
LVL 2

Author Comment

by:Peter Wilson
ID: 40451585
Just to be clear we already have Rd gateway implemented.

To the point of security I need a better password enforcement utility.

Any ideas?
0
 
LVL 4

Expert Comment

by:HostOne
ID: 40451603
Maybe try this:
http://blogs.technet.com/b/seanearp/archive/2007/10/06/windows-server-2008-fine-grained-password-policy-walkthrough.aspx

It shows you how to enforce different password rules by AD OU or by AD group.

So, yes, it still uses Microsoft's rules for complexity (which suck) but on top of that you could add a rule that if someone has access to RDS, then they must have, say, a 10 or 12 character password as minimum. That would allow you to not harass non-RDP users with longer passwords but it would force users who have dictionary words + a number to rethink their password because there's not a whole lot of 12 character dictionary words.

Even if they use a stupid password, like (i.e.) PasswordPassword1, when combined with a lock out policy of say 30 minutes on 5 wrong guesses, the probability of someone cracking a password from outside the organisation, with just 5 guesses an hour, against a 12 character password is...exceptionally remote.

By using the above linked approach, you can just force these rules on users who have RDP access, instead of, say the account lady who just wants to come in and do on site data entry at an approved terminal.

That will go a long way towards fixing the issue you have with passwords not being great. The next issue you'll face (not to continuously raise problems) is that people can set their RDP client to save the password for connections or just write their password on a sticky note and leave it stuck to their laptop (yes, I've seen this done). So, if they're company laptops, the next challenge you'll have to raise is that, when they leave the building, they need to a) have a password for login to the OS (they probably already do) and b) have an encrypted volume, so no one can just read the disk or reset the password with a Trinity USB key to log in. Those steps can easily be handled by Active Directory and should be considered, if security is a real concern.

Fixing the sticky note problem is a whole different issue. :-P
1
 
LVL 4

Expert Comment

by:HostOne
ID: 40451612
Oh sorry - one more issue to raise, so you're forewarned. If you're using password time limits (i.e. new password every 30 days or 60 days, etc.) and Remote Desktop Gateways, this is a bit tricky.

Generally, when you use a RD Gateway, you would not use the RDS as this role, because (presumably) you'd have multiple RDS for 300 users and a gateway would be separate, for redundancy.

When a user logs in with an RD Gateway and their password has already expired, they cannot log in. The connection to the RD Gateway will fail but, because they won't yet have been passed to the RDS by the gateway (because the gateway will not accept their expired password) to be presented with a password change screen, they won't have any way available to change their password and, as such, they simply cannot log in. So you'll be getting an 8pm phone call to reset their password.

So if you plan to time limit passwords you need to make sure people get a warning in advance and they actually listen to the warning. For users who rarely log in via RDP and mostly just get mail on their Android or iPhone, they'll just suddenly find their phone stops working for email and they have no way to fix it.

And on that final note, one last related issue. When a user changes their password, remind them to change it on their BYOD devices, too. Otherwise, their mobile phone is just going to bang away at the Exchange server with the wrong password and get their account locked out. So this starts to lead down the path of remote/mobile/BYOD management.

As you can see, what seems like a simple change to passwords or RDP access leads into a never ending tunnel of changes! :-)
1
 
LVL 2

Author Comment

by:Peter Wilson
ID: 40451619
Wow thanks for revealing the rabbit hole! This is going to require much more planning than I originally anticipated. I was going on a 60 or 90 day password rotation with a 5 times permanent lockout. We have a nifty password resetter so I'm not thinking it was going to burden us too much but then again....

We are planning to role SSO as many places as we can...office 365, ssl-vpn, RDS, etc. I was hoping that a prompt from one of those locations would help remediate the RD gateway scenario you painted above.
0
 
LVL 2

Author Closing Comment

by:Peter Wilson
ID: 40875651
Thanks again for all your input!!!

Sorry for closing so late. I need to work on that. :(
0

Featured Post

Better Security Awareness With Threat Intelligence

See how one of the leading financial services organizations uses Recorded Future as part of a holistic threat intelligence program to promote security awareness and proactively and efficiently identify threats.

Join & Write a Comment

Suggested Solutions

Resolve DNS query failed errors for Exchange
Today, still in the boom of Apple, PC's and products, nearly 50% of the computer users use Windows as graphical operating systems. If you are among those users who love windows, but are grappling to keep the system's hard drive optimized, then you s…
In this Micro Tutorial viewers will learn how they can get their files copied out from their unbootable system without need to use recovery services. As an example non-bootable Windows 2012R2 installation is used which has boot problems.
In this Micro Tutorial viewers will learn how to restore single file or folder from Bare Metal backup image of their system. Tutorial shows how to restore files and folders from system backup. Often it is not needed to restore entire system when onl…

759 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

18 Experts available now in Live!

Get 1:1 Help Now