2

I have a cloud run service behind an HTTPS external load balancer. I'm seeing a number of path scanning style requests (e.g. "/owa", "/admin") that are trying to find vulnerabilities. None of these are supplying a host header.

To reduce unnecessary startups of my cloud run container, and to minimise exposing information to random IP address scanners, I'm trying to find a way to reject requests to my load balancer that are missing a host header.

What I had hoped to do was to respond with a static 403 forbidden style response. However, from the documentation this isn't possible. The best I have come up with is specifying a "Default URL Redirect" in my url map to send all traffic to google.com that doesn't match any host rule in my url map. This works, but seems clunky and perhaps not appropriate.

Is it possible to send a static response - or is it only possible to redirect? Is there a better way to solve this?

  • 1
    The simplest method is to detect the Host header or lack thereof in your app running in Cloud Run and return any response you want. You can also deploy a Cloud Armor rule that rejects requests that do not match a specified Host header. Tip: you are chasing ghosts. For every request type you block, another will pop up. Just accept that public-facing services will be subject to this type of traffic. Unless this traffic is interfering with your application, is the time and money spent on these "ghosts" worth the results? – John Hanley Jun 21 '21 at 03:22
  • Thanks - my intent was to avoid placing this in Cloud Run for the reasons stated. I guess the correct response to my question is to use Cloud Armor. This meets the requirement. My main reason for reducing unecessary traffic is to make log parsing easier and avoid costs. The other solution I could use would be to have a default backend of a cloud storage bucket with no files in it. – James Valentine Jun 21 '21 at 21:57
  • I understand your intent. My comment is to get you thinking about the best implementation for your needs. Some objectives will not achieve good results in the real world. – John Hanley Jun 21 '21 at 22:19

1 Answers1

2

The correct answer from a GCP product perspective:

  • Use a Cloud Armor rule to effect the desired behaviour

This allows you to control a range of aspects of the response.

Alternate options you could consider:

  • Create an empty bucket and have that as the default backend.
  • A barebones nginx service on cloud run as the default backend that returns your desired status code.