A port number identifies which service should receive a connection. It carries no security properties of its own, and moving a service to an unusual number changes nothing about its exposure beyond making it slightly less visible to indiscriminate scanning.
What matters is the protocol listening there, and specifically whether it was designed in an era that assumed a trusted network.
The ones that carry real risk
| Port | Service | Why it matters |
|---|---|---|
| 23 | Telnet | Credentials and session in cleartext |
| 21 | FTP | Cleartext, and awkward to filter |
| 3389 | Remote desktop | Direct interactive access, heavily targeted |
| 445 | File sharing | History of remotely exploitable flaws |
| 3306, 5432 | Databases | Data directly, often weak defaults |
| 6379, 27017 | Cache and document stores | Historically no authentication by default |
| 161 | SNMP | Version one and two send community strings in the clear |
Every row shares one property. Each was designed for a network where every participant was assumed to be authorised, and none of them acquired that assumption by accident.
Cleartext is the oldest problem
Protocols that transmit credentials without encryption are not weakened by a flaw, they are working as specified. Anyone positioned on the path reads the password as it passes.
Each has an encrypted successor, and the reason the originals persist is embedded equipment and scripts written years ago. Replacing them is usually straightforward and usually deferred.
Exposed data stores are the fastest failure
Several widely used data stores historically listened on all interfaces with no authentication enabled, on the reasonable assumption that they would sit on a private network.
Placed on a public address, they are readable and writable by anyone who finds them, and automated scanning finds them within minutes rather than days. This has produced a long series of incidents in which nothing was exploited, because nothing needed to be.
Some services amplify attacks
Certain protocols over UDP return a response substantially larger than the request and do not verify the source address.
An attacker sends small requests with a forged source, and the responses are directed at the victim, multiplied in volume. Anyone running such a service on a public address becomes an unwitting participant, which is why restricting them is a matter of not harming others as much as protecting yourself.
Obscurity is a filter, not a control
Moving a service to a non standard port reduces automated noise in logs, and it will not stop anything deliberate, because a scan of the full range takes minutes.
It is worth doing for the log reduction and worth nothing as a defence, and confusing the two is how services end up exposed with weak authentication because the port was assumed to hide them.
Address translation was doing more than intended
On networks using private addressing, hosts are unreachable from outside unless a mapping exists, and that has functioned as an accidental default deny for decades.
With globally addressable hosts the property disappears, and every device is reachable unless a filter says otherwise. Anything that was safe because it happened to be behind translation is exposed the moment it acquires a routable address, which is a transition that frequently happens without anyone deciding it.
What actually reduces exposure
Do not expose management or data ports to untrusted networks at all, and reach them through an authenticated path such as a bastion or a tunnel. Restrict by source address where the set of legitimate sources is known.
Then verify from outside rather than from the configuration, because the ruleset describes intent and a scan describes reality, and they differ more often than anyone expects.
Note: the useful audit is not which ports are open according to the firewall configuration. It is which respond when scanned from an untrusted network, which is the only view that matches what an attacker sees.