Lock It Down: Essential Linux Server Hardening Steps
Let’s be honest: a fresh Linux installation is not secure. Whether you just spun up a Debian Squeeze box or a CentOS 5.6 instance, that server is effectively sitting naked on the internet. In the time it takes you to read this paragraph, an automated bot scanner has likely already pinged port 22 on your new IP.
I’ve spent the last week cleaning up a mess for a client who thought a default root password was "good enough" for their staging environment. It wasn't. They got hit by a brute-force script that didn't even break a sweat. The result? A compromised server spewing spam, a blacklisted IP, and a very unhappy CTO.
Security isn't a product; it's a process. And in the Norwegian hosting market, where we value stability and compliance with the Personal Data Act (Personopplysningsloven), you cannot afford to be lax. Here is how we harden servers at CoolVDS to ensure your data stays yours.
1. Secure the Keys to the Castle (SSH)
The first vector of attack is almost always SSH. By default, most distributions allow root login with a password. This is suicide. We need to disable root login and switch to key-based authentication immediately.
Open your config file: /etc/ssh/sshd_config
# Protocol 2 is the only secure option in 2011. Protocol 1 is broken.
Protocol 2
# Disable root login. Create a sudo user instead.
PermitRootLogin no
# Turn off password auth. Use RSA keys.
PasswordAuthentication no
UsePAM no
# Change the default port to reduce log noise from dumb scripts
Port 2022
Restart the service (service ssh restart or /etc/init.d/ssh restart). Now, anyone trying to brute-force 'root' or use a dictionary attack on passwords will hit a brick wall. This singular change eliminates 99% of automated drive-by attacks.
2. The Firewall: Learn to Love iptables
I meet too many admins who rely on their hosting provider's edge firewall. That is a mistake. You need host-level protection. iptables is the kernel-level firewall standard, and while the syntax can be arcane, it is powerful.
A basic "deny all, allow specific" policy is your best friend. Here is a baseline script to lock down a web server:
# Flush existing rules
iptables -F
# Default policy: DROP everything
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# Allow loopback (localhost)
iptables -A INPUT -i lo -j ACCEPT
# Allow established connections (so you don't lock yourself out)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow SSH (on your custom port), HTTP, and HTTPS
iptables -A INPUT -p tcp --dport 2022 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# Save rules
/sbin/service iptables save
Pro Tip: Before applying the DROP policy on INPUT, make sure your SSH rule works. I once locked myself out of a remote server in a datacenter in Bergen during a snowstorm. Waiting for remote hands to reboot the box is a humiliation you want to avoid.
3. Ban the Abusers with Fail2Ban
Even with SSH hardened, your logs will fill up with failed login attempts. This is wasted I/O and CPU cycles. Install Fail2Ban. It scans log files like /var/log/secure or /var/log/auth.log and updates iptables to ban IPs that show malicious signs.
On Debian/Ubuntu:
apt-get install fail2ban
Configure it to ban an IP for an hour after 3 failed attempts. It’s simple, efficient, and keeps the noise down.
4. Updates and Patch Management
It sounds obvious, but unpatched software is the root cause of most breaches. In 2011, vulnerabilities in old kernels or unpatched Apache versions are rampant. Run yum update or apt-get update && apt-get upgrade weekly. Automate it with cron-apt if you must, but never let a production server drift too far from the repository.
5. The Architecture Factor: KVM vs. OpenVZ
Software hardening only goes so far if the underlying virtualization technology is flawed. This is where your choice of VPS provider matters.
Many budget hosts pack users onto OpenVZ containers. In that environment, you share the kernel with every other customer on the node. If a vulnerability is found in the host kernel, or if a "noisy neighbor" starts a fork bomb, your security and stability are compromised. You are effectively living in a hostel.
At CoolVDS, we exclusively use KVM (Kernel-based Virtual Machine). This provides true hardware virtualization. Your memory, disk I/O, and kernel are isolated. Even if a neighboring VM melts down, your instance keeps humming. This isolation is critical for compliance with strict Norwegian privacy standards enforced by Datatilsynet.
Why Speed helps Security
Security scanning, log rotation, and encryption overhead (SSL handshakes) all consume resources. On slow spinning disks (HDD), these background tasks can cause I/O wait times that degrade your web application's performance.
This is why we are aggressively rolling out enterprise SSD storage across our Oslo datacenter. The low latency of solid-state drives means your security processes execute instantly without stealing cycles from your PHP or Python workers. While the industry is just starting to talk about future NVMe standards, we are already delivering the fastest SSD block storage available today.
Conclusion
Security is about reducing surface area. By locking down SSH, configuring a tight iptables firewall, and choosing a virtualization platform that offers true isolation, you drastically reduce your risk profile.
Don't wait for a breach to take this seriously. If you need a sandbox to test these configurations, spin up a KVM instance on CoolVDS. With our low latency to the Norwegian internet exchange (NIX), you get a secure, responsive environment to build your infrastructure right.