Open Ports and Network Exposure Explained

What a port is and what open means

An IP address identifies a machine. A port number identifies a service on that machine: web servers conventionally listen on 80 and 443, SSH on 22, mail on 25, 465, 587, 993 and 995, and so on. For TCP, a service is reachable when a client can complete a three-way handshake with the port. When people say a port is open they mean exactly that: from where they stand, something accepted the connection.

Open does not mean broken or compromised. A public web server must have 443 open. The question is never simply whether a port is open but whether it should be open to everyone, and whether the service behind it is configured and maintained for that audience.

Open, closed, filtered and unknown

A scanner sends a connection attempt and sees one of a few outcomes, and each tells a slightly different story.

• Open: the handshake completed. Something is listening and the path from the scanner to it is clear.
• Closed: the host answered with a refusal. Nothing listens on that port, and no firewall is hiding it; the host itself replied.
• Filtered: nothing came back before the timeout. A firewall is probably dropping packets, but the host might also be down or overloaded. Filtered neither proves nor excludes a listener behind the firewall.
• Unknown: the test could not be completed, for instance through a local network error or a time budget. It must not be read as either safe or unsafe.

Likely service versus verified service

Port numbers are conventions, not guarantees. Port 3306 is usually MySQL or MariaDB, but any program can listen on any port. A scanner that names a service from the number alone is guessing. Some protocols speak first: SSH, FTP, SMTP, POP3 and IMAP servers send a greeting as soon as you connect. If the greeting matches the expected protocol, the service is verified rather than assumed. The DNS Tools Open Port Checker uses that distinction: it reads the greeting passively, without sending data, and labels results as likely or verified accordingly.

Neither label establishes a software version, and neither implies a vulnerability. Matching versions to vulnerability databases is a different, more intrusive activity that the checker does not perform.

Which exposures deserve attention

Services fall into rough groups by how appropriate public exposure is.

• Expected public services: HTTP and HTTPS on a website, SMTP on a mail server, DNS on a name server. Open ports here are normal; keep the software maintained and encrypted.
• Remote administration: SSH, RDP, VNC, WinRM and Telnet are for administrators. Public exposure invites constant automated login attempts; restrict to a VPN or known addresses and require strong authentication.
• File sharing and legacy: SMB, NetBIOS, RPC, NFS, rsync and FTP are designed for trusted networks, and several send credentials unencrypted.
• Databases and data stores: SQL Server, MySQL, PostgreSQL, Redis, MongoDB and Elasticsearch normally serve application servers over a private network, and some products historically shipped with weak or no authentication unless configured.
• Exposing SMB, RDP or a database is an exposure to restrict through access control. It is not evidence that you have been compromised, and no scanner result should be read as an incident declaration.

CDNs, proxies and what you are actually testing

If your domain sits behind a content delivery network or reverse proxy, a port scan of the domain tests the proxy's address. Such edges typically answer on web ports and refuse or drop everything else, so a clean result says nothing about your origin server, which has its own address and its own firewall. Conversely, an origin that accepts connections from anywhere defeats the point of the proxy, since attackers can bypass it. To assess the origin, test its own public address with permission, and configure its firewall to accept web traffic only from the proxy's published ranges.

How to restrict an exposed service safely

Reducing exposure is a change to a production system, so treat it as one. The risks are lockout and breaking a connection nobody remembered. Prerequisites are a console or out-of-band path to the machine, and a note of the current rules so you can restore them.

1. Find out who connects. Check service logs, connection tables or cloud flow logs to list real clients before you block anything.
2. Decide the intended audience: administrators on a VPN, application servers on a private subnet, partners with fixed addresses, or the whole internet.
3. Restrict at two layers: the host firewall and the cloud security group or network ACL. Replace any rule that allows every source with specific addresses or a VPN range.
4. If a service is unused, disable it. If it only serves the local machine, bind it to localhost or a private interface.
5. Strengthen the service itself: multi-factor authentication for remote access, enforced authentication and TLS for databases, key-based login for SSH.
6. Verify from outside. Run the port check again; the port should show closed or filtered. On the server, ss -tlnp on Linux or netstat -ano on Windows should show it no longer listens on a public interface.

Limits of outside-in testing

A port check is a snapshot from one place. It tests TCP only, so UDP services such as DNS over UDP, NTP and some VPNs are not covered. It tests a fixed list, so any port outside it is untested. Firewalls that rate-limit scanners, or allow certain source networks only, can make the same host look different elsewhere. A host with several addresses may expose different services on each. And a clean result is a statement about that moment, not a guarantee. Combine outside-in checks with inventory of what should be listening, and repeat them after infrastructure changes.

Frequently asked questions

Written by DNS Tools editorial · Last updated 2026-10-09