By Nupoor Chavan, Senior Solutions Engineer, Edgecast
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 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 a customized solution for their web application without incurring any additional support costs.
If you’re new to this space and have yet to work with the Edgecast WAF, please watch this short tutorial to get a basic understanding of the user interface and how it works.
If you already have an account with us, feel free to do this exercise along with me.
1. Let’s start by heading to the real-time dashboard and filter 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 tuning of the rules before, then be sure to choose a time frame after the latest tuning.)
Figure 1: WAF events that occured in the last 6 hours.
2. Now, 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 if they’re malicious or not. Not sure what they look like? Here are a few potential malicious values that 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 get access to 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 not entirely sure whether the payload was malicious or not, 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 found in the particular Matched On field is never malicious. This is achieved by adding a filter on the Matched On 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 to find the list of Rule IDs triggered by the Matched On field. We’re trying to make a note of all the rules (Rule IDs) that were triggered by this particular 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 field, such as args, request_cookies, or URL where the payload was found. Then enter the name of the parameter, such as query name, or cookie name. 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 from 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 and 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 Edgecast 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 Edgecast 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 Edgecast WAF offers dual WAF, an actual staging environment (we call it the audit mode) for your real-time traffic. You can make use of audit mode for all your recurring updates and fine-tunings to the rule-set without worrying about dropping legitimate traffic.
To learn more about all our security technologies that keep your web applications safe, please connect with us today.
Resources:
¹⁻² OWASP, “Path Traversal,” owasp.org, owasp.org/www-community/attacks/Path_Traversal.
⁴⁻⁵ OWASP, “Cross site scripting,” owasp.org, owasp.org/www-community/attacks/xss/.
⁶⁻⁷OWASP, “SQL injection,” owasp.org, owasp.org/www-community/attacks/SQL_Injection.
