Lock Down Your Box: The Definitive Guide to Linux Server Hardening

I checked my /var/log/secure this morning on a fresh provisioning. It had been online for exactly 45 minutes. The result? 412 failed login attempts from a single IP block in Eastern Europe. If you think your obscure server IP is safe because you haven't pointed a domain to it yet, you are delusional. The bots are scanning 24/7, and they don't sleep.

In the Norwegian hosting market, we pride ourselves on stability. But relying on the Datatilsynet (Data Inspectorate) regulations or the Personopplysningsloven (Personal Data Act) to protect you is legal fiction, not technical reality. Compliance is paperwork; security is engineering. If you are running a VPS in Oslo or anywhere else, you need to harden the OS immediately after the first boot. Here is how we do it at CoolVDS, and how you should do it too.

1. The SSH Fortress

The default OpenSSH configuration is too permissive. Password authentication is a brute-force victim waiting to happen. The first thing I do on any CoolVDS instance is disable passwords entirely in favor of RSA keys.

First, generate your keypair locally:

ssh-keygen -t rsa -b 4096

Push it to your server. Then, edit /etc/ssh/sshd_config. Do not use nano if you want respect; use vi.

# /etc/ssh/sshd_config

# Change the default port to reduce log noise (security by obscurity, but it helps)
Port 2202

# The root user should never log in directly. Su or Sudo up instead.
PermitRootLogin no

# Kill password auth dead.
PasswordAuthentication no
UsePAM no

# Limit who can actually login
AllowUsers yourusername

Restart the service. On CentOS:

service sshd restart

Warning: Keep your current session open while you test the new connection in a separate terminal. If you locked yourself out, and you aren't on a CoolVDS plan with out-of-band VNC console access, you are in for a bad day.

2. IPTables: The First Line of Defense

Many admins are scared of raw iptables. They look for wrappers or GUIs. Don't. You need to understand the packet flow. We want a 'Default Drop' policy. Everything is forbidden unless explicitly allowed.

Here is a battle-tested script for a standard web server (Web + SSH + Loopback):

#!/bin/bash

# Flush existing rules
iptables -F

# Set default chain policies
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# Accept on localhost
iptables -A INPUT -i lo -j ACCEPT

# Accept established connections (don't break your own SSH session)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# SSH (Adjust port if you changed it above)
iptables -A INPUT -p tcp --dport 2202 -j ACCEPT

# Web traffic (HTTP/HTTPS)
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Save settings
/sbin/service iptables save

This configuration is lean. It drops ICMP (ping) flood attempts by default because we aren't accepting anything not listed. It keeps the latency low because the kernel isn't processing junk packets.

3. Fail2Ban: Automating the Banhammer

Even with a custom SSH port, dedicated scanners will find you. You need software that watches logs and updates firewall rules dynamically. Fail2ban is the industry standard for this.

Install it via EPEL on CentOS or apt on Debian:

yum install fail2ban

Configure /etc/fail2ban/jail.conf. I prefer an aggressive stance:

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

If someone fails 3 times, they are gone for an hour. It keeps the logs clean and CPU usage down.

Pro Tip: Don't just watch SSH. Set up jails for Apache or Nginx 0.7 to ban IP addresses that generate too many 404 errors or search for w00tw00t vulnerability scanners.

4. Filesystem Integrity: Tripwire

If an intruder gets in, they will likely install a rootkit to hide their tracks. They replace binaries like ls, ps, and netstat so you can't see their processes. How do you trust your system?

You use a file integrity checker like Tripwire or AIDE. These tools create a cryptographic hash database of your system binaries. Run a check daily via cron. If /bin/login changes md5 sum overnight and you didn't run yum update, pull the plug immediately.

5. The Virtualization Factor: OpenVZ vs. Xen

Security isn't just software; it's architecture. In 2009, many budget hosts are overselling OpenVZ containers. The problem? Shared kernel. If there is a kernel panic or a serious exploit in the host kernel, every container is vulnerable. Isolation is weak.

At CoolVDS, we deploy on Xen (and are testing KVM) because strict isolation matters. We also utilize high-performance SAS 15k RPM RAID-10 arrays. Why? Because when a server is under a DDoS attack, disk I/O often spikes as logs are written furiously. Slow SATA drives will lock up your system, causing a denial of service even if the CPU is fine. Our enterprise storage keeps the system responsive so you can actually log in and mitigate the attack.

Final Thoughts

Hardening is not a one-time script; it is a mindset. Keep your kernel updated, watch your logs, and never assume the firewall upstream catches everything. With the latency to NIX (Norwegian Internet Exchange) being so low from our Oslo datacenter, your response times are fast, but so are the attacks. Be ready.

If you need a rig that gives you full root control with the I/O throughput to handle heavy logging and traffic spikes, stop playing with shared hosting toys.

Secure your infrastructure today. Deploy a hardened Xen VPS on CoolVDS.