Why Changing Default Ports Isn't True Security

Running your SSH server on port 2222 instead of 22. Moving your web server from 80 to 8080. Hiding your database on port 33061 instead of 3306. These changes might feel like security, but they're security theater—the digital equivalent of hiding your house key under a different rock.

Your port number is not a secret. It's a trivia question that any scanner answers in seconds.

The Illusion

The logic seems sound: if attackers scan for SSH on port 22, running it on port 2222 should make your server invisible. Your logs won't fill with thousands of failed authentication attempts from bots. You've hidden in plain sight.

This reasoning has a kernel of truth—changing ports does reduce automated noise—but it fundamentally misunderstands the threat. You haven't hidden anything. You've just made lazy bots work slightly harder while doing nothing against anyone who actually wants in.

Port Scanning Destroys Obscurity

Tools like nmap scan all 65,535 ports on a target in minutes. An attacker doesn't guess which port runs SSH—they discover it. Your server on port 2222 announces itself as SSH when probed, often including its version number. You've handed them exactly what they need.

Worse, modern scanners perform service detection automatically. They don't just find open ports—they identify what's running on each one. Your clever port choice becomes irrelevant before the attacker finishes their coffee.

Targeted attacks don't rely on finding random vulnerable systems. They focus on specific targets. If someone wants your infrastructure, they'll scan it comprehensively. The port number is discovered in the first five minutes of reconnaissance.

When Non-Default Ports Actually Help

Non-default ports solve operational problems, not security problems.

The valid reason to move SSH off port 22: log noise. Bots continuously scan the entire IPv4 space for common services on default ports. An SSH server on port 22 receives millions of authentication attempts from automated scanners, burying real security events in noise.

Moving to a non-default port cleans your logs. The spray-and-pray scanners miss you entirely. This is a quality-of-life improvement for administrators—like getting an unlisted phone number to avoid telemarketers. It doesn't stop someone who specifically wants to reach you, but it reduces the background noise.

Other legitimate uses: running multiple service instances on one machine, avoiding port conflicts in development, working around restrictive network policies. Engineering solutions to engineering problems.

What Actually Secures SSH

The port number is irrelevant to SSH security. What matters:

Key-based authentication. Disable password authentication entirely. An attacker who finds your SSH server still can't authenticate without the private key—regardless of which port they found it on.

Fail2ban or similar protection. Automatically block IPs after failed authentication attempts. This works against brute-force attacks whether they target port 22 or port 22222.

Current software. Patch the SSH daemon. Known vulnerabilities get exploited; patched systems don't have those vulnerabilities.

Access restrictions. Limit which users can authenticate. Restrict SSH access to specific IP ranges via firewall rules if your use case allows it.

These measures work because they address fundamentals. Authentication ensures only authorized users connect. Encryption protects the session. Access controls limit who can even attempt authentication. None of these depend on attackers not finding your service.

The Danger of Feeling Secure

The real problem with port-based "security" is the false confidence it creates. Administrators who believe changing ports provides protection may neglect measures that actually work. They've done something that feels like hardening without doing anything that functions like hardening.

Security through obscurity fails because obscurity is temporary. The moment someone discovers your port number—and discovery is trivial—the protection vanishes completely. Real security continues working even when attackers know everything about your setup. An attacker who knows you use key-based authentication still can't authenticate without the key. An attacker who knows your firewall rules still can't bypass them.

This is the test: does the protection still work if the attacker knows about it? Changing ports fails this test immediately. Strong authentication passes it.

The Actual Threat Model

Ask yourself: who are you defending against?

Automated bots scanning default ports: Non-default ports help here, but only as noise reduction. These bots aren't a serious threat to properly secured systems anyway—they're looking for low-hanging fruit like default credentials and unpatched services.

Script kiddies running pre-built tools: They'll scan all ports. Your non-default port buys you nothing.

Targeted attackers: They'll map your entire infrastructure before attempting anything. Port obscurity is irrelevant.

The attackers that non-default ports stop are exactly the attackers that proper security measures would stop anyway. The attackers that proper security measures stop are exactly the attackers that non-default ports can't stop.

Use Ports for Operations, Not Security

Change your port numbers when they solve operational problems—reducing log noise, avoiding conflicts, working around network restrictions. These are valid reasons.

Don't change port numbers expecting security improvement. That effort is better spent on authentication hardening, encryption, access controls, patching, network segmentation, and monitoring.

The key under the rock doesn't become secure because you picked a different rock. Security comes from not needing to hide the key at all.