A developer I know once got a call at 2 AM. His client’s database had been wiped. No ransomware note, no warning. Just gone. After hours of digging, they found the cause, MySQL port 3306 was open to the internet, and someone had found it in under 10 minutes using an automated scanner. The server had been live for three years.
That’s not a rare story. It happens more than most people admit.
Every port you leave open on a web server is a door. Some doors need to be open. Most don’t. And the ones you forget about? Those are exactly the ones attackers go looking for.
What Ports Actually Are
Think of your server as an apartment building. Your IP address is the building’s street address. Ports are the individual apartment doors, numbered from 0 to 65535. When a service runs on your server, it listens on a specific port number. HTTP traffic comes in on port 80. HTTPS on port 443. SSH connections use port 22.
The problem is, many servers come with extra services running in the background, listening on ports no one meant to expose. Most admins never check. And scanning tools used by attackers absolutely do.
Before going further, if you want a solid foundation on how open ports affect your overall server security posture, our guide on open ports and server security covers the broader picture well. This article goes deeper into the specific ports you should be actively closing.
Ports That Should Be Closed by Default
Port 23 (Telnet)
Telnet sends everything in plain text — usernames, passwords, commands, all of it. Anyone who can intercept traffic between you and your server can read the whole session. There is no reason to have Telnet open on any modern server. Use SSH instead.
Port 21 (FTP)
FTP has the same problem. Login credentials travel unencrypted. If you need file access, SFTP over SSH is the right move. FTP has been considered legacy for years, but servers still run it by default in plenty of shared hosting setups.
Port 3306 (MySQL/MariaDB)
This one is responsible for a huge number of database breaches. MySQL listens on port 3306, and if it’s exposed to the internet, anyone with a scanner and a few minutes can find it. Your application should connect to MySQL through localhost, not through a public-facing port.
Port 5432 (PostgreSQL)
Same situation as MySQL. PostgreSQL uses port 5432. It should never be reachable from outside your private network. If your app and database live on the same server, there’s no reason this port should even think about facing the internet.
Port 445 (SMB)
SMB stands for Server Message Block, and it’s used for Windows file sharing. This is the port WannaCry and NotPetya spread through. It has had more serious vulnerabilities than most people remember. On a web server, there is almost never a reason to have port 445 open to the public. Block it at the firewall level.
Port 137, 138, 139 (NetBIOS)
These are old Windows networking ports used for things like network browsing and name resolution on local Windows networks. On a public web server, they serve no purpose and create real exposure.
Port 3389 (RDP — Windows Remote Desktop)
If you run a Windows server and use Remote Desktop, port 3389 is what makes it work. The problem is this port is constantly being probed by automated scanners. If you genuinely need RDP access, put it behind a VPN and firewall it off from the public internet. Leaving it open is asking for brute force attempts.
Port 9000 (PHP-FPM and Xdebug)
This one catches developers off guard. Xdebug, a PHP debugging tool, often runs on port 9000 during development. If a developer sets something up locally and that config ends up on a production server, Xdebug can be exposed. It allows unauthenticated remote code execution. That’s as bad as it sounds.
Ports 8080 and 8443
These are often used for admin panels, staging environments, or alternate HTTP servers. In production, these should either be closed or restricted to specific IP addresses.
Development Ports (3000, 4200, 5000)
Ports like 3000 (Node.js default), 4200 (Angular dev server), and 5000 (Flask) are meant for local development. They should never be reachable from the internet. If you’re deploying an app that previously ran locally, double-check that none of these slipped through.
The Ports You Should Actually Keep Open
For a standard web server, you really only need three ports open.
Port 80 (HTTP) is needed for web traffic, though you should redirect everything to HTTPS.
Port 443 (HTTPS) is your main serving port for secure traffic.
Port 22 (SSH) is for server management. Even better if you restrict it to specific IPs or move it to a non-standard port.
That’s it for most setups. Every extra open port adds risk without adding value.
Common Mistakes That Get Servers Compromised
Leaving default configs untouched. Most OS and hosting control panel installs open more ports than you need. Plesk, cPanel, WHM — they each have their own set of default ports. Go through them after setup and close what you don’t use.
Opening a port temporarily and forgetting it. This happens a lot during debugging or migrations. You open port 3306 to run a quick database check from your local machine, then move on. Six months later it’s still open.
Trusting the hosting provider to handle it. Shared hosting providers manage a lot at the network level, but on a VPS or dedicated server, firewall rules are your responsibility. Don’t assume someone else is closing ports you never looked at.
Not checking after software updates. Some updates restart services or re-enable listeners. A port you closed three months ago might be open again after a major update. Port audits should be a regular part of server maintenance, not a one-time thing.
Relying on security through obscurity. Changing a port number doesn’t actually secure it. Moving MySQL from 3306 to some random high port will stop naive scanners briefly, but dedicated scanners do full port sweeps. The real fix is always to close or firewall the port properly.
How to Check What’s Open on Your Server
From your server’s terminal, running netstat -tuln or ss -tuln will show you every port currently listening. You’ll likely see more than you expected.
But if you want to check from the outside the way an attacker would see your server, you need to scan it externally. Use our free Open Port Checker to scan your server and see exactly which ports are visible to the outside world. It takes about 30 seconds and often surfaces things people had no idea were exposed.
While you’re at it, running a check with our HTTP Header Checker can tell you whether your server is leaking version information through response headers — another common exposure point attackers use to fingerprint your stack before an attack.
Firewall Is Your First Line
Closing a port means two things. One is stopping the service from listening. The other is blocking it at the firewall level. Even if you shut down a service, adding a firewall rule to drop traffic on that port is good defense in depth.
On Linux servers, ufw and iptables are the standard tools. Cloud providers like AWS, DigitalOcean, and Linode also have security group or firewall panels where you can manage port access without touching the command line.
The general rule from NIST and most security frameworks is the same deny by default, allow only what is explicitly needed. Start with everything closed and open only what your application actually requires to function.
A Practical First Step
If you’ve never done a port audit on your server, start today. It takes 10 minutes and the risk of doing nothing is real. Run ss -tuln locally, scan externally with the Open Port Checker, and cross-reference what you see against what your server actually needs.
Close anything you don’t recognize. And if you’re not sure what a port does, look it up before assuming it’s fine. Assumptions are exactly how servers end up getting hit at 2 AM.
