Our support team is available around the clock to make sure customers always get the best results from our security and performance services. As each customer’s business grows or changes, so do its business requirements. In some cases, this can also affect security policies, and our support engineers field a lot of questions about tailoring security rules for specific types of scenarios.
This post walks you through how to set security exceptions and shares examples of how some customers are using this feature. If you need help setting security exceptions for your website or application, don’t hesitate to contact our support team.
Minimizing False Positives
Leading enterprises and government agencies use Incapsula Web Application Firewall (WAF) to protect their organizations against data breaches and downtime. The WAF has hard-coded security rules that block critical web application security risks, such as SQL injection, cross-site scripting, illegal resource access, remote file inclusion and other OWASP top 10 threats.
Our security team regularly updates these rules based on its assessment of the security landscape and analysis of crowdsourced attack data on the thousands of sites in our network. This data helps us identify emerging attacks and apply mitigation rules against newly discovered vulnerabilities.
Our WAF is configured for optimal security out of the box, but there are special cases where the default security rules need to be adjusted to accommodate a customer’s specific business needs. These security exceptions (whitelists) are used in most cases to prevent false positives. They let you fine tune your security and access policies to specific URLs, fields, IP addresses and countries.
How to Define a Security Exception
When configuring an exception, it’s important to understand the context in which that exception should be added. Incapsula lets you define exceptions to security rules related to specific types of attacks and access control lists, or even white list specific IP sources that will bypass the WAF altogether.
- Attack type exceptions
By default, the WAF blocks the following attack types:
- SQL Injection takes advantage of non-validated input vulnerabilities in a web application to pass SQL commands to a backend database. Attackers exploit a common practice where programmers often chain together SQL commands with user-provided parameters, and can then embed SQL commands inside these parameters. The result is the attacker can execute arbitrary SQL queries and/or commands on the backend database server through the web application.
- Cross Site Scripting (XSS) takes advantage of a website vulnerability in which a site displays content that includes unsanitized user-provided data. For example, an attacker might place a hyperlink with an embedded malicious script into an online discussion forum that attacks other forum users who click on the link. A script like this could copy user cookies and then send those cookies to the attacker.
- Backdoors are widely used by hackers for malicious purposes, such as sending spam and participating in DDoS attacks on other websites. A backdoor is software that allows the hacker to remotely operate the site or server for future exploits.
- Remote File Inclusion (RFI) attacks target vulnerabilities in web apps that dynamically reference external scripts. RFI attacks upload malware (e.g. backdoor shells) from a remote URL located within a different domain. These are used to steal information, compromise servers and modify content on a victim’s website.
- Illegal Resource Access attacks are malicious attempts to access vulnerable or administrative pages, or view or execute system files. This is commonly done using URL guessing, directory traversal, or command injection techniques.
- DDoS or distributed denial of service attacks render an online service unavailable to users. This is typically done by either sending huge amounts of traffic to clog a network connection, or by overloading a server with a large number of resource-intensive requests.
Setting an exception in the WAF for one of the above attack types lets you exclude certain types of traffic from the default blocking rule. You can define the exception to exclude certain users based on any combination of URL, Client App ID, IP, Country or HTTP Parameter.
Note: exceptions defined for a given attack type only apply to that type, and traffic from the same sources will still be inspected for other attack types.
Sample use cases
Some Incapsula customers need to set security exceptions on their WAF. One example was a company web developer who used a WYSIWYG editor to prepare and upload content to the site. The tool’s standard operating procedure sent HTML code to the site using an HTTP parameter. However, our WAF identified this as a cross site scripting scenario because code was being injected from the client (developer) to the web server. This scenario was being blocked by default, even though in this case the action was legitimate. By defining an exception in the HTTP Parameter field, along with the IP address of the web developer, our customer was able to avoid this false positive situation.
We recommend when making a security exception that you define at least two parameters to make the exception as specific as possible. This will minimize any openings for potential attacks.
Another example involved DDoS mitigation rules for a large university. To protect its online portal against application-level DDoS attacks, the university set a threshold for requests per second (RPS) based on the average traffic rates. Anything above this threshold was considered a DDoS attack and was automatically blocked by the WAF. However, the university also realized that at the beginning of a new semester, traffic rates typically jump to more than twice the average rate due to the number of students registering for new courses. To allow for this peak traffic during the expected time frame, the university set a whitelist for a specific URL “/course-registration” for example. To protect against bot-driven DDoS attacks during this period, an additional “Client App ID” parameter was set to limit the whitelisting to known browsers such as Chrome, IE and Firefox.
- Access control list exceptions
The Incapsula access control list determines which human and bot visitors are allowed to access your website. Unlike the default rules for attack types, access control rules are blacklists defined by the customer and not by the Incapsula security team.
Using the management console, you can set exceptions for the following access control rules:
- Bot Access Control: Block clients (search bot, crawler) from visiting the site. Bad bot traffic is blocked by default by Incapsula, and users can add clients to that list.
- Block Countries: Restrict traffic based on geo location of the visitor.
- Block URLs: Restrict traffic to specific resources on the site for example, the “/wp-admin” URL on a WordPress site that should only be accessible to the site admin.
- Block IPs: Block traffic from a specific IP.
In cases where an exception is required, it can be deployed based on URL, IP, Country, Client app ID and User-Agent (for bot access control).
Sample use cases
One common use case involves government entities that only want their own citizens to have access to their online portals. Some governments block traffic from foreign countries to keep out the extra noise and minimize the chance of a data breach involving sensitive information. For example, a US government site may decide to block traffic from all countries (blacklist) except itself (see below).
Whitelist specific IP resources
In most cases, we recommend you whitelist under the specific context in which the block is made (described above). However, there may be cases where you would like traffic from a specific trusted source IP to bypass the Incapsula WAF and security settings altogether.
A good example would be an internal company HR portal that you only want to be accessed by company employees. In this case, simply enter the IP address for the company network in the Whitelist IPs field, and employee traffic to your site will bypass the WAF.
Five Steps to Set Up a Security Exception
Here’s how you can get the best results when you set up security exceptions in Incapsula:
- Define at least two parameters when making a security exception to minimized openings to potential attacks
- Isolate the most specific scenario and then choose the most appropriate approach — either whitelist or blacklist
- Deploy security exceptions in a gradual and controlled manner using “Alert Only” mode
- Once the rule with the security exception has been set to “Alert Only” mode, analyze the logs and then refine your parameters based on those results.
- Once you’ve optimized the results, upgrade from “Alert Only” to “Block” mode.
Security is a serious game and security exceptions are called that for a reason. We tune Incapsula WAF default security rules to maximize website security with minimum impact to legitimate users. Altering security rules needs to be done gradually to minimize interruptions to your customers. If you have any questions, please contact our support team to help you.
Try Imperva for Free
Protect your business for 30 days on Imperva.
