Assume Breach: The Paranoia Needed to Survive Online
Let's be honest. The moment your new VPS IP address is announced to the world via BGP, the scanners are already working. In my years managing infrastructure across the Nordics, I've seen fresh CentOS installs compromised in under 15 minutes because the admin left the root password as something weak or relied on default SSH ports. Security isn't a product; it's a mindset.
Whether you are running a high-traffic e-commerce site targeting Oslo or a dev box for your startup, the principles remain the same. We aren't just talking about uptime; we are talking about integrity. Here is how we harden servers at CoolVDS, and how you should too.
1. Lock the Front Door: SSH Hardening
SSH is the most common attack vector. By default, it listens on port 22 and allows password authentication. This is unacceptable for a production environment.
First, create a dedicated user. Never log in as root directly.
useradd -m viking
passwd viking
usermod -aG wheel viking # For CentOS
# OR
usermod -aG sudo viking # For Debian/Ubuntu
Next, edit your /etc/ssh/sshd_config. We need to disable root login, enforce protocol 2, and switch to key-based authentication only. Passwords are for amateurs.
Port 2222
Protocol 2
PermitRootLogin no
PasswordAuthentication no
UseDNS no
AllowUsers viking
Pro Tip: Moving SSH to a non-standard port (like 2222) isn't "true" security, but it reduces log noise from script kiddies by about 99%. It saves your CPU from wasting cycles on handshake failures.
2. The Shield: Iptables Configuration
We don't have the luxury of fancy next-gen firewalls on every node. We use iptables, and we learn to love it. The strategy is simple: Drop everything, then whitelist what you need.
Here is a standard "Battle-Hardened" ruleset for a web server:
# Flush existing rules
iptables -F
# Default policies: Block everything incoming
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
# Allow SSH (on your new port), HTTP, and HTTPS
iptables -A INPUT -p tcp --dport 2222 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# Save rules (RHEL/CentOS)
service iptables save
service iptables restart
If you are on Debian or Ubuntu 10.04, you might be using ufw, but understanding raw iptables is mandatory for any serious SysAdmin.
3. The Watchdog: Fail2Ban
Even with a custom port, persistent bots will hammer your authentication. Fail2Ban is your automated bouncer. It parses logs (like /var/log/secure or /var/log/auth.log) and updates iptables rules to ban IPs that show malicious signs.
Install it immediately:
yum install fail2ban # CentOS (requires EPEL repo)
apt-get install fail2ban # Debian/Ubuntu
Configure /etc/fail2ban/jail.local to ban an IP for one hour after 3 failed attempts. It’s simple, low-overhead, and incredibly effective.
4. The Norwegian Context: Data Integrity & Speed
Hosting in Norway brings unique advantages and responsibilities. Under the Personopplysningsloven (Personal Data Act), you are responsible for the security of user data. A compromised server isn't just a technical failure; it's a legal liability under the Data Inspectorate (Datatilsynet).
Furthermore, latency matters. If your user base is in Scandinavia, hosting in the US is nonsense. Signals take time to travel. By hosting locally on CoolVDS, you are looking at <5ms latency to NIX (Norwegian Internet Exchange) in Oslo. Low latency makes your SSH sessions feel snappy and your web pages load instantly.
Why Architecture Matters: OpenVZ vs. KVM
Not all VPS providers are created equal. Many budget hosts stuff hundreds of containers onto a single node using OpenVZ. This shares the kernel. If the kernel panics, everyone goes down. If one neighbor gets DDoS'd, your performance tanks.
At CoolVDS, we strictly use KVM (Kernel-based Virtual Machine). This provides hardware-level virtualization. Your memory is yours. Your kernel is yours. This isolation is critical for security; a container escape exploit is much harder when there is a hypervisor layer in between.
Comparison: Budget Hosting vs. CoolVDS
| Feature | Budget OpenVZ | CoolVDS (KVM) |
|---|---|---|
| Virtualization | Shared Kernel | Full Hardware Isolation |
| Storage | Slow SATA 7.2k | Enterprise SSD / SAS 15k |
| Swap Memory | Often Fake/Burst | Dedicated Partition |
| Security | "Noisy Neighbor" Risk | Private Kernel Space |
Conclusion
Security is an iterative process. Today it's iptables and SSH keys; tomorrow it's setting up ModSecurity for Apache or tweaking PHP hardening options. But if you don't get the basics right, the rest doesn't matter.
Don't gamble with cheap, oversold containers. If you need a rock-solid foundation for your next project, look for providers who understand the stack from the metal up. For low latency and robust KVM isolation, VPS Norway solutions like CoolVDS are built for professionals who can't afford downtime.
Ready to secure your infrastructure? Deploy a hardened KVM instance with SSD storage on CoolVDS today.