Implementing preconfigured WAF rules encountering high false positives

DevOps Google Cloud
1

Hi everyone
I’m currently implementing the preconfigured WAF rules in Google Cloud Armor security policy, and I’ve encountered a high number of false positives during testing.

The rules are currently set in preview mode, as our backend is live in production.
Has anyone faced a similar situation? Any recommendations on fine-tuning these rules or best practices for reducing false positives without compromising coverage?

Thanks in advance!

2

You can opt out of individual rules from the preconfigured rulesets

3

One suggestion is to create a log metric that includes the rule ID and action / mode (preview or blocking) as tags / labels. makes it easier to dashboard out the overall rate as well as which rules are getting triggered.

4

But yeah, my experience is that the cloud armor preset rules have a lot of false-positives, and in particular, the sql injection type rules can have a lot.

5

You can enable load balancer logs (jsonPayload.enforcedSecurityPolicy.outcome="DENY" OR jsonPayload.previewSecurityPolicy.outcome="DENY")

You will have information inside to understand which rule exactly and the reason, that can help a lot.

6

Per example, here an example

      "configuredAction": "DENY",
      "matchedFieldLength": 77,
      "matchedFieldName": "fields",
      "matchedFieldType": "ARG_VALUES",
      "matchedFieldValue": ",\"id\",",
      "matchedLength": 6,
      "matchedOffset": 7,
      "name": "<redacted>",
      "outcome": "DENY",
      "preconfiguredExprIds": [
        "owasp-crs-v030301-id942200-sqli"
      ],
      "priority": <redacted>
    },```


You can see that the predefined rules `sqli-v33-stable` were triggered by the signature `owasp-crs-v030301-id942200-sqli` (`Detects MySQL comment-/space-obfuscated injections and backtick termination`). And it was triggered by one value `\"id\"`, in the query parameter fields.

By experience, this <https://github.com/coreruleset/coreruleset/tree/main/rules|repository> can also help to understand each rule/signature
7

Yes – we’ve found the preconfigured rules to be somewhat useless in actual production, and we’re looking at third party alternates specifically because of it

8

and fwiw that seems to also be the same as the cloudflare rules engine, but cloudflare has several extra layers on top of that too

9

If you use GraphQL especially, the SQL injection rules create a lot of headaches

10

We have the Datadog WAF enabled currently had have seen relatively few FPs… YMMV

11

I’ve found the preconfigured rules to be a lot better for new, greenfield apps vs gnarly legacy apps

12

the problem is the method of fixing false positives becomes essentially turning it off

13

The other issue is a “false positive” that just looks like a false positive but might be a legit blocking. Do you want to wait for customers to scream before opting out or do you just want to see a log action for something that looks like a false positive and preemptively opt out before the customer screaming starts

14

https://issuetracker.google.com/issues/238793253
another interesting quirk I found a while back (that I think has still not been fixed)

15

subtle, but in theory, opens up some potential security issues

16

oh nice… I could’ve sworn I read in their documentation that an existing x-forwarded-for would be dropped

17

This was back in 2022, and I haven’t tested / verified it recently, so it’s possible it was fixed and they just didn’t close the issue.

18

Normally, I think Google would treat even a pretty esoteric security flaw a bit more seriously than I think they did this one? I don’t use Cloud Armor for this specific functionality at my current or previous job, so I really haven’t pushed on it more

19

I think you could work around it w/ custom headers

20

they mention in origin.user_uip docs that you could match against X-Real-IP but then they don’t say that is added, I think you have to add that as a custom header still