Automating Security Compliance: From 'Personopplysningsloven' to PCI-DSS on Linux

If you are still manually editing /etc/ssh/sshd_config on every new server deployment, you are already non-compliant. In the current landscape of 2013, the volume of automated attacks targeting SSH and web applications means that "security through obscurity" is dead. For systems architects in Norway, the challenge is double-sided: you must defend against global botnets while strictly adhering to the Personopplysningsloven (Personal Data Act) enforced by Datatilsynet.

I have seen too many "secure" infrastructures crumble because a junior admin forgot to disable root login on a secondary node. Human error is the enemy of compliance. The only solution is code-driven infrastructure.

This guide details how to automate your security baseline on CoolVDS KVM instances (running CentOS 6 or Debian 7) to meet high-level compliance standards without sacrificing I/O performance.

The Foundation: Isolation Matters

Before we touch a single config file, we must address the architecture. Many budget providers push OpenVZ containers. For a compliance-heavy environment, OpenVZ is a risk. You share the kernel with every other tenant on the host. If there is a kernel-level exploit, your data separation is theoretical at best.

At CoolVDS, we prioritize KVM (Kernel-based Virtual Machine). This provides hardware-level virtualization. You get your own kernel, your own memory space, and true isolation. When you are explaining your security posture to an auditor, saying "We run on dedicated kernels" allows you to check boxes that container-based hosting simply cannot.

Automating Hardening with Puppet

We will use Puppet (currently version 3.x) to enforce state. Scripts fail; state engines ensure compliance drift is corrected automatically. If someone accidentally changes permissions on a critical file, Puppet changes it back on the next run.

1. Enforcing SSH Standards

The first step in any Norwegian VPS deployment is locking down access. We need to disable Protocol 1, forbid root login, and restrict users. Here is a Puppet class to enforce this:

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  => present,
    owner   => 'root',
    group   => 'root',
    mode    => '0600',
    content => template('ssh/sshd_config.erb'),
  }
}

Inside your sshd_config.erb template, ensure these lines are hardcoded:

Protocol 2
PermitRootLogin no
PasswordAuthentication no
X11Forwarding no
UseDNS no
AllowUsers deployer_user

Setting UseDNS no is a specific tip for improving login latency. Without it, the SSH daemon attempts a reverse DNS lookup on the client IP, which can stall logins for seconds if the DNS resolver is slow. Speed counts.

Kernel Level Hardening via Sysctl

Default Linux kernel settings are tuned for compatibility, not security. To mitigate DDoS attacks (like SYN floods) and disable IP routing (essential if your VPS is not a gateway), we apply sysctl rules.

Add these to /etc/sysctl.conf. On CoolVDS KVM instances, you have full write access to modify these kernel parameters:

# Disable IP Packet Forwarding
net.ipv4.ip_forward = 0

# Disable ICMP Redirect Acceptance
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0

# Log Spoofed Packets, Source Routed Packets, Redirect Packets
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.default.log_martians = 1

# Ignore ICMP Broadcasts (Smurf attack protection)
net.ipv4.icmp_echo_ignore_broadcasts = 1

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

Apply them immediately with:

Pro Tip: Many shared hosting providers block access to `sysctl` settings. This is a common point of failure in PCI-DSS audits which require specific kernel tuning. Because CoolVDS provides full root access on KVM, you can pass these validation checks effortlessly.

File Integrity Monitoring (FIM) with OSSEC

Compliance requires knowing when a file changed. If an attacker modifies /bin/ls or injects code into your PHP files, you need to know instantly. In 2013, OSSEC is the gold standard for open-source Host-based Intrusion Detection Systems (HIDS).

Install OSSEC on your server and configure the ossec.conf to watch critical directories. This satisfies the requirement for "integrity monitoring" found in most data protection standards.

  
  79200
  
  
  /etc,/usr/bin,/usr/sbin
  /bin,/sbin
  /var/www/html

  
  /etc/mtab
  /etc/mnttab
  /etc/hosts.deny

When a system file changes, OSSEC sends an alert. Combine this with our low-latency email relays, and you are notified before the attacker has even cleared their history.

Network Firewall: The Last Line of Defense

We use iptables. It is robust, proven, and integrated directly into the kernel. Do not rely on external cloud firewalls alone; host-based firewalls are mandatory for defense-in-depth.

Here is a strict ruleset for a web server. This drops everything by default and only opens what is necessary:

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

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

# Accept established connections
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

# SSH (Moved to non-standard port 2222 in this example)
-A INPUT -p tcp -m state --state NEW -m tcp --dport 2222 -j ACCEPT

# HTTP/HTTPS
-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

# ICMP (Ping) - Rate limited to prevent flood
-A INPUT -p icmp -m icmp --icmp-type 8 -m limit --limit 2/sec -j ACCEPT

COMMIT

Save this to /etc/sysconfig/iptables on CentOS and restart the service.

Data Sovereignty and Latency

Technical implementation is only half the battle. Legal compliance regarding where the data lives is becoming increasingly critical. With discussions in the EU about tightening data privacy regulations, hosting your data outside of the EEA is a gamble.

Latency is also a compliance factor—specifically regarding availability and usability. Hosting in a datacenter in Oslo ensures that your Norwegian users experience the lowest possible TTFB (Time To First Byte). A round-trip from Oslo to a US-based server can take 120ms+. A round-trip to the CoolVDS Oslo facility is often under 5ms.

When you automate your hardening on a platform built for performance and located within the correct legal jurisdiction, you stop worrying about audits and start focusing on development.

Ready to lock down your infrastructure? Deploy a KVM instance on CoolVDS today and get full root control to implement these security measures in minutes.