A freshly provisioned dedicated server is not a secure server. It is a blank machine with an operating system, a root password, and an open SSH port, exposed to the internet from the moment it receives a public IP address.
Most server compromises do not involve sophisticated attacks. They involve automated bots scanning the internet for default configurations, weak passwords, and unpatched services. A server that has been online for 24 hours without hardening has already been probed thousands of times.
This checklist covers every security layer you need to address immediately after setup, and the ongoing practices that keep your server secure over time. Follow it in order, because every item exists for a reason, its absence has been the entry point for a real compromise.
📖 Just migrated to a dedicated server?
If you have just completed a migration, run through the Dedicated Server Migration Checklist first to confirm your environment is correctly configured, then return to this guide to harden it.
Why Server Hardening Cannot Wait
The default configuration of any Linux server is built for accessibility, not security. By default, the system enables root login, keeps password authentication active, and runs unnecessary services. Furthermore, no firewall protects the server.
Every hour a server sits in this state is an hour of exposure. Automated scanners identify open ports and attempt credential attacks within minutes of a new IP address appearing online. As a result, the question is not whether your server will be targeted, it is whether it will be hardened before the first successful attempt.
Hardening is not a one-time event either. Instead, it is a baseline you establish immediately and maintain continuously. Therefore, this checklist is structured accordingly: immediate actions, first 24 hours, first week, and ongoing maintenance.
Phase 1 — Immediate Actions (First 30 Minutes)
First and foremost, complete these steps before you install or configure anything else on the server.
SSH Hardening
SSH is the primary administrative entry point to your server and the most frequently targeted service on any Linux machine.
✅ Create a non-root user with sudo privileges Never operate as root for day-to-day administration. Instead, create a dedicated administrative user immediately:
adduser adminuser
usermod -aG sudo adminuser
✅ Set up SSH key authentication Password-based SSH authentication is vulnerable to brute-force attacks. Therefore, generate an SSH key pair on your local machine and copy the public key to the server.:
ssh-keygen -t ed25519 -C "[email protected]"
ssh-copy-id adminuser@your-server-ip
✅ Disable password authentication for SSH Once key authentication is confirmed working, you can then disable password login entirely.. Edit /etc/ssh/sshd_config:
PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes✅ Change the default SSH port Changing from port 22 to a non-standard port (e.g. 2222 or higher) eliminates the vast majority of automated scanning attempts immediately. In /etc/ssh/sshd_config:
Port 2222Remember to update your firewall rules and document the new port.
✅ Set SSH login timeout and attempt limits In /etc/ssh/sshd_config:
LoginGraceTime 30
MaxAuthTries 3
MaxSessions 5
📖 Why isolated infrastructure reduces your attack surface
Read Why Isolated Infrastructure Reduces Cybersecurity Risks, an in-depth look at how physical isolation on dedicated servers removes the cross-tenant vulnerabilities that exist on shared environments before you even begin hardening.
Firewall Configuration
✅ Enable and configure UFW (Uncomplicated Firewall) UFW provides a straightforward interface to iptables rules. Enable it with a default-deny policy:
ufw default deny incoming
ufw default allow outgoing
ufw allow 2222/tcp # Your new SSH port
ufw allow 80/tcp # HTTP
ufw allow 443/tcp # HTTPS
ufw enableOnly open ports that your applications actively require. Every unnecessary open port is an attack surface.
✅ Verify your firewall rules After enabling, confirm what is active:
ufw status verboseReview the output and remove any rules that should not be there.
✅ Block ICMP ping if not required Ping responses help attackers confirm a server is live. If you do not need ICMP responses, block them in your UFW rules or at the network level via your provider’s firewall.
Phase 2 — First 24 Hours
System Updates and Package Management
✅ Update all packages immediately after provisioning
apt update && apt upgrade -y # Debian/Ubuntu
yum update -y # CentOS/RHELA freshly provisioned server may be running package versions from weeks or months ago. As a result, unpatched packages are among the most common vectors for exploitation.
✅ Enable automatic security updates For Debian/Ubuntu systems, run the following::
apt install unattended-upgrades
dpkg-reconfigure unattended-upgradesConfigure to apply security updates automatically. Additionally, review the configuration file at /etc/apt/apt.conf.d/50unattended-upgrades to confirm only security updates are applied automatically, not major version upgrades, which should always be tested first.
✅ Remove unnecessary packages and services A default server installation includes services you may not need. Therefore, list all running services and disable anything that is not required.:
systemctl list-units --type=service --state=running
systemctl disable servicename
systemctl stop servicenameEvery service that is not running cannot be exploited.
📖 What DDoS protection should your provider include?
Server-level hardening protects against intrusion, but network-level DDoS protection is the provider’s responsibility. Read What Is DDoS and How Does It Affect Your Website? to understand what protection your provider should be supplying at the network level before traffic reaches your server.
Intrusion Detection and Brute Force Protection
✅ Install and configure Fail2Ban Fail2Ban monitors log files and, as a result, automatically bans IP addresses that show signs of brute-force activity:
apt install fail2banCreate a local configuration file at /etc/fail2ban/jail.local:
[sshd]
enabled = true
port = 2222
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600As a result, this configuration bans any IP that fails SSH authentication 3 times within 10 minutes for 1 hour..
✅ Install a host-based intrusion detection system (HIDS) Tools like AIDE (Advanced Intrusion Detection Environment) create a baseline of your file system and subsequently alert you to unexpected changes, a key signal that a compromise has occurred::
apt install aide
aideinitRun aide --check regularly or schedule it as a cron job to detect unauthorised file system modifications.
✅ Configure login notifications Set up email or webhook alerts for every successful SSH login to your server. Any login you did not initiate is an immediate security incident.
User and Permission Management
✅ Audit all user accounts First, list all users on the system and remove any that should not be there:
cat /etc/passwdThen, remove any unused accounts with: userdel -r username
✅ Review sudo privileges Only users who genuinely need elevated privileges should have sudo access. Therefore, review your sudoers file carefully:
cat /etc/sudoers
getent group sudo✅ Set a strong password policy Even with SSH keys enabled, password policy still matters for console access and local authentication. As a result, install and configure libpam-pwquality:
apt install libpam-pwqualityAdditionally, configure minimum length, complexity requirements, and password history in /etc/security/pwquality.conf.
✅ Lock the root account password With a sudo user configured and SSH key authentication active, the root password should be locked:
passwd -l root📖 Should you choose managed or unmanaged hosting for your security needs?
If your team does not have the capacity to implement and maintain this checklist, a managed dedicated server may be the right model. Read Managed vs Unmanaged Hosting Explained to understand what security responsibilities each model covers.
Phase 3 — First Week
SSL/TLS Configuration
✅ Install SSL certificates for all services Every service exposed over the network should use TLS encryption. For web services, install Let’s Encrypt via Certbot:
apt install certbot python3-certbot-nginx
certbot --nginx -d yourdomain.com✅ Configure strong TLS settings Default TLS configurations often support outdated protocols. Disable TLS 1.0 and 1.1 , only TLS 1.2 and 1.3 should be enabled. Configure your web server to use strong cipher suites only.
✅ Enable HSTS HTTP Strict Transport Security tells browsers to only communicate with your server over HTTPS, preventing downgrade attacks. Add to your Nginx or Apache configuration:
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;✅ Set up automatic certificate renewal Let’s Encrypt certificates expire every 90 days. Certbot installs a cron job or systemd timer for renewal, verify it is active:
certbot renew --dry-runWeb Application Firewall
✅ Install and configure a WAF A Web Application Firewall filters malicious HTTP traffic before it reaches your application. ModSecurity with the OWASP Core Rule Set is the standard open-source implementation for Nginx and Apache.
Install ModSecurity and enable the OWASP CRS to protect against SQL injection, cross-site scripting, and other common web application attacks.
✅ Configure rate limiting Rate limiting at the web server level prevents abuse of your application endpoints:
For Nginx, add to your server block:
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
limit_req zone=api burst=20 nodelay;Adjust limits based on your application’s normal traffic patterns.
📖 What is a WAF and when do you need one?
Read What Is a Web Application Firewall (WAF) and Do You Need One?, a clear explanation of what WAFs protect against and how they complement server-level firewall rules.
Monitoring and Logging
✅ Set up centralised log management Configure your server to retain logs for a sufficient period and alert on anomalous patterns. At minimum, ensure these log files are being written and rotated correctly:
/var/log/auth.log— authentication events/var/log/syslog— system events/var/log/nginx/access.loganderror.log— web traffic/var/log/fail2ban.log— ban events
✅ Install a performance and security monitoring agent Tools like Netdata, Prometheus with node_exporter, or Datadog provide real-time visibility into CPU, memory, disk, and network metrics, and alert you to anomalies that can indicate an active incident.
✅ Configure uptime monitoring An external uptime monitoring service checks your server from outside your network and alerts you immediately if it becomes unreachable. This catches incidents that internal monitoring cannot detect because they affect the server’s ability to respond at all.
✅ Set up disk usage alerts Disk exhaustion is a common cause of service failures and can be a sign of a log injection or data exfiltration incident. Alert when disk usage exceeds 80%.
📖 What are the best tools to monitor your server?
Read Best Tools to Monitor Dedicated Server Performance, a practical guide to the monitoring stack that gives you visibility into performance and security events from day one.
Backup and Recovery Configuration
✅ Set up automated backups before anything else goes wrong Configure automated backups of your application data, databases, and configuration files. Test restoration from backup before you need it, a backup you have never restored is an untested backup.
✅ Store backups off-server Backups stored only on the same server they protect are useless if the server is compromised or the disk fails. Store backups on a separate server, object storage, or a dedicated backup service.
✅ Encrypt your backups Backup files contain your most sensitive data. Encrypt them at rest using GPG or your backup tool’s native encryption before transferring off-server.
✅ Document your recovery procedure Write down exactly how to restore your server from backup. In an incident scenario, you should not have to figure this out under pressure.
Phase 4 — Ongoing Security Maintenance
Security hardening is not a one-time event. You must maintain these practices continuously.
✅ Apply security patches within 24-48 hours of release Attackers actively exploit critical security vulnerabilities within hours of public disclosure. Subscribe to security advisories for your OS and the software you run. Apply patches as soon as they are available for critical vulnerabilities.
✅ Review firewall rules monthly Rules accumulate over time as new services are added. Review your UFW rules monthly and remove any that your applications no longer need.
✅ Rotate SSH keys periodically Rotate SSH keys at least annually, and immediately whenever a team member with key access leaves the organisation.
✅ Audit user accounts quarterly Review all user accounts and sudo privileges every quarter. Remove accounts that your team no longer needs and revoke access for anyone who has left or changed roles.
✅ Run vulnerability scans regularly Tools like Lynis provide automated security auditing of your server configuration and highlight areas that need attention:
apt install lynis
lynis audit systemReview the output and address any warnings or suggestions systematically.
✅ Test your backups regularly Restore from backup to a test environment monthly. Confirm the restored environment is complete and functional. Document the result.
✅ Review access logs weekly Spend 15 minutes each week reviewing your auth logs and web server access logs for patterns that should not be there, unusual access times, unfamiliar IP addresses, repeated 401 or 403 responses to specific endpoints.
The Complete Security Checklist at a Glance
Stage 1 — Immediate (first 30 minutes) ✅ Create non-root sudo user · ✅ SSH key authentication · ✅ Disable password auth · ✅ Change SSH port · ✅ Set SSH timeout and attempt limits · ✅ Configure UFW firewall · ✅ Verify firewall rules
Phase 2 — First 24 hours ✅ Update all packages · ✅ Enable automatic security updates · ✅ Remove unnecessary services · ✅ Install Fail2Ban · ✅ Install HIDS (AIDE) · ✅ Configure login notifications · ✅ Audit user accounts · ✅ Review sudo privileges · ✅ Set password policy · ✅ Lock root password
Stage 3 — First week ✅ Install SSL certificates · ✅ Configure strong TLS · ✅ Enable HSTS · ✅ Set up certificate renewal · ✅ Install WAF · ✅ Configure rate limiting · ✅ Set up log management · ✅ Install monitoring agent · ✅ Configure uptime monitoring · ✅ Set disk usage alerts · ✅ Configure automated backups · ✅ Store backups off-server · ✅ Encrypt backups · ✅ Document recovery procedure
Phase 4 — Ongoing ✅ Patch within 24-48h of critical releases · ✅ Monthly firewall rule review · ✅ Periodic SSH key rotation · ✅ Quarterly user account audit · ✅ Regular vulnerability scans · ✅ Monthly backup restoration test · ✅ Weekly log review
Start on Infrastructure Built for Security
Swify’s dedicated servers give you the physical isolation, full root access, and network-level DDoS protection you need to implement this checklist from day one, with European datacenters and transparent pricing.
→ Explore Swify Dedicated Server PlansFrequently Asked Questions
FAQ 1 :: How long does it take to harden a dedicated server?
The immediate phase: SSH hardening and firewall configuration, takes 30 to 60 minutes for an experienced administrator. The full first-week checklist, including SSL configuration, WAF setup, monitoring, and backup configuration, typically takes 4 to 8 hours spread across the first week. Ongoing maintenance is approximately 1 to 2 hours per month. If your team does not have this capacity, a managed dedicated server handles most of these layers on your behalf. Read Managed vs Unmanaged Hosting Explained to understand what each model covers.
FAQ 2 :: Is a dedicated server more secure than cloud hosting?
Dedicated servers provide physical isolation that cloud environments cannot match, no other tenant’s workload runs on your hardware, eliminating the cross-tenant attack surface that exists on shared infrastructure. Cloud providers invest heavily in their own security, but logical isolation is structurally weaker than physical isolation for sensitive workloads. Read Why Isolated Infrastructure Reduces Cybersecurity Risks for a full breakdown of how physical isolation changes your security posture.
FAQ 3 :: What is the most critical security step after setting up a dedicated server?
Disabling password-based SSH authentication and enabling key-based authentication is the single most impactful immediate step. The majority of successful server compromises begin with brute-forced SSH credentials. Eliminating password authentication removes this attack vector entirely. This should be completed within the first 30 minutes of server provisioning, before any other configuration work begins.
FAQ 4 :: Do I need a WAF if I already have a firewall?
Yes, they protect against different threat categories. A network firewall controls which ports and protocols can reach your server. A WAF inspects the content of HTTP requests and blocks malicious payloads like SQL injection, cross-site scripting, and path traversal attacks that arrive on legitimate ports that your firewall must keep open. Both layers are necessary for a complete defence. Read What Is a Web Application Firewall (WAF) and Do You Need One? for a full explanation of how WAFs complement firewall rules.
FAQ 5 :: How often should I update my server’s software?
Critical security patches should be applied within 24 to 48 hours of release, vulnerabilities are actively exploited within hours of public disclosure. Enabling automatic security updates handles this for OS-level packages. Application-level updates (web server, database, runtime) require manual review and testing before deployment. General package updates should be applied at least monthly during a scheduled maintenance window.
FAQ 6 :: What should I do if I suspect my dedicated server has been compromised?
Isolate the server immediately by restricting network access at the firewall level, block all inbound connections except from your IP. Preserve logs before taking any action that might overwrite them. Take a snapshot of the disk if your provider supports it. Then begin forensic investigation: review auth logs, check for new user accounts, look for unexpected processes and cron jobs, and compare file system state against your AIDE baseline. Do not attempt to clean an actively compromised server, provision a new one from your last clean backup and investigate the compromised machine separately. Read Best Security Practices for Dedicated Server Environments for preventative measures that reduce compromise risk.