Lock Down Your Box: A Survival Guide for 2010
Let’s be honest: the moment your new VPS comes online, it is being scanned. Somewhere in a basement in Eastern Europe or a dorm room in China, a script is already pinging your IP, checking for open ports, and bruteforcing your SSH root password. If you leave a server running with default settings for more than an hour, you aren't an admin; you're a victim.
I’ve cleaned up enough compromised boxes this year to know the pattern. It usually starts with a weak password and ends with your server sending spam emails until the IP gets blacklisted by Spamhaus. Whether you are running CentOS 5.5 or the new Ubuntu 10.04 Lucid Lynx, the principles of defense are identical.
At CoolVDS, we protect the network edge with heavy-duty Cisco hardware, but once you are inside the OS, you are on your own. Here is how to harden your Linux server so you can sleep at night.
1. The SSH Fortress
The vast majority of attacks are automated SSH bruteforce attempts. Your first job is to make your server invisible to the low-hanging fruit scripts.
First, create a user. Never log in as root.
adduser myadmin
passwd myadmin
usermod -aG wheel myadmin # For CentOS/RHEL
# OR
adduser myadmin sudo # For Debian/Ubuntu
Next, edit your SSH configuration. This is non-negotiable.
Open /etc/ssh/sshd_config and modify these lines:
Pro Tip: Before you restart the SSH service, open a second terminal window and keep it active. If you mess up the config and lock yourself out, you still have one active session to fix it.
Port 2022 # Move off default port 22. Scripts usually only scan 22.
PermitRootLogin no # The most critical setting.
Protocol 2 # SSH-1 is insecure. Disable it.
AllowUsers myadmin # Explicitly allow only your user.
Finally, stop using passwords. Set up RSA Key Authentication. It is 2010; passwords are for chumps.
2. Firewalls: Iptables is Your Best Friend
Many sysadmins are afraid of iptables because the syntax looks like Klingon. Get over it. A proper firewall policy is default-drop.
Here is a battle-tested configuration for a standard web server (Web + SSH). This flushes existing rules and sets a strict policy:
# Flush defaults
iptables -F
# Default policies: Block everything
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# Allow localhost (critical for local processes)
iptables -A INPUT -i lo -j ACCEPT
# Allow established connections
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow SSH (on your new custom port)
iptables -A INPUT -p tcp --dport 2022 -j ACCEPT
# Allow HTTP/HTTPS
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
# Save the rules
/sbin/service iptables save
If you screw this up, you will need to access your CoolVDS console via VNC to fix it.
3. Automated Defense: Fail2Ban
Even with a custom port, determined attackers will find your SSH daemon. You need a bouncer. Fail2Ban parses your log files and bans IPs that show malicious signs.
Install it via EPEL (CentOS) or Apt (Ubuntu). Configure jail.conf to protect SSH:
[ssh-iptables]
enabled = true
filter = sshd
action = iptables[name=SSH, port=2022, protocol=tcp]
logpath = /var/log/secure
maxretry = 3
bantime = 3600
This automatically updates your iptables rules to drop packets from IPs that fail login three times. It is simple, effective, and low overhead.
4. The Norwegian Context: Data Integrity
Hosting in Norway isn't just about low latency to Oslo—though ping times of 4ms compared to 35ms from Frankfurt make a massive difference for database applications. It is about compliance.
Under the Norwegian Personopplysningsloven (Personal Data Act), you have strict obligations regarding data integrity. Security is not just a technical requirement; it is a legal one enforced by Datatilsynet. If your server is compromised and customer data is leaked, ignorance is not a valid defense.
Hardware Matters
Software security means nothing if the hardware fails. This is where the "cloud" hype falls short. You need raw reliability.
| Feature | Budget Host | CoolVDS Architecture |
|---|---|---|
| Storage | Standard SATA 7.2k RPM | RAID-10 SAS 15k RPM or Enterprise SSD |
| Virtualization | OpenVZ (Oversold) | KVM / Xen (Dedicated Kernel) |
| Network | Shared Uplink | Dedicated Gigabit Port |
We use KVM virtualization at CoolVDS because it provides true hardware isolation. If a neighbor on the node gets DDoS'd, your kernel keeps ticking. Combined with our RAID-10 SAS arrays, you get the I/O throughput needed for high-load MySQL databases without the volatility of shared filesystems.
5. Updates and Maintenance
A secure server is a moving target. Security vulnerabilities in the Linux kernel or Apache are discovered weekly. Automate your awareness, if not the updates themselves.
On RHEL/CentOS, install yum-security plugin:
yum install yum-security
yum list-sec
This shows you only the security-relevant updates, ignoring the fluff. Schedule a maintenance window, snapshot your VM via the CoolVDS control panel, and patch it.
Final Thoughts
Security is a process, not a product. There is no "install and forget" button. But by changing your SSH port, implementing strict iptables rules, and deploying on robust infrastructure like CoolVDS, you eliminate 99% of the risk.
Don't wait for the breach. Deploy a hardened KVM instance in Oslo today and keep your data inside the country.