How to reduce FPs from Request Missing an Accept Header (920300) rule in the Azure Web Application Gateway (WAF)? #3453
Comments
|
Hi @JacobChua12345, thanks for the report. Considering that you have been able to identify the specific type of traffic that is triggering the rule, the general suggestion would be to not remove the whole rule but rather to write a specific exclusion rule such as Example 5 (ctl:ruleRemoveById): here the rule is disabled only after a specific match that can be tailored to match the specific kind of traffic. I'm not familiar with the tuning options you have with Azure, but if including a manually crafted additional rule is something not viable, and if it is not possible to convert this exclusion via the Azure exclusion system, I think that the last resort is the suggested solution that you got: disable the whole rule.
Addressing other reports about 920300 false positives, this rule has been indeed moved to PL3, a pretty strict paranoia level where false positives are expected, and considerable tuning is required. Is in Azure WAF the latest CRS release candidate Also, the rule comes with a severity equal to 'NOTICE', it is meant not to rise that much the anomaly score. |
|
I am not facing any other false positives at the moment because it can be excluded with the Exclusion List that I did in Azure Portal WAF. However, from the Splunk screenshots you can see that the rule didn't managed to find anything making it empty and unable to exclude. Which I believe is the downside of the OWASP ModSecurity CRS rules in Azure WAF. What do you mean by "Is in Azure WAF the latest CRS release candidate 4.0.0-rc2 really an option?" Therefore, is this the sole solution which is to use "ctl:ruleRemoveById"? Because I remember this line was used to disable the rule entirely. |
I see two problems:
As far as one can tell, they both are limitations originated by the Azure WAF itself rather than by the rule set.
This action disables the rule entirely only after a certain condition is matched. So it would not disable the rule indiscriminately, but do it only for specific paths, clients, user agents, or any condition that might best suit the use case. Let's see if others will chime in with some possible alternatives or Azure WAF deeper knowledge :).
As per Azure WAF doc the supported CRS versions are
Glad you can deal with them via the Exclusion list. Any feedback about false positives that you are facing with |
|
@franbuehler What is your take on the seeming lack of |
|
@franbuehler Ping. |
|
Oh, thanks for the ping. I overlooked this issue and the former mention... let me check... |
|
I can confirm that the |
Uh oh!
There was an error while loading. Please reload this page.
Description
I oversee the monitoring of Azure WAF logs through Splunk. Currently, there's a significant volume of false positive traffic generated by Azure WAF, leading to frequent triggers of anomaly detection and creating a considerable amount of noise. The browser do show that there are Accept header when I Inspect the web page however the rule is still being trigger. Therefore, I'm seeking ways to address this issue.
My initial solution was to use Exclusion List in Azure Portal to exclude this specific type of traffic but no avail. In addition, I submitted a support ticket to Microsoft Azure to address this concern. However, the suggested solution was to disable the rule, which isn't ideal for my requirements. Disabling the rule would mean that any potentially malicious traffic might go unnoticed, as the rule wouldn't be able to flag it.
Logs
Your Environment
Confirmation
[ ] I have removed any personal data (email addresses, IP addresses,
passwords, domain names) from any logs posted.
The text was updated successfully, but these errors were encountered: