Assume You Are Under Attack Right Now
I deployed a fresh CentOS 5.3 node yesterday at 2:00 PM. By 2:15 PM, /var/log/secure showed 400 failed login attempts. Welcome to the modern internet. If you are running a server, you are a target.
It doesn't matter if you aren't hosting bank data. Botnets want your bandwidth and your CPU cycles. They want to turn your shiny new VPS into a spam relay or a node in a DDoS cannon.
I've spent the last decade cleaning up compromised boxes for clients who thought "default settings" were good enough. They aren't. Here is the exact hardening protocol I use for every production machine, from web servers in Oslo to database clusters in Kyiv.
1. Kill Passwords, Use Keys
If you are still typing a password to SSH into your server, you are doing it wrong. Brute force scripts iterate through dictionaries faster than you can blink. Disabling password authentication is the single most effective step you can take.
First, generate your keypair locally:
ssh-keygen -t rsa -b 4096
Once you've copied your public key to ~/.ssh/authorized_keys on the server, edit your SSH config. This is non-negotiable.
File: /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no
UseDNS no
AllowUsers yourusername
Restart the service. Now, the scripts can knock all day, but nobody is home.
2. The Firewall: IPTables is Your Best Friend
Many admins are scared of IPTables. They shouldn't be. It is the kernel-level gatekeeper that stands between your data and the void. A "Default Drop" policy is the only sane choice. If you don't explicitly allow it, it shouldn't get in.
Here is a baseline configuration for a web server (HTTP/HTTPS/SSH):
# Flush existing rules
iptables -F
# Default policies: Block everything by default
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# Allow loopback (local traffic)
iptables -A INPUT -i lo -j ACCEPT
# Keep current connections alive
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow SSH (If you changed your port, update this!)
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: Always runiptables -L -nto verify before you save. If you lock yourself out, you'll need console access (which is why CoolVDS provides a specialized VNC out-of-band console for emergencies). Save your rules with/sbin/service iptables saveon CentOS.
3. Update or Die
Linux distributions are robust, but software has bugs. The exploit window—the time between a vulnerability being published and a patch being applied—is where you get hacked.
On Debian/Ubuntu:
apt-get update && apt-get upgrade
On CentOS/RHEL:
yum update
Automate the notification, not necessarily the installation. You want to know when patches are available, but you don't want a kernel update automatically rebooting your database in the middle of a transaction.
4. Secure Shared Memory
One common attack vector on shared hosting environments is executing malicious scripts from temporary directories. While /tmp is necessary, it shouldn't be a playground for hackers.
If you haven't partitioned /tmp separately, you can create a secure tmp file:
dd if=/dev/zero of=/usr/tmpDSK bs=1024 count=1024000
/sbin/mke2fs /usr/tmpDSK
mount -o loop,noexec,nosuid,rw /usr/tmpDSK /tmp
chmod 1777 /tmp
Adding the noexec flag prevents binaries from running directly from this directory. It breaks many automated rootkits instantly.
The Virtualization Factor: Why "CoolVDS" is Different
Software hardening only goes so far if your neighbor on the physical server brings the whole node down. In the current hosting market, cheap "Container" VPS hosting (like OpenVZ) is flooding the industry. The problem? You share the kernel. If a kernel exploit hits, everyone on that host is compromised.
This is why at CoolVDS, we rely on Xen virtualization. It provides true hardware isolation. Your memory is your memory. Your Swap is your Swap. We also use high-performance 15k RPM SAS RAID-10 arrays. While others save money with cheap SATA drives that choke under load, we ensure your I/O wait times remain negligible.
Local Law & Latency
For my fellow admins here in the Nordics, physical location matters. Hosting your data in the US puts you under the Patriot Act. Hosting in Oslo (where our datacenter is located) keeps you under the Norwegian Personal Data Act (Personopplysningsloven). Plus, if your users are in Europe, why add 100ms of latency crossing the Atlantic?
Final Thoughts
Security isn't a product; it's a process. These steps are the foundation. From here, you look at installing fail2ban to parse logs and ban IPs automatically, and perhaps rkhunter for daily integrity checks.
But the first step is choosing a platform that respects the technology. Don't build a fortress on a swamp.
Need a sandbox to test your hardening scripts? Deploy a Xen-based instance on CoolVDS today. We are live at NIX (Norwegian Internet Exchange) for unbeatable local speed.