Summary: In this article we discuss how to secure OWA, protect Outlook Web from DoS and brute force attacks, discuss what these attacks are, and how they can be prevented. We also look into automated brute force attacks and why setting an account lockout threshold can leave your Exchange Server vulnerable to DoS attacks.
Last week we highlighted the exposures that exist with attachments in Outlook Web. This week we look at protecting Outlook Web from Denial of Service and Brute Force Attacks. Depending upon how you have configured Outlook Web Access (OWA) and Active Directory, you will be opening your network up to either brute force attacks or denial of service attacks. This is an either/or decision for most organizations as it is difficult in native OWA to choose to protect against both at the same time. The reason for this is that OWA and the Active Directory are both governed by the same account lockout policy settings.
Use the following test to see how your system could be compromised:
The Account Lockout Threshold
The Account Lockout Threshold is one of three configurable account lockout policy settings that can be set in the Group Policy Object (GPO) that allows the system administrator to block a user’s access to the system if a user ID fails a predefined number of logon attempts sequentially.
If the threshold setting is off, you will be allowing an unlimited number of password guesses, leaving the system vulnerable to Brute Force attacks. By setting a number for the account lockout threshold, accounts will be locked after that number of failed password attempts and the system is now vulnerable to Denial of Service attacks.
Let’s start by determining what your current account lockout settings are:
Step 1: Ensure you can execute Active Directory PowerShell commandlet;
Step 2: Launch Exchange PowerShell as an administrator and execute the following commandlet:
Get-ADDefaultDomainPasswordPolicy| Format-List lockout*
If the PowerShell command returns a setting of 0, the account lockout threshold protection is turned off. By leaving the threshold setting off, you have no way of protecting against brute force, automated password guessing attacks. These attacks can only operate successfully when they have an unlimited number of password guesses.
So turning off account lockout protection is not a good security strategy.
Brute force password attacks can be automated to try thousands or even millions of password combinations for any or all user accounts. Limiting the number of failed logons that can be performed nearly eliminates the effectiveness of such attacks.
If the PowerShell command returns a setting >0 (1 –199), the account lockout threshold has been set.
By setting an account lockout threshold, user accounts will be locked after a proscribed number of failed password attempts is exceeded. The locked out accounts will need to be reset by the administrator if the user wants to see their emails or access internal networks. When an attacker has programmatically attacked and locked out enough (or all) users, the attacker will have a successful Denial of Service (DoS) attack and the organization’s users will be locked out (of both email and the internal network.)
So setting the account lockout threshold is not a good security strategy.
The conundrum is whether to facilitate automated password attacks or risk a shut down through a DoS attack … and neither strategy is attractive.
Messageware can help through dynamic CAPTCHA, tarpitting, geo-blocking and other logon protections. If you would like to learn how to protect Outlook web from these attacks, from session hijacking, from attachment data leakage exposures and more, we would be happy to discuss your needs, industry best practices and our solutions and set up a personal demo or a free trial.
Follow the link for additional ways to keep Microsoft Exchange Server Secure.