Linux Server Hardening: The 20-Minute Drill for Norwegian Systems

The Reality of the Public Internet

Let’s cut the marketing fluff. The moment you spin up a new VPS, whether it’s in a datacenter in Oslo or a basement in Frankfurt, it is being scanned. In 2011, we aren't just fighting curious teenagers anymore; we are fighting automated botnets looking for weak SSH passwords and unpatched Apache exploits. I've analyzed `auth.log` files on fresh servers that registered 4,000 failed root login attempts within the first hour of being online.

If you are running a business compliant with the Norwegian Personal Data Act (Personopplysningsloven), relying on default settings is negligence. You need to secure your infrastructure before you even think about deploying your application code. Here is the exact hardening protocol I use for production servers, from high-traffic e-commerce rigs to internal database nodes.

1. SSH: The Front Door

The default OpenSSH configuration is designed for compatibility, not security. We need to change that immediately. The goal here is to disable password authentication entirely and force the use of SSH keys. Passwords can be brute-forced; a 4096-bit RSA key cannot.

First, generate your keys on your local machine (if you haven't already):

ssh-keygen -t rsa -b 4096

Once your public key is on the server (in ~/.ssh/authorized_keys), edit the main configuration file. I recommend using vi or nano to edit /etc/ssh/sshd_config:

# /etc/ssh/sshd_config modifications

# Change the default port to reduce log noise from script kiddies
Port 2222

# ABSOLUTELY NO ROOT LOGIN
PermitRootLogin no

# Disable password auth completely
PasswordAuthentication no
UsePAM no

# Limit who can log in
AllowUsers yourusername

# strict modes
StrictModes yes

Before you restart the service, open a second terminal session and test the connection. If you lock yourself out, you’ll be begging support for console access.

# On CentOS/RHEL 5/6
service sshd restart

# On Debian 6 / Ubuntu 10.04
/etc/init.d/ssh restart

2. Iptables: The Wall

Many sysadmins are afraid of iptables because the syntax is unforgiving. But it is the most robust firewall we have in the Linux kernel today. Forget wrappers; learn the raw commands. We operate on a "Default Drop" policy: if traffic isn't explicitly allowed, it dies.

Here is a standard script I deploy on web servers. It allows SSH, HTTP, HTTPS, and loopback traffic, but drops everything else.

#!/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 existing sessions)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow SSH on our custom port (2222)
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

# Log dropped packets (optional, watch your disk space)
# iptables -A INPUT -j LOG --log-prefix "IPTables-Dropped: "

# Save settings
# CentOS/RHEL:
service iptables save
# Debian/Ubuntu:
iptables-save > /etc/iptables.rules

Pro Tip: Be careful with the `OUTPUT` chain. If you set that to DROP, your server won't be able to run `yum update` or query DNS unless you explicitly allow those outbound ports (80, 443, 53).

3. Fail2Ban: The Bouncer

Even with SSH on a custom port, determined scanners will find it. Fail2Ban scans log files and dynamically updates iptables rules to ban IP addresses that show malicious signs. It is essential for preventing brute-force attacks.

Install it via EPEL (CentOS) or Apt (Debian):

yum install fail2ban

Configure the jail in /etc/fail2ban/jail.local. Never edit jail.conf directly as it gets overwritten on updates.

[DEFAULT]
ignoreip = 127.0.0.1/8
bantime  = 3600
findtime  = 600
maxretry = 3

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

This configuration bans an IP for one hour if they fail to log in 3 times within 10 minutes.

4. Storage Performance and Security Trade-offs

Security logging (auditd, auth logs, web logs) generates significant Disk I/O. On traditional 7.2k SATA drives, I’ve seen heavy logging cause IO_WAIT usage to spike, slowing down the actual application (Magento or Drupal). This is where hardware selection becomes a security feature.

At CoolVDS, we prioritize I/O throughput. While many hosts in Norway are still running older SATA arrays, we utilize enterprise-grade SSD storage in RAID-10 configurations. High-speed storage means your system can write verbose security logs without choking the CPU or delaying the database. When you are under a DDoS attack or a brute-force wave, that extra I/O overhead can be the difference between a server that stays up and one that crashes under the load of its own logs.

5. Keeping it Updated

It sounds obvious, but the number of unpatched CentOS 5 boxes I see is terrifying. Vulnerabilities in the kernel or glibc are discovered monthly. Automate your notifications.

On Debian/Ubuntu systems, install cron-apt to download updates automatically and email you. On CentOS, ensure yum-updatesd is configured, or better yet, run a nightly cron job to check for security errata.

Summary

Security is not a product; it is a process. By locking down SSH, enforcing strict iptables rules, and using Fail2Ban, you eliminate 99% of the noise hitting your server. This allows you to focus on what matters: your application uptime and latency.

If you need a testing ground for these configurations, don't risk your production environment. CoolVDS offers KVM-based virtualization which provides true kernel isolation—unlike OpenVZ containers where a kernel panic affects everyone. Spin up a secure instance in Oslo today and see the difference low latency and SSD speeds make.