Automating Compliance: Server Hardening and Sovereignty in Post-Snowden Norway

It is 3:00 AM. Do you know where your data is? If you are hosting customer data in Norway, the answer needs to be more specific than "the cloud." Following the Snowden revelations last year, the concept of "Safe Harbor" is shaking. For Norwegian businesses, relying on US-owned infrastructure is no longer just a technical choice; it is a liability risk.

As a CTO, I have sat across the table from auditors asking uncomfortable questions about Personopplysningsloven (The Personal Data Act). They don't care about your uptime graphs. They care about access controls, physical location, and data integrity. Manual hardening is a recipe for human error. If you are typing commands into a terminal one by one to secure a production server, you have already failed.

The Foundation: Virtualization Matters

Before we touch a single config file, we must address the architecture. In the Nordic hosting market, you will see a lot of cheap providers pushing OpenVZ containers. For a personal blog, that is fine. For compliance? It is a gamble.

Shared kernels mean shared vulnerabilities. If a neighbor on the same physical node exploits a kernel panic, your segment goes down with them. Or worse, memory isolation fails.

At CoolVDS, we strictly utilize KVM (Kernel-based Virtual Machine). This provides full hardware virtualization. Each VPS runs its own kernel. You get a dedicated block device, distinct memory registers, and complete isolation. When you run uname -r, you see your kernel, not the host's.

Automating the Fortress: The Baseline Script

Consistency is the enemy of risk. We need a baseline hardening script that runs on every new deployment immediately after the root password is set. Below is a shell-based approach suitable for CentOS 6 or Debian 7 (Wheezy) systems. While tools like Puppet 3.x are excellent for fleet management, a raw bash script ensures the initial lock-down happens without external dependencies.

1. SSH Hardening

The default sshd_config is too permissive. We need to disable root login, enforce protocol 2, and ban empty passwords. Here is the sed-fu to handle it automatically:

#!/bin/bash
# Hardening SSHD Configuration
CONFIG="/etc/ssh/sshd_config"

# Backup original config
cp $CONFIG $CONFIG.bak.$(date +%F)

# Apply Security Settings
sed -i 's/^#Protocol 2/Protocol 2/' $CONFIG
sed -i 's/^#PermitRootLogin yes/PermitRootLogin no/' $CONFIG
sed -i 's/^PermitRootLogin yes/PermitRootLogin no/' $CONFIG
sed -i 's/^#PermitEmptyPasswords yes/PermitEmptyPasswords no/' $CONFIG
sed -i 's/^X11Forwarding yes/X11Forwarding no/' $CONFIG

# Restrict Users (Add your specific admin user)
# echo "AllowUsers deploy_admin" >> $CONFIG

echo "SSH Hardening applied. Restarting service..."
service ssh restart

Pro Tip: Always create your sudo user and test the connection before running the script above. I once locked myself out of a remote node in Tromsø while sitting in Oslo. The latency wasn't the problem; the 4-hour drive to fix it was.

The Firewall: IPtables is Your Best Friend

While some are waiting for the next big firewall daemon, good old iptables remains the gold standard for packet filtering in 2014. It is granular, stateless (or stateful if you tell it to be), and present on every Linux box.

A compliant server should operate on a "default drop" policy. Nothing gets in unless explicitly invited.

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

# Allow loopback
-A INPUT -i lo -j ACCEPT

# Allow established connections (crucial!)
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

# SSH (Ensure you use your custom port if changed)
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT

# Web Traffic
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT

# Log dropped packets (Optional, be careful with disk I/O)
# -A INPUT -j LOG --log-prefix "IPTables-Dropped: "

COMMIT

Save this to /etc/sysconfig/iptables (RHEL/CentOS) or load it via `iptables-restore`. This configuration ensures that even if a service accidentally binds to a public interface, the network layer blocks the traffic.

File Integrity Monitoring (FIM)

Datatilsynet often asks: "How do you know if a system binary was modified?" If you don't have an answer, you are non-compliant. In 2014, AIDE (Advanced Intrusion Detection Environment) is the lightweight answer to Tripwire.

Install it, initialize the database, and cron it.

yum install aide -y
aide --init
mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

# Add to crontab to run daily at 3am
echo "0 3 * * * root /usr/sbin/aide --check" >> /etc/crontab

This creates a snapshot of file hashes (md5/sha1). If a rootkit modifies /bin/ls, AIDE will scream about it in the morning logs.

Data Locality and Latency

Beyond security, there is performance. Serving Norwegian users from a datacenter in Frankfurt or Amsterdam introduces an unavoidable latency penalty—usually 15-30ms. Serving them from Oslo? You are looking at 2-5ms.

When you combine strict KVM isolation with local peering, you get a system that is both compliant and fast. This is why CoolVDS invests heavily in local infrastructure. We utilize enterprise-grade SSDs in RAID arrays to ensure that when your database writes a transaction log, it happens instantly, and it stays within Norwegian borders.

Comparison: Hosting Locations

Summary

Compliance is not a product; it is a process. But it is a process that must be built on the right infrastructure. By choosing KVM over OpenVZ and automating your hardening with scripts, you reduce the surface area for attack.

Do not wait for an audit to reveal your weak points. Deploy a secure, low-latency KVM instance on CoolVDS today, and keep your data exactly where it belongs: safe, fast, and in Norway.