Linux powers the majority of the world’s servers — from small personal projects to massive enterprise infrastructure. That popularity makes it a prime target for attackers. A single misconfigured setting or an outdated package can turn a reliable server into an open door for intruders.
Whether you’re a beginner setting up your first VPS or a sysadmin managing production systems, these ten steps form the foundation of a secure Linux environment. If you’re still getting comfortable with the basics, it’s worth brushing up on core Linux system administration concepts before diving into hardening — and if your server also handles user data, pairing this guide with a broader cybersecurity checklist is a smart move.
Quick Reference: Security Layers at a Glance
| Security Layer | Tool / Method | Protects Against |
|---|---|---|
| Access Control | SSH Key Authentication | Brute-force login attempts |
| Network | UFW Firewall | Unauthorized port access |
| Intrusion Detection | Fail2Ban | Repeated failed logins, bots |
| Patch Management | Unattended Upgrades | Known CVEs / exploits |
| Privilege Control | Least-Privilege Users | Lateral movement after compromise |
| Monitoring | journalctl / Logwatch / Wazuh | Undetected breaches |
| Recovery | Automated, Tested Backups | Data loss, ransomware impact |
Keep Your System Updated
Outdated software is one of the most common attack vectors. Security patches exist for a reason — attackers actively scan for servers running known-vulnerable versions.
sudo apt update && sudo apt upgrade -y
For production servers, consider enabling automatic security updates so critical patches are never missed. You can find the official configuration options in the Ubuntu Security Documentation:
sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades
Disable Root Login Over SSH
Logging in directly as root gives an attacker full control the moment they guess your password. Instead, create a standard user with sudo privileges and disable root SSH access entirely.
Edit /etc/ssh/sshd_config:
PermitRootLogin no
Then restart the SSH service:
sudo systemctl restart sshd
Switch to SSH Key Authentication
Passwords can be brute-forced; SSH keys practically cannot. This is one of the most effective steps in any Linux hardening guide. Generate a key pair on your local machine and copy the public key to your server, following the official OpenSSH documentation:
ssh-keygen -t ed25519 -C "your_email@example.com"
ssh-copy-id user@your-server-ip
Once confirmed working, disable password authentication in sshd_config:
PasswordAuthentication no
Change the Default SSH Port
This won’t stop a determined attacker, but it drastically cuts down automated bot scans that target port 22.
Port 2222
Remember to update your firewall rules to match.
Set Up a Firewall
A firewall controls what traffic is allowed to reach your server. ufw (Uncomplicated Firewall) is the easiest option on Debian/Ubuntu systems.
sudo ufw allow 2222/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
Only open ports your applications actually need — every open port is a potential entry point.
Install Fail2Ban
Fail2Ban monitors log files and automatically bans IP addresses that show signs of malicious behavior, like repeated failed login attempts.
sudo apt install fail2ban
sudo systemctl enable --now fail2ban
The default configuration already covers SSH; you can extend it to protect web servers, mail servers, and more.
Use Strong, Unique Passwords and Enable 2FA
Even with SSH keys enabled, other services — control panels, databases, admin dashboards, web app logins — often still rely on passwords. A single reused or weak password on any of these can undo all the SSH hardening you’ve done elsewhere. Use a password manager such as Bitwarden to generate and store unique, complex credentials for every service, and enable two-factor authentication (2FA) wherever it’s supported.
For an extra layer on SSH itself, you can add time-based one-time password (TOTP) verification using Google’s PAM module for two-factor authentication:
sudo apt install libpam-google-authenticator
google-authenticatorThen enable it in /etc/pam.d/sshd by adding:
auth required pam_google_authenticator.soAnd in /etc/ssh/sshd_config, make sure both factors are required:
ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive| Where to Enable 2FA | Recommended Method |
|---|---|
| SSH Login | Google Authenticator PAM module |
| Control Panels (cPanel, Plesk, etc.) | Built-in TOTP / authenticator app |
| Cloud Provider Dashboard (AWS, Azure, GCP) | Hardware key or authenticator app |
| Database Admin Tools (phpMyAdmin, pgAdmin) | Reverse proxy with 2FA gateway |
Limit User Privileges
Follow the principle of least privilege — give each user and application only the access it actually needs. Avoid running web applications or services as root, and regularly audit who has sudo access.
sudo deluser username sudo
9. Monitor Logs and Set Up Alerts
Logs are your early warning system. Regularly check:
sudo journalctl -xe
sudo tail -f /var/log/auth.log
For larger deployments, tools like Logwatch, Wazuh, or a centralized ELK stack can help you spot unusual activity before it becomes a breach.
Back Up Regularly — and Test Your Backups
Security isn’t just prevention; it’s also recovery. Even with every hardening step in this guide applied, no server is 100% immune to ransomware, hardware failure, or human error. Automate regular backups of your critical data and configurations, follow the 3-2-1 backup rule (3 copies, 2 different media types, 1 off-site), and periodically test restoring from them. A backup you’ve never tested is not a real backup.
For most Linux servers, a simple automated approach using rsync or a dedicated tool like Restic or Borg Backup covers both file-level and encrypted, deduplicated backups:
# Example: encrypted backup with Restic
restic init --repo /path/to/backup-repo
restic backup /etc /home /var/www --repo /path/to/backup-repoSchedule it with a cron job so backups run automatically:
0 2 * * * restic backup /etc /home /var/www --repo /path/to/backup-repo| Backup Method | Best For | Notes |
|---|---|---|
rsync |
Simple file syncing | Fast, but no built-in encryption |
| Restic | Encrypted, deduplicated backups | Great for off-site/cloud storage |
| Borg Backup | Large datasets, compression | Strong deduplication, self-hosted friendly |
| Cloud Provider Snapshots | Full-disk/VM recovery | Fastest full restore, provider-dependent |
Test your restore process at least once a quarter — ideally on a separate machine — so you know backups actually work before you’re forced to rely on them during a real incident.
Final Thoughts
Securing a Linux server isn’t a one-time task — it’s an ongoing habit. Start with these ten steps, then build on them with tools like intrusion detection systems, regular vulnerability scans, and a documented incident response plan. The goal isn’t to make your server impenetrable — that’s impossible — but to make it enough of a hassle that attackers move on to easier targets.
Small, consistent effort in security today saves you from costly downtime and data loss tomorrow.
Frequently Asked Questions (FAQs)
1. Is Linux more secure than Windows for servers?
Linux has a smaller attack surface for server workloads and offers more granular permission controls out of the box, but “more secure” ultimately depends on configuration. A poorly configured Linux server can be just as vulnerable as a poorly configured Windows one — the OS is only as safe as its setup.
2. How often should I update my Linux server?
Critical security patches should be applied as soon as they’re released — ideally through automated tools like unattended-upgrades. Full system upgrades can be scheduled weekly or monthly, depending on your uptime requirements and testing process.
3. Do I really need to disable root login?
Yes. Disabling direct root SSH login and using sudo instead adds an extra verification layer and creates an audit trail of exactly which user performed which action — something a shared root login can’t give you.
4. Is changing the SSH port actually useful?
It won’t stop a targeted attacker, but it significantly reduces noise from automated bots that scan the default port 22 around the clock. Think of it as a first filter, not a complete defense.
5. What’s the difference between a firewall and Fail2Ban?
A firewall (like UFW) controls which ports and services are reachable at all. Fail2Ban works on top of that — it watches logs in real time and dynamically blocks IPs showing malicious behavior, such as repeated failed logins.
6. How do I know if my backups actually work?
Schedule regular test restores — ideally on a separate, isolated server — to confirm your backup files are complete and usable. A backup strategy without periodic restore testing is incomplete.
