Port Scanner guide
How XGM Port Scanner tests TCP ports on a public host, what open, closed and filtered mean, which exposed ports are risky and how to close them.
What the Port Scanner does
A TCP port is where a service listens for connections: 443 for HTTPS, 25 for mail between servers, 22 for SSH. Whether a port is reachable from the internet depends on the service, the host firewall, cloud security groups and network firewalls in between. Testing from inside your own network tells you little about what outsiders can reach.
The Port Scanner connects from the XGM server to the host and ports you choose, exactly as any outside client would. It tests only the ports you list, up to 200 at once; the Top 100 preset covers the ports most often found open. On an open port it reads the greeting that SSH, SMTP, FTP, POP3, IMAP and MySQL servers send by themselves, and sends one HEAD request to HTTP and HTTPS ports. It does not log in or probe for vulnerabilities.
How to use the Port Scanner
- Open the Port Scanner and enter a public host name or IP address you are responsible for.
- Enter ports as a comma-separated list or ranges, such as
80, 443, 8000-8005, or choose a preset: Web, Mail, Remote access, Databases or Common 20. - Run the check and read the result per port: open with latency, closed or filtered.
- Review warnings for risky open ports and close or restrict them.
| Preset | Ports |
|---|---|
| Web | 80, 443, 8080, 8443 |
| 25, 465, 587, 110, 143, 993, 995 | |
| Remote access | 22, 23, 3389, 5900 |
| Databases | 3306, 5432, 6379, 27017, 1433, 9200 |
| Common 20 | 21, 22, 23, 25, 53, 80, 110, 143, 443, 445, 465, 587, 993, 995, 1433, 3306, 3389, 5432, 6379, 8080 |
Only test hosts you are responsible for
The port exposure report
The Full report tab of the Port Scanner runs the port exposure report: a fixed, safe list of common service ports (80, 443, 22, 25, 53, 8080 and 8443) with a score, findings and recommendations. Use the Quick check for the ports you choose, and the report when you want the same baseline for every server you compare. The report used to be a separate page at /tools/port-exposure-report; that address now opens this tab.
Open, closed and filtered
| State | What happened | What it usually means |
|---|---|---|
| Open | The TCP handshake completed | A service listens and the firewall allows the connection |
| Closed | The host answered with a reset | Reachable host, nothing listening on that port |
| Filtered (no answer) | No reply within 1.5 seconds | A firewall drops the packets, or the host is down or very slow |
Run the check twice if a result surprises you. A single timeout can be a transient network problem.
Filtered is the best state for ports you do not use, because it reveals the least. Closed is also fine. An open port is only a problem when the service behind it should not be public, or when it is public but poorly secured.
Results are from one location at one moment. Firewalls can allow some source addresses and not others, cloud load balancers may answer on ports the backend does not serve, and rate limiting can turn an open port into a timeout after repeated tests.
Ports that should not be public
| Port | Service | Why it is risky |
|---|---|---|
| 21 | FTP | Credentials are sent in plain text |
| 23 | Telnet | Everything, including passwords, is sent in plain text |
| 445 | SMB | A common ransomware entry point when exposed |
| 1433, 3306, 5432 | SQL Server, MySQL, PostgreSQL | Databases should never be reachable from the internet |
| 3389 | Remote Desktop | Heavily brute-forced; put it behind a VPN |
| 5900 | VNC | Often weakly authenticated |
| 6379 | Redis | No authentication by default; frequently abused |
| 9200 | Elasticsearch | Exposed clusters often leak data |
| 27017 | MongoDB | Exposed instances often leak data |
Exposed databases and remote access services are behind a large share of data breaches and ransomware incidents. Automated scanners find new exposed instances within hours of them appearing online. Treat any of these ports showing as open as an urgent finding.
Closing or restricting ports
The cleanest fix is making the service listen only on a private interface, so there is nothing to reach from outside. Where the service must accept remote connections, restrict the source addresses in a firewall or cloud security group, and put administrative access behind a VPN or a bastion host.
# PostgreSQL: listen only on localhost and the private network (postgresql.conf)
listen_addresses = 'localhost,10.0.0.5'
# Redis: bind to localhost and require a password (redis.conf)
bind 127.0.0.1 ::1
requirepass use-a-long-random-secret
# ufw: allow SSH only from an office address
ufw allow from 203.0.113.10 to any port 22 proto tcp
ufw deny 22/tcp- In the cloud, check security groups and network ACLs as well as the host firewall.
- Containers can publish ports on all interfaces by default; publish them on
127.0.0.1when only a local proxy needs them. - After a change, run the Port Scanner again from outside to confirm the port is now closed or filtered.
- Document which ports each server should expose, so drift is noticed.
Checking mail and web servers
For a mail server, port 25 must be open for receiving mail from other servers, and 465 or 587 for your users submitting mail with authentication. IMAP (993) and POP3 (995) are for mail clients. Plain IMAP (143) and POP3 (110) without TLS should be closed where clients support the encrypted ports.
For a website, 80 and 443 are expected. Ports such as 8080 or 8443 often belong to admin panels, development servers or application servers that were meant to sit behind a proxy. If one of those is open, check what answers there and whether it should be public, then confirm the certificate with the TLS Checker.
FAQ
Is this a port scanner?
It is a targeted check. It tests only the ports you list, up to 200. Open ports are asked for a banner (a HEAD request on HTTP ports, listening only on the others); it never logs in or tests for vulnerabilities. Open ports outside web, mail, DNS and SSH are flagged as unexpected so you can confirm they are intended.
Why is a port filtered when the service is running?
A firewall, security group or provider network is dropping connections from outside, or the service listens only on a private interface. That is often intended.
Can I check UDP ports?
No. The checker tests TCP connections only. UDP services such as DNS or VPNs need protocol-specific tests.
Can I test a private IP address?
No. Private, loopback and internal addresses are refused, because XGM runs checks from a public server and must not reach internal networks.
Why did the latency change between runs?
Connection time depends on network paths and server load at that moment. Small variations are normal.
Why is port 25 filtered on my cloud server?
Many cloud providers block port 25 by default to prevent spam. Send mail through an email service, or request the provider's unblocking process if you run a mail server.
Why does port 443 show open on an IP with no website?
Load balancers, CDNs and some hosting platforms accept connections on shared addresses for many customers. The port being open says that something accepts TCP there, not that your site is configured.
Does an open port mean I have been hacked?
No. It means a service is reachable. Whether that is a problem depends on the service, its authentication and whether it should be public.