Stop Giving Script Kiddies Root Access: A 2012 Survival Guide

I watched a fresh CentOS 6 installation get compromised exactly 14 minutes after it went live on a public IP last Tuesday. No targeted attack, no corporate espionage—just an automated botnet scanning the entire IPv4 range for default passwords. If you think your obscure project isn't a target, you are wrong. In the current landscape, with tools like Armitage making hacking accessible to anyone, security by obscurity is a death sentence.

This isn't about paranoia; it's about uptime. When your server becomes a zombie in a DDoS botnet, your legitimate traffic dies, and your IP gets blacklisted. Here is the exact hardening protocol I use for every node we deploy, tailored for the strict privacy standards we value here in Norway.

1. The SSH Lockdown

The default OpenSSH configuration is too permissive. We need to cut off the most common attack vector: password authentication on Port 22.

Step A: Keys Only, No Passwords

Passwords can be bruteforced. 4096-bit RSA keys cannot—at least not before the heat death of the universe. Generate your keypair locally:

Once you have pushed your public key to ~/.ssh/authorized_keys on the server, edit the daemon config. We are also going to disable Protocol 1, which is fundamentally broken.

File: /etc/ssh/sshd_config

# Force Protocol 2 only
Protocol 2

# Disable root login. Login as a user, then su/sudo up.
PermitRootLogin no

# Disable password auth completely
PasswordAuthentication no
UsePAM no

# Change the default port to reduce log noise from automated scanners
Port 2244

Restart the service to apply changes. On CentOS 6:

Pro Tip: Always keep an active SSH session open when restarting sshd. Open a new terminal window and try to connect before closing your current one. If you locked yourself out, you still have the active session to fix it.

2. IPTables: The First Line of Defense

Many sysadmins rely on their hosting provider's firewall. That is a mistake. You want host-level filtering. In 2012, iptables is still the undisputed king of packet filtering. We want a "Default Drop" policy—everything is forbidden unless explicitly allowed.

Here is a tight ruleset for a web server:

# 1. Flush existing rules
iptables -F

# 2. Allow loopback traffic (critical for local services like MySQL)
iptables -A INPUT -i lo -j ACCEPT

# 3. Allow established connections (so you don't cut yourself off)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# 4. Allow SSH (on our custom port 2244)
iptables -A INPUT -p tcp --dport 2244 -j ACCEPT

# 5. Allow HTTP and HTTPS
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# 6. Drop everything else
iptables -P INPUT DROP
iptables -P FORWARD DROP

Don't forget to save these rules, or they will vanish on reboot:

3. Ban The Bots with Fail2Ban

Even with keys, you don't want your logs flooded with authentication attempts. Fail2Ban parses logs (like /var/log/secure) and dynamically updates iptables to ban IPs that show malicious behavior.

Install it via EPEL repo on CentOS:

Configure a jail in /etc/fail2ban/jail.local. Do not edit jail.conf directly, as updates will overwrite it.

[ssh-iptables]
enabled  = true
filter   = sshd
action   = iptables[name=SSH, port=2244, protocol=tcp]
logpath  = /var/log/secure
maxretry = 3
bantime  = 3600

This creates a penalty box. If someone fails to login 3 times, they are locked out for an hour. It dramatically reduces the noise on your network interface.

4. Secure Shared Memory

A common exploit technique involves writing malicious code to /dev/shm (shared memory). By default, this is mounted as read/write/execute. We need to mount it with noexec and nosuid to prevent scripts from running there.

Edit your /etc/fstab file and find the line for /dev/shm. Change it to look like this:

Remount it immediately without rebooting:

The Hardware Factor: Isolation Matters

Software hardening is useless if your neighbor on the physical server brings the kernel down. This is the hidden danger of OpenVZ containers—they share a single kernel. If a vulnerability is found in the host kernel, every container is at risk.

This is why at CoolVDS, we exclusively use KVM (Kernel-based Virtual Machine) virtualization. KVM provides true hardware virtualization. Your memory, your CPU, and most importantly, your kernel are isolated.

Norwegian Privacy & Latency

Hosting physically in Norway isn't just about latency to the NIX (Norwegian Internet Exchange) in Oslo—though seeing ping times drop below 3ms is satisfying. It is about sovereignty. Under the Personopplysningsloven (Personal Data Act) and Datatilsynet regulations, knowing exactly where your data sits is becoming critical for compliance. European businesses cannot afford to throw data onto a generic US cloud bucket without considering the legal ramifications.

Final Thoughts

Security is an iterative process. Today it's iptables; tomorrow it might be patching a new vulnerability in Apache. But by implementing these baseline locks, you raise the bar high enough that 99% of automated attackers will move on to an easier target.

Don't gamble with shared kernels and spinning rust. If you need a secure, isolated environment to test these configurations, deploy a KVM instance on CoolVDS. We offer pure SSD storage and the stability your infrastructure demands.