Linux Server Hardening: The 15-Minute Survival Guide
Let’s be honest. The moment you spin up a new VPS and it hits the public internet, the clock starts ticking. Before you’ve even finished your first yum update, bots are already hammering port 22. I’ve seen fresh installs compromised in under an hour because an admin thought a generic root password was "good enough" for a dev environment. It isn’t.
In the hosting world, security isn't a product; it's a process. And right now, in 2011, the tools available to us are powerful, but they require manual configuration. Whether you are running CentOS 5.5 or the fresh Debian 6 "Squeeze," the principles remain the same. Lock it down, or lose it.
1. The SSH Fortress
The default OpenSSH configuration is too permissive. Your first task is to disable password authentication entirely. Passwords can be brute-forced; 2048-bit RSA keys generally cannot.
On your local machine, generate your key pair if you haven't already:
ssh-keygen -t rsa -b 2048
Once your public key is in ~/.ssh/authorized_keys on the server, edit the daemon config file. This is non-negotiable.
vi /etc/ssh/sshd_config
Change these parameters:
- Port 2222 (Security by obscurity isn't security, but it reduces log noise from automated scripts).
- PermitRootLogin no (Force login as a user, then
su -orsudo). - PasswordAuthentication no
- UseDNS no (Speeds up login by preventing reverse DNS lookups).
- Protocol 2 (Ensure Protocol 1 is disabled).
Restart the service. If you lock yourself out, you better hope your provider offers a decent VNC console. At CoolVDS, we provide out-of-band console access for exactly this reason, but let's try to avoid using it.
2. Firewalls: Respect the iptables
Graphical interfaces are nice, but a real sysadmin knows iptables. It is the kernel-level packet filter that stands between your data and the chaos of the web. We don't have fancy "security groups" here; we have chains and rules.
A basic policy should drop everything by default and only allow what you explicitly need.
# Flush existing rules
iptables -F
# Default policies
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# Allow loopback
iptables -A INPUT -i lo -j ACCEPT
# Allow established connections (crucial!)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow SSH (on your new port), HTTP, HTTPS
iptables -A INPUT -p tcp --dport 2222 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
Save these rules. On CentOS/RHEL, use service iptables save. On Debian, you might need iptables-save > /etc/iptables.rules and a restore script in /etc/network/if-pre-up.d/.
Pro Tip: Don't rely solely on the OS firewall. At CoolVDS, our upstream hardware firewalls filter out massive volumetric DDoS attacks before they even hit your virtual interface. But for application-level filtering, iptables is your best friend.
3. Fail2Ban: The Bouncer
Even with a custom SSH port, determined attackers will find you. Fail2Ban is an essential Python framework that scans log files (like /var/log/secure or /var/log/auth.log) and updates iptables rules to ban IPs that show malicious signs.
Install it via EPEL (CentOS) or standard repos (Debian/Ubuntu). Configure jail.conf to ban an IP for an hour after 3 failed attempts. It keeps your logs clean and your CPU usage low.
4. Data Sovereignty and The Norwegian Advantage
Security isn't just about hackers; it's about legal jurisdiction. With the Datatilsynet (Data Inspectorate) enforcing the Personal Data Act here in Norway, knowing where your physical bits reside is critical. European Directives are getting stricter regarding data transfers to the US.
Hosting with CoolVDS ensures your data stays within Norwegian borders, benefiting from strict national privacy laws and connecting directly to the NIX (Norwegian Internet Exchange). This isn't just compliance; it's performance. The latency from Oslo to major European hubs is minimal, but the legal protection is massive.
5. The Performance Trade-off
Security adds overhead. Every packet inspection takes CPU cycles. Encryption takes math. On legacy spinning rust (HDD), heavy logging can actually cause I/O wait (iowait) to spike, slowing down your Apache threads.
This is why the underlying infrastructure matters. We don't use shared storage that chokes when a neighbor runs a backup. CoolVDS utilizes enterprise-grade SSD storage in RAID 10 configurations. High IOPS (Input/Output Operations Per Second) means your security logs get written instantly without blocking your web server's ability to serve PHP pages.
Summary Checklist
| Action | Why? |
| Update Kernel | Patch local root exploits. |
| Disable Root Login | Prevent brute-force success. |
| Configure iptables | Minimize attack surface. |
| Mount /tmp noexec | Stop script execution in temp folders. |
Security is a discipline. It requires vigilance. But it starts with a solid foundation.
Don't let slow I/O or weak hardware compromise your security posture. Deploy a hardened instance on CoolVDS today and experience the stability of true enterprise virtualization.