The Port You Closed That's Still Reachable
You audit your server. Port 5432 — PostgreSQL — is firewalled. The scan confirms it. Nothing gets through.
Then someone finds your database anyway, because it's exposed on a different interface, or through a container port mapping that bypassed the host firewall, or on an IPv6 address you weren't scanning.
Port scanning tells you what's reachable from where you scanned, on the address you scanned. Both halves of that qualification matter, and both are routinely overlooked.
Three States, Not Two
A scan doesn't return "open" or "closed." It returns one of three states, and the third is the informative one.
Open. Something accepted the connection. A service is listening and reachable.
Closed. The host responded, actively refusing the connection — a TCP RST. This means the host is up and reachable, and nothing is listening on that port.
Filtered. No response at all. The packet was dropped somewhere without a reply.
Closed and filtered are very different findings.
A closed port means your packet reached the host. The host is alive, routing works, and there's no firewall dropping traffic to that port. You've confirmed connectivity and confirmed the absence of a service.
A filtered port means your packet went somewhere and vanished. A firewall dropped it, a security group blocked it, a router discarded it — or the host doesn't exist.
Filtered is better from a security standpoint: it gives an attacker no information and costs them time, since each filtered port requires waiting for a timeout rather than getting an instant refusal.
But filtered also means you can't tell whether the service behind it is running. If you're troubleshooting rather than auditing, that ambiguity matters.
Scan Position Determines the Answer
The result depends entirely on where the scan originates.
From the public internet, you see what an anonymous outside party sees. This is what the Port Scanner gives you:
- Enter the host.
- Specify the ports or range.
- Read the state for each.
Useful for confirming that your external attack surface is what you think it is.
From inside the same network, you may see ports that are firewalled at the perimeter but open internally. This is often the more alarming result — a database that's properly blocked from the internet but open to every machine on the office LAN.
From the host itself, ss -tlnp or netstat -tlnp shows what's actually listening, and critically, on which interface:
127.0.0.1:5432 ← localhost only, not reachable externally
0.0.0.0:5432 ← all interfaces, reachable from anywhere routing allows
10.0.1.5:5432 ← one specific interface
That bind address is the difference between a service that's genuinely private and one that's only accidentally private because a firewall happens to be in the way.
The layered check that actually tells you something: scan externally, scan internally, and check the listening sockets on the host. Discrepancies between the three are where the findings are.
The Layers That Can Each Block Independently
A modern deployment has several filtering layers, and a port can be open at one and blocked at another:
- Cloud security group or network ACL
- Host firewall (iptables, nftables, ufw, Windows Firewall)
- Container networking — a port published to the host, or not
- Service bind address — localhost versus all interfaces
- Reverse proxy or load balancer in front
- Application-level access control
The common failure is container port publishing bypassing the host firewall. Docker on Linux inserts its own iptables rules, and a published port can be reachable even when the host firewall appears to block it. A rule in the INPUT chain doesn't necessarily apply to traffic that's being forwarded to a container.
Testing externally is the only reliable way to know the net result of all those layers.
What's Worth Checking
Rather than scanning all 65,535 ports, a focused check on services that shouldn't be public:
Databases:
3306 MySQL/MariaDB
5432 PostgreSQL
27017 MongoDB
6379 Redis
9200 Elasticsearch
5984 CouchDB
11211 Memcached
None of these belong on the public internet. Several have historically shipped with weak or absent default authentication, and internet-wide scanning services index exposed instances continuously.
Management and remote access:
22 SSH
3389 RDP
5900 VNC
23 Telnet
2375 Docker daemon (unauthenticated)
2376 Docker daemon (TLS)
10250 Kubelet
SSH is often legitimately public. Telnet should not exist. An unauthenticated Docker daemon on 2375 is effectively remote root.
Administrative interfaces:
8080, 8443 alternate HTTP/HTTPS, often admin panels
9090 various dashboards
15672 RabbitMQ management
5601 Kibana
3000 common dev server port
Legitimately public:
80 HTTP
443 HTTPS
25 SMTP (mail servers)
53 DNS (nameservers)
Anything else open on a public address deserves a reason.
IPv6
The gap most audits miss.
A host with both IPv4 and IPv6 addresses has two separate firewall configurations on Linux — iptables and ip6tables, or the equivalent in nftables. Rules written for one don't apply to the other.
A service bound to :: (all IPv6 interfaces) is reachable over IPv6 even if the IPv4 firewall blocks it, when the IPv6 ruleset is empty or permissive.
Cloud security groups generally handle both address families in one rule set, but host-level firewalls frequently don't. And a default IPv6 ruleset that accepts everything is common on systems where the administrator only ever configured IPv4.
Scan both address families. If your host has an AAAA record, scan that address too. The IPv6 address space being too large for exhaustive scanning doesn't help you — an address published in DNS is trivially discoverable.
What a Port Scan Doesn't Tell You
Whether the service is secure. An open port 22 with key-only authentication and an open port 22 with password authentication and no rate limiting look identical to a scanner.
Whether the software is patched. Version detection is a separate step, and banners can be misleading or suppressed.
Whether the service is authenticated. An open Redis port with no password and one with strong authentication both scan as open.
What's behind a proxy. A single open port 443 on a reverse proxy may front dozens of internal services.
A port scan is a reachability audit. It answers "what can be connected to," which is the first question, not the last one.
Running It Responsibly
Scan only hosts you own or have written permission to test. Unauthorised scanning is prohibited by most acceptable use policies and is illegal in some jurisdictions. The legal position varies by country and by intent, but "I was just checking" is a weak defence.
Expect to be logged. Scans appear in target logs and may trigger automated blocking of your source address.
Scan gently. Aggressive scanning can disrupt services, particularly on embedded devices and older network equipment.
Tell your team. A scan that triggers alerts and pulls people out of bed is a bad way to conduct an audit.
Practical Tips
Compare external, internal and on-host views. The differences are where the problems are.
Check the bind address, not just whether a port is firewalled. Binding to localhost is defence that doesn't depend on a firewall rule staying correct.
Scan IPv6 separately if the host has an IPv6 address.
Re-scan after every infrastructure change. New container, new security group rule, new deployment — the surface changes.
Document what should be open and why. An audit against a documented baseline is far faster than reasoning about each port from scratch.
Treat filtered on an unexpected port as worth investigating. It means something is there and being blocked, which is different from nothing being there.
FAQ
What's the difference between closed and filtered? Closed means the host actively refused the connection — it's reachable and nothing is listening. Filtered means no response at all, usually a firewall dropping the packet.
Is a filtered port more secure than a closed one? Marginally. It reveals less and costs an attacker time waiting for timeouts. Neither is a substitute for the service not being exposed.
Why is my port open despite a firewall rule? Common causes: container networking bypassing host firewall rules, a separate IPv6 ruleset, or the rule being in a chain that doesn't apply to that traffic path.
Should I scan my own servers? Yes, regularly. Knowing your external attack surface is basic hygiene. Only scan what you own or have permission to test.
Does a closed port mean the host is up? Yes. A closed response requires the host to actively refuse the connection, which confirms reachability.
Do I need to scan IPv6 separately? If the host has an IPv6 address, yes. Host firewalls typically maintain separate rule sets per address family.
The Takeaway
The useful output of a port scan isn't the list of open ports — it's the discrepancy between what you see externally, internally, and on the host itself. Filtered and closed carry different information, container networking routinely bypasses host firewalls, and IPv6 gets its own rule set that plenty of audits never check.
Check open ports on your own servers free with the Port Scanner at sadiqbd.com — no sign-up, instant results. Only scan hosts you own or have explicit permission to test.
