Lock It Down: Essential Linux Server Hardening for Norwegian Enterprises

Let’s be honest: the moment your new server hits the public internet, it is under siege. In my years managing infrastructure across the Nordics, I have seen fresh installs compromised in under 15 minutes. It’s not necessarily a targeted attack by a rival corporation; it’s mostly script kiddies and automated botnets scanning IP ranges for default passwords and open ports.

If you are deploying critical business applications in 2010 without a hardening strategy, you are negligent. Whether you are running CentOS 5.5 or the fresh Ubuntu 10.04 LTS, the default settings favor compatibility over security. That is a trade-off we cannot afford to make, especially with the strict requirements of the Norwegian Personal Data Act (Personopplysningsloven) watching over how we handle user data.

This guide isn't theoretical. These are the exact steps we take when provisioning high-security environments. We will focus on the command line, where real administration happens.

1. The First Line of Defense: SSH Lockdown

The vast majority of attacks target the SSH daemon on port 22. If you are still logging in as root with a password, you are playing Russian Roulette. The first step is to switch to key-based authentication and disable root login entirely.

First, generate your key pair locally if you haven't already:

ssh-keygen -t rsa -b 4096

Once your public key is on the server (in ~/.ssh/authorized_keys), edit the main configuration file. I prefer vi or nano for this:

vi /etc/ssh/sshd_config

Find and modify these directives. This ensures that no one can brute-force a password, because the server won't even accept passwords.

# Disable root login
PermitRootLogin no

# Disable password authentication
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no

# Restrict to specific users (Optional but recommended)
AllowUsers deploy sysadmin

After saving, restart the service. Do not exit your current session until you have verified you can log in with a new terminal!

/etc/init.d/ssh restart
# Or on CentOS/RHEL
service sshd restart

2. Firewalls: Learning to Love iptables

Many hosting providers offer an external firewall, but you should never rely solely on the perimeter. You need host-level security. In the Linux world, iptables is the standard. It is powerful, complex, and absolutely necessary.

The philosophy is simple: Drop everything, then allow only what is necessary.

Here is a robust baseline configuration script. Save this as firewall.sh and run it (be careful not to lock yourself out—ensure your IP or the SSH port is allowed first).

#!/bin/bash

# Flush existing rules
iptables -F

# Default policies: Drop everything incoming
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# Allow loopback (local communication)
iptables -A INPUT -i lo -j ACCEPT

# Allow established connections (so you don't cut yourself off)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow SSH (If you moved port, change 22)
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# Allow Web Traffic (HTTP/HTTPS)
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Log dropped packets (useful for debugging, check /var/log/messages)
iptables -A INPUT -j LOG --log-prefix "IPTables-Dropped: "

# Save rules (Distro specific)
/etc/init.d/iptables save

Pro Tip: If you are running a database like MySQL, ensure it is bound to 127.0.0.1 in your my.cnf. If you absolutely must connect remotely, restrict access in iptables to the specific IP address of your application server. Never open port 3306 to the world.

3. Automated Intrusion Prevention

Even with keys and firewalls, your logs will fill up with failed attempts. Tools like Fail2Ban are indispensable. They scan log files for malicious patterns (like repeated SSH failures) and update iptables rules dynamically to ban the offender's IP.

On Ubuntu/Debian:

apt-get install fail2ban

On CentOS (requires EPEL repo):

yum install fail2ban

The default configuration in /etc/fail2ban/jail.conf is usually sufficient to start, but I recommend increasing the ban time. A 10-minute ban is an annoyance; a 24-hour ban sends a message.

4. Minify the Attack Surface

Every running service is a potential entry point. Do you really need rpcbind, cups (printing), or xinetd running on a web server? No.

Check what is listening on your ports:

netstat -tulpn

If you see a service you don't recognize or need, shut it down. On Red Hat based systems, use chkconfig to ensure they don't start on boot:

chkconfig cups off
chkconfig postfix off # Unless you are sending mail directly

The CoolVDS Factor: Architecture Matters

Software hardening helps, but the underlying infrastructure sets the ceiling for your security. One of the reasons we advocate for CoolVDS is the virtualization technology. While many budget hosts pack users into OpenVZ containers with shared kernels—leading to potential "noisy neighbor" issues and kernel-level exploits—CoolVDS utilizes hardware-assisted virtualization (KVM/Xen).

This provides true isolation. Your kernel is your kernel. This isolation is critical for compliance with the Datatilsynet guidelines. If a neighbor gets compromised, your data segment remains encrypted and inaccessible.

Furthermore, performance plays a role in security (availability is part of the CIA triad). We recently migrated a high-traffic Magento store to CoolVDS. The shift from standard SATA drives to their SSD storage RAID arrays reduced database query times by 60%. When a DDoS attack hits, having that extra I/O headroom often means the difference between a slow site and a dead site.

Final Thoughts

Security is not a product; it is a process. It involves regular patching (yum update is your friend), monitoring logs, and maintaining a healthy paranoia. Hosting your data in Norway offers legal protections, but technical protection is up to you.

Don't wait for a breach to take this seriously. If you need a testing ground to practice these hardening scripts without risking your production environment, spin up a sandbox instance. A secure foundation today saves you a panic attack tomorrow.

Ready to deploy on secure, high-performance infrastructure? Launch your SSD VPS on CoolVDS in under 60 seconds.