Organizations migrating web applications and their APIs to the cloud need solutions to protect them from exploits and distributed denial of service (DDoS) attacks. Google Cloud Armor is a network security service that provides defenses against DDoS and OWASP Top 10 risks.
We are excited to introduce several new features in Cloud Armor: granular rate limiting with the ability to combine multiple keys; and more flexibility in creating IP-based custom rules based on the origins of requests to further enhance DDoS and web application protection.
Enforcing rate limiting with one or a combination of unique key identifiers
We announced Cloud Armor’s rate-limiting capability in June 2022, a feature which can help customers curtail Layer 7 web requests or TCP/SSL connections based on request volume to ensure service availability. Since then, we further enhanced Cloud Armor’s per-client rate limiting capability by introducing additional rate limit keys and the ability to combine multiple keys that help throttle traffic.
To configure a Cloud Armor rate limiting rule, users can enforce maximum requests or connection limits per client based on a key using the Google Cloud Console or API. We’re announcing several new key types including:
-
HTTP-PATH: for each HTTP URL path of requests
-
REGION-CODE: for each country/region code from which the request originate
-
SNI: for each server name indication value used in the TLS session for HTTPS requests
Cloud Armor users can now select up to three types from the list above where the combination of values across the selected types will form the actual key on which rate limit action is taken.
Previously a rate limiting rule based on source IP could potentially trigger false positives when a single client is visiting a web application page designed with numerous url paths. To avoid legitimate traffic accidentally being throttled in such design, a multi-key Cloud Armor rate limiting rule based on ‘IP” and “HTTP-PATH” can be a good solution.
A sample gcloud command for this example would be:
Providing flexible WAF rule configurations with new attributes: True-Client-IP and other custom IP
Cloud Armor IP filtering rules typically use the caller’s Client-IP in their evaluation. A common concern we heard from Cloud Armor customers is potential false positive DDoS alerts when Google Cloud-hosted services are run behind other infrastructure providers, such as an upstream CDN proxy or their own ingress proxy, since Cloud Armor will observe larger than usual traffic from a single source. In this example scenario, Cloud Armor’s security policy by default evaluates upstream proxy (23.220.162.152) instead of the actual IPs from upstream distributed clients, leaving users unaware of the true source of the traffic.
To address this, we recently introduced in public preview a user configurable field called “user_ip” to support True-Client-IP and other IP sources in the request header. Users can now tell Cloud Armor which IP address to use for their L7 filtering rules, Adaptive Protection, and Threat Intelligence by using the following instructions:
- code_block
- [StructValue([(u’code’, u’gcloud beta compute security-policies update POLICY_NAME [rn –user-ip-request-headers=HEADER_NAME[,…]rn]’), (u’language’, u”), (u’caption’, <wagtail.wagtailcore.rich_text.RichText object at 0x3e36caafd990>)])]
Take the same example with a single incoming request to Cloud Armor with layered header information on IP. Cloud Armor will still default to interrogating the Client-IP, in this case 23.220.162.152, which belongs to the upstream proxy. Additional configurations, however, allow customers to choose what Cloud Armor inspects.
-
Example 1: You can set “True-Client-IP” (142.251.163.99) to be used by Cloud Armor for policy wide inspection by using “–user-ip-request-headers=True-Client-IP”
-
Example 2: You can set the left most value of the XFF header (142.251.163.102) to be used by Cloud Armor by using “–user-ip-request-headers=X-Forwarded-For”
-
Example 3: You can set a sequence of IP header information to be used by Cloud Armor by configuring “–user-ip-request-headers=True-Client-IP, X-Forwarded-For” which allows Cloud Armor to
-
use True-Client-IP (142.251.163.99) as first choice
-
use XFF header (left most value 142.251.163.102) when True-Client-IP is not present
-
default back to Client-IP (142.251.163.99) when either True-Client-IP nor XFF is present
See more details on which IP you should choose for Cloud Armor evaluation here. After choosing an IP resolution strategy, you can now apply user_ip to Cloud Armor custom rules, Adaptive Protection, and Threat Intelligence. Setting up the appropriate user_ip will reduce false positives when Adaptive Protection is enabled.
Note that use of the user_ip field is an indicator of trust and care must be taken to ensure that the user_ip based features are only used when the upstream is considered trusted. For example, in a case where Adaptive Protection Auto Deploy is configured to use True-Client-IP to establish DDoS model baseline, untrusted sources such as a non-CDN upstream providing an unsanitized True-Client-IP header would allow a potential header-injection attack vector to compromise AutoDeploy rules.
Protecting API workloads with GraphQL content parsing
We understand web applications are evolving with the extensive usage of APIs and new web standards. Cloud Armor is positioned to leverage its WAF capabilities to take on a bigger role in protecting API workloads. The first step is to support parsing of GraphQL content in the incoming request. As an extension to our JSON content parsing capability, we are adding an additional flag for users to apply preconfigured WAF interrogation of incoming POST body requests in GraphQL format.
- code_block
- [StructValue([(u’code’, u’gcloud compute security-policies update my-policy rn –json-parsing STANDARD_WITH_GRAPHQL’), (u’language’, u”), (u’caption’, <wagtail.wagtailcore.rich_text.RichText object at 0x3e36c893b0d0>)])]
This can reduce false positives from preconfigured WAF rules for our customers who natively use GraphQL-formatted requests and expand Cloud Armor’s inspection of OWASP attack vectors in fields with JSON and GraphQL payload.
Do more with Cloud Armor
The first half of 2023 has been a busy and exciting few months for Cloud Armor. We introduced general availability of advanced rule tuning for preconfigured WAF rules early this year to help improve WAF tuning flexibility, reduce false positives, and automatically deploy Adaptive Protection. We also announced Cloud Armor for regional HTTP(S) load balancers in Preview, which allows users to create regionally scoped security policies where Cloud Armor rules are stored, evaluated, and enforced in a designated Cloud region, which can increase reliability needs.
To get the latest Cloud Armor feature release updates delivered to you, add this page to your feed reader.