Using IncapRules to Protect Against Brute Force Attacks

Earlier this year Incapsula introduced IncapRules — a new custom security rules engine that lets you integrate your own security policies on top of our security logic. Six months later, the IncapRules scripting language now being is used by online global organizations to gain complete and granular control over application security.

During the recent wave of large ‘credential dumps’ — where lists of usernames and passwords have been posted on the web — Incapsula has proven to deliver impenetrable protection from attempts to match exposed username/password combinations across various Internet resources.

Such matching attempts are executed as automated brute force attacks. One way to deal with them is to activate the Incapsula Suspicious Bots mode, which employs progressive challenges to sift through unidentified inhuman visitors.

However, a much more elegant solution can be achieved with a simple IncapRules syntax that leverages the Incapsula request-inspection capabilities.

Brute Force is Turning All of the Knobs

Standard login modules rely on POST requests to send a username/password combination to the webserver. During assault preparation, an attacker captures login module conventions, using them to generate a script that can automatically access your server at a very high rate.

The perpetrator then uses the script to flood the login module with numerous username/password combinations. These are usually a mix of popular login credentials and exposed user details from one of the latest credential dumps.

The attacker playing a numbers game, this process is similar to walking down a hall and turning all of the doorknobs. Quickly identifying vulnerable websites, with each successful match the infiltrator gains full access.

Compromised websites are subsequently exploited in a variety of ways: stored data is stolen, landing pages are defaced, servers are turned into DDoS zombies or malware distribution hubs, and so on.

IncapRules Recipes For Brute Force Protection

IncapRules syntax relies on descriptively-named ‘Filters’ and a set of logic operators. Combined these are used to form a security rule (a.k.a. ‘Trigger’) that leads to one of the pre-defined ‘Actions’.

To counter brute force attacks, you can deploy a relatively simple rule, to limit the number of subsequent POST requests to your login page.

For example, this simple Filter will trigger by more than 50 subsequent POST made by inhuman (non-browser) visitors within the span of a minute:

Rate > {post-ip;50} & ClientType != Browser [Block Session]

Once triggered, such rule can respond with any number of actions.

In this case, the rule is set to [Block Session] that will instantly terminate the session. Alternately, you can set the action to [Alert], which will transparently notify you about the incident with email and GUI messages.

Of course, generic rate thresholds can mess up functionality.

One common scenario is that of a web app with integrated API that should be allowed to support higher-than-normal request rates.

Such situations call for a more subtle approach. One thing you can do is to tweak the rule syntax with the [URL] filter, to create a rule that won’t be triggered by POST requests to API URLs:

Rate > {post-ip;50} & URL != /api & ClientType != Browser [Block IP]

Specifying the rule’s “jurisdiction” will help avoid false positives. This may also make you feel more comfortable about using a more aggressive [Block IP] action, which will not only terminate the session but also block all future communications from the offending IP.

When writing a rule, we always suggest asking yourself: “What are the odds of legitimate users doing something like this?”

With IncapRules you have many options but, time permitting, we strongly suggest starting each new rule with an [Alert] action-to see when and why it’s being triggered in the wild.

More Than Meets the Eye

The examples above uses two of the nearly 90 different filters provided by IncapRules, letting you take advantage of the entire range of powerful traffic inspection abilities of Incapsula. With them you can create custom policies based on HTTP header content, geolocation, a pool of over 500 bot clients, and much more.

When employing multiple filters with various logical operators (e.g., and/or, larger/smaller than, and etc.) to link between them, the IncapRules filter set offers limitless combinations — letting you create custom security policy for every type of scenario.