In the modern threat environment, robust protection for web applications is a necessity.
If your application is hosted in a cloud (IaaS) environment such as Google Cloud Platform (GCP), your first choice would probably be to consider a built-in security service such as Cloud Armor. But is that the best choice for your product and team?
In this article (Part 1 of a two-article series), we’ll discuss the pros and cons of Cloud Armor, taking a deep dive into its features and limitations. We’ll cover both technical and operational aspects so you can understand what it takes to use it in a production environment.
Note that Cloud Armor’s features are constantly being modified and updated by GCP’s team. All the observations mentioned in this article were valid at the time of this writing.
Cloud Armor 101
First things first. What is Cloud Armor? As marketed by Google, it’s a solution that helps you “protect your applications and websites against denial of service and web attacks.”
In plain language, Cloud Armor is a service residing between an untrusted network (usually the internet) and your application to protect you from three main attack classes:
- Distributed denial-of-service
- Bot attacks (such as ecommerce fraud, credential stuffing, etc.)
- Web application attacks (e.g., SQL injection, XSS, path traversal, etc.)
These threats are commonly addressed by a cloud WAF (Web Application Firewall), and Google intends Cloud Armor to fulfill that role for its customers. However, as we’ll see, many organizations will need something more.
Implementation and Integration
Cloud Armor integrates natively with other Google Cloud Platform services, such as global load balancers, GKE Ingress, Cloud CDN, and serverless apps. (However, it’s important to mention that for serverless apps, you must be careful to configure it properly; otherwise, attackers will be able to bypass Cloud Armor simply by referencing the default URL for the Cloud Function.)
It’s less straightforward to use Cloud Armor with services running in other clouds (e.g., AWS or Azure), on-prem data centers, or hybrid deployments. If you want to use Cloud Armor for non-GCP-hosted workloads, you’ll need to have a global load balancer in GCP. However, GCP’s load balancer has some limitations; for example, your fully qualified domain name (FQDN) must be resolvable by Google Public DNS, otherwise, the load balancer’s health checks will not be available. And if you aren’t already using GCP for other reasons, it doesn’t make much sense to add more complexity to your application’s architecture by having an extra load balancer and including a new IaaS provider in your cloud ecosystem, not to mention the extra work this would create for your team (including billing, identity and access management, and security hardening).
The discussion below assumes that you have workloads running in GCP, and are considering Cloud Armor as their primary form of protection.
Service Tiers and Pricing
Before we jump into creating and managing rule sets, let’s quickly explore the pricing schema. Cloud Armor is available in two service tiers: Standard and Managed Protection Plus.
In the Standard tier, you simply pay as you go. Most of the time, the largest part of your bill will be for processed requests ($0.75 per million requests). There is also a flat cost for every WAF rule and policy, but if you’re running a large application (such as ecommerce, social media, gaming), this cost is negligible.
Managed Protection Plus can be confusing for Cloud Armor users, as it is not a “pay and forget” type of feature. You still need to configure and handle most of the rules by yourself, although Google provides you with additional features (Threat Intelligence, named lists, and support in handling DDoS attacks).
Managed Protection Plus has a fixed fee (subscription price) of $3,000 per month, plus additional fees for traffic ($0.05 per 1 GB) and extra backend services ($30 per month for every service above a threshold of 100). Taking these fees into account, Cloud Armor can be expensive.
Last but not least, bot management (which for Cloud Armor is primarily reCAPTCHA) is not included in either tier. It’s billed separately.
Summing up, the more traffic you have, the more you’re going to pay. Although Google quotes a price for a service named Managed Protection Plus, in actual use you’ll have to pay quite a bit more than that price, and you’ll also have to do a lot of the management yourself.
How to Configure Cloud Armor
To demonstrate how to configure Cloud Armor to protect against common attack classes, we’ll start with rule sets for web application attacks. Cloud Armor includes these out of the box.
Web Attack Prevention Rules
Cloud Armor offers so-called “preconfigured WAF rules,” which rely on the OWASP ModSecurity Core Rule Set (CRS).
To be clear, Cloud Armor comes with no default rules. You still need to manually enable the preconfigured rules, which can be surprising to many users. On a positive note, the ModSecurity CRS is a well-known and open-source rule set that protects against a number of attack techniques and variations—SQL injection, remote code execution, XSS—if you know how to tune them to your application.
If you don’t have any previous experience with web application testing or WAF fine-tuning, adjusting the configuration of CRS rules on Cloud Armor will be a painful process. Although Cloud Armor allows you to set rules in preview mode and integrates nicely with Google’s Logs Explorer, it is not always easy to understand from logs why certain requests were denied.
Even if you do have previous experience with ModSecurity (e.g., on NGINX), it can be challenging to fine-tune Cloud Armor because it doesn’t give you the ability to edit specific rules. For instance, you can’t remove phrases that generate a large number of False Positives; instead, you have to include some preconfigured rule as-is in the policy, or else disable the rule completely.
Similarly, if your API relies heavily on JSON format, Cloud Armor with CRS rules will generate a lot of False Positive alarms due to special characters used in that notation. Thankfully, there is a configuration option which may help to parse JSON; however, it is disabled by default, so make sure that your security team knows how to enable it.
Processing data in XML format can create similar challenges. As there is no native configuration option to parse them, your team will need to spend time to whitelist certain endpoints or disable specific rules.
These limitations result in extra time needed to set up Cloud Armor correctly. On top of this, you’ll still need to whitelist certain IP addresses or allow good bots (whose traffic pattern may often be incorrectly classified as malicious and blocked). It is reasonable to assume that you will need at least two weeks of fine-tuning before your WAF is operational, and then ongoing maintenance is a continual process.
It’s also important to mention that Cloud Armor has documented limitations around processing certain request types (e.g., PUT, PATCH) or large POST requests (>8 KB). These requests are scanned only partially, which allows hackers to bypass WAF rules completely if no additional steps are taken.
What about L7 DDoS protection? Here, Cloud Armor focuses on two main features: rate limiting (manual) and adaptive protection.
Rate limiting is a mechanism that will perform an action (BAN or THROTTLE) after a defined rate threshold is exceeded. For example, you can configure rate limiting to allow no more than 10 requests per hour to a given URL from a single IP address, and then block subsequent requests. Or, you could allow only 10 requests per hour with a specific header value from a specific geographic location.
Google provides some flexibility while writing these policies, but overall, there are some significant limitations. For example, you can only select the time interval from Google’s predefined list of values (there are only 13 possible values, in an allowed range of 10 seconds to 10 minutes), and admins might need more control than this.
Similarly, the BAN action (which is imposed on clients generating a lot of traffic) can have a maximum duration of 3,600 seconds. If you are experiencing a long-lasting DDoS attack, or a regular DDoS attack every 24 hours, you will either need to blacklist the attacking IP addresses manually or allow them to hit you before they are blocked.
Another issue is how clients are identified and tracked. Cloud Armor can rate-limit by IP address, but many attackers will evade this by rotating IPs. There are only a few other tracking options offered, and even these have limitations. For example, headers, cookies, and URL path values are all truncated down to the first 128 bytes.
A larger problem is that currently, there is no easy way to add multiple IP addresses to Cloud Armor’s deny rules. If you want to block five IP addresses, that’s easy; you can create a rule and block them one by one. However, that’s not practical if you have, say, 1,000 IP addresses of VPN users that you want to include on your denylist. There are many common situations where this issue will arise, e.g. if you have information about a new botnet, or you want to block IP addresses that previously attacked you, and so on.
In the Standard (free) tier, adaptive protection is a Cloud Armor feature where it learns your application’s traffic pattern and notifies you about any anomalies that may indicate your application is under attack. If you spend enough time tuning it and removing False Positives (e.g., traffic spikes from service-to-service communication), it is a reasonably good notification mechanism.
Adaptive protection gets a little bit more interesting with the Managed Protection Plus tier. Apart from being notified about an attack, Cloud Armor also suggests a rule to stop it. Recently, Google even released an “auto-deploy” feature to deploy suggested rules automatically to an environment under attack.
Still, neither rate limiting nor adaptive protection is an “enable and forget” mechanism. They need to be constantly tuned to ensure they’re not blocking or alerting on legitimate traffic. An incorrectly tuned WAF with adaptive protection’s “auto-deploy” feature is a recipe for disaster.
Management & Operations
You can manage Cloud Armor either via a GUI (web console) or a CLI. In both cases, the administrator needs to learn the proper rules syntax, as currently this is the only way to write extra rules. Surprisingly, configuring and operating rules via the web console is a disappointing experience since certain important information (e.g., rate limiting thresholds and intervals) are simply not visible in the web console.
Similarly, Cloud Armor currently lacks any form of reporting. If you run applications in multiple projects or under a single project but with different security policies (which is extremely likely for modern applications), there is no single-pane-of-glass view. This means you can’t fully understand your attack surface and drill down to analyze the data from specific services protected by the WAF.
Because of this, you will likely need another log collection and data visualization tool to present your data properly.
So far, we’ve seen that Cloud Armor has a few advantages (primarily that it integrates natively with multiple GCP services and is easy to deploy). However, configuring it to protect your assets without impacting legitimate traffic can be very challenging, or in certain situations, not possible at all. Reporting, alerting, and visibility are lacking. And these issues must be dealt with not only during onboarding, but continually during production use.
In Part 2, we’ll continue our deep dive into Cloud Armor’s capabilities, focusing especially on its API protection, hostile bot management, and threat intelligence features.
Getting Effective Protection
When seeking a GCP web security solution, organizations often find that they need something more than Cloud Armor.
Reblaze is a comprehensive security platform that runs natively on Google Cloud. It’s a complete, all-in-one web security solution; all customers receive not only a next-gen WAF, but also DDoS protection, advanced bot management, API security, full-featured rate limiting, ATO (account takeover) prevention, full real-time traffic visibility and reporting, and much more.
Reblaze is a fully managed web security solution, configured and maintained for you by a team of security professionals. As new threats arise, Reblaze is hardened against them automatically.
To learn more about Reblaze, or to get a demo, contact us here.
Ziv Grinberg is VP of Product at Reblaze