The Internet is a Hostile Place. Act Like It.
If you just spun up a fresh VPS and left it running with default settings, you are already a target. I’ve seen logs on a fresh node at NIX (Norwegian Internet Exchange) light up with brute-force attempts less than 40 seconds after coming online. Automated scripts don't care if you're a small dev shop in Trondheim or an enterprise in Oslo; they scan IP ranges indiscriminately looking for open port 22 and default passwords.
We aren't talking about advanced persistent threats here. We are talking about basic hygiene. If you don't lock the front door, don't be surprised when someone walks in and installs a rootkit. Here is the battle-tested configuration I apply to every server before it even handles a single HTTP request.
1. SSH: The First Line of Defense
Root login via password is the single most common failure point. I still see admins logging in as root. Stop it. Create a dedicated user and use sudo.
First, generate an RSA key pair on your local machine if you haven't already:
ssh-keygen -t rsa -b 4096Once your public key is on the server (in ~/.ssh/authorized_keys), edit the SSH daemon config. On CentOS 5 or Ubuntu 10.04, crack open /etc/ssh/sshd_config and change these lines:
Port 2222
PermitRootLogin no
PasswordAuthentication no
UseDNS no
AllowUsers yourusernameMoving the port isn't "security by obscurity"—it's noise reduction. It keeps your logs clean from the thousands of script-kiddies scanning port 22, so you can actually spot real threats. Restart the service with /etc/init.d/ssh restart (or service sshd restart on RHEL/CentOS).
2. Iptables: If You Don't Need It, Block It
Hardware firewalls are great, but you need host-level protection. iptables is the standard. Don't rely on wrappers if you want to understand what's actually happening to your packets.
Here is a restrictive baseline policy. We drop everything by default and only open what we need.
# Flush existing rules
iptables -F
# Set default policies to DROP
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# Allow loopback
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 custom port)
iptables -A INPUT -p tcp --dport 2222 -j ACCEPT
# Allow Web Traffic
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPTSave these rules. On RedHat systems, use /etc/init.d/iptables save. On Debian/Ubuntu, you might need iptables-save > /etc/iptables.rules and a load script in /etc/network/interfaces.
3. Banning the Bots with Fail2Ban
Even with keys, you don't want your SSH port hammered. Fail2Ban scans log files and updates iptables rules to ban IPs that show malicious signs. It is lightweight and effective.
Install it via EPEL (CentOS) or apt (Ubuntu):
apt-get install fail2banConfigure /etc/fail2ban/jail.local. I prefer a strict policy: 3 attempts and you are banned for an hour.
[ssh]
enabled = true
port = 2222
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 36004. The Virtualization Factor: Kernel Isolation
Security isn't just about software; it's about architecture. Many budget providers fill their racks with OpenVZ containers. The problem? You share the kernel with every other customer on that physical node. If there is a kernel panic or a local root exploit in the shared kernel, your data is at risk, regardless of your iptables rules.
This is why at CoolVDS, we rely on KVM (Kernel-based Virtual Machine) or Xen. These provide true Hardware Virtualization (HVM). Your kernel is yours. This isolation is critical for compliance with the Norwegian Personal Data Act (Personopplysningsloven). If you are storing customer data in Oslo, you cannot afford "noisy neighbor" security vulnerabilities.
Pro Tip: Check your disk scheduler. On virtualized hardware, the default CFQ scheduler can be slow. Switch to `deadline` or `noop` for better I/O performance on our high-speed RAID arrays.echo noop > /sys/block/sda/queue/scheduler
5. Updates and Daemons
Run netstat -tulpn. Do you see services listening that you don't recognize? Kill them. Does your web server need to run Sendmail? Probably not. Disable it.
Finally, keep the system updated. In 2010, the window between a vulnerability disclosure and an exploit release is shrinking. Subscribe to the CentOS-announce or Ubuntu-security-announce mailing lists.
Conclusion
Hardening is a process, not a checkbox. But by securing SSH, configuring a tight firewall, and choosing a virtualization platform that respects isolation like CoolVDS, you are ahead of 99% of the targets out there. Don't wait for a breach to take this seriously.
Need a secure foundation? Deploy a KVM-based instance on CoolVDS today. Our Oslo datacenter offers low latency and strict physical security for your mission-critical stacks.