Home Blogs WAF Tuning Made Easy
Applications

About The Author

Outline

Small and new businesses are facing a critical security challenge. They need a sophisticated security solution to keep their web applications safe while minimizing the costs of hiring dedicated security specialists or third-party managed services. With new attack vectors constantly emerging, web application security is becoming more crucial – and challenging than ever.

The Edgecast, now Edgio, WAF is the solution. It offers a robust and sophisticated solution that simplifies management. Real-time dashboards and log delivery provide up-to-date visibility so administrators can quickly identify threats and take action.

In this blog, we’ll focus on how businesses can identify and eliminate false positives and build customized solutions for their web application without incurring any additional support costs.

If you’re new to this space and have yet to work with the Edgio WAF, please watch this short tutorial to understand the user interface and how it works.

If you already have an account, feel free to do this exercise with me.

1. Let’s start by heading to the real-time dashboard and filtering the WAF events by time. This is the time period for which you want to analyze the web traffic. (Note: If you’ve already performed some rules tuning before, then be sure to choose a time frame after the latest tuning).

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.

Figure 10: The Exceptions Tab under the Managed Rule configuration. 11. Go ahead and create that condition. Within 30 seconds of saving the managed rule, you will be able to see this false positive passing through the WAF going forward 12. Now that you know how this works, go back to step 3, filter the traffic by another Rule ID, and repeat this process to eliminate as many false positives as possible. You did it. You just customized the WAF solution for your traffic.

A few final tips

If you’re using the Edgio WAF for the first time, we recommend performing 2-3 rounds of this exercise before turning the block mode on. And based on your traffic volume, you can repeat this exercise every 2-7 days. For existing Edgio WAF customers, we recommend performing this fine-tuning exercise every 3-4 weeks. One more thing that you should consider is lowering the threshold value of your managed rule to less than 10, gradually making your way to the optimal value of 5. This ensures that you’re steadily curating a more precise and crisp ruleset. Remember, the Edgio WAF offers dual WAF, an actual staging environment (the audit mode) for your real-time traffic. You can use audit mode for all your recurring updates and fine-tunings to the rule set without worrying about dropping legitimate traffic. Please connect with us today to learn more about all our security technologies that keep your web applications safe.

Resources:

¹⁻² OWASP, “Path Traversal,” owasp.org, owasp.org/www-community/attacks/Path_Traversal.

³ Offensive Security, “File inclusion vulnerabilities,” offensive-security.com, offensive-security.com/metasploit-unleashed/file-inclusion-vulnerabilities/.

⁴⁻⁵ OWASP, “Cross site scripting,” owasp.org, owasp.org/www-community/attacks/xss/.

⁶⁻⁷OWASP, “SQL injection,” owasp.org, owasp.org/www-community/attacks/SQL_Injection.

⁸ Netsparker, “Remote code evaluation (execution) vulnerability,” netsparker.com, netsparker.com/blog/web-security/remote-code-evaluation-execution/.

⁹⁻¹⁰ Ashraff, Ahmad, “Timing-based attacks in web applications,” owasp.org, owasp.org/www-pdf-archive/2018-02-05-AhmadAshraff.pdf.