Linux Server Hardening: The 2012 Survival Guide for Norwegian Systems

Let’s be honest. If you just spun up a fresh VPS and left it running with default settings on port 22, it’s already being scanned. By the time you finish reading this paragraph, a botnet from halfway across the globe has likely tried to brute-force your root password three times. Security isn't a feature you toggle on; it is a constant state of paranoia.

I recently audited a client's setup—a media agency in Oslo dealing with sensitive client data. They were running a vanilla CentOS 5 box with password authentication enabled. It wasn't a matter of if they would get owned, but when. We locked it down, but it reminded me that too many admins in Norway still trust "security by obscurity." That doesn't work when automated scripts are knocking on every IP in the subnet.

This guide isn't for the hobbyist. This is for the systems administrator who needs to sleep at night knowing their infrastructure won't be part of a DDoS botnet by morning. We are going to lock down a Linux VPS (CentOS 6 / Debian 6 Squeeze standard) until it is tighter than a bank vault.

1. The SSH Fortress: Keys Only, No Root

The first rule of server club: You do not log in as root. The second rule: You never use passwords. Passwords can be brute-forced; 4096-bit RSA keys generally cannot.

First, generate your keys locally if you haven't already:

ssh-keygen -t rsa -b 4096

Once your public key is on the server (in ~/.ssh/authorized_keys), we need to eviscerate the SSH configuration. Edit /etc/ssh/sshd_config. Do not just skim this; implementing these specific flags is mandatory for any machine facing the public internet.

# /etc/ssh/sshd_config

# Change the default port to reduce log noise (security through obscurity, but helpful)
Port 2022

# Protocol 2 is the only secure option in 2012
Protocol 2

# Absolutely no root login
PermitRootLogin no

# Disable password authentication entirely
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no

# Limit who can log in
AllowUsers yourusername

After saving, restart the service. On CentOS 6:

service sshd restart

Pro Tip: Before you close your current terminal session, open a new terminal window and try to connect. If you messed up the config, you don't want to lock yourself out. I've seen senior admins drive to the datacenter at 3 AM because they forgot to add their user to AllowUsers.

2. The Firewall: iptables is Your Best Friend

Many providers give you a hardware firewall, but you should never rely solely on the perimeter. Host-level security is critical. In 2012, iptables is the standard. It is raw, it is unforgiving, and it works.

We want a "Default Drop" policy. This means if traffic isn't explicitly allowed, it dies. Here is a baseline script to flush existing rules and set up a stateful firewall.

# Flush old rules
iptables -F

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

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

# Accept established connections (keep your SSH session alive!)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow SSH on your custom port
iptables -A INPUT -p tcp --dport 2022 -j ACCEPT

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

# Save settings (CentOS/RHEL)
/sbin/service iptables save

This configuration creates a silent server. Pings will timeout, and unauthorized ports won't send a "Connection Refused" message; they will simply vanish into the void. This increases the time it takes for an attacker to scan your host significantly.

3. Banning the Bots: Fail2Ban

Even with keys, your logs will fill up with failed attempts on open ports. Install Fail2Ban. It parses logs (SSH, Apache, FTP) and dynamically updates iptables to ban the offending IP address for a set period.

On Debian/Ubuntu:

apt-get install fail2ban

Configure /etc/fail2ban/jail.local. Here is a strict configuration for SSH:

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

If someone hits your custom SSH port incorrectly three times, they get a one-hour timeout. It keeps the logs clean and reduces load.

4. Shared Memory and Network Stack Hardening

Attacks aren't just about ports; they are about memory and stack overflows. We can secure the shared memory segment /dev/shm to prevent exploits from executing scripts there.

Add this line to your /etc/fstab:

tmpfs     /dev/shm     tmpfs     defaults,noexec,nosuid     0     0

Then remount it:

mount -o remount /dev/shm

Next, let's tune the kernel via /etc/sysctl.conf to prevent common network attacks like SYN floods and IP spoofing.

# /etc/sysctl.conf

# Ignore ICMP broadcast requests
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Disable Source Packet Routing
net.ipv4.conf.all.accept_source_route = 0

# Enable TCP SYN Cookie Protection
net.ipv4.tcp_syncookies = 1

# Log Spoofed Packets
net.ipv4.conf.all.log_martians = 1

Apply these with sysctl -p. These tweaks are essential for any high-performance hosting environment where low latency is a priority.

5. The Norwegian Context: Datatilsynet & Jurisdiction

We operate in Norway. That means we answer to the Datatilsynet (Data Inspectorate) and the Personal Data Act (Personopplysningsloven). Unlike hosting in the US, where the Patriot Act allows broad data access, Norwegian hosting offers strict privacy protections.

However, compliance is a two-way street. Your provider secures the physical layer, but you secure the data. If you are storing customer data (names, emails, payment info) on a server without encryption or proper access controls, you are liable. Ensuring your server is physically located in Oslo (as all CoolVDS servers are) reduces latency for your Norwegian users to negligible milliseconds, but it also ensures data sovereignty. Your data stays within the EEA.

Why The Underlying Hypervisor Matters

Software hardening is useless if the virtualization layer leaks. In 2012, many budget hosts are still pushing OpenVZ. OpenVZ uses a shared kernel. If a vulnerability is found in the host kernel, every single container on that node is potentially compromised. It creates a "noisy neighbor" problem where one user's load kills your I/O performance.

This is why at CoolVDS, we use KVM (Kernel-based Virtual Machine). KVM provides full hardware virtualization. Your kernel is your kernel. Your memory is allocated strictly to you. From a security standpoint, the isolation is far superior. If you are serious about security, you don't share your kernel.

Summary Checklist

Security is an iterative process. Update your packages daily (yum update or apt-get upgrade). Monitor your logs. And choose a platform that respects data integrity.

Don't risk your data on shared kernels or unhardened boxes. Deploy a secure, KVM-based instance in Oslo on CoolVDS today and get the isolation your architecture demands.