Linux Server Hardening: The 2009 Survival Guide for Norwegian Systems

Let's be honest. The moment you spin up a new VPS, it starts bleeding. I deployed a vanilla CentOS 5 box last Tuesday, and within 14 minutes, /var/log/secure was flooded with brute-force attempts from an IP block in Shenzhen. If you are running a business in Norway, you can't afford this exposure.

It's not just about uptime; it's about the Personopplysningsloven (Personal Data Act). The Datatilsynet (Norwegian Data Protection Authority) does not accept "we got hacked" as a valid excuse for losing customer data. If you are handling data for Nordic clients, negligence is a legal liability.

This isn't a theoretical guide. This is the exact hardening checklist I use for every CoolVDS production node before it touches the public internet. Grab your coffee. Let's lock this down.

1. SSH: The Front Door Problem

Running SSH on port 22 is like leaving your house keys taped to the front door. It’s the first place scripts look. We need to obscure it and lock out the root user.

Edit your configuration:

Change these lines immediately:

Port 4922  # Or any random high port not in use
Protocol 2
PermitRootLogin no
UseDNS no
AllowUsers yourusername

Why Protocol 2? SSH-1 has inherent design flaws. Do not support legacy clients. By disabling PermitRootLogin, you force an attacker to guess two things: your custom username AND your password (or key). It doubles the complexity of the attack.

Pro Tip: Use DSA or RSA keys with a passphrase. Password authentication is for amateurs. Generate your keys with ssh-keygen -t dsa and disable PasswordAuthentication in the config once you have verified access.

2. Iptables: The Great Wall

We don't have fancy cloud firewalls that wrap around the instance yet. You live and die by iptables. Most default installs allow all traffic. That is unacceptable.

Here is a battle-tested policy. We drop everything by default and only open what is necessary.

# Flush existing rules
iptables -F

# Default policies: Block everything
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# Allow loopback (critical for local services like MySQL)
iptables -A INPUT -i lo -j ACCEPT

# Keep established connections alive
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow SSH (on your new custom port)
iptables -A INPUT -p tcp --dport 4922 -j ACCEPT

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

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

If you are on Debian 5 (Lenny), you might need to save these to a file and load them via /etc/network/interfaces using pre-up commands. Do not lock yourself out. Test the rules before saving.

3. Automated Intrusion Prevention

Even with a custom port, persistent bots will find you. You need software that watches logs and bans IPs dynamically. Fail2Ban is the standard here. It parses log files (like /var/log/auth.log or /var/log/secure) and updates iptables rules to ban offending IPs for a set time.

Install it via EPEL repo on CentOS or Apt on Debian. Configure jail.conf to ban an IP for 3600 seconds after 3 failed SSH attempts. It keeps the log noise down and saves CPU cycles.

4. The Hardware Factor: Performance vs. Security

Security has a cost. Encryption (SSL/SSH) and packet inspection consume CPU. Running strict iptables rules on a heavily loaded web server can introduce latency.

This is where the underlying infrastructure matters. At CoolVDS, we have noticed that virtualization overhead is the silent killer. Many providers in the Nordic market are overselling their CPU cores using OpenVZ, leading to "steal time" effectively pausing your security daemons.

Virtualization Comparison for Security Ops

We stick to KVM and Xen. If a neighbor on the node gets DDoS'd or compromised, your kernel remains isolated. Plus, with the new SAS 15k RAID-10 arrays we deployed in the Oslo datacenter, the I/O bottleneck for writing security logs is virtually non-existent.

5. Keep It Lean

The more software you have installed, the wider your attack surface. Do you need X11 forwarding? No. Do you need Samba on a public web server? Absolutely not.

Run this command to see what is listening:

If you see a service you don't recognize, kill it. Remove the package. Every open port is a potential exploit vector for the next zero-day vulnerability.

Final Thoughts

Hardening is not a "set and forget" task. New vulnerabilities are discovered daily. Just last year we saw the Debian OpenSSL debacle. You must subscribe to your distribution's security mailing list.

However, starting with a secure foundation is half the battle. If you need a rig that gives you full kernel control for advanced iptables modules and low latency to the Norwegian IX (NIX), give our CoolVDS Xen instances a spin. We provide the raw power; you provide the paranoia.

Stay safe out there.