NETWORK EXPOSURE

Open Port Checker

Check which of 31 common administrative, database, web and mail TCP ports accept connections from the internet on a host you own or are authorised to assess, and what to restrict.

No sign-up required. Public hosts and addresses only; results show what was observed, nothing is simulated.

What this open port checker does

The tool resolves the host name once, confirms that every address it resolves to is a public internet address, pins the first address, and attempts a TCP connection to each port on a fixed list of 31 common ports. The list covers remote administration (SSH, Telnet, RDP, VNC, WinRM), file sharing and RPC (FTP, NFS, SMB, NetBIOS, rsync), databases and data stores (SQL Server, MySQL, PostgreSQL, Redis, MongoDB, Elasticsearch), mail (SMTP, submission, POP3, IMAP and their TLS variants), web (80, 443, 8080, 8443) and DNS on port 53.

You cannot choose ports and you cannot aim the check at private, loopback or internal addresses; those are refused before any packet is sent. Connections are limited to eight at a time and each port gets about two and a half seconds. For a few services that speak first (SSH, FTP, SMTP, POP3, IMAP) the tool listens briefly for the greeting the server volunteers. It never sends anything, never logs in and never tries passwords.

Use it only on systems you own or are authorised to assess. It answers one narrow question: from the internet, does this address accept a TCP connection on this port right now?

How to read the results

Every tested port receives one of four states, and the difference matters.

OPEN: the TCP handshake completed, so something is listening and reachable from this scanner. This is exposure, not proof of a flaw.
CLOSED: the host actively refused or reset the connection. Nothing accepts connections on that port at that address, and the host is clearly answering.
FILTERED: no answer arrived in time. A firewall may be dropping the traffic, or the host may be down. It does not prove that nothing listens.
UNKNOWN: the check could not be completed, for example because of a local network error, a cancelled run or the time budget. UNKNOWN is never treated as safe and never as unsafe; re-run it.

Likely service versus verified service

The service name in the table is, by default, only a guess based on the port number: 3306 is usually MySQL or MariaDB, 3389 is usually RDP. The result says 'likely' for that reason. A service is labelled 'verified' only when the first bytes it sent on its own match the expected protocol greeting, for example an SSH identification string or an SMTP 220 banner, and that confirmation exists only for SSH, FTP, SMTP, submission, POP3 and IMAP.

A service can run on an unexpected port, so treat the label as a lead to confirm on the server with ss -tlnp or netstat -ano. The tool does not identify versions and does not compare anything against vulnerability databases: there is no CVE correlation and no claim that a service can be exploited.

Reading exposure in context

Open web ports (80, 443) on a website and open mail ports on a mail server are expected. The ports worth attention are those meant for administrators or trusted networks: RDP, VNC, WinRM, Telnet, SMB, NetBIOS, RPC, NFS, rsync, FTP and the database ports. An open SMB, RDP or database port is an exposure to restrict through access control. It does not mean the host has been compromised or that data has leaked.

If the address belongs to a content delivery network or reverse-proxy edge, the result describes the edge, not your origin server. The tool shows a CDN or edge note when it recognises the owning network, but the absence of a note is not proof that you reached the origin.

Common problems and what they usually mean

RDP, VNC or WinRM open: a management port is reachable by everyone, typically a firewall rule opened for convenience that was never narrowed.
Database port open: a security group allowing any source, or a database bound to all interfaces instead of a private one.
SMB, NetBIOS or NFS open: file-sharing meant for an internal network is reachable from outside, often after a migration or a default cloud rule.
FTP or Telnet open: legacy protocols that send credentials without encryption; SFTP or SSH are the usual replacements.
Everything FILTERED: the host may be down, or a firewall or rate limiter may be dropping this scanner entirely, so the result may be incomplete.
Different results from different places: allow-lists and intrusion prevention make ports visible to some networks only.

How to fix an exposure safely

Prerequisites: know which people, applications and partners legitimately connect to the service, and keep an out-of-band way into the machine such as a cloud console. Risk: tightening a rule can lock out administrators or break an application that connects directly. Rollback: record the existing firewall or security-group rule before editing it so you can restore it.

Identify the real clients of the service from its logs or a connection list.
Restrict the port in the host firewall and in the cloud security group or network ACL to a VPN subnet or to named administrator and application addresses; remove any rule that allows every source.
Where the service is unused, disable it. Where it is only needed locally, bind it to localhost or a private interface.
Require strong authentication, such as multi-factor authentication for remote administration and enforced credentials plus TLS for databases.
Verify from outside your network by running this check again. The port should now show CLOSED or FILTERED, and ss -tlnp on the server should show the service no longer listening on a public interface.

Limits of this check

The test is TCP only. UDP services, including DNS over UDP, NTP and many VPNs, are not examined. Only the fixed list is tested, so a result says nothing about any other port. One address from one vantage point is tested; other addresses of a multi-homed host, other regions and other moments can differ. Rate limiting can make open ports look filtered. A hostname that resolves only to IPv6 cannot be tested when the scanner itself has no IPv6 route, and the tool reports that instead of guessing.

Frequently asked questions

Is this a vulnerability scanner?

No. It reports whether a TCP connection is accepted on a fixed list of ports. It does not identify versions, match known vulnerabilities, attempt logins or exploit anything.

Why does the result say 'likely' instead of naming the service?

The name comes from the port number. Only a greeting sent by the server itself, available for SSH, FTP, SMTP, POP3 and IMAP, turns a guess into a verified service.

My site uses a CDN. Does this test my server?

No. It tests the address that the name resolves to, which is the CDN edge. To check the origin, test the origin server's own public address with permission, and confirm the origin firewall accepts only the CDN's ranges.

Does an open RDP or SMB port mean we were hacked?

No. It means the port is reachable. The correct response is to restrict it with a firewall or VPN and review authentication and logs, not to assume a breach.

Why are some ports FILTERED rather than CLOSED?

A closed port answers with a refusal. A filtered port gives no reply at all, which usually means a firewall is dropping packets. The difference helps you see where a firewall sits.

Scope of this tool

TCP only; UDP is not tested.
Only the fixed list of common ports is tested; you cannot choose ports.
One address and one vantage point.
Run it only against systems you own or are authorised to assess.

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