Lockdown: Essential Linux Server Hardening Steps

Let’s be honest: the moment you plug a server into the public internet, it becomes a target. I deployed a fresh CentOS 5 box last Tuesday, and within 12 minutes, /var/log/secure was already scrolling with failed login attempts from IPs in China and Brazil. It’s not personal. It’s automated.

If you are running a business in Norway, you cannot afford downtime caused by a script kiddie running a dictionary attack. You need a fortress, not a sandbox. Here is how we lock down production servers at CoolVDS, and how you should configure yours.

1. Kill the Root Login (SSH Hardening)

The default SSH configuration is too permissive. Allowing direct root login is suicide. If an attacker guesses your root password, they own the machine.

First, create a wheel-group user for yourself:

Once you verify you can log in as 'viking' and su - to root, edit your sshd config. We need to disable protocol 1 (it is ancient and broken) and stop root logins.

Change these lines:

Pro Tip: Moving SSH to a non-standard port (like 2222) stops 99% of automated scanners. It is security through obscurity, but it keeps your logs clean. Just remember to update your iptables first.

2. The Firewall: Learn to Love iptables

I still see sysadmins relying on hosts.allow. Stop it. You need a packet filter. iptables is the standard in the Linux kernel (2.4 and 2.6).

A default policy should be DROP. If you don't explicitly allow it, it shouldn't get in. Here is a baseline script we use for web servers:

Save it. On CentOS/RedHat:

Without this, a reboot wipes your security. Don't be that guy.

3. Fail2Ban: The Bouncer

Even with a firewall, port 22 (or 80) needs to be open. Brute-force attacks can still hammer these ports, wasting CPU cycles and filling logs. Enter Fail2Ban. It parses your log files and updates iptables rules dynamically to ban IPs that show malicious signs.

Install it from the EPEL repo:

Configure jail.conf to ban an IP for an hour after 3 failed SSH attempts. It is simple, lightweight, and effective.

4. The Norwegian Advantage: Data Privacy & Latency

Security isn't just about hackers; it's about jurisdiction. If you host on US-based servers, you are subject to the Patriot Act, which allows US agencies to access data without a warrant.

For Norwegian businesses, adhering to the Personal Data Act (Personopplysningsloven) is mandatory. Hosting physically in Oslo ensures your data stays under Norwegian jurisdiction and the oversight of Datatilsynet.

Plus, there is the physics of it. Pinging a server in Texas takes 130ms. Pinging a CoolVDS instance in Oslo via NIX (Norwegian Internet Exchange) takes 2-5ms. Low latency makes your SSH sessions feel like you're typing on the local machine.

5. The Hardware Factor: Xen vs. The Rest

Software security means nothing if your neighbor on the physical host can crash your kernel. This is why we avoid container-based virtualization like OpenVZ for serious workloads. It shares the kernel.

At CoolVDS, we use Xen virtualization. It provides true hardware isolation. Your RAM is yours. Your swap is yours. If another customer forks a bomb, your server keeps humming.

We back this with enterprise-grade SAS 15k RPM RAID-10 arrays. While standard SATA drives struggle under high I/O loads (like during a backup or log rotation), our SAS arrays maintain high throughput. It’s not just about speed; it’s about stability under load.

Final Thoughts

Security is a process, not a product. Run yum update nightly. Watch your logs. And choose a host that understands the difference between a cheap container and a hardened Xen VPS.

Need a secure baseline? Deploy a CoolVDS Xen instance in Oslo today. We handle the hardware; you handle the code.