23

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?

onik
  • 997
  • 3
  • 7
  • 20
  • 3
    Do you really need to handle this on your Windows server? Have you considered doing rate-limiting on your edge device (firewall/router)? – Zoredache Feb 02 '11 at 09:18
  • 2
    The Windows box is a VPS run by a hosting company, so I have no access to the network devices. – onik Feb 02 '11 at 09:34
  • 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. – Chris S Nov 29 '11 at 20:55
  • @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. – Evan Anderson Nov 29 '11 at 20:56
  • Use VPN - install eg. OpenVPN on router. Never put windows box directly to internet - it's dangerous. – integratorIT Jan 31 '17 at 18:40

7 Answers7

25

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?)

Community
  • 1
Evan Anderson
  • 141,071
  • 19
  • 191
  • 328
  • 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. – Ryan Bolger Jul 15 '12 at 05:32
  • 1
    @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. – Evan Anderson Jul 15 '12 at 22:17
  • 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) –  Mar 13 '13 at 20:19
  • 1
    I use ts_block [page here](https://github.com/EvanAnderson/ts_block) 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.

    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

     –  Jul 14 '12 at 22:37
  • Based on `ts_block` script here is a solution that uses `fail2ban` on the gateway to block attackers: https://wqweto.wordpress.com/2013/12/10/how-to-use-fail2ban-with-terminal-servers-rdsh-farm/ – wqw Dec 13 '13 at 12:27
5

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

Nicola Boccardi
  • 301
  • 1
  • 5
  • 1
    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 – onik Feb 08 '11 at 09:56
  • 5
    Change the port RDP responds on. – JohnThePro Apr 23 '12 at 20:05
  • The funny thing is that I want to restrict IPs, but the logon failure doesn't report the IP address – Csaba Toth Dec 03 '16 at 22:23
  • Changing the port only obscures. They will find the new port with intelligent port scanning software. – TheLegendaryCopyCoder Jan 23 '17 at 08:25
  • @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. – Michael Steele Feb 15 '17 at 20:07
4

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.

Matthew1471
  • 307
  • 2
  • 4
2

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.

Joel E Salas
  • 5,562
  • 15
  • 25
  • Blocking repeated connection attempts at the firewall is good practice, but assuming that brute force attacks aren't going to happen "behind the firewall" isn't a very good assumption. A host-based brute for block is a reasonably good idea, to my mind. Using account lockout is definitely a good idea, but I also like the idea of squelching the brute force attempts to keep logs cleaner, too. – Evan Anderson Nov 29 '11 at 21:09
  • 1
    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. – boomhauer Jul 13 '12 at 05:39
  • 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. – Dai Jul 15 '12 at 02:35
1

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

abmv
  • 125
  • 8
Juha Jurvanen
  • 61
  • 2
0

Solution is simple: Setup Windows Firewall so that only whitelisted IP addresses can RDP into the desired boxes. See the following resource: How can I allow RDP access to a Windows 2008R2 server from one IP?

Community
  • 1
sean2078
  • 111
  • 2
-1

we improved a powershellscript as fail2ban and other solutions did not do a good job. this works for server 2012, 2016, 2019 as well.

see my post if you want to use the script: Terminalserver Remote Desktop Failed Logon Firewall BruteForce Block Script

Comfine GmbH
  • 1
  • 2
  • 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](/review/low-quality-posts/450769) – Patrick Mevzek Jun 07 '20 at 17:48
  • 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. – Comfine GmbH Jun 09 '20 at 09:38
  • Sorry, this is not how this website works. Please have a look at https://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. – Patrick Mevzek Jun 09 '20 at 15:03
  • 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! ..... – Comfine GmbH Jun 10 '20 at 18:30
  • "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. – Patrick Mevzek Jun 10 '20 at 19:02