Table Of Contents

Fine-Tuning Firewall Rules

Restricting the Size of an HTTP Argument

Testing the Data Overflow Defense Rule

Creating a Modifier

Testing the Modifier

Fine-Tuning Firewall Rules

---

During testing or monitoring of a policy, you may encounter events in which legitimate requests mistakenly trigger a security rule. In order to avoid so-called "false positives," you can define explicit conditions under which the firewall rule accepts traffic that would otherwise be blocked.

Whenever a firewall rule executes (whether in monitor mode or not) it creates entries in the Web App Firewall Incidents page and in the Event Log. Descriptions of rule blocking events in the Event Log have a Create Exemption link that you can use to stop subsequent requests of the same type from triggering an incident. In this chapter, you'll use this feature to construct a modifier to a virtual web application. A modifier applies special processing to a subclass of the traffic handled by a virtual web application.

Restricting the Size of an HTTP Argument

Previously, you used the data overflow defense rules to stop requests that have an excessive number of HTTP headers. In these steps, you'll use the same rule to limit the size of request arguments. Requests with HTTP arguments of excessive length can cause a buffer overflow condition in some web applications. The Data Overflow Defense feature can enforce limits on the size of request arguments.

Configure an argument-length restriction as follows:

---

Step 1 Click the Profiles link in the Manager navigation menu.

Step 2 Click on the name of the profile you created, Poison Oak Traffic Validation.

Step 3 Click the edit link next to Data Overflow Defense in the Active Security section of the page.

The Data Overflow Defense rule editor displays the current configuration of this rule: allow a maximum of one HTTP header in monitor mode.

Step 4 Uncheck the Maximum Number of HTTP Headers option.

Step 5 Check the Maximum Size of Any Argument checkbox.

Argument validation applies to arguments in the URL of GET requests and to arguments in the URL and body of POST requests.

Step 6 In the bytes field, replace the default value with 20.

Step 7 Uncheck the Monitor Mode option.

Step 8 In the Actions section, replace the custom error response body with a descriptive message for this configuration, such as "Argument too big."

Step 9 Click Save Changes.

Step 10 Deploy the policy.

---

The Firewall now checks the length of arguments passed in requests to the Poison Oak application.

Testing the Data Overflow Defense Rule

Test the new rule configuration as follows:

---

Step 1 First make sure that the Firewall accepts requests within the configured limits. In your browser, enter the following address:

http://<Oak_VirtualURL>/index.jsp?myparam=thisisabigarg

Where <Oak_VirtualURL> is the hostname and port at which the Firewall exposes the Poison Oak web application to client requests.

---

Note In general, before sending new requests to the Poison Oak application you may need to clear your browser's cache to ensure that you see fresh rather than cached results.

---

The request should be accepted. Since the Poison Oak application is not programmed to handle the myparam argument, it is simply ignored.

Step 2 Now send a request that violates the argument-length restriction, such as:

http://<Oak_VirtualURL>/index.jsp?myparam=thisisanevenbiggerarg

This time, the Firewall blocks the request and returns an error response.

---

In the next section, you'll create a modifier that exempts the myparam parameter from this rule, while continuing to enforce the restriction on all other arguments.

Creating a Modifier

Recall that event log entries generated by Firewall security incidents provide a way to define an exemption for the violation that triggered the rule. Next, use this feature to create a modifier that exempts the myparam parameter from the 20-byte size limit, as follows:

---

Step 1 Click the Event Log link in the Manager navigation menu.

Step 2 Find an event log entry generated by the Data Overflow Defense rule after you applied the argument-size limit. To quickly find such an event among many log items, follow these steps:

a. Choose all records from the During menu at the top of the page.

b. In the description field, type "argument exceeded 20 bytes".

---

Note The description field is case-sensitive. Type the search string exactly as indicated.

---

c. Click the Update button.

Incidents triggered by the argument-length rule should appear. Notice that the description of the event includes a Create Exemption link.

Step 3 Click the Create Exemption link in the Event Log entry.

The Manager displays an Edit Firewall Modifier page with prepopulated values based on the incident.

Step 4 Keep the prepopulated values for the Path checkbox (checked) and the Path field (/index.jsp). This modifier will only apply to requests for this page.

Step 5 Change the Matching Mode to prefix.

Step 6 Exclude the argument-length restriction for the myparam parameter, as follows:

a. Check the Parameters checkbox.

b. Choose the query string matches regex item from the Parameters menu.

c. In the text field, type myparam=*

This regular expression causes the modifier to apply to all values of the myparam parameter.

Step 7 With the other settings on the page at their prepopulated values, click Save Changes.

Step 8 Deploy the policy to have the changes take effect.

---

When finished deploying, test the configuration of the modifier, as described next.

Testing the Modifier

After creating a modifier that exempts the myparam parameter from the 20-byte argument-length restriction, send a request to the Poison Oak sample application to test the modifier, as follows:

---

Step 1 Clear your browser's cache.

Step 2 Send a request that contains the same myparam parameter that previously violated the argument-length restriction, such as:

http://<Oak_VirtualURL>/index.jsp?myparam=thisisanevenbiggerarg 

This time, the modifier to the data overflow defense rule exempts the myparam parameter from this rule, so the Poison Oak home page appears in your browser.

Step 3 Change the name of the parameter in the request to make sure that the restriction is still imposed on other parameters to the page and try again:

http://<Oak_VirtualURL>/index.jsp?bar=thisisanevenbiggerarg 

This time, data overflow defense blocks the request and returns an error message to your browser.

---

Notice that a modifier applies special processing to a subclass of traffic handled by a virtual web application. For many false positives, the condition that caused the incident is applicable to requests for other resources in the web application, not just to the page on which the incident is triggered. If this is the case for a given incident, you will need to make the change effected by the modifier at a broader level, such as at the profile level.