The Fortress Approach: Hardening Your Linux VPS Against Intruders
Let’s be honest: if you plug a fresh Linux server into the public internet today without protection, it will be scanned by a botnet within 15 minutes. Between the recent Conficker worm scares and the explosion of automated SSH brute-force scripts, the days of "security through obscurity" are over.
Whether you are running a high-traffic e-commerce site targeting Oslo or a development staging box for a client in Kyiv, the baseline is the same. You need to lock the doors before you even think about installing Apache or MySQL.
I’ve spent the last week cleaning up a client's compromised server that was running an outdated version of Joomla. It wasn't pretty. To save you that headache, here is the battle-tested configuration guide we use at CoolVDS to harden our Enterprise Linux instances.
1. Lock Down SSH (The Front Door)
The vast majority of attacks in 2009 are automated dictionary attacks against port 22. If you are still logging in as root with a password, you are playing Russian Roulette.
First, create a dedicated user and give them sudo privileges. Then, edit your SSH daemon config:
vi /etc/ssh/sshd_config
Change these lines to ensure no one can brute-force the root account directly:
PermitRootLogin no Protocol 2 PasswordAuthentication no UseDNS no AllowUsers yourusername
Pro Tip: Move your SSH port away from 22 to something obscure like 22022. It won't stop a targeted attack, but it keeps your logs clean from 99% of the script kiddies scanning standard ports.
2. IPTables: Drop by Default
We see too many admins relying on ISP-level firewalls. You need host-level protection. In CentOS 5 or Debian Lenny, IPTables is your best friend. The golden rule of firewalling is: Drop everything, then open only what is necessary.
Here is a basic, restrictive rule set to get you started:
# Set default chain policies
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# Accept on localhost
iptables -A INPUT -i lo -j ACCEPT
# Accept established connections
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow SSH (If you changed the port, change it here too!)
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
Save these rules. On RedHat/CentOS systems, use /etc/init.d/iptables save. If you mess this up, you will lock yourself out, so keep a console session open via the CoolVDS management portal just in case.
3. PHP Security: The `php.ini` Diet
If you are hosting dynamic sites, PHP is likely your weakest link. Default PHP 5.2 installations are far too permissive. Open your php.ini and disable functions that web scripts have no business using. This stops an attacker from executing shell commands if they manage to upload a malicious script.
disable_functions = exec,system,shell_exec,passthru,proc_open,proc_close expose_php = Off display_errors = Off
Turning off expose_php prevents your server from broadcasting its version number in the HTTP headers, making it harder for attackers to lookup specific vulnerabilities for your version.
4. The Norway Factor: Compliance and Latency
For our Norwegian clients, security isn't just technical; it's legal. Under the Personopplysningsloven (Personal Data Act), you have a responsibility to secure user data. Hosting outside of the EEA or in insecure environments can raise eyebrows with Datatilsynet (The Data Inspectorate).
Furthermore, latency matters for security. Slow connections can lead to timeouts during security updates or backup transfers. By hosting locally in Norway, you benefit from low-latency peering at NIX (Norwegian Internet Exchange), ensuring your management connections are snappy and your backups complete fast.
5. The Hardware Layer: Isolation Matters
Software hardening is useless if your neighbor on the physical server brings the whole node down. In the cheap VPS market, providers often oversell RAM using OpenVZ, meaning your "guaranteed" resources disappear when the server is under load.
At CoolVDS, we prioritize strict isolation using Xen virtualization. This ensures that your memory is yours. We also utilize high-performance 15k RPM SAS RAID-10 arrays. While not the cheapest option, it ensures that high I/O wait times don't cause your security logging services (like Syslog or Auditd) to choke during a DDoS attack.
Performance Comparison:
| Feature | Budget VPS (OpenVZ) | CoolVDS (Xen HVM) |
|---|---|---|
| Kernel Access | Shared | Dedicated (Customizable) |
| Memory | Burst (Unstable) | Dedicated (Guaranteed) |
| Disk I/O | SATA (Slow) | 15k SAS RAID-10 (Fast) |
Final Thoughts
Security is a process, not a product. Keep your distribution updated—CentOS 5.3 was just released recently, so run that yum update regularly. Install Fail2Ban to ban IP addresses that fail multiple login attempts.
Don't let a compromised server destroy your reputation. If you need a stable, isolated environment to build your fortress, we are ready for you.
Ready to deploy? Spin up a secured Xen VPS instance on CoolVDS today and experience true stability.