Setting up Cloud Armor for load balancer/static website in Storage Bucket

Question

I recently setup a Storage Bucket to serve a static website within the Google Cloud Platform. Costs were rising for a few days so I looked into what was causing this. I looked into Logging and found that there are a very large amount of requests sent to the Load Balancer made by bots with ie injection attacks.

GET https://[ip]/nice%20ports%2C/Trinity.txt.bak
GET https://[ip]/nmaplowercheck1672474071

The situation left me with two questions.

1. Are these requests possibly driving up the costs in my project?

If so, I looked into Cloud Armor and it's possibilities in blocking these kinds of requests by implementing OWASP (Preconfigured WAF rules). But i'm not really sure how to set this up correctly.

2. How could one implement Cloud Armor to prevent these requests from coming in, ie through preconfigured WAF rules?

I expect my Load Balancer to block these injection attacks

Answer 1

Cloud Armor has 2 types of "security policies":

1. Edge Security Policy: used to block IP and Geo values only. Edge Security Policies can be applied to either Cloud CDN or a Storage backend on the global load balancer. You cannot do any L7 rules with this policy type. In the future, this may change, but right now, you can only do IP and geo enforcement.

2. Backend Security Policy: this can be applied against a compute based backend or Inte.net Network Endpoint Group (NEG). In the Backend Security Policy, you can apply pre-configured OWASP rules, rate limiting, Common Expression Language (CEL) rules, IP rules, geo rules, etc.

What this means is that you are not going to be able to block these types of probing requests with Cloud Armor against a Storage bucket backend using the Edge Security Policy.

If you wanted to use Cloud Armor to mitigate these sorts of attempts, you need a CEL rule policy to match the incoming URL and that can only be done using a Backend Security Policy. You could attach the Storage bucket as an Inte.net NEG on your load balancer and then draft a backend policy that would contain a rule like this:

request.path.lower().urlDecode().contains("nice port")

Or you could target the suffix match in your rule.

Assuming that you don't have any *.txt.bak files in your Storage bucket, you would just end up serving an error. In general, responses to requests count as egress and are charged, but if you are serving up an innocuous error message, this shouldn't ramp up your bill.

If you do go the Cloud Armor + Inte.net NEG + Storage route as you want to stop the probing of your Storage resources, you would need to attach the Storage bucket as a Pubic resource in the Inte.net NEG and then attach the Inte.net NEG as a Backend Service on the GCLB as opposed to attaching the Storage bucket as a Backend Bucket option on the GCLB. By attaching the the bucket as a Backend Resource via the Inte.net NEG, know that you are now incurring Inte.net egress charges from the use of the Inte.net NEG, as well as you have to make your bucket public (or sign requests to allow users to access the private bucket).