Protecting ldap server against accounts lockout caused by brute-force attacks

Question

During testing the ldap server against bruteforce using patator ldap_login, I've figured the tested account gets locked after bypassing the limits of allowed login attempts. Using this tool, an attacker can lock all the accounts in the company, what are the best way to protect against such lockout?

Answer 1

If you're asking how you can use such a tool to verify passwords are suitably complex without locking out all of your accounts, clone your directory elsewhere. Set the password policy on the clone directory server to not lock accounts on bad passwords, then run your tool against the clone directory.

If you're asking how you can mitigate against someone else using that type of tool to lock out the entire directory of users ... I'm surprised this attack is not more common -- especially as security requirements like PCI required account lockout so there's a good chance the directory will lock the ID after a fairly small number of bad passwords.

I restrict access to the LDAP directory servers using an OS firewall and, for LDAP servers that provide such function, application level access control. It makes more work for the directory support team because each new application has to get set up to access LDAP, but some random person cannot just run a tool on their desktop and lock out the entire directory. One of the authorized servers could still be used as an attack source, but I can drop access from that IP when an attack is discovered.

Restricting access to the LDAP/LDAPS directory server doesn't stop the random person from using an approved application to send authentication requests (e.g. something like "curl --user username:NotThePassword https://businessapp.domain.gTLD" or POSTing the username/NotThePassword to the right auth URL has an approved server make an LDAP call on my behalf). There are a lot of ways to mitigate this sort of attack:

I've had applications include a cool-down period when they start getting a series of bad passwords -- 6 bad passwords locks the account on the directory side, but the application gives you a ten minute timeout where you cannot try to auth again at 2 or 3 bad passwords in 5 minutes. Or throws a "are you really a human" validation.

You can configure your password policy to lock accounts for X minutes after Y bad passwords. This means an attacker would require a sustained attack against a specific ID to keep it locked out for a significant period of time. While an attacker can lock your entire directory, the impact to users is minimized. The X minute pause makes brute force password attacks quite inefficient and generally gets OK'd from security types.

Having user IDs that are not easily walked in an algorithm helps a little. As an example, I worked for a company where user IDs were a static letter followed by five numbers. Walking the entire namespace of their possible user IDs was trivial, and anyone who worked there knew the ID format. An ID namespace with more possible iterations makes it more difficult to lock out a significant portion of the users (i.e. it takes more time to walk through all possible letter/number combinations that are between three and twenty characters {and a lot of the attack is performed against accounts that do not exists} than it takes to walk the X##### namespace).

Ensure all applications return the same error for invalid username or password too -- if you specify "invalid username" when an ID is not found and "invalid password" when the password fails, an attacker can quickly bypass any IDs that don't exist. By returning "bad username or password", they have to waste time attempting to lock non-existent IDs.

For a larger network, an intrusion detection system (IDS) that includes network traffic and log analysis could be used. But directory server log data can be analyzed through a monitoring platform or custom written scripts. I generate alerts when an abnormal number of lockouts occur -- working for a fairly large company, I see a hundred or so lockouts during normal business hours and one or two in the overnight hours. If we're seeing more than a handful in an overnight hour or a thousand during business hours, the lockout source gets notified to investigate. And if the lockouts start getting particularly excessive, we can make the call to remove the source IP from the directory server access list until the application team can figure out what's going on.