Skip to content

Network Security

Statement

ClaimGuard runs on a single internet-exposed VM in GCP. Network security posture is enforced via:

  • GCP VPC firewall rules scoped to the production VM (the production VM, europe-west1-b).
  • Identity-Aware Proxy (IAP) as the only path to administrative SSH — no public SSH, no jump host, no shared bastion.
  • Cloud Audit Logs record every firewall rule mutation in the immutable audit log bucket (see Audit logging).

Implementation

Administrative access (SSH)

SSH is not exposed to the public internet. The only allow-rule for TCP/22 is the IAP-only SSH firewall rule, scoped to Google's IAP source range:

$ gcloud compute firewall-rules describe allow-ssh-iap --project=<project>
direction: INGRESS
allowed:
  - IPProtocol: tcp
    ports: ['22']
sourceRanges:
  - 35.235.240.0/20      # GCP IAP only
targetTags:
  - allow-ssh-iap

To reach the VM, an operator must:

  1. Hold a GCP IAM role granting roles/iap.tunnelResourceAccessor on the VM.
  2. Use gcloud compute ssh ... --tunnel-through-iap (no inbound port from the public internet is involved).

The legacy world-open SSH rules (a legacy SSH firewall rule, the default SSH firewall rule) were deleted on 2026-04-28 (an early plan step, journal entry of the same name).

RDP

There is no RDP service on the VM, and there has not been since at least the start of the hardening engagement. The legacy default RDP firewall rule that exposed RDP to 0.0.0.0/0 was deleted on 2026-04-27 (an early plan step). A second rule, a legacy firewall rule, also opened RDP alongside TCP/8188 and was deleted in the same week.

Application traffic

Application traffic currently reaches the VM directly on its public IP (the VM's static external IP, static, named the static external IP) on the API and frontend dev ports. As of 2026-05-04 the firewall-narrowing step is substantially done — the dev-server and backend-port world-open rules have been removed or narrowed — but a small residue remains. Closing the residue is tracked under Roadmap below.

The remaining sequence:

  1. the LB rollout step (done 2026-05-03) — global external Application Load Balancer with a Google-managed SSL certificate (app.dtectvision.ai). DNS resolves to the LB; HSTS one-year emitted at the application. HTTP→HTTPS 301 redirect added 2026-05-04. Cloud Armor security policy the Cloud Armor policy (per-IP rate limit + Adaptive L7-DDoS protection) attached to the backend service 2026-05-04.
  2. the firewall-narrowing step (substantially done 2026-05-04) — narrow the world-open dev/internal firewall rules. State now:
  3. the dev-server firewall rule (the dev-server port): deleted 2026-05-04.
  4. the internal-tool firewall rule: direct backend port removed 2026-05-04; rule still allows internal tool ports (FastAPI tool ports that nothing external should reach — narrowing further is the remaining work).
  5. an internal-tools firewall rule (an internal tool port, 9998, 8737, 5678): still in place; deferred pending operator confirmation that no external client uses these ports directly. n8n on an internal workflow-tool port is reverse-proxied via nginx at n8n.dtectvision.ai, making the direct an internal workflow-tool port exposure redundant.
  6. Other VPC rules — an internal-tool firewall rule, an internal-tool firewall rule, an internal-tool firewall rule, an internal-tool firewall rule, an internal-tool firewall rule, the n8n firewall rule, an internal-service firewall rule, an internal-service firewall rule, an internal-service firewall rule, a sibling-workload firewall rule, a sibling-workload firewall rule, an internal-tool firewall rule — these target sibling workloads in the project; cleanup is per-VM.

Internal service traffic

The Node.js backend talks to the on-VM Python tool services (an internal analysis service, content-provenance service, the image-detection service, content-provenance, metadata-extraction service) over 127.0.0.1 only. None of those calls leave the VM, so the firewall rules exposing those ports to 0.0.0.0/0 are surplus and slated for removal in the firewall-narrowing step.

Egress

Egress is the GCP default the default egress rule (allow all). Tightening egress is a roadmap item (post-LB, see below).

Status

implemented — verified 2026-05-06. The most material network boundaries are closed: HTTPS LB with Cloud Armor + HTTP→HTTPS redirect on app.dtectvision.ai; nginx + Let's Encrypt + redirect on claim-guard.dtectvision.ai; IAP-only SSH; world-open Vite + direct backend bypass closed 2026-05-04; Jupyter Lab on an internal port discovered + disabled 2026-05-04; firewall mutations audit-logged into the long-retention archive. Known gaps below are roadmap items.

What's done:

  • HTTPS LB live at app.dtectvision.ai with Google-managed cert
  • Cloud Armor (rate limit + Adaptive L7-DDoS protection) + HTTP→HTTPS 301 redirect (the LB rollout step done 2026-05-03; LB hardening layered on 2026-05-04).
  • nginx HTTPS at claim-guard.dtectvision.ai with Let's Encrypt cert + HTTP→HTTPS 301 redirect (canonical user URL today).
  • World-open SSH and RDP eliminated; SSH gated behind IAP.
  • World-open dev-server and direct-backend rules closed 2026-05-04 (the dev-server firewall rule deleted; the internal-tool firewall rule no longer lists 3001).
  • Jupyter Lab on an internal port (un-authenticated, code-execution path) was discovered and disabled 2026-05-04.
  • All firewall mutations are audit-logged via Cloud Audit Logs (now also archived to the long-retention audit log bucket after the sink-filter fix on 2026-05-04).
  • VM uses a known, static external IP (no risk of IP recycling exposing stale DNS).

What's still pending:

  • internal tool ports on the VM IP via the internal-tool firewall rule remain 0.0.0.0/0-reachable. Internal FastAPI tool ports; nothing external should reach them. Tightening is the remaining the firewall-narrowing residue task.
  • an internal-tools firewall rule rule (an internal tool port, 9998, 8737, 5678) remains in place pending operator confirmation that no external client uses these ports.
  • No custom SSL policy attached to the LB HTTPS proxy → defaults to GCP COMPATIBLE (TLS 1.0/1.1 still permitted).

Roadmap

  • Attach a MODERN (TLS 1.2+) SSL policy to the LB target HTTPS proxy.
  • Narrow the internal-tool firewall rule further or delete it (depends on whether tool services move to 127.0.0.1 bind).
  • Resolve the an internal-tools firewall rule (likely delete; n8n is reverse-proxied via nginx anyway).
  • Egress restrictions — define an egress allow-list (Secret Manager, Cloud Logging, GCS endpoints, third-party APIs the app calls).
  • Cloud Armor WAF rules (Layer 7 inspection) — currently the attached policy is rate-limit + Adaptive Protection only; preconfigured WAF rule sets (OWASP CRS) are a re-evaluation point for SOC 2 Type II.