Locking Down Your Box: The Definitive Linux Hardening Guide
Let’s be honest: the internet is getting dirtier. If you tailed your /var/log/secure file right now, you’d see them—script kiddies from halfway across the world hammering port 22, guessing 'admin', 'root', and 'god'. I saw a fresh CentOS 5 install get compromised in 12 minutes last week because the developer left the root password as 'password123'.
It doesn't matter if you are running a high-traffic forum or a corporate mail server. If it has an IP address, it is a target. Here is how we harden servers at the metal level, the same way we configure the base images for our CoolVDS infrastructure in Oslo.
1. Burn the Keys, Ban the Passwords
The single biggest vulnerability in 2009 is still password authentication. Brute force attacks are becoming automated and distributed. The solution isn't a stronger password; it's no password at all.
Switch to SSH keys immediately. Generate a 2048-bit RSA key pair on your local workstation and push it to the server. Once you verify you can log in, edit /etc/ssh/sshd_config and flip these switches:
PermitRootLogin no
PasswordAuthentication no
UseDNS no
AllowUsers yourusername
Restart the daemon with service sshd restart. You have just eliminated 99% of automated attacks. At CoolVDS, we encourage all clients to disable root logins instantly upon provisioning.
2. The Firewall is Your Moat: Master iptables
We don't have fancy GUIs for packet filtering on serious servers. We use iptables. Many providers hand you a server with the firewall wide open. That is negligence.
Here is a baseline policy for a web server. It drops everything by default and only opens what is necessary (SSH, HTTP, HTTPS):
# Flush existing rules
iptables -F
# Default policies: Drop everything incoming
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# Allow localhost and established connections
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# Open specific ports
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
Don't forget to save these rules so they survive a reboot. On RedHat/CentOS systems, run service iptables save.
3. Isolation Matters: Virtualization vs. Containers
Security isn't just about software; it's about architecture. There is a lot of buzz lately about container-based hosting (like OpenVZ), where you share the kernel with every other customer on the node. It's cheap, but from a security standpoint, it keeps me up at night.
If a kernel exploit drops for the host OS in a container environment, everyone is vulnerable. That is why CoolVDS relies heavily on Xen hardware virtualization. It provides true isolation. Your RAM is yours; your kernel is yours. It prevents the "noisy neighbor" effect and adds a critical layer of segregation between your data and the outside world.
Pro Tip: Install fail2ban. It parses your log files looking for failed login attempts and updates iptables rules to ban the offending IP addresses dynamically. It is a lifesaver for keeping log files clean.
4. The Norwegian Advantage: Data Sovereignty
We have all read about the Patriot Act in the US. If your data sits on servers in Dallas or Virginia, US authorities can access it without you ever knowing. For Norwegian businesses, this is a legal minefield, especially regarding the Personopplysningsloven (Personal Data Act).
Hosting locally isn't just about getting 2ms latency to the NIX (Norwegian Internet Exchange) in Oslo—though your developers will love that responsiveness. It's about compliance with the Data Inspectorate (Datatilsynet). Keeping your data on Norwegian soil, protected by EEA regulations, is the only way to ensure you aren't accidentally exposing customer privacy to foreign jurisdictions.
5. Minimal Services, Maximum Uptime
Every running service is an open door. Do you need Sendmail running if you use an external SMTP relay? Do you need Samba running on a public web server? Absolutely not.
Run chkconfig --list | grep '3:on' to see what starts at boot. Be ruthless. Turn off anything you don't recognize or need. A lean server is a fast server, and more importantly, a secure one.
Final Thoughts
Security is a process, not a product. You don't just "install security." You configure, monitor, and update. But it starts with a solid foundation. You need clean hardware, true virtualization isolation, and low-latency connectivity that doesn't route your traffic through three other countries before hitting the user.
If you are tired of wondering who else is on your shared server, or if your current host thinks "security" is just a buzzword, it might be time to move. CoolVDS offers dedicated Xen instances in our Oslo datacenter, hardened and ready for production.