Don't Let Your New Server Become a Botnet Zombie
I logged into a client's fresh CentOS 5.4 box yesterday. It had been online for exactly 45 minutes. The /var/log/secure file was already 20MB large. Thousands of login attempts from IPs in Eastern Europe and China were hammering port 22. If you think "security through obscurity" works, you're going to wake up to a defaced website or, worse, a letter from your ISP about spam relaying.
In the Norwegian hosting market, we have an added layer of responsibility. The Datatilsynet (Data Inspectorate) is cracking down on how we handle personal data under the Personal Data Act (Personopplysningsloven). If your server gets popped because you left the root password as 'password123', legal compliance is the least of your worries. Your reputation is gone.
Here is how to lock down your CoolVDS instance immediately after provisioning. No fluff, just commands.
1. Secure SSH: The Front Door
The default SSH configuration is compatible, not secure. We need to change that. Open your config file:
vi /etc/ssh/sshd_config
Change these lines immediately:
- Port 22: Change this to something arbitrary, like
2299. It stops 99% of automated scanners. - PermitRootLogin no: Never log in as root. Log in as a user and
su -orsudoup. - Protocol 2: Ensure Protocol 1 is disabled. It's broken.
Pro Tip: If you are managing multiple servers, use RSA keys. Password authentication is a relic. Generate a key pair withssh-keygen -t rsa -b 4096on your local machine and upload the public key. Then setPasswordAuthentication no. It makes brute-forcing mathematically impossible.
2. The Firewall: iptables is Your Best Friend
Many sysadmins are afraid of iptables because the syntax is unforgiving. Get over it. A server without a firewall policy is naked. At CoolVDS, we don't put hardware firewalls in front of every VPS because we believe in raw, uninhibited throughput, so you must secure the OS layer.
Here is a baseline script for a web server. Save this as firewall.sh and run it:
#!/bin/bash
# Flush existing rules
iptables -F
# Default policies: DROP everything incoming
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# Allow localhost
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 (New Port), HTTP, HTTPS
iptables -A INPUT -p tcp --dport 2299 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# Allow Ping (optional, good for monitoring)
iptables -A INPUT -p icmp -j ACCEPT
# Save settings (CentOS/RHEL)
/sbin/service iptables save
If you are on the new Ubuntu 10.04 LTS (Lucid Lynx), you might play with ufw, but learning raw iptables is a skill that pays dividends regardless of the distro.
3. Fail2Ban: The Bouncer
Even with a custom port, dedicated attackers will find your SSH daemon. Fail2Ban is a Python script that parses your logs. When it sees too many failures from an IP, it updates your firewall to drop that IP instantly.
On CentOS/RHEL (requires EPEL repo):
yum install fail2ban
Configure /etc/fail2ban/jail.conf. Set the bantime to 3600 (1 hour). If someone messes up 3 times, put them in the penalty box. This significantly reduces log noise and CPU load.
4. Updates and Minimal Services
The beauty of a Virtual Private Server (VPS) compared to shared hosting is isolation. But that means you own the patch cycle. The kernel exploit released last month? You are vulnerable until you patch.
Run this weekly:
yum update -y
Or for Debian/Ubuntu systems:
apt-get update && apt-get upgrade
Also, check what is listening. Run netstat -tulpn. Do you see sendmail or rpcbind listening? If you aren't using them, kill them. Use chkconfig service_name off to stop them from starting at boot. Every open port is a potential liability.
Why CoolVDS?
You can harden the OS all day, but you can't harden a noisy neighbor or a congested network uplink. This is where the platform matters.
| Feature | Budget Hoster | CoolVDS |
|---|---|---|
| Virtualization | OpenVZ (Oversold RAM) | KVM (Kernel-based Virtual Machine) |
| Storage | SATA 7.2k RPM | RAID-10 Enterprise SAS/SSD |
| Location | Germany/USA | Oslo (NIX Connected) |
We use KVM virtualization. Unlike OpenVZ, KVM provides true hardware virtualization. Even if another user on the node gets hit by a massive DDoS, your kernel resources remain isolated. Plus, our storage arrays utilize high-performance SAS and early-generation SSD caching, offering I/O speeds that standard SATA drives simply cannot touch.
For Norwegian businesses, latency matters. Our datacenter is directly connected to the NIX (Norwegian Internet Exchange) in Oslo. Your packets don't need to travel to Frankfurt and back. This low latency feels instantaneous to your local users.
Final Thoughts
Security is a process, not a product. These steps—SSH hardening, iptables, and Fail2Ban—are the absolute minimum required to survive on the public internet in 2010. Don't wait for a breach to take this seriously.
Ready to deploy on a platform that respects your skills? Spin up a secure KVM instance on CoolVDS today.