Automating Compliance: Hardening KVM Instances for Norwegian Data Laws

If you are manually editing /etc/ssh/sshd_config on twenty different servers, you aren't just wasting time. You are building a legal liability. In the wake of the 2013 surveillance revelations, data sovereignty has shifted from a buzzword to a boardroom crisis. For those of us hosting in Norway, the Personopplysningsloven (Personal Data Act) isn't a suggestion. It is a mandate.

The Datatilsynet (Norwegian Data Protection Authority) does not accept "I forgot to run the script" as a valid defense during a breach. We need determinism. We need infrastructure that enforces its own security.

This guide abandons the GUI. We are going deep into automating compliance on Ubuntu 12.04 LTS and CentOS 6 using Puppet and raw shell scripting. We will build a baseline that passes a PCI-DSS scan and keeps your data strictly within Norwegian borders.

The "Root Login" War Story

I recently audited a legacy infrastructure for a Bergen-based e-commerce client. They claimed to be secure. They had firewalls. They had complex passwords. But during a migration, a junior admin had spun up a temporary database node to debug a MySQL replication lag issue. He enabled password authentication "just for an hour."

He forgot.

Three days later, a brute-force botnet from Eastern Europe found it. Because the server had a trusted private IP link to the main database, the attackers pivoted. We caught it only because the egress traffic spiked on the monitoring graphs. The fix isn't telling admins to be careful. The fix is a configuration management agent that wakes up every 30 minutes, sees PasswordAuthentication yes, and mercilessly changes it back to no.

Phase 1: The Foundation (KVM vs. The Rest)

Compliance starts at the hypervisor. Many "cheap" VPS providers use OpenVZ. In an OpenVZ container, you share the kernel with every other tenant on the host. If there is a kernel panic in a neighbor's container, you go down. Worse, kernel-level exploits can potentially bleed through.

For compliant hosting, we rely on KVM (Kernel-based Virtual Machine). This is why CoolVDS exclusively deploys KVM. You get your own kernel. Your memory is hardware-virtualized. It is the closest you get to bare metal isolation without the dedicated server price tag. Do not risk your audit trail on shared kernels.

Phase 2: Automating the Host Firewall

Forget UFW for a moment. We need granular control. We will use a raw iptables script that drops everything by default. This script should be injected via your provisioning system (Kickstart, Preseed, or a post-install script).

Here is a battle-tested configuration for a web server. It handles the "INVALID" packet drop which mitigates certain types of scan attacks.

#!/bin/bash
# Flush existing rules
iptables -F

# Default Policies: DROP EVERYTHING
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

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

# Allow established connections (Critical for SSH not to lock you out)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Drop invalid packets immediately
iptables -A INPUT -m state --state INVALID -j DROP

# Allow SSH (Change 22 to your custom port)
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# Web Traffic
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

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

# Save rules
/sbin/service iptables save

Pro Tip: On CoolVDS instances, the I/O performance from the underlying storage allows for aggressive logging without stalling the CPU. However, always setup logrotate to prevent /var/log from filling up and crashing the system.

Phase 3: Configuration Management with Puppet

Shell scripts are great for initialization, but they don't maintain state. For that, we use Puppet. Even a simple standalone Puppet manifest can ensure your SSH configuration never drifts.

Install Puppet on your master node (or use `puppet apply` locally for standalone nodes). Here is a manifest that enforces the Norwegian security baseline: disabling Protocol 1, root logins, and empty passwords.

class ssh_hardening {

  package { 'openssh-server':
    ensure => installed,
  }

  service { 'ssh':
    ensure     => running,
    enable     => true,
    hasstatus  => true,
    hasrestart => true,
    subscribe  => File['/etc/ssh/sshd_config'],
  }

  file { '/etc/ssh/sshd_config':
    ensure  => present,
    owner   => 'root',
    group   => 'root',
    mode    => '0600',
    content => template('ssh/sshd_config.erb'),
  }
}

And the corresponding sshd_config.erb template values you must enforce:

Port 22
Protocol 2
PermitRootLogin no
PasswordAuthentication no
X11Forwarding no
UsePAM yes
UseDNS no

Kernel Hardening (sysctl)

To mitigate SYN floods and IP spoofing—common noise in the European threat landscape—add these to /etc/sysctl.conf. This is essential for any server facing the public internet.

# Ignore ICMP echo requests (Ping)
net.ipv4.icmp_echo_ignore_all = 1

# Disable IP forwarding
net.ipv4.ip_forward = 0

# Enable TCP SYN Cookie Protection
net.ipv4.tcp_syncookies = 1

# Log packets with impossible addresses
net.ipv4.conf.all.log_martians = 1

Run sysctl -p to apply. If you are on a legacy platform, these settings might fail. On CoolVDS KVM instances, you have full control over these kernel parameters.

Data Sovereignty and Latency

The elephant in the room is the location of the physical drive. The Safe Harbor framework is under scrutiny. Relying on US-based cloud giants creates a legal grey area for Norwegian businesses handling sensitive customer data.

By hosting on CoolVDS, your data resides physically in Oslo. This solves two problems:

1. Legal: You comply with the strict interpretation of the Personal Data Act. The data never crosses the Atlantic.
2. Performance: Physics is undefeated. If your customers are in Oslo, a packet round trip to a Virginia datacenter takes 90ms. To a local datacenter? 2ms.

The Storage Bottleneck

Encryption costs CPU cycles and I/O. If you are using dm-crypt or LUKS for full disk encryption (a best practice for physical theft protection), standard SATA SSDs can become a bottleneck under high load.

We are seeing a massive shift towards PCIe-based flash storage. While still expensive in the enterprise market, CoolVDS has integrated high-performance SSD arrays that mitigate the I/O penalty of on-the-fly encryption. This means you can be compliant (encrypted at rest) without being slow.

Next Steps

Compliance is a process, not a destination. Start by codifying your firewall and SSH configurations today.

Don't let legacy infrastructure compromise your legal standing. Deploy a KVM instance in Oslo today with CoolVDS, verify the latency yourself, and lock it down before the audit comes.