Fortifying the Castle: Essential Linux Server Hardening for 2012

If you have been watching the headlines this year, from the Sony hacks to the chaos caused by LulzSec, one thing is clear: obscurity is dead. If you deploy a default install of CentOS 6 or Debian Squeeze to the public web, you aren't just taking a risk; you are volunteering to be part of a botnet.

I’ve seen too many systems administrators—especially here in the Nordics where we tend to trust a bit too much—leave port 22 wide open to the world. Last month, I audited a client's server in Oslo that was being hammered by 4,000 brute-force attempts an hour. It wasn't a matter of if they would get in, but when.

Security isn't a product you buy; it's a process you adhere to. Whether you are running a high-traffic e-commerce site compliant with the Norwegian Personal Data Act (Personopplysningsloven) or a simple dev box, these are the steps you need to take immediately after provisioning.

1. The Keys to the Kingdom: SSH Hardening

The root user is the ultimate prize. The first rule of battle: remove the target. Never log in as root directly. Create a sudo-privileged user and lock the front door.

Disable Root Login & Password Auth

Passwords are weak. RSA keys are strong. Generate a 2048-bit (or 4096-bit if you’re paranoid like me) key pair on your local machine.

Once you've pushed your public key to the server, edit your /etc/ssh/sshd_config. Do not leave these defaults active:

PermitRootLogin no
PasswordAuthentication no
UseDNS no
AllowUsers yourusername

Pro Tip: Move your SSH port off 22. It’s security through obscurity, yes, but it reduces log noise by 99%. I usually pick something in the 40000-60000 range. Just remember to allow it in your firewall before you restart SSH, or you'll be locking yourself out. Again.

2. The Shield: Configuring iptables

Many VPS providers give you a raw connection. It’s pure, but it’s dangerous. While some people are starting to play with `ufw` on Ubuntu, knowing raw `iptables` syntax is mandatory for any serious admin.

Here is a baseline policy. We drop everything by default and only allow what is necessary. This is a "Whitelisting" 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 (essential for local services like MySQL)
iptables -A INPUT -i lo -j ACCEPT

# Allow established connections (so you don't cut your own SSH session)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow SSH (If you changed the port, use that number 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 (CentOS/RHEL way)
service iptables save

3. The Watchman: Fail2Ban

Even with keys and custom ports, bots will probe you. Fail2Ban is your automated bouncer. It scans log files (like /var/log/secure) and updates iptables to ban IPs that show malicious signs—too many password failures, searching for exploits, etc.

Install it via EPEL on CentOS or apt on Debian. The default configuration in jail.conf is decent, but I recommend increasing the bantime. 600 seconds (10 minutes) is a slap on the wrist. I set mine to 3600 or even 86400 (24 hours).

4. Service Minimization

Every running service is a potential vector. Do you need Sendmail listening on port 25 if you use an external SMTP relay? Do you need RPC bind? If you aren't using it, kill it.

Run netstat -tulpn to see what is listening. If you see something you don't recognize, investigate it and shut it down.

The Virtualization Factor: KVM vs. The Rest

Software hardening only goes so far if the foundation is shaky. This is where architecture matters.

In the hosting market, you see a lot of cheap OpenVZ containers. The problem? You are sharing the kernel with every other customer on that node. If there is a kernel panic or a kernel-level exploit, everyone goes down. It's also harder to tweak kernel parameters (sysctl) for security hardening because you don't own the kernel.

This is why at CoolVDS, we standardized on KVM (Kernel-based Virtual Machine). It provides true hardware virtualization. Your OS is yours. Your kernel is yours. It provides a level of isolation that satisfies even the strict requirements of Datatilsynet here in Norway. When you couple that with our local storage arrays—moving away from spinning rust to high-performance SSD caching—you get security without the I/O bottleneck.

5. Updates and Vigilance

Finally, set up a cron job for updates, or at least subscribe to the security mailing lists for your distribution. A hardened server in December 2011 is vulnerable in January 2012 if you miss a patch for Apache or OpenSSL.

Security is a trade-off between convenience and paranoia. We lean towards the latter. If you need a rig that respects that philosophy—with low latency connectivity to the NIX exchange in Oslo—it’s time to upgrade.

Ready to lock it down? Deploy a KVM instance on CoolVDS today and start with a secure foundation.