Every new server you spin up is a blank slate — and for about the first 30 minutes, it’s also a sitting duck. A port security checklist for new server deployments is the difference between a hardened production machine and an open invitation for automated scanners that hit your IP before you’ve even finished configuring your app. If you’re a sysadmin or security engineer deploying servers regularly, this guide gives you a repeatable, practical checklist you can follow every single time.
I’ve seen it happen more times than I’d like to admit: a developer provisions a cloud instance, installs their stack, opens a few ports “temporarily,” and then moves on to the next task. Three months later, that temporary FTP listener on port 21 is still wide open, running an unpatched vsftpd. Nobody remembered it existed until an incident response team found it during a breach investigation.
Before You Boot: Planning Your Port Strategy
Before the server even goes live, you should know exactly which ports it needs. Write them down. Seriously — a simple spreadsheet or internal wiki page listing port number, protocol, service, and justification saves you from guesswork later.
Start with the absolute minimum. A typical web server needs 22 (SSH), 80 (HTTP), and 443 (HTTPS). A database server behind a firewall might only need the database port accessible from specific application server IPs — and nothing else from the outside. If you can’t justify why a port needs to be open to the public internet, it stays closed.
This is where most teams fail. They think about what to open, but they don’t think about minimizing the attack surface from day one. Every open port is a potential entry point, and the goal is to keep that number as small as humanly possible.
The Deployment-Day Port Security Checklist
Here’s what I run through on every new server. Adapt it to your environment, but don’t skip steps.
1. Audit default open ports immediately. Before you install anything, run ss -tulnp or netstat -tulnp to see what’s already listening. Many OS images ship with services you didn’t ask for — rpcbind, cups, or even an SMTP relay. Kill anything you don’t need.
2. Configure your firewall before exposing the server. On Debian/Ubuntu, set up iptables or nftables rules (or your cloud provider’s security group) to deny all inbound traffic by default, then whitelist only the ports from your plan. Default-deny is non-negotiable.
3. Harden SSH access. Disable password authentication, enforce key-based login, and consider restricting SSH to specific source IPs. Changing the default port is a minor speed bump — real SSH security goes well beyond just changing port 22.
4. Disable or remove unnecessary services. If the server doesn’t need FTP, Telnet, or an SNMP agent, don’t just stop the service — uninstall the package entirely. A stopped service can be restarted accidentally. A removed one can’t.
5. Bind services to specific interfaces. Your database should listen on 127.0.0.1 or a private network interface, not on 0.0.0.0. Same goes for Redis, Memcached, Elasticsearch — any service that has no business being on the public internet. This single step prevents more accidental exposures than most people realize.
6. Verify from the outside. Internal checks are useful, but they don’t tell you what the internet actually sees. Run an external port scan against your public IP immediately after deployment. External scans catch things internal checks miss — NAT misconfigurations, cloud security group mistakes, or that one forgotten IPv6 listener.
7. Set up continuous monitoring. A one-time scan is a snapshot. Servers change — packages get installed, containers spin up, someone opens a debug port. You need ongoing monitoring that alerts you whenever a new port appears. This is exactly what PortVigil does: it continuously scans your server’s public IP from the outside and flags any unexpected open ports before attackers find them.
The Myth of “I’ll Harden It Later”
Here’s the misconception I hear constantly: “We’ll lock it down once we’re done setting up.” This is backwards. The moment your server has a public IP, automated scanners are probing it. Shodan, Censys, and countless malicious bots scan the entire IPv4 space in under an hour. There is no grace period. Your firewall rules and port restrictions need to be in place before the server is reachable, not after.
If your deployment process doesn’t include security hardening as a built-in step, you’re relying on humans to remember — and humans forget. Bake it into your provisioning scripts, your Ansible playbooks, your Terraform configs. Make it automatic so it can’t be skipped.
Post-Deployment: The First 48 Hours
Your checklist doesn’t end at deployment. Within the first 48 hours, verify these:
Review your external scan results. If anything unexpected is open, investigate immediately. Check that third-party applications aren’t listening on ports you didn’t authorize. Many packages silently open listeners during installation — monitoring agents, update daemons, or management consoles.
Enable version detection on your scans. Knowing that port 443 is open is useful. Knowing it’s running OpenSSL 1.1.1 with a known vulnerability is actionable. PortVigil’s service detection identifies not just open ports but the specific software and versions behind them, cross-referencing against known CVEs.
Document everything. Your port inventory from the planning phase should now be verified against reality. Any discrepancies need an explanation or a fix.
FAQ
How many ports should a typical production web server have open?
As few as possible — usually two or three. Most web servers need only 443 for HTTPS and 22 for SSH (ideally restricted by source IP). Port 80 is sometimes kept open just to redirect to HTTPS. Anything beyond that needs a documented justification. The fewer ports you expose, the smaller your attack surface.
Should I use a port security checklist even for short-lived or staging servers?
Absolutely. Staging servers are frequently targeted precisely because teams treat them as disposable and skip hardening. If it has a public IP, it needs the same baseline security as production. Attackers don’t check whether your server is “just for testing.”
How quickly should I respond if monitoring detects an unexpected open port?
Treat it as a priority-one investigation. An unexpected open port means either a configuration change happened without authorization or something is seriously wrong. Identify the process, determine who or what opened it, and close it until you have a clear explanation. Hours matter here — not days.
Final Thought
A port security checklist isn’t a one-time document you file away. It’s a living process that starts before deployment and continues for the entire life of the server. Build it into your provisioning workflow, verify it with external scans, and monitor continuously. The servers that get breached aren’t the ones with sophisticated zero-days — they’re the ones with forgotten open ports that nobody was watching.