Paranoia is a Virtue: The 2011 Guide to Locking Down Your Linux VPS

Let’s be honest: if you leave a server connected to the internet on port 22 with a default root password, it belongs to a botnet within 14 minutes. I’ve timed it. 2011 has been a wake-up call for the industry—from the LulzSec rampages to the constant barrage of script kiddies scanning IP ranges in Scandinavia. Whether you are running a high-traffic e-commerce rig or a backend for a mobile app, security isn't a feature; it is the baseline requirement for survival.

I see too many developers spinning up virtual machines, installing Apache, and thinking they are done. That is negligence. In this guide, we are going to strip down a Linux server (CentOS 6 / Debian 6 Squeeze) and rebuild its defenses. We aren't just talking about changing passwords; we are talking about kernel-level discipline and packet filtering.

1. The SSH Gatekeeper: If They Can't Enter, They Can't Win

The first thing I do on any fresh VPS Norway deployment is decapitate the root login. Using the root user for daily tasks is suicide. You need a limited user with sudo privileges. Furthermore, passwords are a relic of the past for server access. We use 2048-bit RSA keys.

Step A: Create the User

# useradd -m cooladmin
# passwd cooladmin
# usermod -aG wheel cooladmin  # For CentOS
# usermod -aG sudo cooladmin   # For Debian

Step B: Enforce Key Authentication

Edit your sshd config. Don't use nano if you want respect; learn vi.

# vi /etc/ssh/sshd_config

Find and modify these lines. This disables root login and forces key-based auth, rejecting all password attempts.

PermitRootLogin no
PasswordAuthentication no
UsePAM no
AllowUsers cooladmin
Port 4422

Pro Tip: Moving SSH to a non-standard port (like 4422) isn't "true" security (it's obscurity), but it reduces your log noise by 99%. It keeps the logs clean so you can see the real threats. Just remember to open that port in your firewall before you restart SSH!

2. The Firewall: IPTables is Your Best Friend

Many providers give you a raw connection. It is your job to filter the filth. In 2011, iptables is the standard. It is robust, low-overhead, and granular.

Here is a battle-tested ruleset I use for web servers. It drops everything by default—a whitelist approach is always superior to a blacklist approach.

# Flush existing rules
iptables -F

# Set default chain policies to DROP
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# Accept traffic on localhost (loopback)
iptables -A INPUT -i lo -j ACCEPT

# Allow established connections (keep my SSH session alive!)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow SSH (New Port 4422)
iptables -A INPUT -p tcp --dport 4422 -j ACCEPT

# Allow Web Traffic (HTTP/HTTPS)
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Save rules
/sbin/service iptables save

If you are running a database like MySQL, keep it bound to 127.0.0.1. There is zero reason for port 3306 to be exposed to the public internet unless you are asking for a SQL injection disaster.

3. Banning the Brute Force: Fail2Ban

Even with keys, you don't want bots hammering your SSH port. Fail2Ban scans log files (like /var/log/secure) and updates iptables rules to ban IPs that show malicious signs.

Install it immediately:

# yum install fail2ban -y

Configure a jail in /etc/fail2ban/jail.local:

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

This creates an automated defense layer. If someone messes up 3 times, they are in the penalty box for an hour. It saves CPU cycles and keeps your auth logs readable.

4. The CoolVDS Factor: KVM vs. OpenVZ

Security isn't just about software; it's about architecture. A lot of cheap hosts oversell resources using OpenVZ. In OpenVZ, you share the kernel with every other customer on the node. If there is a kernel exploit, isolation can be broken.

This is why at CoolVDS, we standardize on KVM (Kernel-based Virtual Machine). With KVM, you have your own isolated kernel. It acts more like a dedicated server. For serious managed hosting environments, particularly when handling sensitive data subject to the Norwegian Personal Data Act (Personopplysningsloven), this isolation is non-negotiable.

5. Local Context: Latency and Law

Why host in Norway? Two reasons: Latency and Legality.

If your user base is in Oslo or Bergen, hosting in Germany or the US adds unnecessary milliseconds. Physics is physics. Hosting locally means your packets hit the NIX (Norwegian Internet Exchange) faster. In our benchmarks, a ping from Oslo to a CoolVDS instance averages under 2ms. Compare that to 30ms+ for continental Europe.

Secondly, Datatilsynet (The Norwegian Data Inspectorate) is strict. Under the current implementation of the EU Data Protection Directive (95/46/EC), keeping Norwegian customer data within national borders simplifies your compliance burden significantly. Don't risk exporting sensitive data to jurisdictions with questionable privacy protections.

6. Filesystem Hardening

One final trick. The /tmp directory is a favorite playground for hackers to upload and execute scripts. We can stop this by mounting it with the noexec flag.

Add this to your /etc/fstab (assuming you have a separate tmp partition, which you should):

/dev/mapper/VolGroup-lv_tmp /tmp ext4 defaults,noexec,nosuid 0 0

Remount it live:

mount -o remount,noexec,nosuid /tmp

Now, even if they upload a malicious script, they can't run it. Simple. Effective.

Conclusion

Security is a process, not a product. But starting with a solid foundation—strong keys, a tight firewall, and the right virtualization technology—puts you ahead of 90% of the targets out there. Don't compromise on the infrastructure layer.

If you need a rig that supports these hardening measures out of the box, with true KVM isolation and high-performance SSD storage (far superior to standard SATA spinning rust), you know where to look. Don't let slow I/O or noisy neighbors kill your uptime.

Ready to deploy? Spin up a secure KVM instance on CoolVDS in 55 seconds.