Linux Server Hardening: Survival Guide for 2009
I just checked the /var/log/secure file on a fresh server I provisioned three hours ago. It already has 400 failed login attempts. Welcome to the modern web. If you are running a server in 2009 without locking it down, you aren't an admin; you're a victim waiting to happen.
Whether you are hosting a high-traffic forum for a Norwegian gaming clan or a corporate portal for an oil services firm in Stavanger, the threat is the same. Automated bots don't care about your uptime—they want your bandwidth for spam relays.
Here is how we secure our infrastructure at CoolVDS, and how you should secure yours. No fluff, just the commands that keep you online.
1. SSH: The Front Door
The default SSH configuration on most Linux distributions (yes, even CentOS 5.3) is too permissive. We need to cut access to the root user immediately. If you lose your root password and allow login, it’s game over.
Open your config:
vi /etc/ssh/sshd_config
Find and change these lines:
PermitRootLogin no
Protocol 2
MaxAuthTries 3
Critical: Create a standard user and give them sudo (Debian/Ubuntu) or add them to the wheel group (CentOS) before you restart SSH, or you will lock yourself out. I've seen senior sysadmins make that drive of shame to the datacenter console.
CoolVDS Pro Tip: Change your SSH port from 22 to something random, like 5522. It’s security by obscurity, which isn't perfect, but it stops 99% of the automated scripts hitting our IP ranges in Oslo.
2. iptables: The Bouncer
We don't have fancy next-gen graphical firewalls on bare Linux. We have iptables. It is robust, stateless, and efficient. If you aren't filtering packets, you are wrong.
Here is a standard "deny all, allow specific" policy. This assumes you are allowing Web (80), SSL (443), and your custom SSH port (5522).
# Flush existing rules
iptables -F
# Allow loopback
iptables -A INPUT -i lo -j ACCEPT
# Keep current connections alive
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow SSH, HTTP, HTTPS
iptables -A INPUT -p tcp --dport 5522 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# Drop everything else
iptables -P INPUT DROP
iptables -P FORWARD DROP
On CentOS, don't forget to save:
/sbin/service iptables save
3. Fail2Ban: The Automator
Even with a custom port, dedicated attackers will find you. You can't watch logs 24/7. Use Fail2Ban. It parses logs (SSH, Apache, FTP) and dynamically adds iptables rules to ban IPs that show malicious behavior.
Install it via EPEL (for CentOS) or apt (Debian). Configure the jail to ban an IP for an hour after 3 failed attempts. It saves CPU cycles because your server stops processing the handshake request entirely.
4. The Norwegian Context: Latency and Law
Security isn't just about hackers; it's about compliance. With the strict enforcement of the Personal Data Act (Personopplysningsloven) here in Norway, Datatilsynet is not forgiving about data leakage.
If you host customer data on cheap US servers, you are navigating a legal minefield regarding the Safe Harbor framework. Hosting locally in Norway simplifies compliance. Plus, the physics doesn't lie: ping times from Oslo to a server in Amsterdam might be 25ms, but to a CoolVDS server in our Oslo datacenter, it's sub-3ms via NIX (Norwegian Internet Exchange).
Why Architecture Matters
Many budget hosts use OpenVZ and oversell resources. This is a security risk—a "noisy neighbor" can destabilize your kernel. At CoolVDS, we prioritize Xen HVM virtualization. It provides true isolation. If another user creates a kernel panic, your instance keeps humming.
| Feature | Budget OpenVZ Host | CoolVDS (Xen/KVM) |
|---|---|---|
| Kernel Isolation | Shared (Risky) | Dedicated (Secure) |
| Storage | Slow SATA | Enterprise 15k SAS / SSD RAID-10 |
| Swap | Often Unavailable | Full Control |
We use high-performance SAS 15k RPM drives and emerging Enterprise SSD technology in RAID-10 arrays. While standard SATA drives bottle-neck during log rotation or backups, our I/O throughput keeps your database queries instant.
5. Disable Unused Services
A default installation often includes services you don't need. Sendmail? X11? Cups (printing)? Kill them.
chkconfig sendmail off
chkconfig cups off
chkconfig yum-updatesd off
The fewer ports listening, the smaller your attack surface.
Final Thoughts
Security is a process, not a product. Keep your kernel updated (yum update is your friend), monitor your logs, and choose a host that respects the hardware. Don't let a compromised server destroy your reputation.
Ready to deploy on hardware that takes security seriously? Launch your hardened CoolVDS instance in Oslo today.