Automating Compliance: Hardening CentOS 6 for Norwegian Data Standards
If you are still manually editing /etc/ssh/sshd_config on every new server deployment, you are already compromised. It’s not a matter of if, but when a human error will leave port 22 open to the world or a default MySQL password exposed.
In the Norwegian hosting market, we don't just deal with script kiddies; we deal with the Datatilsynet (The Norwegian Data Protection Authority). With the current discussions around the EU Data Protection Reform (the proposed regulation replacing Directive 95/46/EC), the scrutiny on how we handle personally identifiable information (PII) is tightening. Under the Personopplysningsloven (Personal Data Act of 2000), security cannot be an afterthought.
I’ve spent the last month auditing infrastructure for a Bergen-based fintech startup. Their "security strategy" was a wiki page of commands that the junior admin was supposed to copy-paste. That doesn't scale. Today, we look at automating compliance using Puppet on a clean KVM architecture.
The Architecture of Trust: Why Virtualization Matters
Before we touch code, we must address the substrate. Compliance often dictates strict data segregation. This is where many cheap VPS providers fail you.
Many hosts oversell resources using OpenVZ. In an OpenVZ container, you share the kernel with every other customer on the node. You cannot modify kernel parameters (sysctl) critical for hardening, and strict SELinux policies can be impossible to enforce inside a container.
Pro Tip: For compliance-heavy workloads, always insist on KVM (Kernel-based Virtual Machine) virtualization. KVM provides full hardware virtualization, meaning you run your own kernel. This is standard on all CoolVDS instances, allowing you to enable LUKS disk encryption—a requirement often cited for storing sensitive PII.
Step 1: The Baseline Puppet Manifest
We will use Puppet (Open Source) to enforce a state of security. If a junior admin accidentally changes a permission, Puppet changes it back within 30 minutes. That is compliance.
Here is a battle-tested init.pp class for hardening a base CentOS 6.5 node. This ensures that even fresh kickstarts from CoolVDS meet the standard immediately.
Defining the SSH Hardening Class
We need to disable root login and enforce Protocol 2 to mitigate man-in-the-middle attacks.
class system_hardening {
# 1. Secure SSH Configuration
file { '/etc/ssh/sshd_config':
ensure => present,
owner => 'root',
group => 'root',
mode => '0600',
content => template('system_hardening/sshd_config.erb'),
notify => Service['sshd'],
}
service { 'sshd':
ensure => running,
enable => true,
hasstatus => true,
hasrestart => true,
}
# 2. Enforce TCP Wrappers
file { '/etc/hosts.allow':
ensure => present,
content => "sshd: 192.168.1.0/24 10.0.0.0/8\n",
owner => 'root',
mode => '0644',
}
file { '/etc/hosts.deny':
ensure => present,
content => "sshd: ALL\n",
owner => 'root',
mode => '0644',
}
}
In your template sshd_config.erb, ensure these lines are hardcoded:
Protocol 2
PermitRootLogin no
PasswordAuthentication no
X11Forwarding no
UseDNS no
Step 2: The Firewall (IPTables)
While we wait for newer firewalls to mature, iptables remains the gold standard in 2014. However, typing rules manually is a recipe for locking yourself out. We automate this.
Do not rely on the hosting provider's external firewall alone. Defense in depth requires host-level filtering.
# /etc/sysconfig/iptables
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
# Allow loopback
-A INPUT -i lo -j ACCEPT
# Allow established connections (Stateful inspection)
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# SSH (Limit to your management IP if possible)
-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
# ICMP (Ping) - Rate limited to prevent flood
-A INPUT -p icmp -m limit --limit 1/sec -j ACCEPT
COMMIT
Reloading this on a live server is risky. I recommend using the at command to revert changes automatically if you cut your own connection:
echo "/etc/init.d/iptables stop" | at now + 5 minutes
If you are still connected after applying the rules, you can cancel the job with at -r.
Step 3: Sysctl Kernel Tuning for DDoS Mitigation
Norway's internet infrastructure is robust, but that doesn't make you immune to SYN floods. Adjusting the Linux kernel parameters via /etc/sysctl.conf is mandatory for any production web server.
Add these to your Puppet manifest or edit manually:
# Enable SYN Cookies
net.ipv4.tcp_syncookies = 1
# Disable packet forwarding (We are a server, not a router)
net.ipv4.ip_forward = 0
# Ignore ICMP broadcasts
net.ipv4.icmp_echo_ignore_broadcasts = 1
# Log Martian Packets (Spoofed source IPs)
net.ipv4.conf.all.log_martians = 1
Apply these changes instantly with sysctl -p.
Data Residency and Latency
Technical hardening is only half the battle. Legal compliance often centers on where the data physically sits. Under current interpretation of the Personal Data Act, storing sensitive Norwegian data outside the EEA (European Economic Area) introduces significant legal headaches (Safe Harbor notwithstanding).
When selecting a VPS, verify the physical location. A server in Frankfurt is good; a server in Oslo is better for local latency. CoolVDS offers transparency here—you know exactly which datacenter your KVM slice resides in. For a Norwegian e-commerce site, the difference between 40ms (Central Europe) and 5ms (local IX) to Oslo users is palpable in the checkout flow.
Conclusion
Compliance is not a checkbox; it is a configuration state. By using Puppet to enforce SSH hardening, IPTables rules, and kernel tuning, you turn a chaotic infrastructure into a fortress.
Don't build your fortress on sand. Start with a dedicated-kernel KVM environment that respects your need for low-level control.
Ready to audit? Spin up a fresh CentOS 6 instance on CoolVDS today and apply these manifests. Secure your data before the auditors arrive.