Does windows Remote Desktop have any protection against brute force attacks?

Question

If I were to have a server (Windows Server 2008) out on the internet that is allowed Remote Desktop connections, is there anything to stop random people from trying brute-force Username/password combinations?

e.g. would it lock out users or IP addresses after a certain number of failures?

Solution 1

(Edited per comments):

As noted, RDP should generally not be directly exposed on the public Internet. Limiting this exposure can be done in several ways, through simply blocking port 3389 access except over VPN, to using RD Gateway for a more advanced solution. If you have an IPS or IDS+Firewall that supports it you can use them to block hosts with repeated login failures.

For internal brute-force protection you can set lockout policies in the Local Security Policy. There are settings for account lockout duration, account lockout threshold, and how long to wait before resetting a lockout.

You can use secpol.msc to modify these settings: secpol.msc -> Security Settings -> Account Policies -> Account Lockout Policy.

Solution 2

Don't open port 3389 to the internet. Use a Remote Desktop Services Gateway (RD Gateway) and wrap yourself in the warm fuzzy blanket of SSL-protected RDP over HTTPS!

(It may still be known as TS Gateway on Server 2008 non-R2; don't remember.)

You can add the RDS role to Windows Server 2008 R2. The RD Gateway is a role service of RDS.

What this gives you is the ability to "RDP" to the RD Gateway using the regular RDP client (version 7+) over SSL-protected port 443, and not the traditional port 3389. Via that gateway, you can then seamlessly RDP to internal hosts that are on the other side of the gateway. You use RD CAPs and RD RAPs to control exactly who can connect to what. You use a PKI certificate for SSL purposes.

This is significantly more secure than regular RDP. Also it is not as susceptible to certain exploits that hit regular RDP recently, such as MS012-020.

You can find a very thorough tutorial here:

http://www.myotherpcisacloud.com/post/2011/11/23/Remote-Desktop-Services-Tutorial-1-(RD-Gateway).aspx

Solution 3

I notice this question is answered, but you have RDP "open" on the Internet. Alarm bells start ringing. You really need to think about front-ending it with an SSL VPN.

Comments

[codeulike]

Yeah, that would help. I was more asking about what sort of protection is enabled by default

[Ryan Ries]

Don't open port 3389 to the internet. Use a Remote Desktop Services Gateway and wrap yourself in the warm fuzzy blanket of SSL-protected RDP over HTTPS!

[codeulike]

@Ryan could you add an answer with a bit more detail on that?

[Ryan Ries]

@codeulike Consider it done

[Alfabravo]

Yet the brute force attacks with (wrong) usernames dictionary are allowed (no policy to stop them, something must be put in front)

[codeulike]

So this is an out-of-the-box way to make RDP more secure? Fantastic for AWS instances etc ...

[Ryan Ries]

RDP isn't terribly insecure on its own, but yes, I think RD Gateway is a fantastic tool. Using the Gateway by itself doesn't cost anything extra, it's only the full blown RD Session Host that you need CALs for. So yes, out of the box, free, SSL protected, only requires port 443, serves as a single point gateway to be able to access all your internal servers from. It's awesome.

[Mhmd]

The question is about random username/password attack via RDP, and answer here not covered this

[Austin ''Danger'' Powers]

This should not have been marked as the answer. It's a lazy man's solution which just causes another problem - your domain administrator account will get locked out. A useful solution would involve blocking connections from a consistently failing source IP address, not locking out the user account which is the target. You're basically just making it possible for the attacker to do a DOS attack on you by locking you out whenever they want. Sure, use this as a last line of defence but not your first line of defence. That should involve blacklisting the attacker's IP address.

[phoebus]

@Austin This is a very old answer, but I do I agree with you from a technical standpoint. That said as far as I know that sort of "fail2ban" blocking isn't implemented in RDP, sec policies, or windows firewall; I supposed I was being very literal in the interpretation of the question title, although it's hard to remember back then. When I'm not on a mobile device I'll add a clarification. No need to get snippy though.