Rootkits Don't Sleep: The Definitive Linux Server Hardening Guide
Let’s be honest: default installations are for hobbyists. If you just spun up a fresh instance of CentOS 6 or Debian Squeeze and left it running on port 22 with password authentication, you aren't an admin; you're a target. I've cleaned up enough compromised boxes this year to tell you that security through obscurity is dead. The script kiddies scanning IP ranges don't care that your site is small. They want your bandwidth for DDoS attacks and your CPU for mining Bitcoin.
In the Norwegian market, where data integrity is mandated by the Personal Data Act (Personopplysningsloven) and overseen by Datatilsynet, getting hacked isn't just an inconvenience—it's a legal nightmare. Here is how we lock things down.
1. Burn the Bridge: Securing SSH
The first thing a bot does is hammer port 22 with a dictionary attack against the 'root' user. If you are still logging in as root, stop. Create a sudo user and cut the head off the snake.
Edit your /etc/ssh/sshd_config file immediately:
# /etc/ssh/sshd_config
Port 2222
Protocol 2
PermitRootLogin no
PasswordAuthentication no
UseDNS no
AllowUsers cooladmin
Note: We change the port to 2222 (or any high port) to reduce log noise from dumb scanners. More importantly, PasswordAuthentication no forces the use of SSH keys (RSA 2048-bit or higher). If you don't have your private key, you don't get in. Period.
Pro Tip: On CoolVDS instances, we provide an out-of-band VNC console. If you accidentally lock yourself out while configuring the firewall (we've all been there), you can still access the box via the client portal to fix it.
2. The Iron Gate: IPTables Configuration
Forget the fancy GUI tools. You need to understand iptables. It is the kernel-level firewall that stands between your data and the wild web. A proper policy is "Drop by Default." If you don't explicitly allow traffic, it shouldn't get in.
Here is a battle-tested baseline for a web server:
# Flush existing rules
iptables -F
# Default policies: DROP everything incoming
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# Allow loopback (critical for local services like MySQL)
iptables -A INPUT -i lo -j ACCEPT
# Allow established connections (so your SSH session doesn't die)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow SSH (on your new custom port)
iptables -A INPUT -p tcp --dport 2222 -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 specific)
/sbin/service iptables save
This configuration ensures that even if a service accidentally starts listening on a random port, the outside world can't touch it.
3. Banning the Bots: Install Fail2Ban
Even with a custom SSH port, determined attackers will eventually find it. Fail2Ban is mandatory software for 2011. It scans your log files (like /var/log/secure) for failed login attempts and dynamically updates your iptables rules to ban the offender's IP address.
On RHEL/CentOS, you'll need the EPEL repository enabled first:
rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-5.noarch.rpm
yum install fail2ban
Configure it to ban an IP for an hour after 3 failed attempts. It saves system resources and keeps your logs clean.
4. The Hardware Factor: Why Infrastructure Matters
Software hardening is useless if the host node is unstable or oversold. In the hosting industry, "noisy neighbors" are a plague. If another VPS on the same physical server gets DDoS'd, your latency spikes. This is unacceptable for serious applications.
At CoolVDS, we use KVM (Kernel-based Virtual Machine) virtualization. Unlike OpenVZ, KVM provides true hardware isolation. Your RAM is your RAM. We also utilize enterprise-grade RAID 10 SSD caching arrays. While full SSD storage is still expensive for mass storage in 2011, our hybrid setups ensure that your I/O wait times remain negligible, even during backup windows.
Comparison: Virtualization Tech
| Feature | OpenVZ (Common) | KVM (CoolVDS Standard) |
|---|---|---|
| Kernel | Shared with Host | Isolated / Custom |
| Performance | Variable (burst resources) | Consistent (dedicated resources) |
| Security | Lower isolation | High isolation |
5. Local Jurisdiction and Latency
For those of us operating in Northern Europe, latency to the Oslo Internet Exchange (NIX) is a critical metric. Hosting your data in the US might be cheaper, but the 100ms+ round-trip time kills the responsiveness of dynamic applications. Furthermore, under current EU directives, keeping customer data within the EEA (European Economic Area) simplifies compliance with privacy laws significantly.
CoolVDS infrastructure is located physically in Oslo. This guarantees sub-10ms latency for your Norwegian users and keeps your data strictly under Norwegian jurisdiction—safe from the Patriot Act overreach.
The Final Check
Hardening is not a one-time task; it is a process. Keep your kernel updated with yum update, watch your logs, and never trust a default setting. If you need a rock-solid foundation to build on, you need a provider that respects the technical demands of 2011.
Ready to deploy securely? Spin up a KVM instance on CoolVDS today and experience the stability of true hardware isolation.