Google Cloud Threat Intelligence (GCTI) considers me dangerous and blocks me in their default threat intelligence rules

Well, not quite. For a brief moment I did in fact believe I was on “GCTI’s Most Wanted”. This is a story of finding a default misconfigured threat intelligence firewall rule from Google Cloud that cut off network connectivity to the platform.

The misconfigured rule

Google Cloud launched a great new feature known as Firewall Standard rules in June of this year. These capabilities are wonderful additions to the network security portfolio and help bring Google Cloud closer in line with features available in other clouds, such as AWS’s Network Firewall capabilities.

Notably included in these new rules are ‘Threat Intelligence for firewall policy rules’. Managed threat intelligence and easily implemented within the platform? Sign me up. I really liked the story of being able to lean on GCTI to quickly achieve outcomes such as: blocking ingress traffic from TOR exit nodes, known malicious IPs, etc.. Tie those rules together with GCP’s relatively new Hierarchical firewall policies that inherit across the entire environment and now we have a security outcome that shines pretty on the quarterly security executive report.

Google Cloud even provides you with a collection of these GCTI rules configured by default when you create a heirarchical firewall policy in the console! How convenient.

Note: This is the core misconfiguration and no longer accessible in Google Cloud

While playing around with these new GCTI rules in a sandbox environment, I quickly noticed something was odd. I was blocked from ANY ingress traffic despite permitting the correct traffic from the tried and trusty GCP Identity-Aware Proxy IP range. I felt silly enabling firewall logs for the new rules (certainly GCTI doesn’t think my IP is malicious!) and lo and behold - I was being blocked by the newly added TOR exit node rule.

# snipped firewall log
"rule_details": {
  "source_range": [
    "0.0.0.0/0"
  ],
  "reference": "0/firewallPolicy:$policy_id",
  "ip_port_info": [
    {
      "ip_protocol": "UNKNOWN_PROTOCOL"
    }
  ],
  "priority": 2147483543,
  "action": "DENY",
  "direction": "INGRESS",
  "source_threat_intelligence": [
    "iplist-tor-exit-nodes"
  ]
},
"disposition": "DENIED",
"connection": {
  "dest_port": 22,
  "dest_ip": "$private_ip",
  "src_port": $src_port,
  "protocol": 6,
  "src_ip": "35.235.244.x" <-- part of GCP's IAP CIDR range
"logName": "projects/$project_id/logs/compute.googleapis.com%2Ffirewall",

The following debugging session was a feverish sprint towards figuring out what was wrong: “my IP cycled on my router this weekend, did I pick up a residential IP from someone who was hosting TOR exit nodes?” Because I was using Google Cloud’s default rules for this policy, then certainly it was a mistake or context on my end, right?

The answer here is far less interesting. It quickly became apparent that the default GCTI rules provided by GCP were enforcing a ‘deny’ action on a firewall statement of ‘Is this ingress IP address coming from 0.0.0.0/0 OR is it included in our GCTI TOR exit node list?’. As a result the rule did not function as the advanced security control that would make InfoSec directors happy and was instead blocking all ingress traffic into my GCP sandbox. The default rules also included a rule to block all traffic egressing to known malicious IPs, which this rule also suffered from the same misconfiguration as the TOR exit node rule, thus blocking all traffic from leaving the GCP environment as well. This drama was compounded by the fact that the rules were applied against the Organization Hierarchical firewall policy, meaning these rules would be processed against all NICs under the account. My good intentions had cut off all network connectivity!

Obviously, this couldn’t be right. I double checked the workflow, got a sanity check from my go-to network engineer expert, and sent off a note to my GCP security contacts outlining the misconfiguration and its ramifications to good-willed security engineers like myself.

I deleted my problem firewall policies and moved on with life. I eventually revisited the bug and found the problem had been fixed - Google Cloud no longer offered the default misconfigured rules. A few days later the network engineer expert followed up with a Google Cloud notice sent to his email.

I will admit that this email was extremely cathartic to me. I had my fair share of ‘Chicken Little’ moments in this journey. To see the problem acknowledged was a blessing.

Why bother telling this story?

Cloud platforms are incredible engineering feats and market themselves are the best and brightest in the world. I agree with their messaging - their products are fascinatingly complex!

However like all software, these providers are prone to mistakes like anyone else. This firewall misconfiguration is a reminder to all engineers of all skill levels to raise your hand if something doesn’t smell right. You might point out something that no one has caught before.