Using IncapRules to Customize Your Security and Access Control

At Incapsula Deep Dive Day in San Francisco, Peter Klimek, principal security engineer at Imperva, talked about how to protect websites with IncapRules. He looked at how applications owners and security engineers can configure IncapRules to solve a variety of security and performance issues.

For ops teams keeping a website safe and available is more important today than ever before. With websites and apps becoming a critical business need, the resulting proliferation of threats against them has made online businesses and organizations take a more critical look at their security systems. In addition, the complexity of online threats requires adaptive and flexible solutions that can deliver real-time response and mitigation.

Customizing Security

Incapsula provides IncapRules, a proprietary scripting language which lets users configure their existing security, delivery and access control rules. These IncapRules can either be manually coded or generated via a dedicated GUI to

• Prevent bots from accessing a site’s registration form
• Restrict access to a specific part of an application based on its IP address
• Limit the rate of requests to a website
• Manipulate traffic routes and redirects
• Control a request’s URL structure, headers and cookies

“Many of our customers are using IncapRules to create feedback loops between their other systems. In other words, they’re writing rules and deploying rules on a regular basis,” Peter says. “By doing this, they’re using IncapRules as a way to manage some of the advanced attacks that they end up seeing across their environment.”

IncapRules are built using filters, operators and values. Peter again on filters, “We can move beyond simple geoblocks (a system that blocks unwanted bot traffic from a large geographic area, such as Russia or China). We can actually leverage IncapRules to create more complex logic, that can balance the needs of both the business and the security teams.”

However, take the case where an executive or sales person from the company travels to any of these countries. Here a better solution would be to have a security policy that can detect a legitimate user from the rest of the traffic to make the site accessible without blocking all traffic to entire geo locations.

Writing Security Policies

Peter points out how IncapRules are an easy way to build security policies within Incapsula. There are three levels of actions that can be taken with unverified traffic:

• Alert
• Block
• Challenge

“Alert is something that I always use when writing IncapRules,” says Peter. “I’ll never immediately block a request without setting up an alert first. The reason I do this is because I want to know what I’m catching at this stage.” Writing an alert action gives you the ability to write a rule, to test it, and then make sure it’s working correctly.

Once you decide an action is required, you can start the blocking process. There are three different types of blocks available with IncapRules: You can block the request, the session or the IP address.

Beyond blocking a request IncapRules further challenges the user if necessary. “In this way,” says Peter, “we’re asking them to actually prove that they’re a human being.”

There are various ways to differentiate between a bot and a real person. We can challenge a request via a cookie, we can use JavaScript, or we can challenge via CAPTCHA.

CAPTCHA is used sparingly because users universally hate them. “I know that I’m sick and tired of them,” confesses Peter. “But at the same time, I realize that they are needed and they are useful in certain situations.”

×

Apr 25 Upcoming Webinar

Build a Robust API Security Strategy in 2024 (APJ)

Register Now

Intelligent Filters

Filters are the basis of how IncapRules work. There are more than 30 filters contained directly within the management console. More filters are available by request from support and technical solutions staff.

Here you can see the attacks count in the notable counter filters

Filters fall into one of three categories: information about the client, information about the request, and information about counters.

• Information about the client provides details concerning the connection. In other words, what is the IP address and what is the ASN? Am I talking to a browser or a bot?
• Information about the request allows us to pick apart the actual HTTP request – all the headers, the post message and the parameters.
• Information about counters gives us a chance to see what’s happening during the entire user session. This is important because it allows us to build rules beyond the context of a single request.

Default Incapsula WAF rules will stop most threats before they become a problem but you can write your own rules as needed. For example, if your organization needs to prove to an auditor that it has a rule specific to its concerns, or if you want to directly reference it by name, it’s easy enough to write that rule.

Common Rules

One of the first common rule sets blocks malicious clients where the Incapsula service identifies bad client types and blocks them.

IncapRules also uses CAPTCHA support for a high rate of access. “By doing this we can measure the rate of requests and evaluate the index,” says Peter. This provides a more granular view of your site’s traffic.

Using IncapRules to Block a CSRF Attack

Peter used the example of writing a mitigation rule for a malicious cross-site request forgery attack to illustrate how IncapRules works. CSRF attacks can be tricky he acknowledges but IncapRules gives you the ability to keep your site safe from it.

Start by making sure the request has a session cookie. One way to do this is to make sure the request contains the cookie you’re currently leveraging.

Next, you should validate whether there’s an origin header. This is the preferred method for detecting the client’s origin, but it only applies to HTTPS. From the browser’s perspective a header can’t actually be forged in the same way that a referrer cookie can. So it’s always a good idea to look for it.

To be sure Peter recommends that your IncapRules specifically look for vulnerable GET requests, as CSRF attacks always come bundled via a GET request, and limiting the rule to only that method helps to minimize false positives.

When using IncapRules it’s important to balance the needs of making rules generic to serve broad needs versus making them specific. In some cases, you’ll want to cast a wide net to block most unwanted traffic. In other instances where you’re trying to mitigate certain vulnerabilities in your application, you’ll want to make those more specific.