1

I have front door and WAF configured for one of my web application. The WAF is currently in detection mode. While reviewing the logs, I majorly see below details in all the block requests

ruleName_s : Microsoft_DefaultRuleSet-2.0-BLOCKING-EVALUATION-949110 action_s : Block policyMode_s : detection details_matches_s : [] details_msg_s : Inbound Anomaly Score Exceeded Type: AzureDiagnostics

The above is logged on random requestUri_s that have .html, .js, .jpeg etc. I did follow the trackingReference_s , but didnt get any derails with the trackingReference in the log.

I just want to see how can I evaluate false positive in this case. Is it ok to change the policy mode to prevention if these request are blocked in prevention mode.

Thanks Rajesh

neuro
  • 14,948
  • 3
  • 36
  • 59
Rajesh
  • 301
  • 3
  • 8

1 Answers1

1

To evaluate if these are false positives you'll need to look at several things.

An Azure Front Door log entry with the field "ruleName_s" of "Microsoft_DefaultRuleSet-2.0-BLOCKING-EVALUATION-949110" and an "action_s" of "Block" follows one or more log entries with an "action_s" of "AnomalyScoring". You can see all the relevant entries for a blocking evaluation by using the "trackingReference_s" field.

enter image description here

Text of the query:

AzureDiagnostics
| where trackingReference_s == '03VuQZAAAAABzkx+f3NXPRoWkytsHgm/vQVRBRURHRTEyMTYANTcxYzNhYmEtNjFlOC00NmZhLWJlNTktOTEyMjlkMTIyNzkz'
| project TimeGenerated, Category, ruleName_s, action_s, trackingReference_s
| order by TimeGenerated desc

After you know which rules triggered the block (in the example image, Microsoft_DefaultRuleSet-2.0-XSS-941170 and Microsoft_DefaultRuleSet-2.0-XSS-941130) you can investigate the "details_matches_s" and details_msg_s" columns to see what data from the request matched the blocking rule.

You can also determine how these rules evaluate by cross referencing the Web Application Firewall core rule sets here. For example, the rule in the Azure Front Door log for "Microsoft_DefaultRuleSet-2.0-XSS-941170" is a hit for the REQUEST-941-APPLICATION-ATTACK-XSS, specifically rule 941170 for "NoScript XSS InjectionChecker: Attribute Injection"

You can then download the rule definitions from the OWASP site to see the regex used to evaluate the rule.

Narthring
  • 1,124
  • 18
  • 32
  • Thanks Narthring, I followed the process that you have suggested and majorly I found the below under details_msg_s and action_s = AnomalyScoring SQL Injection Attack: SQL Operator Detected Possible XSS Attack Detected - HTML Tag Handler XSS Filter - Category 5: Disallowed HTML Attributes and Inbound Anomaly Score Exceeded for block action. After reviewing details_matches_s it seems majorly variables has junk data. Will it be safe that these are junk data and switching to prevention mode will be helpful? – Rajesh Jul 08 '23 at 17:09
  • I find the same thing, that most of the time strange, random stuff in the variables set off these rules. To be honest I’m not sure the difference switching modes from detection to prevention will do. I’ve found that it seems like even in prevention mode this traffic gets blocked. – Narthring Jul 08 '23 at 21:00
  • If you want this traffic to pass through you could set up a custom WAF rule to detect and pass the traffic. – Narthring Jul 08 '23 at 21:01
  • Thanks Narthring, I believe, in detection mode it will just detect, log and pass the traffic. But in prevention mode it will not pass the traffic. Only issue which I see is when I switch to prevention mode and it blocks the genuine request. Its getting hard to evaluate false positive in these cases. – Rajesh Jul 09 '23 at 07:21