Ports: exposed services on your server

1. How DNSprobe checks open ports

DNSprobe does a lightweight TCP connect scan on a small, fixed list of ports that are common on web hosting servers. The goal is to give you a quick picture of what is publicly reachable, not to brute-force every possible port.

Why this matters

Every open port is a door to a service that must be maintained, patched and monitored. Unnecessary services or legacy protocols increase your exposure to attacks and misconfigurations.

How the check is performed

For each IP associated with your domain, DNSprobe tries to establish a short TCP connection to a curated list of well-known ports. This list includes web ports (80, 443, 8000, 8080, 8888), mail ports (25, 110, 143, 465, 587, 993, 995), DNS (53), SSH/SFTP and alternates (22, 9999), file transfer services (FTP/TFTP/rsync on 20, 21, 69, 873), hosting control panels (cPanel on 2082–2083/2086–2087, DirectAdmin on 2222), databases (SQL Server 1433, Oracle 1521, MySQL/MariaDB 3306, Sybase 5000, PostgreSQL 5432, MongoDB 27017–27018), cache and remote access services such as Redis (6379), RDP (3389) and VNC (5900–5902). If a connection succeeds, the port is listed as open with its usual service name.

Good practices

• Keep only the ports that are strictly required for your website and mail delivery.
• Restrict administrative ports (SSH, control panels) by IP address or VPN whenever possible.
• Regularly review your open ports after configuration changes or server migrations.

2. Common web and DNS ports

On a typical hosting server, some ports are expected to be open publicly. DNSprobe marks these as normal as long as they match the role of the server.

• 80/tcp – Plain HTTP. Often used only to redirect users to HTTPS. Ideally, the site itself should be served over HTTPS on port 443.
• 443/tcp – HTTPS. Main port for secure web traffic and the one that should normally be open to everyone.
• 53/tcp – DNS over TCP. Used by authoritative nameservers for larger DNS responses and zone transfers (when restricted).
• 22/tcp – SSH remote access. Legitimate but should be limited to administrators and protected by strong authentication.
• 2222/tcp – Alternative SSH or control panel port (for example DirectAdmin). Also legitimate but should be restricted to trusted IPs.

In addition to 80 and 443, DNSprobe also checks alternative HTTP ports such as 8000, 8080 and 8888, as well as common hosting control panel ports (for example cPanel on 2082/2083/2086/2087 and DirectAdmin on 2222). If one of these ports appears open, make sure the corresponding interface is really meant to be exposed and is properly secured (HTTPS, strong authentication, IP restrictions when possible).

3. Mail-related ports

Mail servers expose several ports for SMTP, POP3 and IMAP, in both clear-text and encrypted variants. DNSprobe lists them so you can verify that only the modern, secure variants are exposed.

• 25/tcp – SMTP relay between mail servers. Normally open on inbound mail hubs only. On shared hosting, port 25 is sometimes restricted or firewalled.
• 110/tcp – POP3 in clear text. Kept only for backward compatibility and should be avoided in favour of encrypted POP3 (995).
• 143/tcp – IMAP in clear text. As with POP3, the encrypted equivalent on port 993 is strongly recommended.
• 465/tcp – Legacy SMTPS (SMTP over SSL). Still used by some clients but often replaced by STARTTLS on port 587.
• 587/tcp – SMTP submission with STARTTLS. Recommended port for authenticated outbound mail from clients.
• 993/tcp – IMAPS (IMAP over SSL/TLS). Recommended port for secure access to mailboxes.
• 995/tcp – POP3S (POP3 over SSL/TLS). Recommended port for secure POP3 access.

Whenever possible, encourage users to configure their mail clients with the encrypted ports (993/995/587) and disable the clear-text equivalents if they are no longer required.

4. Risky or suspicious ports

Some ports are widely known to be high risk when left exposed to the Internet. This includes legacy clear-text protocols (FTP, Telnet, POP3/IMAP without TLS), remote desktops (RDP, VNC), databases listening on public IPs (MySQL, PostgreSQL, MongoDB, SQL Server, Oracle, Sybase) and internal admin ports that were never meant to be reachable from everywhere. DNSprobe highlights these ports as "suspicious" so that you can review them carefully.

• 21/tcp – FTP in clear text. Credentials and data are sent unencrypted, making it easy to intercept. SFTP (over SSH) or HTTPS-based file managers are strongly preferred.
• 23/tcp – Telnet. Completely unencrypted remote shell, obsolete on modern systems and should never be exposed publicly.
• 3306/tcp – MySQL / MariaDB. Opening your database server directly to the Internet is rarely necessary and creates a huge attack surface.
• 3389/tcp – RDP (Remote Desktop Protocol). Often targeted by brute-force and ransomware attacks, especially when exposed without additional protection.
• Any high port open to the world – High ports used by test services, debug tools, development frameworks or alternate SSH/HTTP endpoints may expose internal features that were not meant to be public. Always double-check any unexpected open port and close it if you do not explicitly rely on it.

When DNSprobe shows the message "Suspicious ports detected", it does not mean you are already compromised, but it does mean that at least one service (for example FTP on 21, Telnet on 23, a database on 3306/5432/27017, Redis on 6379, RDP on 3389 or VNC on 5900–5902) deserves a security review. Close or restrict these ports if they are not strictly required.

5. Hardening recommendations

Reducing the number of open ports and tightening access to administrative services are key steps in hardening your infrastructure.

Firewall and network controls

• Use a host-based firewall (such as iptables/nftables, firewalld, UFW, CSF) to explicitly allow only required ports.
• Restrict administrative ports (SSH, RDP, control panels) to specific IP addresses or a VPN subnet whenever possible.
• Place management interfaces behind a bastion host or VPN instead of exposing them directly to the Internet.

Service configuration

• Disable or uninstall unused services so that they cannot accidentally be re-opened later.
• Prefer encrypted alternatives such as SFTP instead of FTP, and HTTPS APIs instead of plain-text protocols.
• Enable rate limiting and intrusion detection (for example fail2ban) on services that must remain exposed.

A regular security review of open ports combined with good patch management goes a long way towards reducing the likelihood of successful attacks.

* Some hosting providers can move your account to a more locked-down IP address, where only the strictly necessary ports (typically 80 and 443 for HTTP/HTTPS) are open.
If you are on shared hosting and cannot control the firewall yourself, ask your provider whether such a hardened IP or security profile is available.

6. Test open ports manually from your own terminal

DNSprobe checks whether common service ports (such as HTTP/HTTPS and mail ports) are reachable from the Internet. You can reproduce similar tests from a terminal to verify that the expected ports on your host are open and responding.

Linux: using nc (netcat) and nmap

On most Linux distributions, the nc (netcat) and nmap tools are available in the repositories. The following commands attempt to connect to common web and mail ports on your host and, optionally, run a small TCP port scan:

                nc -vz example.com 80 443 25 587 993 995
    
                # Optional: use nmap for a more detailed TCP port check on the same set of ports    
                nmap -p 80,443,25,587,993,995 example.com
        

macOS: using nc and nmap

On macOS, you can use nc from the Terminal and, if installed, nmap for more advanced checks. The commands below try to open TCP connections on typical web and mail ports and then perform a quick port scan:

                nc -vz example.com 80 443 25 587 993 995
    
                # Optional: use nmap for a more detailed TCP port check on the same set of ports    
                nmap -p 80,443,25,587,993,995 example.com
        

Windows: using PowerShell Test-NetConnection

On Windows, PowerShell includes the Test-NetConnection cmdlet, which can test whether a given TCP port is reachable on a host. Run the following commands from a PowerShell window to check web ports first, then the most common mail ports:

                Test-NetConnection example.com -Port 80
                Test-NetConnection example.com -Port 443
    
                REM Optional: test the main SMTP/IMAP/POP3 ports used for email delivery and secure mailbox access    
                Test-NetConnection example.com -Port 25
                Test-NetConnection example.com -Port 587
                Test-NetConnection example.com -Port 993
                Test-NetConnection example.com -Port 995
        

Important: only scan hosts and ports that you own or are authorised to test. Port scans and repeated connection attempts against third-party systems may be classified as intrusive or abusive activity by some providers.