How to stop brute force attacks on Terminal Server (Win2008R2)?

Question

I'm more familiar with Linux tools to stop brute force attacks, so I'm having trouble finding suitable tools for Windows. I'm running a Windows Server 2008 R2 with Terminal Server, and I'd like to block an IP after repeated attempts to login via RDP. Any hints?

Solution 1

to stop rdp login attempts, as already told, you need control of your firewall to isolate a particular ip. You can do some settings in Administrative tools -> Terminal services manager but can do nothing to stop one ip in this way. Maybe you've to consider a batch script to listen rdp port and control logon failures, so if there were a tot attempts (you choose the number...) by the same ip, then no other attempt for a known span of time could be. I'm not sure if it's possible, but could be a way...

Solution 2

You really should block these attempts at your edge firewall, if only with rate-limiting. If you don't have the ability to do that read on.

If you can't block at the edge firewall and need RDP open only to a subset of the Internet use the built-in Windows Firewall features to lock down incoming connections.

Finally, if you really must have RDP open to the entire Intenet you might have a look at the modified version of my SSH brute force blocker program for Windows that I have in a github repository. This script, ts_block, blocks brute force Terminal Services logon attempts on Windows Server 2003, 2008, and 2008 R2. Unfortunately, because of changes to the events logged by Windows when using the TLS/SSL security layer for RDP this script is becoming increasingly ineffective. (Why Microsoft chose to omit the IP address of the host attempting to authenticate is beyond me. Seems like that would be a pretty important thing to log, eh?)

Solution 3

I have a C# program that does exactly this. I had an issue on Server 2008 R2 where the event log didn't always list the IP addresses of the user (if they connected from the newer Remote Desktop clients). Some services implement their own credential check provider that doesn't provide all of the information you would want.

http://cyberarms.net/security-insights/security-lab/remote-desktop-logging-of-ip-address-%28security-event-log-4625%29.aspx

For Remote Desktop however I discovered that going into "Remote Desktop Session Host Configuration" and changing the RDP-TCP connection to have the security layer of "RDP Security Layer" instead of "Negotiate" or "SSL (TLS 1.0)" brought back the IP addresses.

Whether you really want to do this is another question for you, "If you select RDP Security Layer, you cannot use Network Level Authentication."

I found http://www.windowsecurity.com/articles/logon-types.html to be helpful. I used EventLogWatcher and bound to "*[System/EventID=4625 or System/EventID=4624]" so I could reset a bad count on success if the user genuinely just got their password wrong. Also I whitelisted ::1, 0.0.0.0, 127.0.0.1 and "-". You may or may not wish to whitelist LAN / management IPs.

I use Forefront TMG so I used the API to add bad IP addresses to a group of IPs that way and I've asked Cisco to add API access to one of their SMB routers (which they have assured me they just might do!)

If you want to use the native Windows Firewall to block them have a look at the API for that ("netsh advfirewall").

I allow x number of attempts before I ban and a success will reset the count.

Solution 4

Are you trying to prevent break-ins, or cluttered logs? If you're trying to prevent break-ins, Windows has a built-in way to block attempts at logging in. There is an Account Lockout Threshold Group Policy setting in Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Account Policy -> Account Lockout Policy.

Attackers will use common user names like Administrator, and they will certainly lock those out. You'd need a separate account for actual administration, which is probably advisable anyhow.

Automatically blocking at the firewall level will require some scripted log reading with automatic updating of firewall rules. You should be able to add rules based on IP address this way. This is basically what iptables does in a Linux system.

It may be a bit obvious, but have you also considered running Remote Desktop Services on a non-standard port? This has been very effective for me at thwarting break-ins.

Solution 5

There are a few other solutions also if you want to have a GUI based solution instead and create different sets of rules for different events really. The easiest one would be RDPGuard ( hxxp://www.rdpguard.com ) but in a corporate environment you'd probably want more reporting such as from where the attack came (country, origin) and what username was used so you can quickly decide if it's one of your own users accidentally blocking themselves out or trying to login from where you know they are not.

Personally I like Syspeace ( hxxp://www.syspeace.com ) that does all those thing for us but I'd thought I'd mention them both anyway

View more solutions

Comments

[Zoredache]

Do you really need to handle this on your Windows server? Have you considered doing rate-limiting on your edge device (firewall/router)?

[SoufCoder]

The Windows box is a VPS run by a hosting company, so I have no access to the network devices.

[Philip]

You could setup a Task Schedule event on failed logins to fire a PS script; the PS Svript would have to count the number of times an IP tried then block it with a Firewall rule. I don't have such a script but it'd be possible to create.

[Spence]

@Chris S: That's more-or-less what my ts_block script does, except that it runs as an event log "sink" and receives a callback each time new events are logged. As such, it runs more-or-less in realtime.

[integratorIT]

Use VPN - install eg. OpenVPN on router. Never put windows box directly to internet - it's dangerous.

[SoufCoder]

Ok, so it's as I thought. I have to study the Event Viewer to see if I can export the ip addresses to a file for batch processing. For the time being have to grep them from manually generated .csv dumps

[JohnThePro]

Change the port RDP responds on.

[Jack69]

Im already running on a nonstd port, and my bigger concern is actually having my server taken effectively offline due to the large number of login attempts.

[Admin]

I use ts_block page here and it's amazing! My windows server (2008 R2) used to slow down under numerous brute force attacks but not anymore! TS_BLOCK Is written in vbscript - and can/should be installed as a windows service - but don't use the MSI version just edit the .vbs code and install yourself with the nssm util. You don't need the registry entries cos the .vbs code has the defaults hardcoded.<p> I've edited the code and it blocks EVERY failed login immediately - as being my own webserver there should be NO failed login attempts. So the script

[Dai]

One option is to disable access to Remote Desktop via the Firewall completely, but have a service running on the server that reconfigures the firewall to allow RDP traffic through, this service is password protected and maybe only allows access from a "trusted" IP source (such as a mobile phone's IP range or your office). It introduces hassle, but works.

[Ryan Bolger]

This is pretty sweet, Evan. I've got half a mind to re-implement it in C# so you could run it as a native windows service rather than hacking around with srvany and the like. If I ever do, I'll throw it up on Github or something as well.

[Spence]

@RyanBolger: I have a soft spot for VBScript and interpreted languages in general. I find that using "Non-Sucking Service Manager" makes for a fairly painless experience running VBScript programs as services.

[Admin]

ts_block is amazing its exactly what I was looking for "Thank You Evan Anderson" When I placed my first Terminal virtual server live directly on the web within one day I had over 10,000 failed logins. When I have time I might modify it and add permanent blocking based on number of previous blocks. eg: IP gets banned 4 times in one day. (Unless it was created already)

[wqw]

Based on ts_block script here is a solution that uses fail2ban on the gateway to block attackers: wqweto.wordpress.com/2013/12/10/…

[Csaba Toth]

The funny thing is that I want to restrict IPs, but the logon failure doesn't report the IP address

[TheLegendaryCopyCoder]

Changing the port only obscures. They will find the new port with intelligent port scanning software.

[Michael Steele]

@CsabaToth The event log doesn't record useful information by default. You can enable verbose logging in the netlogon service from a domain controller or computer receiving the RDP requests for some additional information. You can enable Windows firewall logging to determine the IP address.

[Patrick Mevzek]

While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. - From Review

[Comfine GmbH]

it makes no sense to post the scrpit at two locations cause i would need to update two locations if something changes again, thats why i posted the link here only. ....feel free to copy the script if you like too, Patrick.

[Patrick Mevzek]

Sorry, this is not how this website works. Please have a look at serverfault.com/help/how-to-answer and specifically the part on "Provide context for links". As it is written your answer does not give any useful details. Just saying "there is a solution, go over there to find it" could apply to everything and hence does not really add value to this website.

[Comfine GmbH]

Sorry Patrick, i cant agree! Of course my answer does provide details and i did NOT just drop a link here without any notice or details what it is about, and what you try to describe is not described in the how-to-answer-text. again, if you think, it is worse to have a copy of this 181-lined script here, feel free to maintain a copy here - but for me this makes totally no sense! if we will provide further improvements of this scrpit for free i will leave them at ONE place only. comeon dude, we are not talking about a small snippet of code! .....

[Patrick Mevzek]

"again, if you think, it is worse to have a copy of this 181-lined script here, feel free to maintain a copy here " I do not think you are still understanding how this site works, and its aim (for example you say "we improved... and other solutions did not do a good job" without ever explaining HERE what you improved or the differences with the other solutions and which ones, etc.). But it won't discuss it more with you here, I gave you a link to learn more, if you want, take some time to read it.