Stop the Brute Force: Securing Your Linux VPS from Day Zero
Let’s be honest: within 60 seconds of your server going online, a botnet from halfway across the world is already hammering port 22. I see it in the logs every single day. If you are still running a default installation of CentOS 5 or Ubuntu 10.04 with password authentication enabled, you aren't an admin; you're a victim waiting to happen.
In the Norwegian hosting market, we pride ourselves on stability, but stability implies security. Whether you are hosting a client's database requiring strict adherence to Personopplysningsloven (the Personal Data Act) or running a high-traffic e-commerce site, a compromised root account is a career-ending event.
Here is the no-nonsense guide to hardening your Linux box immediately after provisioning. No fluff, just the commands that keep you safe.
1. Kill Password Authentication Dead
Passwords are the weak link. Brute force attacks will eventually succeed if your password is weak, and even if it's strong, the constant authentication attempts eat up your CPU cycles. We move to SSH keys immediately.
On your local machine, generate a 2048-bit RSA key if you haven't already:
ssh-keygen -t rsa -b 2048
Once you've pushed your public key to the server using ssh-copy-id, edit your SSH daemon config. This is non-negotiable.
vi /etc/ssh/sshd_config
Find and change these lines:
PasswordAuthentication no
PermitRootLogin no
Protocol 2
UseDNS no
Disabling PermitRootLogin forces you to log in as a standard user and use sudo (or su -) to escalate privileges. This adds a critical layer of accountability and stops scripts that blindly attack the 'root' user. Setting Protocol 2 prevents fallback to the insecure SSH-1 protocol.
2. The Firewall: IPTables is Your Best Friend
Many admins are afraid of iptables because the syntax can be unforgiving. Get over it. A server without a firewall policy is a public toilet. The strategy is simple: Drop everything by default, then whitelist only what is necessary.
Here is a baseline configuration script I use for new web servers:
# Flush existing rules
iptables -F
# Default policy: DROP everything
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# Allow loopback (localhost)
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
# Allow SSH (adjust port if you changed it)
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# Allow Web Traffic
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
Pro Tip: Before applying these rules, ensure you have console access via your provider's control panel. If you mistype the SSH port, you will lock yourself out. At CoolVDS, we provide VNC console access specifically for these "oops" moments.
3. Kernel Isolation: OpenVZ vs. KVM
This is where hardware architecture becomes a security feature. In 2011, the market is flooded with cheap OpenVZ containers. While efficient, OpenVZ shares the host kernel. If a kernel exploit is discovered, an attacker inside one container could theoretically impact the whole node.
For serious projects, we advocate for KVM (Kernel-based Virtual Machine). KVM allows your VPS to run its own isolated kernel. If your neighbor gets compromised or crashes their kernel, your instance keeps humming along. This isolation is critical for compliance with strict data standards required by the Datatilsynet.
| Feature | OpenVZ (Common) | KVM (CoolVDS Standard) |
|---|---|---|
| Kernel | Shared with Host | Fully Isolated |
| Security | Moderate | High (Hardware Virtualization) |
| Performance | Variable (noisy neighbors) | Consistent (Dedicated RAM/CPU) |
4. Automate Defense with Fail2Ban
Even with keys, your logs will be filled with noise. Install Fail2Ban. It parses logs (like /var/log/secure) and dynamically updates your iptables firewall to ban IPs that show malicious signs—like too many password failures.
On Debian/Ubuntu:
apt-get install fail2ban
On CentOS (requires EPEL repo):
yum install fail2ban
Configure it to ban an IP for an hour after 3 failed attempts. It cleans up your logs and saves CPU resources for what matters: serving your application.
5. The Hardware Factor: Speed is Security
Security logging and I/O wait times are related. If your server is under a DDoS attack, your logs explode in size. On traditional spinning 7.2k RPM drives, this write-load can freeze the server entirely, turning a minor probe into a Denial of Service.
This is why high-performance I/O matters. We utilize enterprise-grade SSD arrays and RAID-10 SAS configurations. When your disk throughput is massive, your system can handle the logging overhead of an attack without buckling under pressure. Combined with low latency to NIX (Norwegian Internet Exchange), you ensure that your legitimate Norwegian users get served fast, even while your firewall is dropping packets from botnets.
Conclusion
Security is not a "set it and forget it" task; it is an ongoing discipline. But by disabling password auth, configuring a strict firewall, and choosing the right virtualization technology, you eliminate 99% of the risk profile.
Don't gamble with shared kernels or slow disks. If you need a robust, isolated environment to test these hardening scripts, spin up a KVM instance with us. You get full root access, VNC control, and the peace of mind that comes with true hardware isolation.
Ready to lock it down? Deploy a CoolVDS KVM instance in Oslo today.