Locking Down Your Linux Box: Essential Server Hardening Survival Guide
Let’s be honest: the moment you spin up a new server and it hits the public internet, it’s being scanned. I tail /var/log/secure for fun, and the number of automated bots trying to brute-force root with password lists is staggering. If you are running a default install of CentOS 5 or Debian Squeeze without tweaking the locks, you aren't an admin; you're a victim waiting to happen.
I've spent the last week cleaning up a mess for a client who thought "default settings" were good enough for their e-commerce rig. Spoiler: they weren't. Their server became a zombie node in a DDoS botnet because they left port 22 wide open to the world with password authentication enabled.
Here is how we lock things down. No fluff, just the commands and configs that keep your uptime high and your blood pressure low.
1. The Keys to the Kingdom: SSH Hardening
The first thing to die is password authentication. Passwords can be guessed; 4096-bit RSA keys generally cannot (at least, not before the heat death of the universe). If you are still typing a password to log into your server, stop.
First, generate your key pair locally:
ssh-keygen -t rsa -b 4096
Push the public key to your server. Once you verify you can log in without a password, edit /etc/ssh/sshd_config. We are going to change the default port (security through obscurity isn't security, but it does reduce log noise) and kill root login.
Port 2200
Protocol 2
PermitRootLogin no
PasswordAuthentication no
UseDNS no
AllowUsers yourusername
Reload the service (service sshd reload). Congratulations, you just eliminated 99% of the automated scripts hitting port 22.
Pro Tip: Before you close that terminal session, open a second terminal and try to log in. If you messed up the config and disconnect, you lock yourself out. I've seen senior admins drive to the datacenter at 3 AM because of this. Don't be that guy.
2. The Shield: IPTables (Because You Have To)
I know, iptables syntax is painful. But until something better comes along, it is the standard. You want a policy of "Deny All, Permit Some."
Here is a battle-tested baseline script I drop onto most fresh CoolVDS instances. It flushes existing rules and sets a strict policy:
# Flush defaults
iptables -F
iptables -X
# Default Policy: Drop everything
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# Allow localhost (essential for local app comms)
iptables -A INPUT -i lo -j ACCEPT
# Allow established connections (so you don't kick yourself off)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow SSH (use your custom port from step 1!)
iptables -A INPUT -p tcp --dport 2200 -j ACCEPT
# Web traffic
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
Save this (/etc/init.d/iptables save on RHEL/CentOS) and make sure it loads on boot.
3. Fail2Ban: The Bouncer
Even with keys, bots will hammer your custom SSH port. Fail2Ban is mandatory. It watches your logs for suspicious activity and updates your iptables rules dynamically to ban the offending IP addresses.
Install it (yum install fail2ban or apt-get install fail2ban) and configure /etc/fail2ban/jail.local. Set the ban time to something painful.
[ssh-iptables]
enabled = true
filter = sshd
action = iptables[name=SSH, port=2200, protocol=tcp]
logpath = /var/log/secure
maxretry = 3
bantime = 3600
If someone fails to log in 3 times, they go to timeout for an hour. It keeps the logs clean and the server resources focused on serving your app, not rejecting handshakes.
4. The Norwegian Context: Data, Latency, and Trust
We are operating in Norway. This gives us specific advantages and responsibilities. Under the Personopplysningsloven (Personal Data Act), you are responsible for the data you host. Hosting data in the US is getting riskier with the Patriot Act implications. Keeping your data on Norwegian soil—like in a CoolVDS datacenter in Oslo—simplifies compliance significantly. You satisfy the Datatilsynet requirements without needing complex legal frameworks for cross-border data transfer.
Furthermore, latency matters. If your user base is in Oslo or Bergen, why route packets through Frankfurt? Use mtr (My Traceroute) to check the hops. You'll see that staying local keeps your ping in the single digits.
Virtualization Matters: KVM vs. OpenVZ
Security isn't just software; it's architecture. A lot of budget hosts sell you OpenVZ containers. The problem? You share the kernel with every other customer on that node. If there is a kernel exploit, isolation can be broken.
This is why at CoolVDS we stick to KVM (Kernel-based Virtual Machine). It provides full hardware virtualization. You get your own kernel. If a neighbor does something stupid, it doesn't crash your OS. For serious production environments, KVM is the only responsible choice in 2011.
5. Keep It Fresh
It sounds obvious, but run your updates. The Linux kernel community patches vulnerabilities fast, but that doesn't help if you haven't rebooted into the new kernel in six months.
- CentOS:
yum update -y - Debian/Ubuntu:
apt-get update && apt-get dist-upgrade
Subscribe to the mailing lists for your distro. When a major vulnerability hits (like the Apache range header DoS we saw recently), you need to patch immediately, not next week.
Final Thoughts
Security is a process, not a product. You don't "install security" and walk away. But if you implement keys, a strict firewall, Fail2Ban, and choose a virtualization platform that respects isolation like KVM, you are ahead of 90% of the market.
Don't let a script kiddie ruin your weekend. If you need a sandbox to test these configurations without risking your production rig, spin up a KVM instance on CoolVDS. Our SSD-cached storage handles the I/O load of aggressive logging and monitoring without breaking a sweat.