Insecure vs Secure Ports: Clear-Text Protocols, Their Replacements and How to Fix Them

Key takeaways

• The protocol, not the port number, decides whether data is encrypted. Moving Telnet to another port does not make it secure.
• Clear-text protocols expose passwords and data to anyone who can capture the traffic.
• Replacements: SSH for Telnet, SFTP or FTPS for FTP, HTTPS for HTTP, encrypted mail ports for POP3, IMAP and SMTP.
• Find insecure services by scanning your own network and listing listening ports on each server.
• Migrate in order: inventory, replace, restrict, then monitor.

What is the difference between insecure and secure ports?

Strictly speaking, ports are neither. A port is a number that identifies a service on a host. What matters is whether the protocol on that port encrypts and authenticates traffic. We say "insecure port" as shorthand for a port normally used by a protocol that sends data, including passwords, in clear text.

The original version of this post included a story about a university network misconfiguration. We could not verify it, so we removed it. A related reference is our post on the idea of "old and new" port numbers.

Which clear-text protocols should be replaced?

For more detail on other ports see our lists of top 20 network ports and commonly used TCP and UDP ports.

Why does it matter?

Anyone who can see the traffic, such as someone on the same Wi-Fi, a compromised switch or a malicious network device, can read clear-text credentials. They can also alter data in transit. Encrypted protocols also check the server's identity, which blocks many man-in-the-middle attacks.

Lab: see clear text for yourself

In your own lab, install an FTP server on one virtual machine, start Wireshark on another on the same host-only network, log in with a test account, and apply the display filter ftp. You will see the username and password in the packet details. Repeat with SFTP and notice that the content is unreadable. This is a safe way to learn why we replace FTP. See the Wireshark documentation. Only capture traffic on networks you own.

How do you find insecure services on your network?

• On each Linux server, list listening ports: ss -tulpn.
• From a management host, scan your own address ranges with Nmap, for example nmap -sV 192.168.1.0/24, with permission for the range.
• Review firewall rules for allowed 21, 23, 80, 110, 143 and 445 from untrusted networks.
• Check network devices, printers and cameras, which often keep Telnet or HTTP management on.

How do you migrate safely?

1. Inventory each service, its users and why it exists.
2. Enable the encrypted version and test with a few users or systems.
3. Update clients and scripts that use the old protocol.
4. Redirect or block the old port. For web, redirect HTTP to HTTPS and consider HSTS.
5. Restrict by network where the old service must remain, and plan its retirement.
6. Monitor for attempts on closed ports.

On RHEL, you can remove a service from the firewall with firewall-cmd --permanent --remove-service=telnet and then firewall-cmd --reload.

Common mistakes

• Believing a service on a high port is secure.
• Enabling HTTPS but leaving HTTP open without a redirect.
• Replacing FTP with FTPS using a self-signed certificate that users learn to ignore.
• Forgetting devices such as printers and cameras.

Next steps

Next steps: to practise securing network services, see our Computer Network course, and read about common network ports.