Yeah, working with Application Gateway and Web Application Firewall isn’t always a dream come true. Sometimes you need to get hold of what rules are being triggered and actually hindering your traffic to APIM.
Today I sat down and had a go at actually finding where it logs triggered rules and came up with this little Kusto script for it:
AzureDiagnostics
| where ResourceProvider == "MICROSOFT.NETWORK" and Category == "ApplicationGatewayFirewallLog" and requestUri_s has "/ifs/"
| order by TimeGenerated desc
As you can see, I had a problem with an API for IFS. You can omit that part if you need to or tweak it to suit your needs.
When browsing through the result I found another peculiar thing here. At least, something I didn’t know about before. WAF has several levels and if you break any rules it actually counts against the call and can trigger a global ruleset. This global ruleset is not visible in the WAF config in Application Gateway. As I understand it, you need to migrate your rules first. Don’t know what that means (yet), but I deduced that another triggered rule was the actual culprit and it sure helped to turn it off in our case.
The message I found in the logs was: Inbound Anomaly Score Exceeded (Total Score: 5) paired with the Global rule REQUEST-949-BLOCKING-EVALUATION. After digging around a bit more we found yet another rule that had fired on the same call: REQUEST-942-APPLICATION-ATTACK-SQLI with the message: Detects concatenated basic SQL injection and SQLLFI attempts.
The basis here is that we are exposing an API that takes OData requests in the URI. The request can contain ‘$select’ and I think this triggers the rule in ruleset 942 which is confirmed in the log field ‘details_data_s’: Matched Data: $select found within ARGS_NAMES: $select
Now I just need to contemplate the consequences of inactivating this rule… Yes, we tried to have the complete URL encoded, didn’t help…