Paranoia is a Virtue: The 2010 Guide to Locking Down Your Linux VPS
If you checked your /var/log/secure or /var/log/auth.log this morning, you probably saw it: thousands of failed login attempts from IPs in countries you have no business with. The automated botnets are scanning, poking, and prodding every exposed port 22 on the internet. It’s not personal. It’s just business. But if they get in, it becomes your problem.
Most hosting providers hand you a root password and wish you luck. That is negligence. In the datacenter trenches, we know that a default install of CentOS 5 or Debian Lenny is about as secure as a screen door on a submarine. If you value your uptime—and your reputation with the Datatilsynet (Norwegian Data Inspectorate)—you need to harden that box before you even install Apache.
1. The SSH Fortress
The first casualty in any server compromise is usually the root account. Brute-force tools like Hydra are getting faster, and dictionary attacks are relentless.
Step one: Stop using passwords. SSH keys are not optional for serious sysadmins. Generate a 2048-bit RSA key pair.
Step two: Edit your /etc/ssh/sshd_config file. We are going to decapitate the default attack vectors.
# /etc/ssh/sshd_config
Port 4422 # Move off port 22. It reduces log noise by 90%.
Protocol 2
PermitRootLogin no
PasswordAuthentication no
UseDNS no
AllowUsers cooladmin
Restart the service with /etc/init.d/ssh restart. If you lock yourself out, you better hope your provider has a working KVM console. At CoolVDS, our out-of-band VNC console is always available for exactly this reason, because we know even seniors make typos.
2. Iptables: The First Line of Defense
Forget GUI firewalls. Learn iptables. It is the kernel-level packet filter that stands between your data and the chaotic internet. 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 web server. Note the explicit permission for the loopback interface—forgetting that breaks local services like MySQL.
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# Accept loopback
iptables -A INPUT -i lo -j ACCEPT
# Allow established connections (keep your SSH session alive!)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow SSH (on your custom port), HTTP, HTTPS
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
3. Automated Bans with Fail2Ban
Even with a custom port, persistent attackers will find you. You need a bouncer that never sleeps. Fail2Ban scans your log files for malicious patterns (like repeated password failures) and updates your iptables rules to ban the offending IP for a set time.
Install it from the EPEL repository on CentOS or apt on Debian. Configure the jail.conf to ban an IP for an hour after 3 failed attempts. It’s simple, effective, and keeps your CPU from being wasted on encryption overhead from handshake attempts.
4. Virtualization Matters: OpenVZ vs. Xen/KVM
Security isn't just software; it's architecture. Many budget VPS hosts in Norway are overselling OpenVZ containers. In OpenVZ, you share the kernel with every other customer on the node. If there is a kernel exploit (and there are always kernel exploits), a neighbor could theoretically break out of their container and affect you.
This is why CoolVDS is standardized on Xen HVM and emerging KVM technology. We provide true hardware virtualization.
Architect's Note: Hardware isolation means your memory is yours, and your kernel is yours. It also prevents the "noisy neighbor" effect where another user's high I/O kills your database performance. For high-compliance environments dealing with Personopplysningsloven, shared kernels are a risk you shouldn't take.
Resource Isolation Comparison
| Feature | OpenVZ (Common) | Xen/KVM (CoolVDS) |
|---|---|---|
| Kernel | Shared Host Kernel | Dedicated Kernel |
| Isolation | Process Level | Hardware Level |
| Swap | Fake (Burst RAM) | Real Partition |
| Security Risk | Kernel Panic affects all | Isolated to VM |
5. The Norwegian Advantage
Latency is the silent killer of user experience. If your target market is Oslo or Bergen, hosting in Germany or the US adds unnecessary milliseconds to every TCP handshake. But beyond speed, there is sovereignty.
Data stored on servers physically located in Norway falls under Norwegian jurisdiction. With the increasing scrutiny on data privacy, knowing exactly where your bits live—down to the datacenter hall—is a competitive advantage. CoolVDS infrastructure is interconnected directly to the NIX (Norwegian Internet Exchange), ensuring your traffic stays local and low-latency.
Don't wait for a breach to take security seriously.
Hardening is a process, not a checkbox. Start with these steps. If you need a platform that respects your need for raw performance and true isolation, deploy a test instance on CoolVDS. Our new SSD-backed storage tier provides the I/O throughput you need for heavy database workloads without the jitter of spinning rust.