How to Troubleshoot Azure WAF
Microsoft Azure offers a WAF solution, for which a quick guide for debugging it can be useful. Let's take a closer look!
Join the DZone community and get the full member experience.
Join For FreeWhat is Azure Application Gateway?
Azure Application Gateway is a (WAF) that protects web applications against common vulnerabilities and exploitation. It is based on OWASP rules and follows all the rules 3.0 or 2.2.9 of OWASP (Open Web Application Security Project). Microsoft tells us that these rules update themselves, which does not prevent it from having rules that generate false positives. This may also be due to a poorly implemented application, or a perfectible web framework, or perhaps that should be updated. It, therefore, seems useful to know how to debug it if you plan to use it in a project. This article is, therefore, a quick guide for debugging your WAF.
You may also enjoy: Understanding Azure Load Balancing Solutions
Before Troubleshooting
- First, ensure that the "WAF Diagnostics Logs" are enabled. Make sure you have access to the administration console (I know it goes without saying, but it gets better by saying it).
- Second, find out the mode in which the WAF is located:
- Detection: Monitor and log all threat alerts. You enable the recording of diagnostics for Application Gateway in the Diagnostics section. You must also check that the WAF log is selected and activated. The web application firewall does not block incoming requests when it operates in detection mode.
- Prevention: Blocks intrusions and attacks detected by the rules. The attacker receives a "403 Unauthorized Access" exception and the connection is terminated. The prevention mode records such attacks in WAF logs.
- Read some documentations :
Generic Process
- Generate errors, noting the date, time, and environment (production, pre-production, etc.) of the error occurrence.
- Go read the logs at these times, using the Azure Monitor
@TODO
and take a screenshot. - Analyze the logs (which is a JSON file).
- List of important keywords :
- requestUri: URI of the request, useful in case the problem occurs each time with the same URI.
- ruleId: Rule ID
- ruleGroup: As the name suggests
- details\file: Name of the file where the rule is defined
- details\line: File line where the rule is triggered
- message: Generic wording of the detected problem
- details\Message: Explanation of the error
- details\data: Explanation of the error containing the problematic content
- To find the rule:
- Go to: https://github.com/SpiderLabs/owasp-modsecurity-crs/tree/v3.0/master/rules
- Open the file indicated in the parameter details\file and go to the line indicated by the parameter details\line
- List of important keywords :
- Depending on the case:
- Either ask the project to make the necessary changes
- Or add an exclusion, as indicated above at this URL
- Examples of exclusion :
- I have a cookie that contains attributes that cause concern :
- Add an exclusion rule "Request cookie name equals <cookie-attribute-name>"
- I have a setting on my HTTP call that raises concerns :
- Add an exclusion rule "Request attribute name equals content"
- I have a cookie that contains attributes that cause concern :
- Examples of exclusion :
- Go back to point 2, as long as you have errors.
Further Reason
Web Application Security: The New Way Forward
Opinions expressed by DZone contributors are their own.
Comments