1

I've seen this same question discussed for unix style servers- such as here Is it normal to get hundreds of break-in attempts per day?

But I would like to know if there is a similar recommendation for windows based servers. My server has RDP open to the net, and at times I've been hit with so many login requests it actually DOS'ed the machine. I've changed my port number and this helped for a while, but now I see they're back to hitting on the "new" port as well. I'm also seeing that these login attempts come from many source ip's, so it is distributed.

Is there a service or app that can see all the failed logins and temporarily ban the ip's? Like a fail2ban for win?

2
  • 2
    My server has RDP open to the net - which in my opinion is the real problem here. Can't you force users to have to connect via VPN before they can access hosts with RDP? Or if you must have the service public, what about avoiding port 3389? edit: Just read you've changed the port.
    – Bryan
    Jul 11, 2012 at 21:49
  • There is quite new and free utility available now serverfault.com/questions/282510/… Jul 7, 2021 at 12:09

6 Answers 6

4

I'd really recommend you to migrate away from direct RDP from internet if it is feasible. If not, make sure you are patched for the RDP remote code vulnerability discovered recently. The exploit code is the part of metasploit now and is also available in the wild.

Changing port doesn't help much because tools like nmap can trivially find it. You can change the port, but you can't change the fingerprint.

2

You have a few options available to you.

  1. Mitigate The Attack Point - Implement something like TS Gateway which will have all of your RDP traffic go to the standard SSL port of 443. This will allow you to close off port 3389 from the outside world, reducing (if not eliminating) your brute force attempts. That said, the Mac RDP client is not compatible with TS Gateway as of yet so if you have Macs connecting then you may be out of luck.
  2. Implement an account lockout policy - Allow for 5 incorrect login attempts before locking out the account. Most brute force attempts happen to specific names (as I'm sure you can tell) so they will stop trying if their account gets locked out. Occasionally you will see a bot that will try several names however most of them will only try a specific name (ie owner, root, test, besadmin, etc)
  3. You could implement a VPN - Similar premise to the TS Gateway a VPN would put your users inside the firewall, again allowing to close off port 3389. The caveat here is that most sysadmins don't want unknown computers connecting to their VPN so I would only implement this if the computers connecting are under your control.

There are third party tools available to help you block brute force attempts, however as you can see this can be done without them as well. Even before we had a TS Gateway established, implementing a lockout policy drastically reduced the traffic we saw on port 3389.

2
  • 1
    1.) This is a good suggestion, however it means you're going to lose compatibility. 2.) This is an awful idea because an attacker can then lock out an account if they repeatedly intentionally fail to authenticate to an account. It's best to block the IP address from continuing to attempt logging in. 3.) A VPN is fine for only trusted users who are going to be making transmissions from within the network, nothing more. It's a bad idea to just let anyone on it, as you had pointed out. Jul 11, 2012 at 23:15
  • 1
    If you look at the audit logs of failed login attempts you'll notice that they use very common usernames - administrator, sql, owner, root, etc. These are usernames that should either not be used, or should not be granted access to log on to the terminal server - users not granted logon access to the terminal server will not be affected. If you're concerned about locking out a legit account then set a small time frame like 30 mins lockout. The attacker will hit a wall and move on to the next IP address
    – DKNUCKLES
    Jul 11, 2012 at 23:54
2

Evan anderson put together a tool called ts_block to block terminal services/RDP requests. It's discussed here, How to stop brute force attacks on Terminal Server (Win2008R2)?

The tool itself is available here https://github.com/EvanAnderson/ts_block

1

maybe you can try http://rdpguard.com/

0

Is it 2008 server? You can turn on NLA (Network Level Authentication) which helps as the session doesn't establish until credentials are authorized.

0
0

Really the problem is as many mentioned is RDP open to the Internet. It depends on your situation but a VPN is the best solution if it fits your situation.

A really really hard password can help. 12 or more random characters and don't be afraid to have 20 or 30 characters. This is not a real password but something like "hh078A$%jhSqS69DdCtq". You save it in a safe location or in a password manager like KeePass or any number of commercial ones like LastPass. This only helps for preventing successful attempts but it won't prevent DDoS.

How about running openssh on the machine and allowing only key authentication? You can forward the port using SSH and their are tools that make this very simple. I like bitvise. In this case RDP would only be allowed from localhost.

You can block by IP. If you have a dynamic IP and if you have a firewall like pfsense or opnsense then you can block by dynamic DNS. I like duckdns or afraid but there are others. If you don't have such a firewall then I heard of scripts that will update your Windows firewall every so often.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .