Linux Server Hardening: Stop Relying on Luck

I logged into a fresh server yesterday—one that had been online for exactly 45 minutes. The /var/log/secure file was already 2MB in size. Thousands of brute-force attempts from IPs in China and Eastern Europe were hammering port 22. If you are deploying a server in 2010 without an immediate lockdown strategy, you aren't an admin; you're a victim in waiting.

Whether you're running a high-traffic forum on vBulletin or a critical Magento storefront, the threat landscape has shifted. We aren't just dealing with curious hackers anymore; we're dealing with automated botnets hunting for weak passwords and unpatched exploits. Here is how I secure every box I deploy, specifically tailored for the Norwegian market where Datatilsynet (The Data Inspectorate) takes a dim view of data breaches.

1. SSH: The Front Door Must Be Reinforced

The default configuration of OpenSSH on most distributions (even CentOS 5.4 or Debian Lenny) is too permissive. Your first task is to edit /etc/ssh/sshd_config. Do not delay.

We need to disable root login and switch to SSH keys. Passwords are a liability. If you are still typing a password to manage your server, you are doing it wrong.

# /etc/ssh/sshd_config

# Force Protocol 2 to avoid legacy vulnerabilities
Protocol 2

# Disable root login immediately
PermitRootLogin no

# Turn off password authentication completely
PasswordAuthentication no
UsePAM no

# Change the default port to reduce log noise (Security by Obscurity, but helpful)
Port 2222

Restart the service with /etc/init.d/sshd restart. Now, anyone trying to brute force 'root' on port 22 will hit a wall.

Pro Tip: At CoolVDS, our default templates for CentOS and Ubuntu come with a clean slate. We don't pre-install bloat that opens ports. You get a minimal OS, exactly how a sysadmin wants it. That's why serious devs prefer our KVM slices over overloaded shared hosting.

2. IPTables: The Iron Wall

Many admins are intimidated by iptables. They rely on TCP Wrappers (/etc/hosts.allow) and think that's enough. It's not. You need stateful inspection.

Here is a baseline rule set that drops everything by default and only allows what is necessary. This is the "deny all" strategy.

# Flush existing rules
iptables -F

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

# Allow loopback
iptables -A INPUT -i lo -j ACCEPT

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

# Allow SSH (Make sure this matches your config!)
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

# Allow Ping (ICMP) for monitoring, with limits to stop floods
iptables -A INPUT -p icmp -m limit --limit 1/s -j ACCEPT

Save this configuration. On RedHat/CentOS systems, use /sbin/service iptables save.

3. Automating Defense with Fail2Ban

Even with keys and a custom port, your logs will fill up. Fail2Ban is mandatory software in my arsenal. It scans log files (like /var/log/auth.log) and bans IPs that show malicious signs by updating your iptables rules dynamically.

Install it via EPEL (for CentOS) or apt (for Debian). Configure the jail for SSH:

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

This simple tool drastically reduces the load on your CPU caused by processing thousands of failed handshake attempts. In a virtualized environment, CPU cycles are money. Don't waste them on bots.

4. The Norwegian Context: Compliance & Latency

Hosting in Norway isn't just about speed; it's about the law. Under the Personal Data Act (Personopplysningsloven), you have a responsibility to secure personal data. If you are hosting customer data on a cheap server in Texas, you are creating a legal headache for your company.

Furthermore, latency to the NIX (Norwegian Internet Exchange) in Oslo is critical. If your target audience is in Scandinavia, why route packets through Frankfurt?

Why Infrastructure Matters

Software hardening helps, but hardware stability is the foundation. Many budget VPS providers oversell their nodes, leading to "I/O wait" spikes that look like DDoS attacks but are actually just your neighbors hogging the disk.

This is where CoolVDS takes a different stance. We utilize enterprise-grade RAID-10 SAS storage (and are currently testing High-Performance SSDs for upcoming plans). We don't oversell RAM. When you run top on a CoolVDS instance, the resources you see are yours.

Final Thoughts

Security is not a "set it and forget it" task. It is a process. But by locking down SSH, configuring a strict firewall, and hosting on reliable infrastructure within Norwegian borders, you eliminate 99% of the risk.

Don't wait for the breach notification from Datatilsynet. Secure your infrastructure today.

Need a test environment? Deploy a hardened CentOS 5 VPS on CoolVDS in under 2 minutes and experience the difference of local Norwegian peering.