GICT knowledge base
How to Harden Linux Servers Against Common Attacks
Published
Let’s be honest-no one wants to wake up to the news that their server’s been hacked. Whether you manage one tiny VPS or a rack’s worth of machines, the threats are real, and they’re relentless. Attackers don’t discriminate; automated scans target everything online, looking for easy wins. If you’re running Linux servers, you’re already ahead-Linux has a strong security foundation. But “secure by default” isn’t the same as “bulletproof.”
This article isn’t just another checklist. Instead, it’s a conversation about why securing your Linux servers matters, what you should prioritize, and-most importantly-how to put practical safeguards in place. I’ll walk you through the basics, share insights from real-world incidents, and help you develop habits that make your servers tough targets for common attacks.
Why Server Hardening Matters
It’s easy to think, “Why would anyone bother attacking my server?” But attackers don’t care who you are. They’re after resources-processing power for crypto mining, bandwidth for botnets, or just bragging rights. Most attacks are automated, which means your system gets scanned for vulnerabilities as soon as it’s online.
Hardening is about reducing your attack surface. You’re removing unnecessary entry points, locking down services you need, and putting up defenses to slow down or stop attackers cold. Even if you’re not hosting sensitive data, a compromised server can put your reputation, customers, and business at risk.
Where to Start: Mindset and Habits
Before diving into commands, it’s important to develop a security mindset:
- Be proactive, not reactive. Don’t wait for an attack to start thinking about security.
- Stay up-to-date. System updates and patches are your first-and sometimes best-defense.
- Document changes. Keep track of what you tweak, so you can trace issues or roll back if needed.
- Backup often. Security isn’t just about keeping intruders out. It’s also about recovering quickly if something goes wrong.
Step 1: Keep Your System Updated
This sounds basic, but it’s astonishing how many breaches happen because of unpatched vulnerabilities. Make it a habit to:
sudo apt update && sudo apt upgrade # or
sudo dnf update # or
sudo yum update
Consider setting up automatic security updates, especially for critical or unattended servers. On Ubuntu and Debian:
sudo apt install unattended-upgrades
Step 2: Minimize the Attack Surface
The fewer services you have running, the fewer things an attacker can exploit. Here’s how to trim the fat:
Audit Running Services
Check what’s listening for connections:
sudo ss -tuln
Or:
sudo netstat -tulnp
If you see services you don’t use (FTP, Telnet, or even web servers you forgot about), stop and disable them:
sudo systemctl stop servicename
sudo systemctl disable servicename
Remove Unnecessary Packages
Why leave server software installed if you’re not using it? For example:
sudo apt remove apache2 # or
sudo dnf remove httpd
Step 3: Lock Down SSH
SSH is the lifeline to your server, but it’s also a favorite target for brute-force attacks.
Change the Default Port (Optional)
While not foolproof, moving SSH off port 22 can cut down on noise:
Edit /etc/ssh/sshd_config:
Port 2222
Reload SSH:
sudo systemctl reload sshd
Disable Root Login
Attackers love trying “root” with default or weak passwords. Disable root SSH access:
In /etc/ssh/sshd_config:
PermitRootLogin no
Use Key-Based Authentication
Passwords can be cracked. SSH keys are nearly impossible to brute-force.
On your local machine:
ssh-keygen
ssh-copy-id user@yourserver
Then, in sshd_config:
PasswordAuthentication no
Always make sure you can log in with your key before disabling password login. Otherwise, you might lock yourself out!
Set Up Fail2Ban
This tool watches logs for failed login attempts and blocks repeat offenders:
sudo apt install fail2ban
sudo systemctl enable --now fail2ban
It works out of the box for SSH, but you can tweak /etc/fail2ban/jail.local for stricter rules.
Step 4: Configure a Firewall
A firewall is your server’s bouncer. It decides which traffic gets in and which gets turned away at the door.
Using UFW (Uncomplicated Firewall):
sudo ufw allow 2222/tcp # Or your chosen SSH port
sudo ufw allow 80,443/tcp # If you run a web server
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable
Using firewalld:
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --permanent --set-default-zone=drop
sudo firewall-cmd --reload
Be careful: never lock yourself out of SSH! Always test firewall rules from another session before closing your current one.
Step 5: Keep Accounts Clean and Tight
Unnecessary user accounts are a risk. Regularly review users:
cut -d: -f1 /etc/passwd
Remove or lock users who no longer need access:
sudo userdel username
For shared servers, enforce strong password policies and consider using tools like chage to require password changes.
Step 6: Monitor and Audit Regularly
Security isn’t set-and-forget. Attackers are always evolving, so you have to keep an eye out.
Set Up Log Monitoring
Tools like logwatch, logcheck, or even a simple tail command can help:
sudo apt install logwatch
sudo logwatch --detail High --mailto [email protected] --range today
Use Intrusion Detection
Install AIDE (Advanced Intrusion Detection Environment):
sudo apt install aide
sudo aideinit
Set up regular checks to spot unexpected changes in critical files.
Step 7: Secure Network Services
If you run web servers, databases, or mail servers, don’t expose them to the whole internet unless you must.
- Bind services to localhost or internal IPs when possible.
- Use strong, unique passwords for databases and apps.
- Remove default/test databases and accounts after install.
- Consider tools like fail2ban for more than just SSH-many services can be protected.
Step 8: Use AppArmor or SELinux
These security modules limit what services can do-even if they’re compromised.
AppArmor (common on Ubuntu/Debian):
sudo aa-status
sudo aa-enforce /etc/apparmor.d/*
SELinux (common on RHEL/CentOS):
Check status:
sestatus
Enforce mode:
sudo setenforce 1
Learning to tailor these tools is a deeper topic, but even their default profiles add a strong layer of protection.
Step 9: Encrypt Data Wherever Possible
Use full-disk encryption on laptops or where physical access is possible.
Encrypt sensitive data at rest and in transit.
For web servers, always use HTTPS (Let’s Encrypt is free and easy).
Step 10: Keep Backups and a Recovery Plan
No system is invincible. If all else fails-whether from attack, mistake, or hardware failure-regular backups are your lifeline.
- Store backups offsite or in the cloud.
- Test restores regularly to ensure your backups actually work.
Real-World Tips and Stories
Security isn’t just about running through a checklist. Here are a few lessons learned the hard way:
- Once, I inherited a server where the previous admin left old accounts with weak passwords. Guess which account got brute-forced first? Always audit your users.
- I’ve seen web servers compromised by outdated WordPress plugins, not Linux itself. Patch everything, not just the OS.
- On more than one occasion, a firewall misconfiguration locked everyone out-including the admins. Test from a second terminal before ending your session.
Frequently Asked Questions
Is changing the default SSH port enough to secure my server?
No, but it helps reduce automated scans. Combine it with key authentication, firewalls, and fail2ban for real protection.
How often should I update?
For critical security patches, as soon as possible. For other updates, regularly-but test beforehand on non-production systems.
What’s the biggest mistake people make with server security?
Assuming it won’t happen to them, and leaving default settings untouched. Take a proactive approach.
Should I use root or sudo?
Use sudo. Disable root SSH login and only elevate privileges when you need them.
Conclusion
Hardening your Linux server isn’t about paranoia-about smart, proactive stewardship. By making these steps a habit, you’re not just protecting your own systems, but also contributing to a more secure internet for everyone. Remember, attackers go for low-hanging fruit. Make your server a tough target and you’ll already be miles ahead.
Regular audits, timely updates, and a bit of healthy skepticism are your best tools. Stay alert, document your changes, and never stop learning-security is a journey, not a destination.
Related guides
How to Set Up zram on a Small VPS
Configure zram on Ubuntu with kernel and swap checks. Understand compressed memory limits, monitor real use and avoid unsafe swap-file changes.
LinuxHow to Find Services That Need a Restart After Updates with needrestart
Find services using outdated libraries with needrestart on Ubuntu. Read restart reports, review automatic restart policy and plan maintenance safely.
LinuxHow to Limit a Linux Service’s Memory with systemd
Limit a Linux service with systemd MemoryHigh, MemoryMax and swap controls. Check cgroup support, diagnose pressure and remove only your own policy.
LinuxHow to Protect SSH with CrowdSec on Ubuntu
Protect SSH with CrowdSec on Ubuntu. Connect log detection to firewall enforcement and test temporary blocking without losing administrator access.
