Lockdown 2011: The Definitive Guide to Linux Server Hardening
Let’s be honest: the default installation of any Linux distribution—be it CentOS 5, Debian 6 (Squeeze), or Ubuntu 10.04 LTS—is not ready for the public internet. With groups like LulzSec and Anonymous making headlines this year, the threat landscape has shifted from automated bots to targeted disruption. If you are running a server with a public IP, you are already being scanned.
I’ve spent the last decade cleaning up compromised boxes where the admin thought “security through obscurity” was a strategy. It isn’t. Whether you are hosting a high-traffic e-commerce site or a critical backend for a Norwegian enterprise, the latency to NIX (Norwegian Internet Exchange) won't save you if your SSH port is wide open to brute-force attacks.
Here is the no-nonsense, battle-tested protocol for hardening your Linux VPS. No fluff, just commands that work.
1. The SSH Fortress
The majority of breaches I see start with a brute-forced root password. If you are still logging in as root with a password, you are negligent. Period.
Step A: Keys Only
Forget passwords. Generate a 2048-bit RSA key pair. It is the only acceptable standard right now.
ssh-keygen -t rsa -b 2048
Step B: Modify sshd_config
Edit /etc/ssh/sshd_config. We need to disable root login and password authentication entirely. While we are at it, move SSH off port 22. It doesn't stop a determined hacker, but it stops 99% of the script kiddies filling up your /var/log/secure.
Port 4422
Protocol 2
PermitRootLogin no
PasswordAuthentication no
UseDNS no
AllowUsers yourusername
Restart the service (service sshd restart on CentOS or /etc/init.d/ssh restart on Debian) only after you have verified your new user works in a separate terminal. I've seen too many admins lock themselves out on a Friday night.
2. The Firewall: Learn to Love iptables
Many 'managed' hosting providers give you a web-based firewall. It’s cute, but for real control, you need to master iptables. We operate on a 'Default Drop' policy. If traffic isn't explicitly allowed, it dies.
Here is a baseline script to save you hours of reading man pages:
# Flush existing rules
iptables -F
# Default policies: DROP everything incoming
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# Allow localhost (crucial for local IPC)
iptables -A INPUT -i lo -j ACCEPT
# Allow established connections (so you don't cut yourself off)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow SSH (on your new custom port)
iptables -A INPUT -p tcp --dport 4422 -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
/sbin/service iptables save
Pro Tip: If you are running a database like MySQL, bind it to127.0.0.1in yourmy.cnf. Never expose port 3306 to the world unless you absolutely must, and even then, whitelist the specific source IP in iptables.
3. Fail2Ban: The Bouncer
Even with a custom port, bots will find you. Fail2Ban is mandatory software in 2011. It scans log files for malicious behavior (too many password failures) and updates iptables to ban the offending IP for a set time.
On CentOS/RHEL, you'll need the EPEL repository enabled to grab it:
yum install fail2ban
Configure it to ban an IP for an hour after 3 failed attempts. It keeps your logs clean and your CPU focused on serving HTTP requests rather than processing authentication failures.
4. Virtualization Matters: KVM vs. OpenVZ
Security isn't just about software; it's about architecture. In the current VPS market, there is a flood of cheap providers using OpenVZ. They oversell RAM and, more dangerously, you share the kernel with every other customer on the node. A kernel exploit in a neighbor's container could theoretically compromise your data.
This is why CoolVDS strictly uses KVM (Kernel-based Virtual Machine). With KVM, your operating system is fully isolated. You have your own kernel. You can load your own modules (like SELinux). It mimics a dedicated server environment far more accurately than container-based solutions.
| Feature | OpenVZ (Budget Hosting) | KVM (CoolVDS Standard) |
|---|---|---|
| Kernel Isolation | Shared (Risky) | Full Isolation (Secure) |
| Resource Guarantees | Burst/Oversold | Dedicated RAM/CPU |
| SELinux Support | Limited/Difficult | Full Support |
5. The Norwegian Context: Datatilsynet Compliance
Operating in Norway adds a layer of responsibility. Under the Personal Data Act (Personopplysningsloven), you are responsible for securing personal data against unauthorized access. The Datatilsynet (Data Protection Authority) does not view "I didn't patch my server" as a valid excuse.
By hardening your server and choosing a provider that respects physical data sovereignty—keeping your data within Norwegian borders—you are not just securing bits and bytes; you are ensuring legal compliance. Our datacenters in Oslo connect directly to NIX, ensuring that your traffic stays local and low-latency, reducing the hops where interception could occur.
6. Updates and Minimization
Finally, run yum update or apt-get upgrade weekly. The kernel vulnerabilities we've seen in late 2010 and 2011 are nasty. If you don't need a service, uninstall it. Does your web server need Samba? No. Does it need X11? Definitely not. Remove them.
Security is a process, not a product. But starting with a solid foundation on a true hardware-virtualized platform like CoolVDS gives you a fighting chance against the chaos of the modern web.
Ready to get serious? Deploy a secure KVM instance on CoolVDS today and experience the stability of true isolation.