Linux Server Hardening: The 2010 Survival Guide for Norwegian Sysadmins

Let’s be honest: The moment you spin up a fresh VPS, the countdown starts. It takes less than 15 minutes for a botnet to sniff out port 22 on a public IP. If you are hosting in Oslo or deploying for a client regulated by Datatilsynet, leaving a server exposed isn't just negligent—it’s professional suicide.

I’ve cleaned up enough compromised boxes this year to know the pattern. It’s rarely a sophisticated zero-day; it’s a weak root password or a default SSH configuration. Whether you are running CentOS 5.5 or the new Ubuntu 10.04 LTS, the principles of defense remain the same: reduce the attack surface, ban the noise, and lock the doors.

This isn't a theoretical paper. This is the exact hardening checklist I apply to every CoolVDS instance before it goes into production. We’re talking about securing the perimeter using tools that actually work: IPTables, hardened OpenSSH, and Fail2Ban.

1. The Root Account is Dead. Long Live Sudo.

The first rule of fight club: You do not log in as root. Brute-force scripts target the user `root` because they know it exists. Don't give them the satisfaction.

First, create a user with actual accountability. If you are managing a team, every admin needs their own account. It’s the only way to track who broke the config file at 3 AM.

# useradd -m cooladmin
# passwd cooladmin
# usermod -aG wheel cooladmin  # For CentOS
# usermod -aG sudo cooladmin   # For Debian/Ubuntu

2. SSH: The Front Door

By default, OpenSSH is too polite. It listens to everyone and accepts passwords. We need to turn it into a fortress. We are going to disable password authentication entirely and enforce RSA key pairs.

Generate your keys locally (ssh-keygen -t rsa -b 4096) and push them. Once you have verified you can log in with your key, edit /etc/ssh/sshd_config. This is where most admins get lazy and get hacked.

# /etc/ssh/sshd_config hardening

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

# Disallow root login entirely
PermitRootLogin no

# Maximize authentication attempts to stop heavy brute forcing
MaxAuthTries 3

# Disable passwords. Keys only.
PasswordAuthentication no
PermitEmptyPasswords no

# Restrict users
AllowUsers cooladmin

Warning: Do not restart SSH until you are 100% sure your key works in a new terminal window. I've seen too many people lock themselves out of a remote box.

# /etc/init.d/ssh restart
# OR on CentOS
# service sshd restart

3. IPTables: The Wall

We don't rely on ISP firewalls alone. We use IPTables. It’s granular, it’s robust, and it’s built into the kernel. The logic is simple: Drop everything by default, and only punch holes for what is absolutely necessary.

Here is a baseline configuration script for a web server. Note the explicit drops.

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

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

# Allow loopback (essential for local services like MySQL connection via localhost)
iptables -A INPUT -i lo -j ACCEPT

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

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

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

# Allow ICMP (Ping) - strictly limited to prevent floods
iptables -A INPUT -p icmp -m icmp --icmp-type 8 -m limit --limit 2/second -j ACCEPT

# Save the rules
/sbin/service iptables save

Pro Tip: If you are hosting on CoolVDS, our upstream network filters massive volumetric DDoS attacks, but IPTables is your defense against application-layer scans and unauthorized access attempts.

4. Fail2Ban: The Bouncer

Even with a custom SSH port, persistent bots will find you. Fail2Ban is your automated bouncer. It parses log files (like /var/log/secure or /var/log/auth.log) and updates IPTables to ban IPs that show malicious signs.

Install it via EPEL (CentOS) or Apt (Debian). Then configure /etc/fail2ban/jail.local. Never edit the `.conf` file directly, or you'll lose settings on the next update.

[DEFAULT]
# Ban hosts for one hour
bantime  = 3600

# A host is banned if it has generated "maxretry" during the last "findtime"
findtime  = 600
maxretry  = 3

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

5. Filesystem & Updates

Security is a process, not a product. An unpatched kernel is a vulnerability waiting to be exploited. On CentOS, I run yum update weekly. On Debian, apt-get update && apt-get upgrade.

Furthermore, secure your shared memory. Rootkits often use /tmp or /dev/shm to execute scripts. Mount these with noexec and nosuid options in /etc/fstab.

# Example /etc/fstab entry for shared memory
tmpfs     /dev/shm     tmpfs     defaults,noexec,nosuid     0 0

The CoolVDS Advantage: Infrastructure Integrity

You can harden your OS all day, but if the underlying virtualization is weak, you have problems. Many budget providers pack users onto OpenVZ nodes where kernel exploits can bleed across containers.

This is why CoolVDS utilizes KVM and Xen virtualization. We provide true hardware isolation. When you write to disk on our RAID-10 arrays, your I/O is yours alone. We don't oversell, and we don't gamble with tenant separation.

Final Thoughts

The Norwegian Personal Data Act (Personopplysningsloven) places the burden of security on the data controller. By following these steps—keys for SSH, strict IPTables, and active banning—you aren't just securing a server; you are ensuring compliance and uptime.

Don't wait for the breach. If your current host feels sluggish or insecure, verify your setup on a platform built for professionals. Spin up a secure KVM instance on CoolVDS today and experience the stability of premium infrastructure.