A firewall rule specifies traffic conditions and the action taken when those conditions match. In practice, its direction, action, ports, sources, targets, and priority determine which connections are allowed or blocked. section 11.1.3 section 11.1.4
Treat unexpected allowed traffic as a configuration-change investigation. Compare normal and abnormal destination ports, locate the first change, identify the rule responsible, and verify whether the logs show attempts rather than established sessions. section 11.1.3
A repeatable investigation workflow is:
- Chart allowed ingress connections by destination port, first over a broad time span and then around the suspected change. section 11.1.3
- Count destination ports and compare the result before and after the change; a sudden increase can reveal an overly broad rule. section 11.1.3
- Group events by rule reference to identify which rule allowed the traffic, then inspect its configuration and change history. section 11.1.3 section 11.1.4
- Record the finding, disable an unauthorized permissive rule, and escalate the exposure for threat-hunting and incident-response follow-up. section 11.1.4 section 11.1.7
Listing 11.1 Charting for allowed inbound connections with 1-hour time span
@sourcetype = "gcp:firewall" #1 | parseJson() #2 | "jsonPayload.rule_details.direction"="INGRESS" AND jsonPayload.rule_details.action="ALLOW" #3 | timeChart(span=1h, function=count(), series="jsonPayload.connection.dest_port") #4
Use the query listing to chart allowed GCP ingress connections by destination port and expose changes in the incoming traffic profile. section 11.1.3
The test-allow-all exposure
A junior administrator added the permissive GCP rule test-allow-all for testing and left it enabled. Around 12:05 UTC, unexpected incoming ports rose sharply; the rule allowed most of the traffic. The rule was disabled the next day, but exploitation could not be confirmed from firewall events alone. section 11.1.4 section 11.1.7
