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 could 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 ADFS) - 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 cover tuning (to maximize their effectiveness) 2 potential solutions that help reduce the impact of this type of attack. They are IPBan and EZWinBan. Both solutions run on Windows and leverage the Windows Event Log (to identify IP addresses with authentication failures) and Windows Firewall (to ban IP addresses that are responsible for excessive failed AD login attempts).
Determining and setting the proper value for failed login attempts before ban
This setting is named as follows in each of the banning solutions:
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.
|Count of public facing servers||Account lockout threshold setting (AD)||Recommended failed login attempts before ban|
|2||3||1 (Since 3 / 2 =1.5, round down to 1 - we cannot have fractional login failures)|
|2||5||2 (Since 5 / 2 =2.5, round down to 2 - we cannot have fractional login failures)|
|2||10||4 (Although 10 / 2 is an even 5, the value must be LESS THAN 5, so we round down to 4)|
|5||10||1 (Although 10 / 5 is an even 2, the value must be LESS THAN 2, so we round down to 1)|
|7||15||2 (Since 15 / 7 =2.14, round down to 2 - we cannot have fractional login failures)|
|10||5||NA (No feasible value in this situation. Reduce # of public servers or increase Account lockout threshold)|
Determining and setting the proper value for ban time
This setting is named as follows in each of the banning solutions:
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 be unable to access your services for extended periods. Also, you can 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 suspect there is an 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.
|Reset account lockout counter after (AD)||Recommended ban time|
|5 minutes||5 minutes (or more)|
|15 minutes||15 minutes (or more)|
|30 minutes||30 minutes (or more)|
|60 minutes||60 minutes (or more)|
Implementing an IP banning solution should help reduce 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 Azure AD and other SAML/OATH based identity providers (IdPs). But alas, we do not live in a perfect world and I can envision scenarios where public-facing AD authentication is a necessary evil.
In any case, I hope this helps someone facing an Active Directory account lockout issue and looking for a solution and tuning guidance to address it. 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.