Lock It Down: The Definitive Linux Server Hardening Guide (2011 Edition)

Let’s be honest: if you are running a server with a default installation of CentOS 6 or Debian Squeeze right now, you are painting a target on your back. 2011 has been a wake-up call for the industry. From the LulzSec rampages to the constant background radiation of botnet port scans, the days of "security through obscurity" are dead.

I’ve seen too many competent sysadmins deploy a fresh VPS, leave port 22 open to the world with password authentication, and then wonder why their bandwidth graph looks like a hockey stick three days later. It’s not a matter of if you get scanned; it’s a matter of when.

In this guide, we aren't just talking about theory. We are going to the command line to implement the exact hardening protocols we use on our own infrastructure here in Norway. Whether you are hosting a high-traffic e-commerce site or a critical backend for a startup, these are the non-negotiables.

1. SSH: The Front Door Must Be Reinforced

The vast majority of automated attacks target SSH. If you are still using passwords for root access, stop reading this and change it immediately. We need to disable password authentication entirely and force the use of SSH keys.

Generate Your Keys

On your local machine (not the server), generate a 2048-bit RSA key pair. 1024-bit is no longer sufficient for paranoia-level security.

ssh-keygen -t rsa -b 2048

Once pushed to your server (ssh-copy-id is your friend), edit the daemon config. This is where most people get lazy, and it’s where you get hacked.

# File: /etc/ssh/sshd_config

# Change the default port to reduce log noise (security by obscurity, but effective against dumb scripts)
Port 2202

# absolute prohibition on root login
PermitRootLogin no

# Disable password auth
PasswordAuthentication no
UsePAM no

# Limit who can actually log in
AllowUsers yourusername

Restart the service with service sshd restart. Pro Tip: Keep your current session open while you test the new connection in a second terminal window. If you messed up the config, you don't want to lock yourself out.

2. The Firewall: Learn to Love iptables

Many control panels try to abstract this away, but a real sysadmin knows iptables. It is the kernel-level packet filter that stands between your application and the chaos of the public internet.

Here is a baseline configuration for a web server. We drop everything by default and only whitelist what we need.

# Flush existing rules
iptables -F

# Default policies: Block everything incoming
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# Allow loopback (localhost)
iptables -A INPUT -i lo -j ACCEPT

# Allow established connections (so the server can talk back to you)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow SSH (on our custom port 2202)
iptables -A INPUT -p tcp --dport 2202 -j ACCEPT

# Allow Web Traffic
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Save rules (CentOS/RHEL)
/sbin/service iptables save

Note on Latency: A bloated firewall rule set can impact network performance. At CoolVDS, our upstream routers handle the heavy lifting for DDoS mitigation, so your local iptables only needs to handle logic, not volume. This keeps your latency to the NIX (Norwegian Internet Exchange) in Oslo as low as possible.

3. Fail2Ban: The Bouncer

Even with a custom SSH port, you will eventually be found. Fail2Ban is a Python script that scans log files (like /var/log/secure) and bans IPs that show malicious signs—too many password failures, seeking exploits, etc.

Install it via EPEL (for CentOS) or apt (Debian). The default configuration is decent, but I recommend tightening the bantime.

[ssh-iptables]
enabled  = true
filter   = sshd
action   = iptables[name=SSH, port=2202, protocol=tcp]
logpath  = /var/log/secure
maxretry = 3
bantime  = 3600  # Ban them for an hour. Let them cool off.

4. The "CoolVDS" Factor: KVM Isolation

Software hardening is useless if your neighbor on the physical host can compromise the kernel. This is the dirty secret of cheap VPS hosting in 2011: many providers use OpenVZ or Virtuozzo containers that share a single kernel.

If a vulnerability is found in the host kernel, every container is at risk. That is why CoolVDS utilizes KVM (Kernel-based Virtual Machine) hardware virtualization. Each of our instances runs its own isolated kernel. If your neighbor crashes or gets hacked, your environment remains hermetically sealed.

Why Norwegian Hosting Matters

Beyond the technical specs, physical location matters. Under the Norwegian Personal Data Act (Personopplysningsloven), your data is protected by some of the strictest privacy laws in the world—far safer than servers located in jurisdictions with loose data retention directives. Plus, if your customer base is in Scandinavia, the milliseconds you save by hosting in Oslo versus Frankfurt make a tangible difference in page load times.

5. Keep It Updated

It sounds simple, but yum update or apt-get upgrade is your first line of defense. With the rise of complex SQL injection attacks and PHP vulnerabilities, running old software is negligence. Set up a cron job to email you when security updates are available, or use a tool like yum-cron to handle security patches automatically.

Final Thoughts

Security is a process, not a product. There is no "install and forget" command. However, by securing SSH, configuring a strict firewall, and choosing a virtualization platform like KVM that respects isolation, you are already ahead of 90% of the market.

Don't let your hard work be undone by a script kiddie. Deploy your next project on a platform that takes security as seriously as you do.

Ready to deploy? Spin up a secure, SSD-accelerated KVM instance on CoolVDS today and experience the stability of premium Norwegian infrastructure.