Port scanner

How this tool works

Enter a hostname or an IP address. Our probe server, a dedicated machine used for active network tests, attempts a TCP connection to each port on a list of commonly used ports, in parallel, with a short overall time limit. The result is a table of ports with their state and the service normally associated with each. The tool is free and needs no account.

A TCP connect scan is the simplest and most honest kind of scan: the probe completes the normal handshake on each port exactly as a client would, then closes the connection without sending data. There are no crafted packets and no attempt to evade anything. The states are the same as on the port checker: open when a program accepted the connection, closed when the host refused it, filtered when nothing answered within the time limit.

The port list covers what matters on most hosts: web servers on 80, 443, 8080 and 8443; mail on 25, 465, 587, 110, 143, 993 and 995; remote access on 22, 23 and 3389; file transfer on 21 and 445; databases on 3306, 5432, 1433, 6379 and 27017; DNS on 53; and a selection of application, VPN and game ports. Up to 50 ports are tested per run.

The probe refuses to scan private and reserved address ranges and its own networks, and each visitor is rate-limited. The scan is intended for checking your own server, router or home connection, and the per-visitor limits are set for that use, not for scanning the internet.

How to read the result

The table lists each port, its state and the service that usually runs there. Only the state is measured; the service name is the conventional assignment for that port number, and a host can run anything on any port.

Open ports are the ones to review. Each is a program accepting connections from the entire internet. For a web server, 80 and 443 open is expected. For a home connection, an open port that you did not deliberately forward deserves attention: a router with remote administration enabled, a camera or media server with UPnP, a device with a default service still switched on.

Closed ports tell you the host is reachable and simply has nothing listening there. A host that shows every port closed and none filtered is up, but has no packet filtering in front of it, which is unusual for anything but a bare server.

Filtered ports mean a firewall or router dropped the probe's packets. On a home connection the normal picture is every port filtered: the router discards unsolicited traffic by default. On a server, a mix of a few open ports and everything else filtered means a firewall is in place and configured.

A scan that shows nothing but filtered results, including on ports you know are open, usually means the host blocks our probe's address, or an intermediate network drops the traffic. Run the ping test to see whether the host answers at all.

What to do with the result

Close what you do not need

1. On the host, find the program behind each open port. sudo ss -ltnp on Linux, netstat -abno in an administrator Command Prompt on Windows, sudo lsof -iTCP -sTCP:LISTEN -n -P on macOS. The output names the process.
2. Stop and disable services you do not use. A database that only the local application talks to should bind to localhost, not to every interface.
3. For services that must stay reachable, restrict the source addresses in the firewall or the cloud security group. Administrative ports such as SSH and RDP are best reached through a VPN rather than exposed directly.
4. On a home router, turn off remote management, UPnP and any port forwarding rule you no longer recognize.
5. Re-scan. Ports you closed should now show closed or, with a firewall in front, filtered.

Verify a server after setup

1. Scan immediately after provisioning and again after installing each service. Cloud images sometimes ship with a management agent, a database or a mail daemon listening on all interfaces.
2. Compare the open list with what you intended. Anything extra is either a surprise or a default you should know about.
3. Keep the scan result as a baseline. A later scan that shows a new open port is one of the clearest signs that a host has changed, by you or by someone else.

Understand what an attacker sees

The result is the view any scanner on the internet gets. Each open port is a door; the question for each one is whether the software behind it is patched and whether it requires strong authentication. A port that is open and running old software is the typical entry point, and the port scan is the first step an automated attack takes. Running it yourself, regularly, puts you ahead of that.

Port scanner versus port checker

Use the port checker when you want to know about one specific port, such as whether a game server or a web application you just forwarded is reachable, and you want an answer about that port only. Use the port scanner when you want to know what a host exposes overall, or when you are not sure which ports are in play.

The two also differ in where they run. The port checker's single connection comes from our web server. The scanner runs from the dedicated probe server, which is built for active tests and is the same machine behind the ping and traceroute tools. Firewalls that allow or block by source address will see different addresses from the two tools.

Open ports that deserve immediate attention

Some ports are rarely open for a good reason on a device that faces the internet, and finding them in the result should prompt action the same day.

Ports 22, 80 and 443 open on a server you administer are expected. The same ports open on a home connection mean a device inside is exposing a service, deliberately or through UPnP, and you should know which one.

Scanning a home connection versus a server

On a home connection, scan your public address while connected to that network. The expected result is every port filtered, because the router drops unsolicited traffic. Anything open is either a forwarding rule you created, a UPnP mapping a device requested, or the router itself. Check the router's forwarding and UPnP pages to match each open port to its cause, and turn off UPnP if the mappings surprise you.

On a server, the expected result is the short list of services you run and nothing else. Scan after every change, keep the output, and compare. A port that opens without your knowledge is the earliest and cheapest warning you will get that a host has been modified, by a package update that enabled a service or by someone who should not have access.

Limits of this tool

• Only common TCP ports are scanned, at most 50 per run. A service on an unusual port is not found; the port checker can test any single port on request.
• UDP is not scanned. VPN endpoints, DNS resolvers, NTP servers and most game servers are invisible to this tool.
• The scan runs from one location. Firewalls with source-based rules, geographic blocks and rate limiting can make an open port look filtered.
• The service name next to each port is the conventional assignment, not a detection. The scanner does not read banners, identify software versions or check for vulnerabilities.
• Hosts that limit connection rates may answer some ports and drop the rest, producing a result that mixes real and false filtered states. Re-running the scan after a short pause usually resolves it.
• A hostname with several addresses is scanned at the first address returned; other addresses behind the same name are not tested.
• The scan has a short overall time limit. A host that answers very slowly can show ports as filtered that would eventually have answered.
• Private, loopback, reserved and the probe's own address ranges are refused, and scans are rate-limited per visitor.