Firewall Allows Public SMB: Closing Port 445 on GCP

SMB has no business being reachable from the open internet, yet it shows up in exposed firewall rules more often than you would expect. The vpc_opensmb check inspects your GCP VPC firewall rules and raises a finding whenever TCP port 445 is allowed from a public source range. If you run Windows file servers, domain controllers, or anything sharing files over SMB on Compute Engine, this is one of the first things an attacker will scan for.

---

What this check detects

Lensix reads your VPC firewall rules and looks for ingress rules that meet all of these conditions:

• Direction is INGRESS
• Action is ALLOW
• The protocol/port set includes TCP 445 (either explicitly, as part of a range, or via an "all ports" rule)
• The source range includes a public CIDR, most commonly 0.0.0.0/0

SMB (Server Message Block) is the protocol Windows uses for file and printer sharing, and it also underpins authentication traffic between domain-joined machines. Port 445 is the modern transport for it. When a firewall rule opens 445 to the world, every Windows host the rule applies to is reachable by anyone who can route to its public IP.

---

Why it matters

SMB is one of the most heavily targeted protocols on the internet, and for good reason. The risk is not theoretical.

A history of wormable exploits

EternalBlue (CVE-2017-0144) abused a flaw in SMBv1 and powered the WannaCry and NotPetya outbreaks in 2017, which together caused billions of dollars in damage. SMBGhost (CVE-2020-0796) hit SMBv3 with a pre-authentication remote code execution bug. These are not one-off events. SMB vulnerabilities resurface regularly, and a publicly exposed port 445 means you are exposed the moment a new one drops, before you have a chance to patch.

Credential theft and relay attacks

Even without a memorable CVE, an exposed SMB endpoint leaks information. Attackers can enumerate shares, attempt null sessions, and run NTLM relay or brute-force attacks against accounts. A single weak service account password on an internet-facing SMB host can lead to lateral movement across a Windows domain.

Ransomware ingress

SMB is a favorite for both initial access and ransomware propagation. Once inside, ransomware uses SMB to spread to every reachable share. An exposed port 445 shortens the attacker's path from internet to encrypted file server to almost nothing.

---

How to fix it

The goal is simple: SMB traffic should only come from trusted internal sources, never from the public internet. Here is how to find and remediate the offending rule.

1. Find the offending rule

List firewall rules and filter for anything allowing port 445:

gcloud compute firewall-rules list \
  --format="table(name, network, direction, sourceRanges.list(), allowed[].map().firewall_rule().list())" \
  --filter="direction=INGRESS AND allowed.ports:445"

To inspect a specific rule in full:

gcloud compute firewall-rules describe RULE_NAME --format=json

Look at sourceRanges. If you see 0.0.0.0/0 (or any public block) alongside an allowed entry for TCP 445, that is your problem.

2. Decide: restrict or remove

Most of the time, no instance needs SMB from the public internet. Confirm whether anything legitimately depends on this rule before touching it.

3a. Restrict the source range

If SMB access is genuinely needed from specific known networks, replace the public range with those CIDRs. You cannot edit sourceRanges in place to add and remove in one call, so update the rule with the exact set you want:

gcloud compute firewall-rules update allow-smb \
  --source-ranges=10.0.0.0/8,192.168.1.0/24

This overwrites the source ranges entirely, dropping 0.0.0.0/0 and allowing only your internal blocks.

3b. Delete the rule

gcloud compute firewall-rules delete allow-smb

4. Use IAP for admin access instead

If you need to administer Windows instances remotely, do not expose SMB or RDP publicly. Use Identity-Aware Proxy (IAP) TCP forwarding, which tunnels traffic over Google's authenticated, authorized path. Allow IAP's range to your instances and tunnel from your workstation:

# Allow IAP source range to reach the relevant ports
gcloud compute firewall-rules create allow-iap-smb \
  --direction=INGRESS \
  --action=ALLOW \
  --rules=tcp:445 \
  --source-ranges=35.235.240.0/20 \
  --target-tags=windows-fileserver

# Tunnel to the instance from your machine
gcloud compute start-iap-tunnel INSTANCE_NAME 445 \
  --local-host-port=localhost:4450 \
  --zone=us-central1-a

---

Fixing it with Terraform

If your firewall rules live in Terraform, fix the source of truth rather than the live resource, otherwise your next apply will reintroduce the exposure. A safe internal-only SMB rule looks like this:

resource "google_compute_firewall" "allow_smb_internal" {
  name      = "allow-smb-internal"
  network   = google_compute_network.main.name
  direction = "INGRESS"

  allow {
    protocol = "tcp"
    ports    = ["445"]
  }

  # Internal ranges only, never 0.0.0.0/0
  source_ranges = ["10.0.0.0/8"]
  target_tags   = ["windows-fileserver"]
}

Search your codebase for any rule pairing "445" with a 0.0.0.0/0 source range and correct it the same way.

---

How to prevent it from happening again

One-off fixes do not last. Bake the rule into your pipeline so a public SMB rule can never merge in the first place.

Policy as code with OPA / Conftest

Add a policy that fails any plan opening 445 to the public internet:

package terraform.firewall

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "google_compute_firewall"
  rule := resource.change.after
  rule.source_ranges[_] == "0.0.0.0/0"
  allow := rule.allow[_]
  allow.ports[_] == "445"
  msg := sprintf("Firewall rule '%s' exposes SMB (445) to the public internet", [rule.name])
}

Run it in CI before any merge:

terraform plan -out=tfplan.binary
terraform show -json tfplan.binary > tfplan.json
conftest test tfplan.json

Continuous monitoring

Pipeline gates catch new code, but rules also get created by hand in the console or by scripts that bypass review. Keep vpc_opensmb running continuously in Lensix so any drift, regardless of how it was introduced, surfaces immediately rather than waiting for the next audit.

---

Best practices

• Never expose SMB, RDP, or WinRM to the internet. Ports 445, 3389, and 5985/5986 belong on internal networks only.
• Default to deny. Start with no ingress and add narrow rules for specific tags and source ranges as you need them.
• Use IAP or a VPN for remote administration rather than punching holes in the firewall.
• Scope rules with target tags or service accounts, not broad subnet matches, so a rule's blast radius stays predictable.
• Disable SMBv1 entirely on your Windows hosts. It has no place in a modern environment and is the vector for the worst SMB worms.
• Keep Windows instances patched. SMB vulnerabilities recur, and a fast patch cadence is your last line of defense if a host is ever exposed.
• Review firewall rules on a schedule. Rules accumulate. Periodically prune anything with no clear owner or purpose.

SMB exposure is a high-severity, low-effort fix. Lock port 445 to internal ranges, route admin access through IAP, and gate your pipeline so the rule never comes back. A few minutes of work closes one of the most reliably exploited doors in the cloud.