Automating Server Hardening: Meeting Norwegian Compliance Without the Headache

Let’s be honest: if you are still manually editing /etc/ssh/sshd_config on every new server deployment, you are doing it wrong. It is 2013. We have tools for this. Yet, I still see sysadmins in Oslo logging into production boxes as root, typing yum update by hand, and calling it “maintenance.”

That approach doesn't scale, and more importantly, it doesn't satisfy the auditors. With the increasing scrutiny from Datatilsynet (The Norwegian Data Protection Authority) and the strict requirements of the Personopplysningsloven (Personal Data Act), relying on human memory to secure a server is a direct path to a fine—or a breach.

I’ve spent the last month migrating a financial services client from a mess of shared hosting accounts to a proper dedicated VPS infrastructure. The biggest challenge wasn't the migration itself; it was proving that every single node was compliant with their internal security policy 24/7. Here is how we automated the hardening process, ensuring every CoolVDS instance launched is a fortress from the first second of uptime.

The War Story: The "Permissive" Firewall

In a previous project, a developer disabled iptables to debug a connectivity issue with a MySQL replication slave. He forgot to turn it back on. Three days later, we noticed a massive spike in outgoing traffic. A script kiddie had found the open port 3306, brute-forced a weak root password, and was using the server to scan other networks.

The cleanup took 14 hours. The reputational damage took months to repair. The lesson? Security cannot be an opt-in process. It must be baked into the provisioning layer. If you are deploying on a platform like CoolVDS, you have the advantage of KVM virtualization, which gives us a true kernel separation—unlike OpenVZ containers where a kernel exploit could theoretically expose the host. But the OS inside that KVM slice is still your responsibility.

Phase 1: The Base Hardening Script

Before we even touch configuration management tools, every server needs a bootstrap script. This runs immediately after provisioning. We focus on CentOS 6.4 here, as it is the current stability king for enterprise workloads.

This script handles the basics: disabling root login, setting up a firewall, and removing unused services.

#!/bin/bash
# excessive-hardening.sh - v1.2 (2013)

# 1. Create a sudo user (never use root directly)
useradd deployer
echo "deployer:SuperSecurePassword123!" | chpasswd
usermod -aG wheel deployer

# 2. Hardening SSH
sed -i 's/#PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config
sed -i 's/PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config

# 3. Network Hardening (sysctl)
cat <<EOF >> /etc/sysctl.conf
# Disable IP Packet Forwarding
net.ipv4.ip_forward = 0
# Ignore ICMP Broadcasts
net.ipv4.icmp_echo_ignore_broadcasts = 1
# Protect against SYN Floods
net.ipv4.tcp_syncookies = 1
EOF
sysctl -p

# 4. Basic IPTables (Deny all by default)
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# Allow loopback and established connections
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow SSH and Web
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

service iptables save
service iptables restart

Pro Tip: Always test your firewall rules with a cron job scheduled to stop the firewall in 5 minutes (service iptables stop). If you lock yourself out, the cron job will save you. If it works, delete the cron job.

Phase 2: Continuous Compliance with Puppet

Scripts are great for one-off setups, but configuration drift is real. Someone changes a permission for a "quick test" and never changes it back. To adhere to Norwegian compliance standards regarding access control and integrity, we need state enforcement. Enter Puppet.

Puppet allows us to define the desired state of the system. If a file changes, Puppet changes it back. This is critical for maintaining the "integrity" principle of the Data Protection Act.

Defining a Secure SSH Class

Instead of relying on the shell script above forever, we move the logic into a Puppet manifest. This ensures that across 50 CoolVDS instances, the policy is identical.

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

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

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

In your sshd_config.erb template, you ensure strict modes are enabled:

Protocol 2
SyslogFacility AUTHPRIV
PermitRootLogin no
MaxAuthTries 3
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no
ChallengeResponseAuthentication no
GSSAPIAuthentication no
UsePAM yes

Why Infrastructure Choice Matters for Compliance

Software hardening is useless if the physical layer is compromised or if the legal jurisdiction is ambiguous. This is where the choice of hosting provider becomes a compliance decision, not just a technical one.

Under the EU Data Protection Directive (95/46/EC), transferring personal data outside the EEA requires strict adherence to Safe Harbor principles (if using US providers) or standard contractual clauses. However, for Norwegian entities, keeping data on Norwegian soil—or at least within the EEA—simplifies the legal burden significantly.

We choose CoolVDS for critical workloads for three specific reasons:

1. Data Sovereignty: Their data centers are located locally. This means latency to the NIX (Norwegian Internet Exchange) is often sub-2ms, but more importantly, the data stays under Norwegian jurisdiction.
2. True Hardware Virtualization (HVM): CoolVDS uses KVM. Unlike container-based VPS (OpenVZ), KVM provides a higher degree of isolation. You run your own kernel. This prevents "noisy neighbor" issues where another customer's high load impacts your I/O, and it adds a critical security boundary.
3. SSD Performance: While not a security feature per se, fast I/O reduces the window of vulnerability during backups and updates. We have benchmarked their SSD arrays against standard SATA VPS providers, and the difference in yum update execution time is staggering. Less time patching means higher availability.

Auditing the Setup

Finally, you need to verify your work. You can use Lynis, an open-source security auditing tool that is gaining traction. It scans the system and provides a hardening index.

cd /usr/local/src
wget http://cisofy.com/files/lynis-1.3.0.tar.gz
tar xfvz lynis-1.3.0.tar.gz
cd lynis-1.3.0
./lynis -c

If you have followed the steps above, your score should be well above 80. If you are running a default install from a budget provider, you will likely score below 40.

The Verdict

Compliance is not about checking boxes; it is about architecture. By combining automated provisioning scripts, Puppet for state management, and the robust isolation of CoolVDS KVM instances, you create an environment that is secure by default.

Don't wait for a letter from Datatilsynet to take this seriously. Secure your infrastructure today.

Need a compliant, high-performance environment to test your hardening scripts? Spin up a CoolVDS instance in Oslo. The network latency is low, but the security standards are high.