Bulletproof Your Box: Essential Linux Server Hardening Guide

It starts the same way every time. You spin up a fresh VPS, go to grab a coffee, and by the time you return, your /var/log/secure is already bleeding red with failed SSH login attempts. The internet of 2010 is not a friendly neighborhood; it’s a constant siege. Whether you are running a high-traffic Magento store or a critical backend for a startup in Oslo, the default settings on your Linux distribution are simply not enough.

I’ve spent the last week cleaning up a compromised RHEL box for a client who thought "security through obscurity" was a valid strategy. It isn't. If your server faces the public web, it is being scanned right now. In this guide, we are going to walk through the essential steps to harden your Linux environment, specifically tailored for CentOS 5.5 and the brand-new Ubuntu 10.04 LTS.

1. Lock the Door: SSH Hardening

The root user is the ultimate prize. Leaving remote root login enabled is like leaving your safe unlocked in the middle of Karl Johans gate. The first thing we do on any CoolVDS deployment is disable password authentication entirely in favor of RSA keys.

Open your config:

Find and modify these lines. If they aren't there, add them:

PermitRootLogin no
PasswordAuthentication no
UseDNS no
AllowUsers your_username

Pro Tip: Setting UseDNS no prevents the SSH daemon from trying to resolve the hostname of the connecting client. This fixes that annoying 10-second lag when you first connect to your server, a common headache we see with residential ISPs in Norway.

After saving, restart the service (service sshd restart on CentOS or service ssh restart on Ubuntu). Do not close your current session until you have verified you can log in with a new terminal window. I've seen too many admins lock themselves out on a Friday afternoon.

2. The Moat: Configuring Iptables

Many providers give you a server with all ports open. While convenient, it’s dangerous. We need to construct a firewall that drops all traffic by default and only allows what is necessary. In 2010, iptables is the standard.

Here is a battle-tested baseline configuration. This script flushes existing rules, sets the default policy to DROP, and opens only SSH (port 22) and Web (80/443).

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]

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

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

# Allow SSH (If you moved ports, change 22 here)
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT

# Allow Web Traffic
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT

# Allow ICMP (Ping) - useful for monitoring latency to NIX
-A INPUT -p icmp -j ACCEPT

COMMIT

Apply it instantly with iptables-restore < /etc/iptables.rules. At CoolVDS, our managed hosting clients get a custom firewall profile pre-applied, but if you are running unmanaged, you must own this configuration.

3. Update or Die

It sounds obvious, but the number of servers I see running kernel versions from 2008 is terrifying. Exploits for the Linux kernel are released regularly. With Ubuntu 10.04 Lucid Lynx just released last month, you have access to a Long Term Support release that will be patched for years.

Run your updates daily. Automate it if you can, but verify critical kernel updates manually.

# CentOS
yum update -y

# Ubuntu
apt-get update && apt-get upgrade

4. Minimize the Attack Surface

A default install of CentOS often includes services you don't need, like sendmail, cups (printing), or xinetd. If you aren't using them, kill them. Every running service is a potential open door.

Check what is running:

Disable the fluff:

5. Filesystem & PHP Security

If you are hosting PHP applications, you are at risk of remote file execution/inclusion attacks. One simple mitigation is to mount your temporary directories with the noexec flag. This prevents scripts from executing in /tmp, a common landing spot for malware scripts.

Edit your /etc/fstab and locate the line for /tmp (or create a loopback file if you don't have a separate partition):

Why Infrastructure Matters: The Norwegian Context

Hardening the OS is half the battle. The other half is where that OS lives. In Norway, we operate under strict privacy standards defined by the Personal Data Act (Personopplysningsloven) and the Datatilsynet.

Hosting your data on a budget VPS in the US might save you a few kroner, but the latency penalties and the legal gray areas of the Safe Harbor framework can cost you more in the long run. Speed is also a security feature—slow sites get abandoned, and slow admin interfaces lead to mistakes.

The Hardware Reality

We built CoolVDS on enterprise-grade hardware RAID 10 arrays. Why? Because I've seen software RAID implode under high I/O load during backup cycles. We use KVM (Kernel-based Virtual Machine) virtualization technology. Unlike OpenVZ, which is popular among budget hosts, KVM provides true hardware isolation. If your neighbor spikes their CPU usage, your kernel doesn't panic. Your memory is yours.

Conclusion

Security is not a "set it and forget it" task; it is an operational discipline. By disabling root logins, tightening your iptables, and stripping unnecessary services, you place yourself ahead of 90% of the targets out there. Hackers are opportunistic—they look for the low-hanging fruit. Don't be the low-hanging fruit.

If you need a stable, low-latency environment to implement these practices, we are ready for you. Our servers are located directly in Oslo with direct peering to NIX, ensuring your ping times are negligible and your data stays within Norwegian jurisdiction.

Ready to lock it down? Deploy a KVM instance on CoolVDS today and get full root access in under 2 minutes.