Cloud Armor pt. 2 – Customization of Rules

Dennis Sheen

March 6, 2023

Tags: Web Application Firewall, Waf, Technical Track, Cloud Armor, Google Cloud Platform (Gcp)

Cloud Armor Advanced Features

In my last post, I discussed a basic Cloud Armor setup and how to tune it. However, I didn’t get into some of the more advanced features that Cloud Armor supports that you will either want to turn on by default or potentially use, depending on your implementation and needs.

Adaptive Protection

Cloud Armor has a feature called Adaptive Protection which helps to highlight if an attack is happening to your site. Turning on Adaptive Protection is very simple with the command:

gcloud compute security-policies update security-policy-crs \
   --enable-layer7-ddos-defense

To ensure this feature is turned on in an existing environment, run this command:

gcloud compute security-policies describe security-policy-crs | grep -A2 adaptive

output:

adaptiveProtectionConfig:
  layer7DdosDefenseConfig:
    enable: true

It is worth noting here that there are two levels to adaptive protection:

Standard – this comes with the Cloud Armor Standard Tier Pricing and above.
Managed Protection Plus – this is an upgraded managed service from Google that includes some features and Google response teams in the event of a DDOS type of event.

With Google’s Adaptive Protection, Google runs a series of machine learning routines. These attempts identify attacks trying to bring down your site or attempting to access your data. With this, you can also see:

Detection and Alerting of anomalous activity
Generation of a signature of the potential attack (Managed Protection Plus only)
Generation of a custom WAF rule to implement (Managed Protection Plus only)
- There is currently a Pre-GA feature to automatically apply these custom Cloud Armor rules.

Adaptive Protection will send an alert with either package, but Google will provide more support to manage the issue if you have Managed Protection Plus services. Finally, Google heavily depended on this feature for the recent attack outlined in the news.

https://cloud.google.com/blog/products/identity-security/how-google-cloud-blocked-largest-layer-7-ddos-attack-at-46-million-rps

JSON Parsing

JSON Parsing is a tool to help Cloud Armor reduce the number of false positives. If you are using any amount of RESTful services or other json types of activity, you should enable this feature. It can be turned on with the command:

gcloud compute security-policies update security-policy-crs \
   --json-parsing=STANDARD

The feature looks for the standard “application/json” content type and will parse the json string before running other rules. This is to help reduce false positives in many cases. Google uses the example of a very basic json string {“test”: “123”} as triggering the owasp-crs-v030001-id942431-sqli rule if json-parsing is not enabled. This is because all of the value’s special characters {}:” will trigger the rule, but if json parsing is enabled, only the values of test and 123 will be inspected appropriately.

To ensure json parsing is turned on in your Cloud Armor instance, run this command:

cloud compute security-policies describe security-policy-crs | grep -A2 advanced

output:

advancedOptionsConfig:
  jsonParsing: STANDARD

Custom Rules

Finally, when you have exhausted all of the features and tuning you can manage, you may need to implement your own custom rules. These rules are available in the Standard Package and can be very basic to extremely complex. Also should be viewed as any code and need to be managed accordingly.

While very flexible, the implementation can be viewed more like a spreadsheet formula than a standard procedure, as you do not have any real ability to handle loops, if statements or any kind of GOTO line commands.

With that said, a few common scenarios may utilize this structure. For example, if you needed to block a given country of origin from your website for compliance reasons. Google has implemented a region code setting that is available to the rule.

gcloud compute security-policies rules create 100 \
    --security-policy security-policy-crs \
    --expression "origin.region_code == 'IR'" \
    --action "deny-403" \
    --description "country is Iran"

These can also start to get much more complex and specific. For example, you may have a known cookie that your site requires as long as you are logged in and your username requires word characters.

gcloud compute security-policies rules create 101 \
    --security-policy security-policy-crs \
    --expression "!((has(request.headers['user-id']) && request.headers['user-id'].matches('(?:^[0-9A-Za-z_]+$)')) || request.path.contains('login'))" \
    --action "deny-403" \
    --description "check for valid cookie or login page"

Notice that for this rule, we don’t want it to evaluate the engine as true otherwise, it will stop processing the next rule. So the last thing is to flip the boolean to false to allow access to the next rule, not give carte blanche to the whole site if this is true. Obviously, others looking at this will find it confusing at times, and too many of these rules will be challenging to manage, so the more complex rules will need to be kept to a minimum if you expect to be able to manage all of them over time.

Conclusion

Cloud Armor has some excellent advanced features that help deal with potential attacks, more encompassing rules for restful services and finally, just full-on customized rules. These allow you to tune your rules to your application well beyond just the preconfigured rules that Google has already created. This gives a lot of flexibility with the rules. However, it is important to understand it isn’t a full program you are running. The language is built for very low CPU/memory requirements, and as high a speed as possible limits what you can do.

In particular, if you have compliance needs or are trying to ensure older applications, which are more challenging to maintain, exposing a WAF like Cloud Armor is a must.

Supporting Links: