Linux Server Hardening: The Paranoid Admin's Survival Guide

Let’s be honest: the moment your new VPS IP goes live, it is being scanned. Somewhere in a basement in Eastern Europe or a dorm room in China, a script is already hammering port 22. I’ve seen fresh installs compromised in under 15 minutes because the admin thought they could wait until after lunch to configure the firewall.

If you are deploying critical infrastructure in 2009, obscurity is not security. You need a fortress. Whether you are running a high-traffic Magento store or a backend for a Norwegian bank, the principles remain the same: reduce the attack surface, log everything, and trust no one.

Here is the battle-tested configuration I use on every single CoolVDS instance I deploy. No fluff, just commands that work.

1. SSH: The Front Door

Most breaches happen because of weak passwords on the root account. If you are still logging in as root with a password, you are asking for trouble. We need to switch to SSH keys and disable root login entirely.

Step A: Generate Keys

Do this on your local machine (your laptop), not the server.

ssh-keygen -t rsa -b 4096

Step B: Configure sshd_config

Edit /etc/ssh/sshd_config. Find these lines and change them to reflect the following values. This forces Protocol 2 (which avoids the vulnerabilities in Protocol 1) and kills password authentication.

Protocol 2
PermitRootLogin no
PasswordAuthentication no
UseDNS no
AllowUsers yourusername

Note: Make sure you have created your user and tested the key-based login BEFORE you restart SSH, or you will lock yourself out. I've done it. It’s a long walk to the console.

2. The Firewall: IPTables is Your Best Friend

Many 'managed' hosts give you a fancy control panel firewall. Ignore it. You want control at the kernel level. We use iptables. It’s robust, it’s built into the Linux kernel, and it doesn't waste resources.

Here is a baseline policy. It drops all incoming traffic by default and only opens what is necessary (SSH, HTTP, HTTPS).

# Flush existing rules
iptables -F

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

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

# Allow established connections (so you don't cut yourself off)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow SSH (If you moved ports, change 22)
iptables -A INPUT -p tcp --dport 22 -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)
/sbin/service iptables save

Pro Tip: On CoolVDS instances, we position our Xen hypervisors behind a hardware edge firewall that filters widespread volumetric DDoS attacks. However, application-level filtering via iptables is still your responsibility. Don't rely solely on the network edge.

3. Banning the Bots with Fail2Ban

Even with keys, your logs will fill up with failed login attempts. This wastes CPU cycles and disk I/O. Install Fail2Ban. It scans log files for malicious patterns (like too many password failures) and updates iptables to ban the offender's IP for a set time.

On Debian/Ubuntu:

apt-get install fail2ban

Configure /etc/fail2ban/jail.conf to ban an IP for an hour after 3 failed attempts. It’s satisfying to watch the /var/log/fail2ban.log populate with banned IPs.

4. Minimal Services, Maximum Speed

Every running service is an open port or a potential exploit. On a fresh install, run netstat -tulpn to see what is listening.

Do you need Sendmail listening on port 25 if you aren't a mail server? No. Do you need RPCbind? Likely not. Kill them.

chkconfig sendmail off
chkconfig portmap off
service sendmail stop

This is where the CoolVDS philosophy differs from the budget providers. Many hosts give you a "fat" image loaded with unnecessary control panels and services. We provide minimal, clean OS templates (CentOS 5.4 or Debian Lenny). You start with zero bloat, which means zero zero-day vulnerabilities from software you didn't even know you were running.

5. The Norwegian Context: Data Integrity

If you are hosting data for Norwegian clients, you are bound by Personopplysningsloven. While physical security is our job (our datacenters in Oslo have strict access controls), logical security is yours.

Datatilsynet (The Data Inspectorate) is clear: you must take "appropriate technical measures" to secure personal data. Leaving a MySQL port open to the public internet is technically a violation of due diligence. Always bind MySQL to 127.0.0.1 in your my.cnf unless you have a very specific reason not to.

Conclusion

Security is not a product; it is a process. But starting with a solid foundation makes the process easier. By locking down SSH, configuring strict iptables rules, and using a clean virtualization platform like Xen, you eliminate 99% of the noise.

Don't gamble with your uptime. If you need a rig that respects these standards out of the box—with high-speed RAID-10 storage and low latency to NIX (Norwegian Internet Exchange)—spin up a server with us.

Secure your infrastructure today. Deploy a hardened CoolVDS instance in Oslo.