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

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.