Working With Cloud Armor

This repo is a scratch pad of how to create rules, validate them, gain visibility into Google Cloud Armor. Hopefully you will find it useful to learn from what others have done.

What is Cloud Armor?

Google has published much information here. The TL;DR is Cloud Armor is a DoS and WAF protection system built on Google's network, leveraging the same technology Google uses for security, that can protect you application from volumetric, malformed protocol or Web Application security risks.

Is a WAF a replacement for secure coding practices?

No. A WAF is a security control to used in conjunction with proper code and patching practices.

Can I "Set it and forget it?"

No. All WAFs require tuning as applications are unique. Rules should be evaluated to ensure they allow your application to function correctly prior to enforcing them.

Best Practices

• Create spacing between each rule. You may need to insert rules, so having space to insert a rule at given priority value is powerful for when you need to add a rule. Recommended is a minimum of 10. For example 100, 110, 120 etc.

• Use a default DENY in the policy. Require the explicit allowing of all traffic, even if you want the entire internet to access it.

• Create "blocks' of related rules in based on the priority list. You may have IP ranges or other traffic that you may wish to allow, you may be using the preconfigured expression IDs for OWASP Core Rule Set, you may have scanners etc. By creating blocks of rules combined with spacing you now have have "sections". For example

  • 1000's Any explict GEOs, IPs or ASN's that should be blocked.
  • 2000's Trusted source systems (1010,1020,1030 etc)
  • 3000's OWASP evaluation - 1 per rule (2010,2020,2030,2040 etc)
  • 4000's Custom rules based on your application (3010,3020,3030 etc)
  • 5000's Security scanners
  • 10000 Default permit
  • Rule default action DENY

• Manage your rule set as code by importing and exporting it.

• Test your rules and logic, rules cannot be combined so the first match / action will occur. Get comfortable with CURL to test the rules for HTTP attributes.

• Understand if all HTTP methods should apply to all URLs. Filter methods that should be disallowed.

• Filter content-type for your application or API. For example if you only accept JSON in PUTS or POST requests drop XML at the edge.

• Build dashboards aligned to the application. You want to keep track of other indicators of risk. Application latency, CPU load etc.

• Create relevant custom metrics and alerts for your application and operations team(s)

• Separation of duties. All to often a mistake can be made where the policy allows more access then necessary.

• Think broadly of how attacks and redirects can be embedded. For example if you want to secure /admin you may want to not just match /admin you may want to use contains.

Example Rules