GigaOM Radar Edge Platform Leader & Outperformer 2024 | 
Figure 1: WAF events that occurred in the last 6 hours.
2. Look at the top 10 Rule IDs triggered by this traffic. Rule IDs are a great way to filter traffic further and observe the payloads for various WAF events. That said, start filtering the traffic by these Rule IDs one by one for further analysis.
Figure 2: Top 10 rules that were fired by the WAF events.
3. Next, review the payload values that triggered this rule by looking at the Matched Value field.
Figure 3: Payload values under the Matched Value column.
4. Analyze the payload values to identify whether they’re malicious. Not sure what they look like? Here are a few potential malicious values you may find in the payload.
- Path traversal: http://some_site.com.br/../../../../some dir/some file¹ http://testsite.com/get.asp?f=/etc/passwd²
- LFI vulnerabilities: An attacker is trying to access sensitive files on the server, such as .ini. The Edgecast WAF blocks this and many other critical filesystem extensions by default.³
- Cross-site scripting: http://testsite.test/<script>alert(“TEST”);</script>⁴ <img src=”http://url.to.file.which/not.exist” onerror=alert(document.cookie);>⁵
- SQL injection: SELECT * FROM items WHERE ‘a’=’a’;⁶ SELECT 1;⁷
- Remote code execution: eval(“\$$user = ‘$regdate’);⁸
- Time-based attacks: select 1 and sleep(2);⁹ select BENCHMARK(2000000,MD5(‘A’));¹⁰
5. If you’re still unsure whether the payload was malicious, a great way to figure it out is by looking at the list of client IPs that initiated the requests with the corresponding payload. If the client IPs are distributed, that is to say, varied, there is a good chance that the payload is a false positive. However, if all client IPs have the same value, that would indicate a potential volumetric attack, thus classifying it as a malicious payload. To demonstrate this, let’s refer to step 3 and pick this Matched value– {“iata”:[“TGZ”,”MEX”]} and use it as an example. To find out the list of client IPs that sent this payload, add the Matched value as a filter as follows:
Figure 5: Client IPs that sent the payload value: {“iata”:[“TGZ”,”MEX”]}.
In this case, given the variety of IP addresses making this request, there’s a high likelihood that these requests originated from real users making this a good candidate for a false positive.
6. Once a false positive is identified, you can create an exception for it in the Managed Rules section, but before doing that, you need to find out where this payload was found; query string, request header, URL, or other location. This is easily done by looking at the Matched On column on the same page from step 5. In this use case, the payload was found in the “data” query argument, as shown below:
Figure 6: Location of the payload value: {“iata”:[“TGZ”,”MEX”]}.
7. A good rule of thumb is to filter these specific Matched On fields that contain the false-positive payload and then verify that there isn’t any other request with this Matched On parameter carrying an actual malicious payload. In other words, the payload in the particular Matched On field is never malicious. This is achieved by adding a filter on the Matched On a field in question. Looking at our use case, we can confirm that there isn’t any malicious payload found in this query argument:
Figure 7: All payload values sent in the query argument: data.
8. The final step before creating an exception is finding the rule IDs triggered by the Matched On field. We’re trying to note all the rules (Rule IDs) that were triggered by this false positive. Based on our use case, this information is available on the same page from step 5.
Figure 8: The list of rules triggered by the payload value: {“iata”: [“TGZ”,”MEX”]}.
9. It’s time to create the exception. Go to the Managed Rules section and click on the managed rule to which you want to add these exceptions.
Figure 9: Existing Managed Rules created for the WAF configuration.
10. Go to the Exceptions tab and click on Add New Condition. Choose the type of Matched On the field, such as args, request_cookies, or URL where the payload was found. Then enter the parameter’s name, such as query or cookie. Finally, enter the list of all the Rule IDs the payload triggered.
