Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
Port knocking? – Xepoch Oct 15 '10 at 21:16
Yeah, that would help. I was more asking about what sort of protection is enabled by default – codeulike Oct 18 '10 at 9:27
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! – Ryan Ries Aug 21 '12 at 12:26
@Ryan could you add an answer with a bit more detail on that? – codeulike Aug 21 '12 at 14:28
@codeulike Consider it done – Ryan Ries Aug 21 '12 at 14:42

3 Answers 3

up vote 6 down vote accepted

(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.

share|improve this answer
Yet the brute force attacks with (wrong) usernames dictionary are allowed (no policy to stop them, something must be put in front) – Alfabravo Aug 21 '12 at 15:50
The question is about random username/password attack via RDP, and answer here not covered this – MohD Dec 14 '12 at 16:13
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. – Austin ''Danger'' Powers Nov 24 '14 at 8:34
@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. – phoebus Nov 24 '14 at 8:42
Don't take it personally! :) It takes under an hour for an attacker to find internet-facing forwarded RDP ports and to start brute forcing them dozens of times per minute. Anyone who follows that advice will get locked out all the time. Instead, you could create a rule in Windows Firewall to only allow inbound connections from "good" IP ranges (i.e. your own). Using a 3rd party tool like RdpGuard to automatically block bad IP addresses, or using SSH (as suggested by Ryan Ries). Those are three better solutions which won't get you locked out of your own server right there! :D – Austin ''Danger'' Powers Nov 24 '14 at 10:54

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:

share|improve this answer
So this is an out-of-the-box way to make RDP more secure? Fantastic for AWS instances etc ... – codeulike Aug 23 '12 at 11:08
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. – Ryan Ries Aug 23 '12 at 13:11

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.