Linux Server Hardening: Essential Security Steps for the Paranoid Sysadmin

Let’s be honest: a default Linux installation is not a server; it's a target. If you spin up a fresh VPS and tail your auth logs, you'll see connection attempts from random IPs in China or Russia within minutes. I've seen clean installs compromised in under an hour because someone thought "password123" was sufficient protection for root.

In the Nordic hosting market, we pride ourselves on stability and trust. But trust isn't a firewall rule. Whether you are running a high-traffic Magento store or a critical backend for a Stavanger oil firm, the principles remain the same: reduce the attack surface, trust no one, and monitor everything. This guide covers the absolute essentials for hardening CentOS 6 and Ubuntu 12.04 servers in October 2012.

1. The First Line of Defense: SSH Keys

Password authentication is dead. Brute force scripts are getting smarter, and dictionary attacks are relentless. The very first thing you do—before installing Apache, before setting up MySQL—is disabling password logins.

First, generate a key pair on your local machine (Linux/Mac):

Once generated, push the public key to your server. If you are using a provider like CoolVDS, you can often inject this during the KVM provisioning process. If not, do it manually:

Now, lock the door. Edit /etc/ssh/sshd_config. We are going to change the default port (security by obscurity is a weak layer, but it reduces log noise) and disable passwords.

# /etc/ssh/sshd_config

# Change the port to something non-standard
Port 2222

# vital for security
PermitRootLogin no
PasswordAuthentication no
UseDNS no
AllowUsers your_username

Restart the service (service ssh restart or service sshd restart). Do not close your current terminal until you have verified you can login with a new session. If you lock yourself out, you'll be begging support for KVM console access.

2. Firewalls: Respecting the iptables

Many developers are scared of iptables because the syntax looks arcane. Get over it. It is the kernel-level packet filter that stands between your data and the internet. In 2012, we don't rely on fancy wrappers; we write the rules.

Here is a battle-hardened baseline policy. It drops all incoming traffic by default and only opens what is necessary. This script is designed for a web server (HTTP/HTTPS) with our custom SSH port.

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

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

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

# Allow established connections (so the server can talk back)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow SSH on our custom port
iptables -A INPUT -p tcp --dport 2222 -j ACCEPT

# Allow Web Traffic
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Allow Ping (ICMP) - optional, useful for monitoring latency to Oslo
iptables -A INPUT -p icmp -j ACCEPT

# Save rules (CentOS)
service iptables save
service iptables restart

Pro Tip: Be careful with ICMP. Blocking it entirely breaks Path MTU Discovery. Rate limit it if you must, but don't drop it blindly. Stability on the Norwegian internet backbone is generally good, but you want to know if your VPS goes dark.

3. Banish the Brute Force: Fail2Ban

Even with a custom SSH port, bots will find you. Fail2Ban is mandatory. It parses logs (like /var/log/auth.log or /var/log/secure) and dynamically updates iptables to ban IPs that show malicious signs.

Install it via EPEL (CentOS) or apt (Ubuntu). Then configure /etc/fail2ban/jail.local. Never edit jail.conf directly, as updates will overwrite it.

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

This configuration gives an attacker 3 tries before banning them for an hour. It’s simple, efficient, and keeps your CPU from wasting cycles handling failed auth attempts.

4. Data Compliance and Updates

Operating in Norway means respecting Personopplysningsloven (Personal Data Act). The Data Inspectorate (Datatilsynet) is clear: you must secure personal data. Running outdated software is negligence.

Automate your security updates. On Ubuntu 12.04, install unattended-upgrades:

On CentOS, use yum-cron. It minimizes the window of opportunity for exploit kits. Remember, we aren't just protecting the server; we are protecting client data. If you are hosting a database, ensure your my.cnf binds to 127.0.0.1 unless you have a specific, tunneled reason to expose it.

The CoolVDS Advantage: Infrastructure Isolation

Software hardening is useless if the underlying virtualization is leaky. This is why we argue against OpenVZ for security-critical applications. Shared kernels introduce "noisy neighbor" risks and potential kernel-level exploits.

At CoolVDS, we use KVM (Kernel-based Virtual Machine). This provides true hardware virtualization. Your memory is yours. Your kernel is yours. When you run top, you see your load, not the load of the guy next door running a Minecraft server.

We also tackle the physical layer. Our datacenters are equipped with enterprise-grade DDoS protection. While you handle the iptables on your host, we scrub the volumetric attacks at the edge before they even hit your NIC.

Final Thoughts

Security is not a product; it is a process. The commands above are the foundation, not the entire building. Monitor your logs, check your disk I/O, and keep your packages updated.

If you need a hosting environment that respects these technical requirements—low latency connectivity to NIX, pure KVM isolation, and high-speed SSD storage—stop fighting with oversold budget hosts. Deploy a secure instance on CoolVDS today and sleep better tonight.