If you’re running a web server that’s exposed to the internet, every open port is essentially an unlocked door. Some of those doors you need open — port 80 for HTTP, port 443 for HTTPS — but the rest? They’re just invitations for trouble. I’ve seen servers compromised not because of some sophisticated zero-day exploit, but because someone left port 3306 (MySQL) wide open to the world. It’s the kind of mistake that takes five minutes to prevent and five days to clean up.
This guide is for anyone managing Apache, Nginx, or IIS in production. Whether you’re a sysadmin handling a single VPS or overseeing a fleet of servers, the principles here will help you reduce your attack surface and sleep a little better at night.
Why Port Security Matters More Than You Think
There’s a common misconception that a firewall alone is enough. It helps, sure, but port security goes deeper than that. Your web server software itself often listens on ports you didn’t intend. Apache might spin up a status page on port 8080. IIS might have SMTP running on port 25 from a default installation. Nginx reverse proxy setups sometimes expose upstream application ports unintentionally.
The real risk isn’t just that a port is open — it’s what’s listening behind it, what version it’s running, and whether that version has known vulnerabilities. Attackers use automated scanners that sweep entire IP ranges in minutes. If your server responds on an unexpected port, it gets flagged, catalogued, and eventually probed.
Apache: Tighten What’s Already Running
Apache is flexible, which is both its strength and its weakness. Out of the box, it tends to be more permissive than it needs to be.
Start with the Listen directive in your main configuration file, usually found at /etc/apache2/ports.conf on Debian-based systems. Make sure it only lists the ports you actually need. If you’re running HTTPS exclusively (which you should be in 2025), you can remove the Listen 80 line entirely or redirect all traffic to 443.
Disable modules you’re not using. Run apache2ctl -M to see what’s loaded, then disable unnecessary ones with a2dismod. Modules like mod_status and mod_info are useful for debugging but dangerous in production. If you must keep them, restrict access to localhost only.
One thing I learned the hard way: if you run virtual hosts on non-standard ports for testing, don’t forget to remove them before pushing to production. I once left a staging site running on port 8443 for three weeks before noticing it in a scan report. Nobody exploited it, but it was completely unnecessary exposure.
Nginx: Minimal by Default, But Watch Your Configs
Nginx is leaner than Apache, and that works in your favor from a security standpoint. It doesn’t load a pile of modules by default. But the risk with Nginx often comes from misconfigured reverse proxy setups.
When you proxy traffic to a backend application — say Node.js on port 3000 or a Python app on port 8000 — that backend port should never be accessible from outside the server. Bind your application to 127.0.0.1 instead of 0.0.0.0. This single change prevents external access while still allowing Nginx to forward requests internally.
Check your server blocks carefully. Every listen directive should be intentional. If you have a default server block catching all traffic, make sure it returns a 444 (Nginx’s special “close connection” response) for requests that don’t match any configured domain. This prevents port scanners from fingerprinting your setup.
Also, hide your Nginx version by setting server_tokens off in the http block. It won’t stop a determined attacker, but it removes one piece of information from their toolkit.
IIS: Don’t Trust the Defaults
Windows Server with IIS tends to install more services than you need. After setup, open Server Manager and review which roles and features are actually installed. FTP, SMTP, and other legacy services often tag along, each opening their own ports.
Use IIS Manager to verify your site bindings. Each site should bind only to the specific IP, port, and hostname it needs. Remove any bindings to port 80 if you’ve fully migrated to HTTPS. Enable HTTP Strict Transport Security (HSTS) through response headers to enforce secure connections.
Windows Firewall with Advanced Security should be your next stop. Create inbound rules that explicitly allow only the ports you need and block everything else. The default “allow” posture of many Windows installations is the opposite of what you want in production.
The Bigger Picture: Continuous Monitoring
Hardening your server once isn’t enough. Configurations drift. Someone installs a debugging tool and forgets to remove it. A package update re-enables a service. A new team member opens a port for testing.
This is where continuous external port scanning becomes essential. Tools like PortVigil perform regular scans of your public IP from the outside, exactly as an attacker would see it. They detect newly opened ports, identify what’s running behind them, and flag known vulnerabilities. It’s the difference between hoping your configuration is correct and actually verifying it.
I run external scans on all my servers weekly at minimum. More than once, a scan has caught something I missed — a Docker container exposing a management port, or a monitoring agent listening on a port I didn’t configure.
Quick Checklist for Any Web Server
Audit your open ports right now using ss -tlnp on Linux or netstat -an on Windows. Compare the results against what you expect. Remove or restrict anything that shouldn’t be there. Bind internal services to 127.0.0.1. Disable server version headers. Set up firewall rules that default to deny. And schedule regular external scans so you catch changes before attackers do.
Common Questions
Is it safe to run HTTP on port 80 if I redirect to HTTPS? Generally yes, but keep the redirect configuration minimal. Don’t serve any actual content on port 80.
Should I change my SSH port from 22 to something else? It reduces automated scanning noise, but it’s not real security. Use key-based authentication and fail2ban instead. Changing the port is fine as an extra layer, just don’t rely on it.
How often should I scan my own ports? At least weekly. Daily is better if you’re making frequent changes to your infrastructure. Automated continuous monitoring is the ideal approach.
Do I need to worry about UDP ports? Yes. DNS (port 53), SNMP (port 161), and other UDP services are common attack vectors that people forget about because they focus exclusively on TCP.
Port security isn’t glamorous work. There’s no dramatic moment where you defeat a hacker in real time. It’s quiet, preventive, and repetitive — and that’s exactly what makes it effective. The servers that get compromised are almost always the ones nobody was watching.