Stop Trusting Default Configs: A Survival Guide for 2011

Let’s be honest: the internet has become a hostile environment. If you tail your authentication logs on a public-facing server for just five minutes, you will see the swarm. Script kiddies, automated botnets, and brute-force scanners are hammering port 22 before your OS installation is even cold. With the release of Debian 6.0 (Squeeze) just four days ago, many of you are spinning up fresh instances. That’s great, but a fresh install is not a secure install.

I’ve cleaned up enough compromised web servers to know that 90% of breaches aren't sophisticated zero-days; they are lazy administrators leaving PermitRootLogin yes in their config files. Security isn't a product you buy; it's a process you execute. Here is how we lock down boxes at the infrastructure level, the same way we secure the host nodes at CoolVDS.

1. The Keys to the Kingdom (SSH)

The first thing you do—before you install Apache, before you set up MySQL—is secure your remote access. Passwords are dead. If you are still typing a password to log into your server, you are one dictionary attack away from losing your data.

Edit your /etc/ssh/sshd_config. We need to disable the root login and enforce key-based authentication. Also, verify you aren't supporting the legacy, broken SSH Protocol 1.

# /etc/ssh/sshd_config
Protocol 2
PermitRootLogin no
PasswordAuthentication no
UseDNS no
AllowUsers yourusername

Pro Tip: Moving SSH to a non-standard port (like 2222) is often cited as "security through obscurity." While it doesn't stop a determined hacker, it does keep your logs cleaner by filtering out the dumbest automated scripts. It’s worth the 30 seconds of effort.

2. The Firewall: Learn to Love IPTables

There is no fancy GUI here. We are using iptables. It is robust, it is built into the kernel, and it works. The default policy for INPUT should always be DROP. If you don't explicitly allow it, it shouldn't get in.

Here is a baseline configuration for a standard web server. Note that we are explicit about allowing loopback traffic—forgetting that will break local services like MySQL communicating with Apache.

# Flush existing rules
iptables -F

# Default policies
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

# SSH (Adjust port if you changed it)
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# Web traffic
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Save rules (RHEL/CentOS)
/sbin/service iptables save

3. Minimize the Attack Surface

Every running service is an open door. Do you need Sendmail running if you aren't processing mail locally? Do you need RPC bind? On a standard CoolVDS instance, we strip the OS image down to the bare essentials, but packages sneak in.

Check what is running at startup:

# CentOS / RHEL
chkconfig --list | grep '3:on'

# Debian / Ubuntu
service --status-all

Disable anything you don't recognize or need. If you are running a database server, it shouldn't be listening on a public IP unless absolutely necessary. Bind MySQL to 127.0.0.1 in your my.cnf.

4. Data Sovereignty and the Norwegian Advantage

Security isn't just about packet filtering; it's about legal jurisdiction. In light of the Data Retention Directive discussions in the EU, knowing physically where your data sits is paramount.

Hosting in Norway offers a distinct advantage due to the strong stance of Datatilsynet (The Data Inspectorate) and the Personal Data Act. Unlike hosting in the US where the Patriot Act can compel data disclosure, servers located in our Oslo facility operate under strict Norwegian privacy laws. For our clients handling sensitive data, this legal layer is as critical as the firewall.

The Hardware Factor: Why Virtualization Matters

Software hardening can be rendered useless if your virtualization platform is weak. Many budget providers use OpenVZ, where kernels are shared. If the host kernel has a vulnerability, your container is at risk.

This is why CoolVDS bets heavily on KVM (Kernel-based Virtual Machine). It provides true hardware virtualization. Your RAM is allocated, your disk I/O is isolated, and your kernel is your own. Combine that with our RAID-10 Enterprise SSD setups, and you get a platform that is secure by design and fast by default.

5. Keep It Updated

It sounds obvious, yet it is the most common failure. Subscribe to the security mailing lists for your distribution (CentOS-announce or Debian-security-announce). When a kernel patch drops, apply it.

yum update or apt-get upgrade should be part of your weekly ritual. Automated tools are great, but a human eye ensures an update doesn't deprecate a library your application depends on.

Final Thoughts

A hardened server is a quiet server. By disabling root logins, configuring tight IPTables rules, and choosing a host that respects data sovereignty, you reduce your risk profile drastically. Don't wait for the breach to happen.

Ready to deploy on a platform that takes security as seriously as you do? Spin up a KVM instance on CoolVDS today and experience the stability of Norwegian infrastructure.