Skip to content

Open port check

Find out whether risky services such as Remote Desktop (RDP), Windows file sharing (SMB) or SSH can be reached on your server from the internet. We check 10 common ports and explain what to do about the result.

Loading verification…
← Back to all tools

What the check verifies

Every service listening on a network port is a possible way in for an attacker. A website on ports 80 and 443 belongs on the internet; Remote Desktop or file sharing usually does not. This check shows which of ten common ports can be reached on your server from the internet.

We do not run the scan ourselves. For a domain, we first look up its IPv4 address. We check that the address is public and pass only that address to HackerTarget, an Australian company, which runs nmap against it from its own servers at that moment. The result does not come from a database of earlier scans like Shodan or Censys; it shows the current state as HackerTarget's servers see it.

We check these 10 TCP ports:

  • 21 FTP and 23 Telnet: older protocols for file transfer and remote administration that send passwords unencrypted.
  • 22 SSH: encrypted remote administration, typically of Linux servers.
  • 25 SMTP, 110 POP3 and 143 IMAP: receiving and collecting email.
  • 80 HTTP and 443 HTTPS: the web.
  • 445 SMB: Windows file and printer sharing.
  • 3389 RDP: Windows Remote Desktop.

How to read the result

The tool lists only ports in the open state, meaning the server accepted a connection and a service is listening. A port missing from the list is either closed (the server refused the connection) or filtered (a firewall silently dropped it). The tool does not tell these two apart, but both are fine from a security point of view.

The service name is taken from nmap's output. It may be only a guess based on the port number, so check on the server what actually runs there. If the scan also reports a version, the tool shows it under the service name; it is what the service says about itself, not a verified fact. An open port is not a vulnerability by itself either: what matters is whether the service should be there, whether it is up to date and how it protects logins.

Port   Service         Status
22     ssh             Open
80     http            Open
443    https           Open
3389   ms-wbt-server   Open
  • 80 and 443 are expected on a web server. Port 80 should only redirect to HTTPS.
  • 22 SSH can stay reachable if logins use keys only, the server is patched and, ideally, access is limited to known IP addresses.
  • 3389 (ms-wbt-server) is Windows Remote Desktop. Attackers try passwords on it constantly, and it is one of the most common routes to ransomware. It should not be reachable directly from the internet, only through a VPN or a gateway with multi-factor authentication.
  • 445 (microsoft-ds) is SMB. It never belongs on the internet; WannaCry spread through it in 2017.
  • 21 FTP and 23 Telnet send passwords and data unencrypted. Replace them with SFTP and SSH.
  • 25 is needed only by a mail server that receives email. POP3 and IMAP on ports 110 and 143 start unencrypted; ports 995 and 993, encrypted from the start of the connection, are safer.
  • Databases such as MySQL 3306, PostgreSQL 5432, MS SQL 1433, Redis 6379 or MongoDB 27017 are not checked by this tool, but they should not be reachable from the internet either.

What to do about an exposed service

  1. Find out what is running on the port

    List listening services on the server with ss -tlnp (Linux) or netstat -ano (Windows). For each one, find out who uses it and whether it really needs to be reachable from the whole internet.

  2. Turn off what nobody needs

    Disable or uninstall anything nobody uses. A service needed only by applications on the same server, typically a database, should listen on 127.0.0.1 only.

  3. Restrict access with a firewall

    Open to the public only the ports that are meant to be public and block the rest. Allow administrative services from specific IP addresses only. In the cloud, update security groups too, and do not forget the IPv6 rules.

  4. Put remote access behind a VPN

    Make RDP, SSH or device management available through a VPN or a gateway, such as Remote Desktop Gateway, with multi-factor authentication. Changing the port number alone does not stop attackers; it only cuts some of the automated attempts.

  5. Patch and protect logins

    Keep services that stay public up to date. For SSH, disable password logins and use keys. Elsewhere, use strong passwords, multi-factor authentication and a limit on login attempts.

  6. Check again from outside

    Run the check again after the change. A scan from your internal network is not enough, because firewalls often treat it differently from the internet.

What the check cannot tell you

  • It checks only the 10 TCP ports listed above. It does not check other ports, such as 8080, 8443, databases or router and camera management, or UDP services such as DNS, SNMP or VPNs. For a full picture, scan all 65,535 TCP ports and the important UDP ports.
  • Only IPv4 is scanned, and for a domain only one of its IPv4 addresses. If your server can also be reached over IPv6, check its IPv6 firewall rules separately. If the site is behind a CDN or proxy such as Cloudflare, you see the proxy's ports, not your server's.
  • The result shows the view from HackerTarget's servers. If your firewall allows access only from certain countries or IP addresses, or an intrusion prevention system blocks the scan, more may be visible from elsewhere.
  • If the server does not respond to the scan at all, the tool says so and gives no verdict. If a firewall silently drops only the connections to the checked ports, though, the result looks the same as closed ports.
  • It does not look for vulnerabilities and does not try to log in. A service version, if shown, is not checked against any vulnerability database.
  • The number of scans is limited: to a few per minute on our side, and by a small daily HackerTarget quota shared by everyone using the tool. If it runs out, try again later or the next day.
  • We send HackerTarget only the IPv4 address being scanned, not the domain you enter or your own IP address. Bot protection is provided by Cloudflare Turnstile. We do not store the result.

Common questions

Can I scan someone else's server?

Only check servers you manage, or ones whose owner has given you permission to test them, ideally in writing. Scanning other people's systems without permission usually breaks the terms of internet providers and of HackerTarget, and administrators may treat it as an attack. If a scan is followed by login attempts or misuse of a service, it can also be a criminal offense, for example unauthorized access to a computer system under Section 230 of the Czech Criminal Code. Watch out for shared hosting and CDNs too: the IP address then belongs to the provider, not to you. This is not legal advice; if in doubt, ask a lawyer.

The tool found no open ports. Is my server secure?

It only means that none of the 10 checked ports accepted a connection. Other ports and the applications themselves are not checked. If you do not even see port 80 or 443 for a website that works, a firewall probably blocked the scan or the server did not respond to it.

Why are ports 80 and 443 open? Is that a problem?

No. Ports 80 and 443 serve your website, and visitors could not load it without them. Port 80 should only redirect to HTTPS. Focus on administrative services and file sharing instead.

Why does the result differ from Shodan or from a scan inside our network?

Shodan and similar services show results of their earlier scans, which can be days or weeks old, while this check scans now. A scan from your internal network bypasses the perimeter firewall, so it sees more. A CDN, the domain having several IP addresses, or a firewall that blocks only some sources can also explain differences.

Will the server's administrator notice the scan?

Often, yes. The scan comes from HackerTarget's addresses, and a firewall or intrusion detection system may log, report or block it. If a hosting company or supplier manages your server, let them know in advance.

Is moving RDP or SSH to a different port enough?

No. Automated scanners go through all ports, so they find services on non-standard ports too, just a little later. It cuts some login attempts, but real protection comes from a VPN, limiting access to known IP addresses and multi-factor authentication.

Not sure which services should be reachable from the internet?

Tell us which ports the tool found and what the server is for. We will help you restrict access without losing remote administration.

Contact us

Ten ports are only the start. In a penetration test, we find out which services your server exposes to the internet and check whether an attacker could use them to get further.

Penetration testing