The Paranoid Sysadmin’s Guide to Linux Server Hardening
I watched a fresh CentOS 5 installation get compromised in exactly 14 minutes last Tuesday. It wasn't a targeted attack by a state-sponsored hacker group; it was a dumb, automated script scanning for weak root passwords on port 22.
If you are deploying servers in 2011 without a hardening checklist, you aren't an admin; you're a victim. Whether you are hosting a high-traffic e-commerce site targeting the Oslo market or a backend for a mobile app, security is not an 'add-on'. It is the baseline.
Here is how we lock down boxes at CoolVDS to ensure our clients don't wake up to a defaced website or a massive spam relay bill.
1. Kill the Root Login
The root user is the holy grail for attackers. If they crack it, they own your hardware. The first thing I do on any new server—before I even run an update—is create a sudo-user.
useradd deployer
passwd deployer
usermod -aG wheel deployer # For CentOS
Once you verify you can sudo with this new user, go into /etc/ssh/sshd_config and set the following flag. This forces attackers to guess both a username and a password, exponentially increasing the difficulty of a brute-force attack.
PermitRootLogin no
2. SSH Keys or Go Home
Passwords are dead. In an era where rainbow tables and dictionary attacks are trivial, relying on an 8-character string is negligence. Generate a 2048-bit RSA key pair.
On your local machine:
ssh-keygen -t rsa -b 2048
Push it to your server. Then, edit sshd_config again to disable password authentication entirely:
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no
Now, the only way into that box is with the private key sitting on your laptop.
3. The Firewall: iptables is Your Best Friend
Many admins are intimidated by iptables syntax. They rely on the hosting provider's external firewall. That is a mistake. You need host-level security. If an attacker bypasses the perimeter, your server needs to defend itself.
I operate on a policy of "deny everything, permit necessity". Here is a standard strict ruleset for a web server:
# Flush existing rules
iptables -F
# Default policies: DROP everything
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# Allow established connections (so you don't lock yourself out)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow loopback
iptables -A INPUT -i lo -j ACCEPT
# Open SSH (Custom port recommended), HTTP, HTTPS
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
Save these rules. On RedHat/CentOS systems, use service iptables save.
4. Brute Force Prevention with Fail2Ban
Even with keys, your logs will be flooded with failed login attempts. This wastes CPU cycles and fills up disk space. Install Fail2Ban. It parses your log files (like /var/log/secure) and updates your iptables rules dynamically to ban IP addresses that show malicious behavior.
Pro Tip: Don't just protect SSH. Configure Fail2Ban jails for Apache or Nginx to block bots scraping your site for vulnerabilities. A simple jail configuration can drop an IP for an hour after 3 failed attempts.
5. The Norwegian Context: Data Residency and Latency
If you are operating out of Norway, you are likely dealing with sensitive customer data. Under the Personopplysningsloven (Personal Data Act), you have a responsibility to secure this data. Hosting your data outside the EEA can introduce legal headaches regarding Safe Harbor frameworks.
Furthermore, latency matters. If your users are in Oslo or Bergen, routing traffic through a datacenter in Frankfurt or Amsterdam adds unnecessary milliseconds. Local peering at NIX (Norwegian Internet Exchange) ensures your packets take the shortest path.
Why Virtualization Technology Matters for Security
Not all VPS hosting is created equal. Many budget providers use OpenVZ. In OpenVZ, all containers share the same kernel. If a vulnerability is found in the host kernel, every single container on that node is potentially exposed.
At CoolVDS, we exclusively use KVM (Kernel-based Virtual Machine). This provides true hardware virtualization. Each instance has its own isolated kernel. Even if a neighbor on the physical node gets compromised, your environment remains secure behind the hypervisor wall. Combine that with our RAID-10 Enterprise SSD storage, and you get security without sacrificing I/O performance.
Final Thoughts
Security is a process, not a product. Run yum update regularly, monitor your logs, and never assume you are too small to be a target.
Need a secure, low-latency environment to test these configurations? Deploy a KVM instance on CoolVDS today. Our datacenters are in Oslo, fully compliant with Norwegian regulations, and built for professionals who refuse to compromise on stability.