Innovate | Connect | Transform
ContactService statusUSD $

GICT knowledge base

How to Harden Linux Servers Against Common Attacks

Published

LinuxLinux and Commands

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

Account services are unavailable until the production backend is configured.