Firewall rules that allow a range of ports instead of the specific ports a service needs
What does ZopNight detect here?
A firewall rule written as a port range, for example `tcp:20000-25000`, opens every port in the span even when the service behind it listens on two. ZopNight flags VPC firewall rules whose allowed ports include a range, as a medium compliance finding, and recommends listing discrete ports such as `tcp:80,443` so only the intended listeners are reachable.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1253 |
| Category | compliance |
| Severity | medium |
| Metric | none — pure configuration read |
| Threshold | allowed ports include a range |
| Source | ZopNight |
| Permissions used | compute.firewalls.list |
Where it applies
How port ranges creep into firewall rules
Google Cloud firewall rules accept a protocol with a single port, a comma list, or a range. The
protocols and ports table shows tcp:20-22 as
the range form and notes that a rule with a range applies to every destination port in it. The
console invites the same thing: its field takes entries like 20-22, 80, 8080.
Ranges are easy to write and hard to audit. A rule opened as tcp:8000-9000 for one
application server during a proof of concept quietly exposes whatever else later binds to any of
those thousand ports on the same targets. Nobody reviewing the rule a year later knows which of
them matter.
Spotting ranges in allowed ports
gcloud compute firewall-rules list \ --format="table(name, network, direction, sourceRanges.list(), allowed[].map().firewall_rule().list())"Any entry with a hyphen in the allowed column, such as tcp:8000-9000, is a range. Pay most
attention to the ones whose source column includes 0.0.0.0/0.
What ZopNight checks on each rule
While inventorying a firewall rule, ZopNight derives whether its allowed ports include a port range and stores that as a yes or no. The rule fires when the answer is yes. Source ranges, direction and target tags do not change the outcome, and no traffic data is used. Severity is medium, since a range is broader than necessary but not necessarily open to the internet.
When a rule passes
Rules listing only individual ports are silent. So are rules where the inventory could not determine the port layout: ZopNight needs a confirmed range before reporting. A rule that opens every port is a more serious case with its own finding, GCP Firewall Rule Allows All Ports. The finding clears automatically once a later scan sees the rule with discrete ports.
No dollar figure, a hygiene issue
There is no saving. The cost of a range is attack surface that grows silently: every new listener inside the span is reachable by whoever the rule’s sources are, with no firewall change and no review.
Replacing the range with specific ports
-
Find what actually listens. On the target VMs, check listening sockets, or enable firewall rule logging for a while and read which ports receive traffic.
-
Rewrite the allowed list with just those ports:
Terminal window gcloud compute firewall-rules update RULE_NAME --rules=tcp:8080,tcp:8443Note that a port cannot be given on its own: Google warns that
80alone is read as IP protocol 80, not TCP port 80, so always prefix the protocol. -
Test the service end to end, then remove any leftover rules that duplicated the range.