When it comes to IT security, I am a subscriber to a couple of "bear" paradigms (admittedly, the second one is a little morbid):

• If the bear is hungry, it will eat - in other words, if a person or entity wants something from your environment badly enough, chances are they will eventually get it (think Stuxnet).
• You do not have to outrun the bear, only your slowest friend - in other words, incremental improvements in security practice can reduce the impact of attacks against your environment and make your organization a less appealing target.

In the spirit of this, I wanted to share some potentially useful information about curbing Active Directory brute force, denial of service (DoS), and/or AD account lockout attacks (event code 4740) against internet-facing systems that authenticate against internal Active Directory Domain Services. Although an AD account password might eventually be discovered this way, that is less of a concern in my opinion. The real annoyance is that when an AD account becomes locked in this manner, it impacts the actual user who may be legitimately attempting to log in and perform work. When an attacker locks a user's account, the user must wait until the interval you specify for "Reset account lockout counter after" in AD elapses before she/he can resume work.

This sort of attack is most effective when the following criteria are met:

• Your organization operates internet-facing services that authenticate directly against Active Directory (not AD FS) - these could be Remote Desktop Services/Remote Desktop Protocol (RDS / RDP), CIFS/SMB (File Sharing), Internet Information Services (IIS - websites or web applications), simple mail transfer protocol (SMTP) relay, etc.

• AD user names in your organization are known in the "wild" - this may be a result of a previous breach/compromise (one of the first steps most attackers take when an account is compromised is dumping your organization's directory/GAL/etc.) or simply because some AD usernames are easy to guess (i.e. "bob").

In this post, I will share some tips on properly tuning EZWinBan to maximize its effectiveness in preventing AD account lockouts.

Determining and setting the proper value for failed login attempts before ban

This setting is named as follows:

With a single public-facing server, setting this value is cut and dry. It simply needs to be less than (NOT equal to) the "Account lockout threshold" setting in Active Directory (AD).

If multiple publicly accessible servers authenticate against AD, login attempts from ALL of the nodes must be taken into account (they all count against the Account lockout threshold in Active Directory). The goal is to ensure that the malicious IP address is banned on all nodes before the lockout threshold in AD is reached.

(Failed login attempts before ban) < (Account lockout threshold in AD) / (Number of public facing servers)

The Failed login attempts before ban setting on each node should be a whole number (usually rounded down) less than the Account lockout threshold in AD divided by the number of public facing severs authenticating against AD.

Examples:

Determining and setting the proper value for ban time

This setting is named as follows:

My knee jerk reaction is generally to the effect of "ban them forever". That is counterproductive though; these attacks may originate from behind a NAT or from an unknowingly compromised host. If ban time is set too high, you may end up banning legitimate traffic and if the ban duration is weeks/months/years, legitimate users may also be unable to access your services for a long time. You can also easily clog up your firewall with thousands and thousands of rules if you hold onto banned IPs for too long. Although the Windows Firewall is relatively efficient, I am sure there is a slight increase in load (memory/CPU) as the number (and size/scope) of the ruleset grows.

With that in mind, you only need to outrun your slowest friend; as a starting point, I recommend setting your ban time based on your "Reset account lockout counter after" setting in Active Directory (AD). In brief, just enough to allow the lockout counter to reset.

(Ban time) >= (Reset account lockout counter after in AD)

Ban time should be greater than or equal to the time specified in the Reset account lockout counter after in AD.

Examples:

Closing thoughts

Implementing an IP banning solution should help alleviate the impact of AD account lockout attacks in your environment. There are always caveats though; even with a perfectly tuned solution, it is impossible to completely prevent lockouts of this nature. The attacker may vary IP addresses between login attempts with the same username, there are delays in processing failed login attempts (Event Viewer) by both IP banning solutions (seconds matter), etc.

In an ideal world, systems and services that authenticate against Active Directory should not be publicly exposed (there are other solutions for these cases, like Active Directory Federation Services (AD FS) and other SAML/OATH based identity providers (IdPs). But alas, we do not live in a perfect world and I can envision many scenarios where public-facing AD authentication is a necessary evil.

In any case, I hope this helps someone facing Active Directory account lockout issues and looking for a solution / tuning guidance to address them. If you are doing something similar or have additional guidance, feel free to comment. I am always interested to hear about innovative methods that others have used to tackle problems like this.