Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Any ideas on how to protect against the following scenario?

Company x uses active directory for authentication of it's employees. The company has multiple authentication points that are semi-public and some that are fully public. (e.g., Extranet accessible from the Internet)

Usernames are pretty easy to guess, as they follow a standard naming convention, based on the name of the employee.

If Eve wanted to mount a DoS against Company X, and she has access to a large number of employee names, it would seem pretty trivial for her to lockout accounts of a lot of the employees of the company.

Any ideas on how to protect against this type of attack?

I understand that a variable length lockout could help, but it would still mean that employees are not logged in, working.

Thoughts?

share|improve this question

4 Answers 4

up vote 8 down vote accepted

There is a paper describing how to use Microsoft Lync (formerly Office Communications Server) to mitigate brute force attacks:

http://blogs.technet.com/b/drrez/archive/2010/05/26/protecting-the-edge-server-against-dos-and-password-brute-force-attacks-in-office-communications-server.aspx

snippets:

"DoS attacks are indistinguishable from legitimate sign-in requests. The only differentiation is in the frequency of sign-in attempts and origin. A large number of sign-in attempts in rapid succession can be indicative of a DoS attack. DoS attacks attempt to guess the user's password to gain unauthorized access, and often result in locking out the user account if security policy is enabled in Active Directory."

"By enforcing account lockout at the Edge Server, the security filter prevents DoS attacks at the edge of the network perimeter, and as a result, protects internal Office Communications Server resources"

Microsoft has another white paper titled: Account Lockout Best Practices White Paper
search for "Protecting from External Account Lockout Denial of Service Attacks"

key snippets (copied verbatim):

Protecting from External Account Lockout Denial of Service Attacks
It is possible for a malicious user to launch a denial-of-service attack against your enterprise from outside of your network. Because most networks are interconnected, this can be a difficult attack to mitigate. The following techniques technologies are common techniques and technologies that you can use to help mitigate or prevent such attacks:

Require complex passwords: All accounts should have a complex password. All administrator accounts (local and domain) should have a long, complex password and you should change the password regularly.

Rename the administrator account: Because the administrator account cannot be locked out, it is recommended that you rename the account. Although this does not mitigate all of the attacks against the administrator account, it does help mitigate these attacks most of the time. For more information, see "HOW TO: Rename the Administrator and Guest Account in Windows 2000" on the Microsoft Knowledge Base|http://support.microsoft.com/?id=320053.

Protect your environment with firewalls: To avoid an account lockout denial of service attack, block the TCP and UDP ports 135 through 139 and port 445 on your routers and firewalls. When you do this, you prevent logon attempts that occur outside of your network.

Prevent anonymous access: Set the RestrictAnonymous value to 2 on all computers that are exposed to the internet and to the entire domain if all of the computers are running versions of Windows 2000 or later. This stops malicious users from making anonymous connections to resources and may help defeat some types of attacks. Note that some operating systems have limited support for computers that have this setting. Some programs may also have issues with this setting if the programs use an anonymous connection to gain access to resources. For more information, see "How to Use the RestrictAnonymous Registry Value in Windows 2000" on the Microsoft Knowledge Basehttp://support.microsoft.com/?id=246261.

Protect site-to-site traffic by using a VPN tunnel: If communication between domain members in two sites is required, use a site-to-site VPN tunnel to securely connect site networks together. Do not open all NetBIOS ports on the firewall. You can use the Windows 2000 Server Routing and Remote Access service to create site-to-site VPN tunnels. If no VPN devices are available, you should configure the edge firewall or router filters to limit the traffic that is permitted to flow between the Internet Protocol (IP) address ranges that are used by each site. If sites need to use Active Directory replication only across the Internet, then use Internet Protocol security (IPSec) transport mode through the firewalls to secure all traffic between Active Directory servers. For more information about Active Directory replication through firewalls, see the "Active Directory Replication over Firewalls" white paper on the Microsoft Web site|http://www.microsoft.com/serviceproviders/columns/config_ipsec_p63623.asp.

Protecting authentication and NetBIOS ports from Internet attack: On either the firewall or the router that connects your internal network to the Internet, block access to TCP and UDP ports 135 through 139 and port 445. If no edge filtering device is available, you can use IPSec filters to block these ports. To do this, use the configuration that is described in "How to Block Specific Network Protocols and Ports by Using IPSec" on the Microsoft Knowledge Base|http://support.microsoft.com/?id=813878.

• In the same IPSec policy, you must create an additional rule that adds filters to permit traffic to these ports when the source address is in a subnet that is used by the internal network. To do this, use the configuration that is described in "How to Block Specific Network Protocols and Ports by Using IPSec" on the Microsoft Knowledge Base|http://support.microsoft.com/?id=813878.

Protecting authentication and NetBIOS ports from internal attack: If you must protect access to both authentication and NetBIOS ports from internal malicious users, you can restrict the computers that are permitted to gain access to these ports to only domain member computers by using the feature in IPSec that allows you to negotiate security. By allowing only trusted computers (domain member computers) to gain access to both authentication and NetBIOS ports, you reduce the number of computers that can perform the attack. This extra protection provides a defense against any breaches in your security perimeter and against malicious users who can connect to the internal network. For information about how to create a custom IPSec policy to use Kerberos authentication when negotiating IPSec security for access to TCP and UDP ports 135 through 139 and port 445 see the "Step-by-Step Guide to Internet Protocol Security (IPSec)" on the Microsoft Web site|http://www.microsoft.com/windows2000/techinfo/planning/security/ipsecsteps.asp.

Update the server: Keep all of your servers up-to-date with current versions of antivirus software, firewall software, and Windows security patches. This helps prevent trojan horse programs and viruses from attacking your resources if the malicious user can launch an attack from your internal network instead of from the Internet. These updates are an important part of an in-depth and defensive security strategy.

share|improve this answer
  1. Detection
    • You need auditing controls to alert you of a high frequency of account lockouts
  2. Defense
    • One idea is to track the source IP address that is causing the account lockouts. After this src IP address has crossed a defined threshold (say 2 accounts in 10 seconds), then the user is prompted with a CAPTCHA that must be successfully completed in order to continue authentication attempts on the website. This would stop the attacker from being able to script an account lockout attack.
    • After the src IP address has crossed a second threshold (say 10 accounts locked out in 60 seconds) then the IP address is blocked for X minutes. Sure, this could block out other users if the attacker is behind a corporate NAT, but it is an option you can use to defend your application.

If the attacker is using multiple proxies and has scripted an account lockout attack that leverages a variety of source IP addresses then you will not be able to use these ideas. However, hopefully you detection controls in step 1 have alerted an admin who can manually investigate the issue.

None of this is built into LDAP - it would all of to be custom code.

  • Michael
share|improve this answer
    
Hi @Michael, I agree with your answer - except the part about CAPTCHA. That's a broken mechanism, and if there's enough value it is close to trivial to get through it. –  AviD Jan 18 '11 at 8:13
    
@AviD - captcha is broken, sure, but it mitigates against a lot of automated attacks and increases the effort required for an attack, so I do see it helping to reduce lockout DOS. –  Rory Alsop Jan 18 '11 at 10:42
1  
@Rory - captcha can definitely help protect against drive-by attacks. However, in a targeted attack, the increased effort necessary is very low. See my answers to this on SO - here and here. –  AviD Jan 18 '11 at 11:07

The first thing that comes to mind is to watch for multiple failed logins across multiple accounts once they've been locked out. E.g. Eve tries Bob's account 10 times and gets locked out. She then tries Tim's account and gets locked out. After n number of accounts you have a pretty good idea that someone is trying to DoS the accounts. However this doesn't really solve your problem, it only allows you to audit it.

A simple-ish solution would be to seperate login lockouts by network, so if you try logging in via the extranet and get locked out, you can still log in locally. With that being said, I'm not sure how you can do that via Active Directory, nor am I sure what sort of implications this has.

share|improve this answer

If for any reason you cannot really segregate your public authentication points from the internal user accounts then you face the possibility of constantly having to deal with locked-out users. Even if there is no immediate threat of a breach this could overload your admin team with unlock requests.

Moreover, there's another aspect: Account Lockout can become a problem even on the internal network. In the past malware has been known to try to brute force accounts in order to spread (e.g. some conficker versions were trying dictionary attacks on the ADMIN$ shares) which could lead to uncomfortable situations for admins.

I would therefore suggest:

  1. to carefully consider your Lock-out policies to prevent a complete lockout
  2. to fine-tune your "unlock" safeties to allow for the eventual lock-release

LockOutThreshold, ObservationWindow, and LockOutDuration can all help with these. For their exact usage check MS Account Lockout Best Practices.

One approach I would think of (more suggestions in the document above) are:

normal users:

  • medium or high number of tries (to help forgetful users),

  • (relatively) short observation window (to prevent brute force attacks),

  • quick release, perhaps 15'-30' (to save the helpdesk from those calls...)

admins:

  • small number of tries (they should know the password),

  • bit longer observation window (password complexity should offer some protection from brute force),

  • release after a few hours

Your ideas?

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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