Lock It Down: Essential Linux Server Hardening in 2009

It is the Wild West out there. If you hook a fresh CentOS 5 server up to a public IP today, logs show brute-force attempts on port 22 within minutes. I’ve seen it happen. I’ve cleaned up the mess after a client left a default root password on a production box. It isn't pretty, and the downtime is expensive.

Whether you are running a high-traffic forum or a critical corporate mail server, security cannot be an afterthought. In the Nordic market, where reliability is currency, a compromised server is a reputation killer. Here is how we harden boxes at the infrastructure level—and how you should configure yours.

1. SSH: The Front Door

Most attacks in 2009 are automated scripts guessing passwords. If you are still logging in as root with a password, you are asking for trouble. Key-based authentication is not optional anymore; it is mandatory for sanity.

Open your config:

vi /etc/ssh/sshd_config

Make these changes immediately:

• Protocol 2: Ensure you aren't supporting the vulnerable Protocol 1.
• PermitRootLogin no: Create a sudo user. Log in as them. Elevate only when needed.
• PasswordAuthentication no: Use RSA keys. Period.

Pro Tip: Move SSH off port 22. It’s security through obscurity, sure, but changing it to something like 2299 drops log noise by 99% because most bots are hardcoded to scan default ports. Just remember to allow it in your firewall first!

2. The Firewall: iptables is Your Best Friend

We don't have fancy GUI firewalls on bare-metal servers. We have iptables. It is rugged, fast, and does exactly what you tell it to. A default policy of DROP is the only acceptable setting.

Here is a baseline script for a web server:

# Flush defaults
iptables -F

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

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

# Allow established connections (crucial!)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow SSH (If you changed the port, use that here)
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
/etc/init.d/iptables save
/etc/init.d/iptables restart

3. Fail2Ban: The Bouncer

Even with keys, you don't want logs filled with failed attempts. Fail2Ban (currently version 0.8.4) scans log files and bans IPs that show malicious signs.

On a CoolVDS Debian instance, it's a quick install:

apt-get install fail2ban

Configure it to jail repeat offenders for an hour. It saves CPU cycles that should be used for serving PHP, not rejecting handshakes.

4. Services: If You Don't Use It, Kill It

Default installs of Red Hat or Debian often come with baggage. Sendmail, FTP, or rpcbind might be running. If you are only serving HTTP, why is an FTP daemon listening?

Run netstat -tulpn to see what is listening. Stop the service, then remove it from startup:

chkconfig sendmail off
chkconfig portmap off

5. The Hardware Factor: Isolation Matters

Software hardening is useless if your neighbor crashes the kernel. This is the dirty secret of cheap VPS hosting: Overselling.

Many providers pack hundreds of containers (OpenVZ) onto a single host. If one user gets DDoS'd, the whole node chokes. Security is also about availability.

At CoolVDS, we lean heavily on Xen virtualization. It provides strict resource isolation. Your RAM is yours. Your swap is yours. Combined with our enterprise 15k RPM SAS RAID-10 arrays, you get I/O performance that doesn't tank when another user runs a backup script. In 2009, disk I/O is usually the bottleneck; do not settle for a single SATA drive.

6. Local Compliance: The Norwegian Advantage

Hosting in Norway isn't just about latency to Oslo (though <5ms is nice). It is about the Personopplysningsloven (Personal Data Act). Data stored within Norwegian borders falls under strict privacy protections, distinct from US-centric Safe Harbor agreements.

For our clients handling sensitive data, keeping the physical bits in our Oslo datacenter simplifies compliance with the EU Data Protection Directive significantly.

Summary Checklist

Security is a process, not a product. But starting on the right foundation—clean configs and isolated hardware—puts you ahead of 90% of the targets out there.

Need a sandbox to test your iptables rules? Deploy a CoolVDS Xen instance in Oslo today. Real hardware isolation, no noisy neighbors.