I am using Windows 2008 R2.

I am wondering if there is any way to block a brute force attack.

I seeked here and there and I could not find a way to block an IP address after its makes some failing attempts to logon.

Maybe I missed something obvious.

There should be something that monitor event log for logon failure events and block culprit IP address


If you want to block the ip you can use firewall policies to block the ip. Windows will lock an account and auto unlock it at times specified in the account security policies. This typically prevents brute force attacks, when set at reasonable times, but on an unmonitored server, could lead to a DOS attack. A simple solution is to write a script to parse the logs for account lockouts and after N number of lockouts block the ip. This script can run scheduled at whatever interval makes sense for your situation. An IDS will also solve the issue.

  • I am wondering if someone hase this kind of script that scan the eventlog file and block and IP address after some number of failures. Maybe a link to something already done. I am quite sure I am not the first personn with such need!!! – user385411 Jun 19 '11 at 7:42
  • I've never seen such a script. Medium-to-large companies with this kind of requirement use an IPS/IDS. What kind of connection is being made in this instance? – mfinni Jun 19 '11 at 12:13
  • Actually, I have a new isolated web server. I can see in the security eventLog a lot of failing attempts to logon with the administrator account. I don't really care because I renamed the Administrator account. I however mind the bandwith used by those parasites – user385411 Jun 19 '11 at 14:33
  • @mfinni agreed - in an enterprise situation this would be handled by ips/ids. I feel it was a safe assumption that the OP doesn't have one. My answer here serverfault.com/questions/42396/… gives an example script (specific to IIS but once the event sink is there you can do pretty much anything). Setting up an anti-dos script on front end web-servers is pretty common in the hosting world- or the small to medium enterprise. With 2008+ you no longer have to create an event sink you as you can trigger off of an event. – Jim B Jun 19 '11 at 14:55
  • Very nice, Jim! – mfinni Jun 19 '11 at 15:11

In the group policy editor,

Computer configuration \ Windows Settings \ Security settings \ Account policies \ Account lockout policy

Voted to migrate to SF.

  • That would lock the account being tried, not the source IP address the attempts are coming from, which is what is being asked for here. – mfinni Jun 19 '11 at 0:10
  • @mfinni Exactly. I known that. But this is the way Windows has to offer. In fact, it does work. Unless you, the attacker, know all user names from a domain, in which case you can lock them all out, which'd be a DoS attack, but still your bruteforce attempt would fail in its ultimate goal of figuring a password. – GSerg Jun 19 '11 at 0:19
  • From a Windows Server perspective, if this is only coming from one IP, you can block it manually via IPSec or Windows Firewall. From a holistic IT perspective, you could block it at the border firewall, and if you had a good one or an IDS/IPS, you can block the IPs based on a number of login failures. – mfinni Jun 19 '11 at 0:46

I found this excellent summary of why account lockout policies won't do the trick (from https://www.owasp.org/index.php/Blocking_Brute_Force_Attacks)

The problems with account lockouts are: An attacker can cause a denial of service (DoS) by locking out large numbers of accounts.

Because you cannot lock out an account that does not exist, only valid account names will lock. An attacker could use this fact to harvest usernames from the site, depending on the error responses.

An attacker can cause a diversion by locking out many accounts and flooding the help desk with support calls.

An attacker can continuously lock out the same account, even seconds after an administrator unlocks it, effectively disabling the account.

Account lockout is ineffective against slow attacks that try only a few passwords every hour.

Account lockout is ineffective against attacks that try one password against a large list of usernames.

Account lockout is ineffective if the attacker is using a username/password combo list and guesses correctly on the first couple of attempts.

Powerful accounts such as administrator accounts often bypass lockout policy, but these are the most desirable accounts to attack. Some systems lock out administrator accounts only on network-based logins.

Even once you lock out an account, the attack may continue, consuming valuable human and computer resources.

There are a few softwares out there that can help you out. A few scripts that one would have to modify and at least two with GUI , called Syspeace and RDP Guard

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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