Zero Trust networking — the security model that assumes no network location is inherently trusted — changes what port scanning means operationally: in a perimeter-based security model, open internal ports are assumed safe; in Zero Trust, every service must authenticate every connection regardless of network location, which makes the internal port exposure question a fundamentally different conversation
The previous articles on this site covered which ports should be open, cloud security group misconfigurations, NAT and port forwarding, IPv6 scanning resistance, and what attackers learn from port scans. This article addresses port scanning in the context of Zero Trust and microsegmentation — how organisations that have adopted Zero Trust think differently about network exposure, and what a port scanner reveals that's different from traditional perimeter-based thinking.
What Zero Trust means for internal port exposure
Traditional perimeter security assumes: if traffic is inside the network, it's trusted. An internal service listening on port 5432 (PostgreSQL) is safe because it's behind the firewall — only internal users can reach it.
Zero Trust inverts this assumption: no network location is inherently trusted. An authenticated user inside the corporate network must still authenticate to access each service, and services must authenticate to each other. A database on port 5432 that requires no authentication is a risk even if it's "internal only" — because:
- An attacker who compromises any internal device can pivot to the database
- Malware that infects a workstation can reach unauthenticated services
- Misconfigured VPN allows external access to "internal" resources
- Cloud VPC peering expands the "internal" boundary to include third-party environments
The Zero Trust port scanning question: not "is this port reachable from the internet?" but "what does every listening service require from connections, regardless of where they originate?"
Microsegmentation: network security below the VPC level
Microsegmentation divides a network into small zones where communication between zones requires explicit policy — instead of one large "internal" zone where all services can reach each other.
Traditional segmentation:
- External network (internet)
- DMZ (public-facing services)
- Internal network (everything else talks to everything else)
Microsegmentation:
- Application tier A (web servers) → can only reach Application tier B (app servers) on specific ports
- Application tier B → can only reach Database tier on port 5432
- Database tier → no outbound connections allowed
- Management plane → separate, only reachable from admin workstations on specific IPs
What a port scanner reveals in a microsegmented environment: running a port scan from within Application tier A should only show ports that Application tier A is permitted to reach in the microsegmentation policy. If it shows additional ports (the database directly, or other services), the microsegmentation policy has gaps.
Application-aware firewalls: beyond port-based filtering
Traditional firewalls filter on IP address, port number, and protocol. A rule that allows TCP port 443 permits all HTTPS traffic matching that rule.
Application-aware firewalls (Next-Generation Firewalls, NGFW) identify traffic by application behaviour regardless of port:
- Traffic on port 443 that behaves like a video streaming application → blocked by "no video streaming" policy, regardless of being on HTTPS port
- Traffic on a non-standard port that exhibits database query patterns → identified as database traffic, applies database access policy
- Traffic that attempts port scanning behaviour → detected and blocked by IDS/IPS integration
The port scanner interaction: a port scan against an NGFW-protected service may produce different results from a traditional firewall scan. The NGFW may detect the scan pattern and block subsequent probes, making ports appear "filtered" that are actually open but scan-protected. Rate-limited or randomised scanning behaviour bypasses some detection, but any active scan is potentially detectable.
Service mesh and mTLS: making port exposure less relevant
A service mesh (Istio, Linkerd, Consul Connect) sits alongside each service in a microservices architecture, intercepting all service-to-service communication:
mTLS (mutual TLS): in a service mesh, every connection requires both sides to present a certificate — the client proves its identity to the server, and the server proves its identity to the client. An unauthorised client that reaches the port gets an mTLS handshake failure, not access to the service.
What this means for port scanning: a port scanner that reaches a service mesh proxy sees an open port. But connecting to that open port without a valid certificate produces a TLS handshake error. The port is technically open; the service is effectively inaccessible without the certificate.
The operational implication: in a mature Zero Trust / service mesh environment, "open port" and "accessible service" are decoupled. Port scanning reveals network reachability but not service accessibility.
Container ports and Kubernetes service exposure
Kubernetes has a specific port exposure model that produces unexpected scan results:
Container ports: defined in the Pod spec, but not automatically exposed beyond the pod's network namespace. A container listening on port 8080 within a pod is only reachable from within the same pod or from other pods (subject to NetworkPolicy).
ClusterIP service: exposes a port within the Kubernetes cluster only. Not reachable from outside the cluster at all.
NodePort service: exposes a port on every node's IP in the cluster (typically in the 30000-32767 range). Reachable from the cluster network but not the internet (unless nodes have public IPs).
LoadBalancer service: provisions an external load balancer, making the service reachable from the internet.
Port scanning a Kubernetes cluster from outside: a standard port scan sees NodePort services (if any exist) and any ports opened directly on the node's host network. It does not see ClusterIP services at all. This can create a false sense of security — ClusterIP services are "invisible" to external port scans but are reachable from any compromised pod within the cluster.
How to use the Port Scanner on sadiqbd.com
- Zero Trust gap detection: run scans from within your internal network segments and compare results to your microsegmentation policy — any service visible that shouldn't be reachable from that segment represents a policy gap
- Before cloud deployments: scan your cloud resources (with permission) before moving them to production to verify that only the intended ports are externally reachable — surprises discovered in production are far more costly than in pre-launch audits
- Kubernetes external audit: scan your Kubernetes node IPs to identify any NodePort services that are externally reachable — these are often created for development convenience and forgotten in production
Frequently Asked Questions
Does Zero Trust eliminate the need for port scanning in security audits? No — it changes what port scanning means, not whether it's useful. In a Zero Trust environment, port scanning verifies that the network-level controls (firewall rules, microsegmentation policies, Kubernetes NetworkPolicies) are implemented correctly. Even if every service requires mTLS or application-level authentication, a service reachable from an unexpected network segment represents a misconfigured policy that could be exploited by a more sophisticated attack. Port scanning remains valuable as a network-layer control verification tool; Zero Trust adds application-layer authentication on top rather than replacing the network-layer controls entirely.
Is the Port Scanner free? Yes — completely free, no sign-up required.
Try the Port Scanner free at sadiqbd.com — check which ports are open on any host you have permission to scan.
