Linux Server Hardening 2012: The Battle-Tested Guide for Norwegian SysAdmins

Let’s be honest: the internet in 2012 is becoming a hostile environment. We just watched the massive LinkedIn and Last.fm breaches happen back in June, and if that didn't wake you up, nothing will. I’ve spent the last week cleaning up a client's compromised eCommerce stack because they thought a default CentOS 5 install with root:password123 was sufficient. It wasn't.

If you are managing infrastructure, whether it's a dedicated box in a basement in Trondheim or a VPS in a major datacenter, security is no longer an "afterthought." It is the foundation. As systems architects, we need to move beyond basic setups and implement defense-in-depth.

This guide is written for the Battle-Hardened DevOps professional. We aren't using GUI tools here. We are diving into configuration files, setting up stateful firewalls, and ensuring that when the bots come knocking (and they will), your server stays standing. We will focus on CentOS 6.3 and Ubuntu 12.04 LTS, as these are the current workhorses of our industry.

1. The Front Door: SSH Hardening

Running SSH on port 22 with password authentication enabled is suicide. Script kiddies run scanners 24/7 looking for that specific configuration. The moment you provision a server, your first task is to secure the access method.

Key-Based Authentication Only

Passwords are prone to brute-force attacks. SSH keys are cryptographic proof of identity. Generate a 2048-bit RSA key pair on your local machine if you haven't already:

ssh-keygen -t rsa -b 2048

Once your public key is on the server (in ~/.ssh/authorized_keys), edit your daemon config. This is non-negotiable.

# File: /etc/ssh/sshd_config

# Change the default port to reduce log noise
Port 2202

# Disable root login. Login as user, then su/sudo.
PermitRootLogin no

# Disable password authentication entirely
PasswordAuthentication no
ChallengeResponseAuthentication no

# Use Protocol 2 only (Protocol 1 is insecure)
Protocol 2

# Restrict allowed users
AllowUsersdeploy masteradmin

Restart the service (service sshd restart). If you lose connection now, you did it wrong. Always keep a secondary session open when messing with SSH configs.

Pro Tip: On CoolVDS KVM instances, you have VNC console access via our portal. If you lock yourself out while hardening SSH, you can use the out-of-band console to revert changes. This is a lifesaver that OpenVZ containers often lack.

2. The Shield: IPTables Stateful Firewall

Many providers deliver servers with empty firewall rules. You need a stateful firewall that tracks connection states. We are using iptables here. Forget about fancy wrappers; learn the raw syntax.

Here is a robust starting configuration for a web server. It drops everything by default and only opens what is necessary.

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]

# 1. Accept loopback traffic
-A INPUT -i lo -j ACCEPT

# 2. Accept established and related connections (Stateful)
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# 3. Allow SSH on our custom port
-A INPUT -p tcp --dport 2202 -j ACCEPT

# 4. Allow HTTP and HTTPS
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT

# 5. Allow ICMP (Ping) - useful for monitoring latency to NIX (Norwegian Internet Exchange)
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT

# Log dropped packets (careful with disk I/O on high traffic)
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 7

COMMIT

Apply this by editing /etc/sysconfig/iptables on CentOS or using iptables-save on Debian systems.

3. The Watchdog: Fail2Ban

Even with keys and a custom port, your logs will fill up with failed attempts. Fail2Ban scans log files and bans IPs that show malicious signs. It updates your IPTables rules dynamically.

Install it via EPEL repo on CentOS:

rpm -Uvh http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-7.noarch.rpm
yum install fail2ban

Configure a jail for SSH. In /etc/fail2ban/jail.local:

[ssh-iptables]
enabled  = true
filter   = sshd
action   = iptables[name=SSH, port=2202, protocol=tcp]
logpath  = /var/log/secure
maxretry = 3
bantime  = 3600

This simple step drastically reduces background noise and protects against dictionary attacks.

4. Kernel Tuning via Sysctl

The default Linux kernel settings are often too polite. We need to harden the networking stack against SYN floods and spoofing. Add these to /etc/sysctl.conf:

# Enable SYN cookies to defend against SYN floods
net.ipv4.tcp_syncookies = 1

# Log spoofed packets, source routed packets, and redirect packets
net.ipv4.conf.all.log_martians = 1

# Disable ICMP broadcasting
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Ignore bogus ICMP errors
net.ipv4.icmp_ignore_bogus_error_responses = 1

# Disable source routed packets
net.ipv4.conf.all.accept_source_route = 0

Run sysctl -p to apply.

5. The Infrastructure Factor: Why CoolVDS?

You can configure software all day, but if your underlying architecture is weak, you are building on sand. In Norway, data sovereignty is becoming a massive topic with the Personal Data Act (Personopplysningsloven) and the oversight of Datatilsynet. You need to know exactly where your data lives.

At CoolVDS, we don't oversell our nodes. We use KVM (Kernel-based Virtual Machine) virtualization exclusively. Unlike OpenVZ, KVM provides true hardware isolation. If a neighbor gets hit with a DDoS, your kernel is separate. Your memory is reserved.

Performance meets Security

Security scanning and encryption (SSL/TLS) eat CPU cycles. You need fast I/O to handle logs and database transactions without locking up. While many hosts are still spinning 7.2k RPM SAS drives, we are rolling out high-performance SSD storage arrays. The difference in I/O wait times is night and day.

Final Thoughts

Security is a process, not a product. Keep your systems updated (yum update is your friend), monitor your logs, and choose a provider that respects the technical demands of 2012.

If you need a robust, low-latency environment to test these hardening scripts, don't settle for oversold shared environments. Deploy a test instance on CoolVDS today and experience the stability of true KVM isolation paired with Norwegian connectivity.