Lock It Down: The Essential Guide to Hardening Linux Servers

Let's be honest: default Linux installations are not secure. Whether you are spinning up a minimal Debian Squeeze image or a CentOS 6 node, the default configuration is designed for usability, not security. In the wake of the LulzSec attacks last year, if you aren't paranoid, you aren't paying attention. I've seen too many competent sysadmins deploy a server to production on a Friday, only to find it part of a botnet by Monday morning because they left port 22 wide open to password auth.

Security is not a product; it is a process. In this guide, we are going to walk through the non-negotiable hardening steps for any VPS deployed in 2012. We will focus on the command line, strict access control, and network filtering. If you are hosting critical data here in Norway, complying with the Personopplysningsloven (Personal Data Act) starts with infrastructure integrity.

1. The First 5 Minutes: User Management & SSH

The moment your IP comes online, scripts are already scanning it. Using the root user for daily operations is a rookie mistake that ends in disaster. We need to create a privileged user and disable root login immediately.

Step 1: Create a sudo user

# On CentOS/RHEL 6
useradd deployment
passwd deployment
usermod -aG wheel deployment

# On Debian/Ubuntu 10.04+
adduser deployment
usermod -aG sudo deployment

Step 2: SSH Keys Only

Passwords are dead. They are sniffable and brute-forceable. Generate a 2048-bit RSA key pair on your local machine and push it to the server. Once your key is in place, we edit the daemon config.

# /etc/ssh/sshd_config

Port 2202  # Security through obscurity isn't security, but it reduces log noise
Protocol 2
PermitRootLogin no
PasswordAuthentication no
UseDNS no
AllowUsers deployment

Restart the service immediately. On CentOS 6, that's service sshd restart. Do not close your current session until you have verified you can log in with a new terminal window. I once locked myself out of a remote box in a data center in Frankfurt; the remote hands fee was painful. Don't be me.

2. The Firewall: Mastering iptables

Hardware firewalls are great, but you need host-level protection. iptables is the kernel-level packet filter we rely on. Forget fancy GUIs; learn the syntax. We want a default policy of DROP for everything incoming, and explicitly ALLOW only what we need.

Here is a battle-tested configuration script for a standard web server:

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]

# Allow localhost traffic
-A INPUT -i lo -j ACCEPT

# Allow established connections (crucial!)
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow SSH (New Port)
-A INPUT -p tcp --dport 2202 -j ACCEPT

# Allow HTTP/HTTPS
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT

# ICMP (Ping) - Rate limited to prevent floods
-A INPUT -p icmp -m icmp --icmp-type 8 -m limit --limit 1/sec -j ACCEPT

COMMIT

Apply this by editing /etc/sysconfig/iptables on RedHat systems or using iptables-restore on Debian. This configuration drops all other traffic. If you are running a database, do not expose port 3306 to the world. Tunnel it through SSH or bind it to localhost.

Pro Tip: When testing firewall rules, use iptables -A ... commands with a scheduled cron job to flush rules (iptables -F) every 10 minutes. If you lock yourself out, the cron job will save you. Remove the cron job once the rules are stable.

3. Brute Force Protection: Fail2Ban

Even with a custom SSH port, bots will hammer your server. Fail2Ban parses your log files (like /var/log/secure or /var/log/auth.log) and updates iptables rules dynamically to ban offending IP addresses.

Install it via EPEL repo on CentOS or apt on Debian. The default configuration is decent, but we want to be aggressive.

# /etc/fail2ban/jail.local

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

This bans any IP for an hour after 3 failed attempts. It drastically reduces the load on your SSH daemon and keeps your logs clean.

4. The CoolVDS Factor: Isolation Matters

Software hardening is useless if the virtualization layer leaks. This is where the choice of provider becomes architectural, not just financial. Many budget hosts use OpenVZ, where the kernel is shared among all tenants. If a neighbor triggers a kernel panic or an exploit targets a kernel vulnerability, your hardened container is compromised.

At CoolVDS, we exclusively use KVM (Kernel-based Virtual Machine) virtualization. Each instance runs its own isolated kernel. This provides a hardware-level distinction between your environment and the rest of the node. When we talk about security compliance in Norway, specifically regarding data integrity mandates from Datatilsynet, having that strict isolation is often a requirement, not a luxury.

5. Filesystem & Permissions

Restrict access to critical files. A common vector for privilege escalation involves world-writable scripts.

# Secure shared memory
echo "tmpfs /dev/shm tmpfs defaults,noexec,nosuid 0 0" >> /etc/fstab
mount -o remount /dev/shm

# Lock down compiler access (optional but recommended for web nodes)
chmod 700 /usr/bin/gcc
chmod 700 /usr/bin/g++

Preventing execution in /dev/shm stops a whole class of exploits that attempt to run malicious binaries from shared memory space.

Conclusion: Constant Vigilance

Hardening is the baseline. From here, you should be looking at setting up Logwatch to email you daily summaries, and perhaps Tripwire to detect file integrity changes. If you are serving clients in Oslo or Bergen, latency and legal jurisdiction are your next concerns.

Hosting on CoolVDS solves the physical layer: low latency connection to NIX (Norwegian Internet Exchange), pure SSD storage for rapid I/O, and KVM isolation for peace of mind. But the software layer? That is on you. Apply these configs, rotate your keys, and keep your packages updated.

Ready to deploy a secure stack? Launch a KVM instance on CoolVDS today and experience true hardware isolation.