Stop Trusting Default Configurations: A Hardening Guide for 2011

If you are deploying a server in 2011 with default settings, you aren't an admin; you're a victim waiting to happen. We have watched LulzSec and Anonymous tear through "secure" networks all year. Why? Because most systems administrators are lazy. They leave SSH on port 22, they rely on obscurity, and they think a simple password is enough to stop a botnet.

It isn't. Whether you are running a high-traffic Magento store or a backend for a mobile app, the internet is hostile territory. Especially here in Europe, where the latency between a Russian botnet and your Norwegian server is negligible. I've spent the last week cleaning up a client's compromised Wordpress install because they thought admin123 was a valid password strategy. Don't be that guy.

Here is how we lock things down at CoolVDS, and how you should too.

1. Burn the Rope: SSH Hardening

The first thing a bot does is scan port 22. If you are still using password authentication, you are already losing CPU cycles to brute-force attacks, even if they don't get in. We need to switch to keys and move the door.

First, generate a 2048-bit RSA key pair on your local machine. Once that key is on the server, edit your /etc/ssh/sshd_config file immediately.

# /etc/ssh/sshd_config
Port 4422
Protocol 2
PermitRootLogin no
PasswordAuthentication no
UseDNS no
AllowUsers deploymaster

The rationale: Moving the port stops 99% of dumb scripts. Disabling PermitRootLogin ensures that even if they get a password, they can't get god-mode instantly. Disabling UseDNS prevents SSH from trying to resolve the client's hostname, which speeds up login times—critical when you're managing a fleet of servers.

2. The Holy Grail: Netfilter & Iptables

We don't have fancy GUI firewalls that work well yet. We have iptables. It is raw, it is unforgiving, and it is the only thing standing between your kernel and a flood of SYN packets.

Do not just "allow traffic." You need a default DROP policy. If a packet isn't explicitly invited, it dies. Here is the baseline script I drop on every CentOS 6 box I provision:

# Flush existing rules
iptables -F

# Default Policy: DROP everything
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# Allow loopback (critical for local services)
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

# Open SSH (Custom port) and Web
iptables -A INPUT -p tcp --dport 4422 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

Pro Tip: Always run iptables -L -n to verify before you log out. If you mess this up, you'll need KVM console access to fix it. At CoolVDS, we provide out-of-band VNC console access exactly for this reason—because everyone locks themselves out eventually.

3. Virtualization Matters: KVM vs. OpenVZ

Security isn't just about what you do inside the OS; it's about the container you sit in. In the budget hosting world, everyone is pushing OpenVZ. It's cheap because it shares the host kernel. That is a security nightmare. If a vulnerability exists in the host kernel, one tenant can potentially exploit it to affect others. It's the "noisy neighbor" problem on steroids.

This is why we stick to KVM (Kernel-based Virtual Machine) at CoolVDS. KVM provides hardware virtualization. Your memory is your memory. Your kernel is your kernel. If the guy next door gets DDOSed or hacks his own kernel, your instance keeps humming along. For Norwegian businesses dealing with sensitive data under the Personopplysningsloven (Personal Data Act), that isolation is not optional; it's a requirement.

4. Fail2Ban: The Bouncer

Even with a custom SSH port, determined attackers will find you. Fail2Ban is your automated bouncer. It parses log files (like /var/log/secure) and updates your iptables rules dynamically to ban IPs that show malicious signs.

Install it from the EPEL repository:

Then configure /etc/fail2ban/jail.local to be aggressive. I set the ban time to 3600 seconds. If you fail 3 times, go away for an hour.

5. Local Jurisdiction & Data Integrity

Let's talk about the legal side. The US Patriot Act is a major concern for European developers right now. If your data sits on a US-owned server, it is subject to US inspection, period. By hosting in Norway (or strict EU jurisdictions), relying on the EU Data Protection Directive (95/46/EC), you add a legal layer of hardening.

CoolVDS infrastructure is physically located in Oslo. We peer directly at NIX (Norwegian Internet Exchange). This doesn't just lower your latency to 2ms for local users; it keeps your data under Norwegian jurisdiction, supervised by Datatilsynet. That is a selling point your CTO will care about.

Performance Trade-offs

Hardening has a cost. Deep packet inspection or complex firewall rules consume CPU. However, on modern hardware with pure SSD storage (which we are finally rolling out to replace 15k RPM SAS drives), the I/O bottleneck is gone. You can afford the CPU cycles for security.

Don't wait for a breach to take this seriously. Spin up a test instance, apply these rules, and try to break in. If you can't, neither can they.