- A 15-point practical checklist for locking down a dedicated server in 2026, covering access control, network exposure, patching, logging, and the operational habits that keep a box secure long after day one.
- Use it as a standing reference, not a one-time task list.
Most dedicated server breaches are not the result of some exotic zero-day. They are the result of skipped basics: a root account still reachable over SSH, a firewall rule nobody closed after a test, a package that has not been patched in eight months. This checklist is deliberately not a deep-dive into any single technique — if you want a full walkthrough of hardening a CentOS or RHEL box line by line, we already have a dedicated guide for that. This article is the thing you pin to the wall: fifteen concrete, verifiable steps that apply regardless of distro, covering the full surface area of a production server rather than going deep on one part of it.
We run this exact checklist against every new dedicated server before it goes into production at WebsNP, and we re-run an abbreviated version quarterly against servers already in service. Print it, adapt it, and use it as a gate before you hand a server to a client or a dev team.
Why a Checklist Format Works Better Than a Single Long Guide
Security hardening guides tend to either drown you in theory or assume you already know what "harden SSH" means in practice. A checklist forces two things a narrative guide does not: it forces you to actually check something off (or admit you have not), and it forces breadth — you cannot skip network security because you spent all your energy on file permissions. Every item below includes the actual command or setting, not just the concept, so you can verify compliance rather than assume it.
Who This Checklist Is For
This applies whether you are hardening a freshly provisioned dedicated server before launch, auditing a box that has been in production for two years with nobody quite sure what was configured when, or handing a server off between team members and needing a shared baseline both sides agree on. The steps are distro-agnostic — the commands below assume a systemd-based Linux distribution (Ubuntu, Debian, AlmaLinux, Rocky, RHEL), but the underlying principle in each item applies regardless of exact distro or even OS family.
Before You Start: Establish a Baseline
Before touching any configuration, take an inventory of the current state: what is listening (ss -tulpn), what packages are installed and their versions (dpkg -l or rpm -qa), what cron jobs and systemd timers exist, and who currently has SSH key access. Save this output somewhere off the server. It is the reference point you will compare against during the quarterly re-audit, and it is invaluable if you ever need to explain to a client or auditor exactly what changed and when.
The 15-Point Security Checklist
1. Disable Direct Root Login Over SSH
Create a named administrative user, add it to the wheel or sudo group, then set PermitRootLogin no in /etc/ssh/sshd_config and restart sshd with systemctl restart sshd. Verify with ssh root@your-server-ip from another machine — it should be refused outright, not just prompt for a password.
2. Move SSH Off Port 22 (and Layer Key Auth on Top)
Changing Port 22 to something in the 20000-60000 range cuts opportunistic bot scanning by well over 90% in our logs, though it is not a substitute for real access control. Combine it with PasswordAuthentication no and PubkeyAuthentication yes so only holders of an authorized private key can even attempt a login. Also set MaxAuthTries 3 and LoginGraceTime 20 in the same file — both shrink the window an automated scanner has to work with per connection attempt.
3. Enforce Key-Based Authentication Everywhere
Generate keys with ssh-keygen -t ed25519 -a 100, copy the public key with ssh-copy-id -p 2222 admin@server-ip, confirm you can log in with the key, then disable password auth entirely. Keep one physical or encrypted backup of the private key off the server — losing it with no console access means a full IPMI-based recovery. For teams, avoid one shared key pair; issue a distinct key per administrator so authorized_keys entries can be individually revoked when someone leaves, and add a comment to each line (ssh-ed25519 AAAA... jane@laptop-2026) so a stale audit does not turn into guesswork about whose key is whose.
3b. Consider a Bastion or Jump Host for Larger Fleets
If you manage more than a handful of servers, route SSH access through a single hardened bastion host rather than exposing SSH directly on every box. This shrinks your total attack surface to one carefully monitored entry point and lets you centralize login auditing (who connected, from where, to which server) instead of stitching together logs from a dozen machines after the fact. For a single server this is overkill — but it is worth planning for before your fleet grows past the point where retrofitting it becomes painful.
4. Install and Configure a Firewall (iptables or CSF)
Default-deny inbound, explicitly allow only the ports you use: your SSH port, 80/443 for web traffic, and anything your application needs. A minimal iptables baseline looks like:
iptables -P INPUT DROP iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -p tcp --dport 2222 -j ACCEPT iptables -A INPUT -p tcp --dport 80 -j ACCEPT iptables -A INPUT -p tcp --dport 443 -j ACCEPT
We cover full iptables and CSF rule sets, including rate limiting and port-knocking patterns, in our firewall configuration guide. For a more resilient baseline, add explicit rate limiting on your SSH port at the same time you write the allow rule, rather than treating it as a later add-on:
iptables -A INPUT -p tcp --dport 2222 -m state --state NEW -m recent --set --name sshlimit iptables -A INPUT -p tcp --dport 2222 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --name sshlimit -j DROP
5. Set Up Fail2ban or CSF Login Failure Daemon
Fail2ban watches auth logs and temporarily bans IPs after repeated failed logins. apt install fail2ban (Debian/Ubuntu) or dnf install fail2ban (RHEL/Alma/Rocky), then enable the sshd jail in /etc/fail2ban/jail.local with maxretry = 4 and bantime = 3600. Verify it is catching attempts with fail2ban-client status sshd. A jail definition worth copying directly:
[sshd] enabled = true port = 2222 filter = sshd logpath = /var/log/auth.log maxretry = 4 findtime = 600 bantime = 3600 bantime.increment = true bantime.factor = 2
The bantime.increment setting doubles the ban duration on each repeat offense from the same IP, which is a meaningfully better deterrent than a flat one-hour ban that a persistent bot simply waits out.
6. Patch the OS and Installed Packages on a Schedule
Set up unattended security updates (unattended-upgrades on Debian/Ubuntu, dnf-automatic on RHEL-family) for security-only patches, and schedule a manual full update window monthly for anything requiring a reboot. A server that is two kernel versions behind is a server with publicly documented, exploitable CVEs sitting open. On Ubuntu, confirm unattended-upgrades is actually applying updates (not just installed but inert) with cat /var/log/unattended-upgrades/unattended-upgrades.log — a surprising number of "we have automatic updates configured" servers turn out to have the service silently failing for months.
For kernel updates specifically, check whether your distro supports live-patching (kpatch on RHEL-family, livepatch via Canonical on Ubuntu) so critical kernel CVEs can be patched without a reboot at all — useful when a reboot window is hard to schedule but a known-exploitable kernel bug cannot wait for the next one.
7. Disable Unused Services and Close Unused Ports
Run ss -tulpn to see every listening socket, then stop and disable anything you do not recognize or use: systemctl disable --now cups, systemctl disable --now avahi-daemon, and so on. Every open port is attack surface, whether or not it is currently vulnerable. Extend the same audit to installed packages, not just running services — apt list --installed or dnf list installed piped through a quick review will usually turn up compilers, mail servers, or FTP daemons nobody remembers installing, each one a package that needs patching even while sitting completely unused.
8. Enforce Least-Privilege File Permissions
Web-writable directories should be owned by the application user, not root, and should never be world-writable (chmod 777 is a red flag, full stop). Set config files containing credentials to 640 or tighter, and audit with find / -type f -perm -o+w -not -path "/proc/*" 2>/dev/null to catch stray world-writable files. Also check for orphaned SUID/SGID binaries with find / -perm -4000 -o -perm -2000 -type f 2>/dev/null — a stray SUID binary left over from a debugging session is a privilege-escalation path waiting to be found, and this list should be short and fully explainable at all times.
9. Enable Centralized, Tamper-Evident Logging
Ship auth, kernel, and application logs to a remote syslog server or log aggregator so an attacker who gains root cannot simply delete the local evidence of how they got in. Even a cheap remote rsyslog target is better than logs that live only on the compromised box. A minimal remote-forwarding configuration on the client side:
*.* @@log-collector.internal:514
The double-@ forces TCP delivery instead of UDP, which matters for auth logs specifically — a dropped UDP packet during an actual intrusion is exactly the log line you cannot afford to lose. If budget allows, feed logs into something queryable (Graylog, an ELK/OpenSearch stack, or even a managed log service) rather than a flat text file on a second server — a five-minute grep across weeks of logs during an active incident is a very different experience than tailing a remote file by eye.
10. Set Up Automated Backups With an Offsite Copy
Ransomware and destructive attacks assume your only backup is reachable from the compromised server. Use the 3-2-1 rule — three copies, two media types, one offsite — and test a real restore quarterly. We go deep on backup architecture, including RAID vs snapshot vs offsite tradeoffs, in our backup strategies guide.
11. Deploy DDoS Protection at the Network Edge
Application-layer hardening does not help if a volumetric flood saturates your uplink before packets even reach your firewall rules. Confirm your provider offers always-on or on-demand scrubbing, and understand the trigger thresholds before you need them — details in our DDoS protection guide.
12. Run a Host-Based Intrusion Detection Tool
Tools like AIDE or Tripwire baseline your filesystem and alert on unexpected changes to binaries and config files — exactly the kind of tampering a rootkit performs. Initialize the database (aide --init) right after hardening, before the server goes live, so your baseline is clean. Schedule a nightly comparison run (aide --check) via cron and email the diff to a separate address — one that is not itself on the server being monitored, since an attacker with root can otherwise simply silence the alert at the source.
13. Restrict Outbound Traffic, Not Just Inbound
A compromised server phoning home to a command-and-control host, or exfiltrating data, relies on unrestricted outbound access. Default-deny outbound and allow only what your applications legitimately need (package mirrors, your database, your CDN) closes a door most checklists forget entirely. A starting egress policy:
iptables -P OUTPUT DROP iptables -A OUTPUT -o lo -j ACCEPT iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT iptables -A OUTPUT -p udp --dport 53 -j ACCEPT iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
Expect to iterate on this — a default-deny outbound policy will break things you did not expect (NTP sync, a package manager hitting a mirror on an unusual port, an application calling a third-party API) the first time you enable it, which is exactly why it belongs on a maintenance window with console access standing by, not pushed live at 5pm on a Friday.
14. Use Multi-Factor Authentication for Panel and Admin Logins
SSH keys protect shell access, but your hosting control panel, WordPress admin, or database GUI logins are often still password-only. Add TOTP-based MFA (Google Authenticator, Authy) to every admin-facing login surface, not just SSH. WordPress in particular has no native MFA — a plugin (Wordfence, miniOrange, or similar) is mandatory, not optional, for any site with more than one admin user.
15. Document and Test Your Incident Response Plan
Know, before an incident, who has IPMI/remote console access, how you isolate a compromised server from the network without powering it off (preserving forensic evidence), and who gets notified. A plan you have never tested is a plan that will fail exactly when you need it. Our IPMI and remote management guide covers the out-of-band access this depends on. At minimum, the written plan should answer: who has the authority to take the server offline unilaterally, what the internal and (if applicable) customer notification timeline is, where forensic disk images get stored, and who your point of contact is at your hosting provider for law-enforcement or abuse-related requests.
Ongoing Maintenance: Making This a Habit, Not a Memory
A checklist that lives only in a document nobody re-reads decays the same way an unpatched server does. Put a recurring calendar reminder on the quarterly re-audit, keep the baseline inventory from before you started somewhere version-controlled (a private git repo works well — config files, firewall rules, and package lists all diff cleanly), and treat any deviation from that baseline as something to explain, not ignore. Teams that treat hardening as a project that finishes are the same teams that get breached eighteen months later through a change nobody tracked.
Quick-Reference Checklist Table
| # | Action | Time to Implement | Risk if Skipped |
|---|---|---|---|
| 1-3 | SSH hardening (root, port, keys) | 15 min | Critical — most common entry point |
| 4-5 | Firewall + fail2ban | 30-60 min | Critical |
| 6-7 | Patching + service audit | 1-2 hrs setup | High |
| 8-9 | Permissions + logging | 1 hr | Medium-High |
| 10-11 | Backups + DDoS protection | Varies by provider | Critical (data loss / downtime) |
| 12-13 | Intrusion detection + egress control | 1-2 hrs | Medium |
| 14-15 | MFA + incident response plan | 1-3 hrs | High |
Common Mistakes We See in Security Audits
- Hardening SSH thoroughly, then leaving a hosting control panel reachable on its default port with no MFA
- Enabling a firewall but never auditing rules after a temporary rule (opened for testing) is forgotten
- Backups that exist but have never been restored — until the day they are needed and turn out to be corrupt
- Treating this as a one-time launch task instead of a recurring quarterly review
Buyer's Checklist: What to Ask Your Hosting Provider
- Do you provide a firewall or DDoS scrubbing at the network edge, or is that entirely my responsibility?
- Is out-of-band IPMI/KVM access included, so I can recover a server that firewalls itself out?
- What is your policy on abuse reports and how quickly do you notify me of suspicious traffic from my server?
- Do you offer managed security patching, or is the server fully unmanaged?
- Can I get a snapshot or backup add-on provisioned at order time rather than bolted on later?
- Is remote syslog or log-shipping infrastructure available on the provider's network, or do I need to run my own?
- What is the provider's documented process if my server is compromised and used to attack others — do they null-route first and ask questions later, or work with me on remediation?
Severity Tiers: Prioritizing When You Cannot Do Everything at Once
| Tier | Items | Do This First If Time-Constrained |
|---|---|---|
| Critical (do today) | 1-6 | SSH hardening, firewall, patching — closes the doors automated attacks actually use |
| High (this week) | 7-11 | Service audit, permissions, logging, backups, DDoS protection |
| Medium (this month) | 12-15 | Intrusion detection, egress control, MFA, incident response documentation |
If you only have an hour before a server goes live, items 1-6 cover the overwhelming majority of real-world automated attack vectors — everything after that reduces risk further but addresses progressively less common attack paths.
Frequently Asked Questions
Is this checklist enough on its own, or do I still need a full hardening guide?
Treat this as the "did I cover everything" gate and pair it with topic-specific deep dives — our CentOS/Linux hardening guide for OS-level lockdown steps, and the firewall and DDoS guides linked above for network-layer depth.
How often should I re-run this checklist?
At provisioning, then a full re-audit quarterly, plus an ad-hoc check any time you open a new port, install new software, or add a team member with server access.
Do managed dedicated servers still need this checklist?
Yes, though your provider typically handles items 6, 10, and parts of 11-12 for you. Confirm exactly which items are covered in your management SLA — "managed" means different things across providers.
What is the single highest-impact item on this list?
Disabling password authentication over SSH (items 1-3 together). The overwhelming majority of automated compromise attempts on fresh servers are brute-force SSH login attempts against root or common usernames.
Does this checklist apply to Windows dedicated servers too?
The principles transfer (least privilege, patching, firewall, MFA, logging, backups) but the specific commands do not — Windows uses RDP hardening, Windows Firewall/Group Policy, and Windows Update instead of SSH and iptables.
Should I run this checklist myself or ask for managed hardening?
If you do not have in-house Linux administration experience, a managed hardening service is worth the cost — a partially-applied checklist can create a false sense of security that is worse than an honest "we have not hardened this yet."
How is this checklist different from a compliance framework like PCI-DSS or SOC 2?
Compliance frameworks are broader and include organizational, contractual, and audit requirements well beyond server configuration; this checklist covers the technical server-hardening subset that most frameworks assume as a baseline. Passing this checklist does not mean you are compliant, but failing it almost certainly means you are not.
What is the fastest way to check if a server has already been compromised before I start hardening it?
Compare running processes and listening ports against what you expect (ps aux, ss -tulpn), check for unexpected cron entries and SUID binaries, and review last and auth logs for logins from unfamiliar IPs — if anything looks off, treat the server as compromised and rebuild from a known-clean image rather than hardening on top of a potentially backdoored system.
Does containerized deployment (Docker/Kubernetes) change any of these steps?
The host-level items (SSH, firewall, patching, logging) still apply to the underlying node unchanged; containers add their own additional surface (image provenance, container escape risks, network policies between pods) that this checklist does not cover in depth and that deserves its own dedicated review.
WebsNP's dedicated servers ship with IPMI access, network-edge DDoS mitigation, and optional managed hardening so this checklist is largely done for you on day one. View our dedicated server plans or talk to our team about a managed security add-on.