Lock Down or Get Owned: The 2009 Linux Hardening Survival Guide

It’s 3:00 AM. Your pager goes off. Your Apache logs are growing by a gigabyte every minute, and your load average just hit 50. You aren't just having a bad night; you've been owned. In today's landscape, a fresh Linux install connected to the public internet lasts about 10 minutes before the scanners find it.

I've spent the last decade cleaning up after admins who thought "default settings" were good enough. They aren't. Whether you are running a high-traffic forum on vBulletin or a critical corporate mail server, security is not a feature—it is a baseline requirement. If you are hosting here in Norway, you also have the Personopplysningsloven (Personal Data Act) to worry about. The Datatilsynet does not accept "we got hacked" as a valid excuse for leaking customer data.

Here is how we lock down servers at CoolVDS. No fluff, just the raw commands that keep our uptime spotless.

1. SSH: The Front Door Must Be Reinforced

The default SSH configuration is an invitation for brute-force attacks. I see logs on new servers showing thousands of login attempts for 'root' within hours of provisioning. Stop using passwords. Stop logging in as root.

First, create a dedicated user and give them sudo access. Then, edit your /etc/ssh/sshd_config file immediately:

# /etc/ssh/sshd_config
Port 2222  # Move it off standard port 22. It cuts log noise by 90%.
PermitRootLogin no
PasswordAuthentication no
UseDNS no
AllowUsers yourusername

You need to generate an RSA or DSA key pair locally and push your public key to the server (~/.ssh/authorized_keys) before you restart the service. If you lose that key, you are locked out. That’s the point. If you can't get in easily, neither can the botnets.

Pro Tip: On our CoolVDS Xen instances, we recommend using the VNC console available in your client area to test SSH config changes safely. Don't lock yourself out of a remote box without a backup plan.

2. The Firewall: iptables is Your Best Friend

Forget GUI firewalls. Learn iptables. It is the kernel-level packet filter that stands between your application and the chaos of the internet. The policy is simple: Drop everything by default, then open only what is necessary.

Here is a battle-tested script for a standard web server (HTTP, HTTPS, and our custom SSH port):

#!/bin/bash
# Flush existing rules
iptables -F

# Default policies: Block everything
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 you don't cut yourself off)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow SSH (Port 2222), HTTP (80), HTTPS (443)
iptables -A INPUT -p tcp --dport 2222 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Save settings (CentOS/RedHat specific)
service iptables save

If you are running on Debian 5 (Lenny), make sure you use iptables-save > /etc/iptables.rules and load it on network up. Without this, a reboot leaves you naked.

3. Fail2Ban: Automated Defense

Even on a custom port, persistent attackers will hammer your SSH or FTP services. Fail2Ban scans your log files (like /var/log/secure or /var/log/auth.log) and updates iptables rules dynamically to ban the IP addresses of offenders.

Install it via EPEL repo on CentOS or apt on Debian. Configure the jail strictly:

[ssh-iptables]
enabled  = true
filter   = sshd
action   = iptables[name=SSH, port=2222, protocol=tcp]
logpath  = /var/log/secure
maxretry = 3
bantime  = 3600

This creates a self-healing defense system. While you sleep, your server is actively banning IPs from China, Russia, or anywhere else that are trying to guess your password.

4. Physical Jurisdiction & Compliance

Security isn't just software; it's legal. If you are handling Norwegian customer data, hosting it on cheap servers in the US puts you in a gray area regarding the EU Data Protection Directive (95/46/EC). The safe harbor principles are shaky at best.

Hosting with CoolVDS ensures your data stays physically located in Oslo. We peer directly at NIX (Norwegian Internet Exchange), which keeps latency low—often under 5ms for local users—and keeps your data within the jurisdiction of Norwegian law and the Datatilsynet.

Why Architecture Matters

You can harden your OS all day, but if your host oversells resources, you have a security availability problem. Many budget providers use OpenVZ and stuff 100 containers onto a single hard drive. One neighbor gets DDoS'd, and your database crawls.

At CoolVDS, we use Xen virtualization. This provides true hardware isolation. Your RAM is yours. Your swap is yours. We run on enterprise-grade RAID-10 SAS storage arrays. While not as cheap as SATA, the I/O reliability is non-negotiable for serious database work.

Don't risk your reputation on unhardened servers or oversold hardware. Security is a process, not a product, but starting on the right foundation makes all the difference.

Ready to deploy a secure foundation? Spin up a Xen-based VPS in our Oslo datacenter today and experience true stability.