Linux Server Hardening: Essential Security Steps for 2011
Let’s be honest: 2011 has been a wake-up call. We watched Sony get humiliated, HBGary Federal get dismantled, and the CIA website get taken offline. If massive organizations with dedicated security teams are getting owned by scripts and SQL injections, what chance does your fresh CentOS 5 box have?
None. Unless you lock it down.
I see it every day. A developer spins up a VPS, installs Apache, and leaves SSH open on port 22 with a weak root password. Automated bots scanning netblocks usually crack these servers within 48 hours. If you are hosting data in Norway, you aren't just risking downtime; you are risking the wrath of the Datatilsynet (Data Inspectorate). Under the Personal Data Act of 2000, negligence isn't a defense.
Here is the battle-tested configuration we use at CoolVDS to keep the script kiddies out.
1. Kill the Password
Passwords are dead. Brute force attacks are too cheap and too fast. If you are still logging in by typing a string of characters, you are doing it wrong. Step one on any new server is generating an RSA key pair.
On your local machine:
ssh-keygen -t rsa -b 4096
Upload the public key to your server and then—this is the critical part—edit your /etc/ssh/sshd_config file. We need to disable password authentication entirely and stop root from logging in directly. Use vi or nano:
PermitRootLogin no
PasswordAuthentication no
UseDNS no
AllowUsers yourusername
Restart the service with service sshd restart. Now, the only way into that box is with the physical key file on your laptop. Even if an attacker has your username, they can't brute force a 4096-bit key.
2. The IPTables Fortress
Many hosting providers give you a server with all ports open. That is negligent. You need a firewall that drops everything by default and only opens what is strictly necessary.
Forget complex GUI tools. Learn iptables. It is the kernel-level standard. Here is a baseline configuration script I drop on every new deployment:
# Flush existing rules
iptables -F
# Default policies: Block everything
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# Allow established connections (so you don't lock yourself out)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow loopback
iptables -A INPUT -i lo -j ACCEPT
# Allow SSH (If you moved ports, change 22)
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# Allow Web Traffic
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
# Save settings
/etc/init.d/iptables save
Pro Tip: Before applying firewall rules, set a cron job to flush iptables (iptables -F) every 5 minutes. If you accidentally lock yourself out, wait 5 minutes, and you're back in. Delete the cron job once you confirm the rules work.
3. Banish Unnecessary Services
A default installation of RHEL or Debian often comes with baggage. sendmail, rpcbind, or xinetd might be running. Every open port is a potential exploit vector.
Run netstat -tulpn to see what is listening. If you don't need it, kill it. Use chkconfig to ensure they don't resurrect on reboot:
chkconfig sendmail off
chkconfig rpcbind off
Less code running means fewer vulnerabilities to patch.
4. Intrusion Detection: Fail2Ban
Even with keys, your logs will be flooded with authentication attempts. Install Fail2Ban. It parses your log files (like /var/log/secure) and looks for patterns of failed attempts. When it sees an IP address fail 3 times in 60 seconds, it dynamically updates your iptables rules to ban that IP for an hour.
It keeps the log noise down and prevents targeted hammering of your SSH port.
The Architecture Matters: OpenVZ vs. KVM
Software hardening only gets you so far. You also need to trust the virtualization layer. In the budget hosting market, OpenVZ is popular because it allows providers to oversell RAM. But OpenVZ containers share the host kernel. If a vulnerability is found in the host kernel, every container on that node is potentially compromised.
This is why CoolVDS exclusively uses KVM (Kernel-based Virtual Machine). With KVM, your OS kernel is isolated. A kernel panic in your neighbor's VPS won't crash your database. For mission-critical applications in Norway, where stability is paramount, true hardware virtualization is the only professional choice.
We combine this isolation with high-performance RAID-10 SSD storage (rare in 2011, but standard for us) and direct peering at NIX (Norwegian Internet Exchange) in Oslo. This gives you low latency without sacrificing security.
Summary Checklist
| Action | Benefit |
|---|---|
| Disable Root Login | Prevents dictionary attacks on the admin account. |
| Use SSH Keys | Eliminates password theft risks. |
| Default Drop Firewall | Ensures only explicit traffic enters. |
| Update Kernel | Patches local root exploits. |
Security isn't a product; it's a process. But starting on a solid foundation helps. Don't let your server be low-hanging fruit for hackers.
Need a secure baseline? Deploy a hardened KVM instance on CoolVDS today and get root access in under 55 seconds.