Automated Compliance: Hardening RHEL/CentOS for Norwegian Data Standards

If you are still editing /etc/ssh/sshd_config by hand in 2014, you have already lost. The Edward Snowden revelations of last year shattered the illusion of data privacy, and for those of us managing infrastructure in Norway, the implications are concrete. It is no longer enough to just "secure" a server; you must prove it, maintain it, and ensure that your data stays under Norwegian jurisdiction in compliance with Personopplysningsloven (Personal Data Act).

I recently audited a setup for a client in Oslo trying to pass PCI-DSS Level 2 requirements. They were running a patchwork of shell scripts across a dozen VPS instances hosted on a budget provider. The result? Configuration drift. Three servers had root login enabled because a junior dev forgot to copy the .bash_profile. This is not just a technical failing; it is a compliance violation that attracts the attention of Datatilsynet.

Real security requires automation. In this guide, we will implement a baseline hardening strategy using Puppet and IPTables that enforces state rather than hoping for it. This is designed for KVM-based environments like CoolVDS, where you have actual kernel control—something you simply cannot get with the cheap OpenVZ containers flooding the market.

The Core Principle: Infrastructure as Code

The goal is simple: if a file is changed manually on the server, the automation engine must revert it within 30 minutes. We are not just preventing hackers; we are preventing "quick fixes" by your own team.

1. Enforcing SSH Hardening via Puppet

We start by disabling the vectors used in 90% of brute-force attacks. Below is a Puppet class compatible with Puppet 3.4 that locks down SSH. This ensures that Protocol 2 is strictly enforced and root cannot log in remotely.

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

  service { 'sshd':
    ensure     => running,
    enable     => 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, you must explicitly set these parameters to satisfy PCI-DSS requirement 2.2.2:

# /etc/ssh/sshd_config template snippet
Port 22
Protocol 2
PermitRootLogin no
MaxAuthTries 3
X11Forwarding no
UseDNS no
AllowUsers deploy_user sysadmin

Pro Tip: Never rely on default timeout settings. Set ClientAliveInterval 300 and ClientAliveCountMax 0 to disconnect idle sessions. This is a common finding in security audits.

2. Immutable Firewall Rules with IPTables

While some distributions are toying with firewalld, the battle-tested standard remains pure iptables. We need a default-drop policy. If traffic isn't explicitly allowed, it must die. This is crucial for servers sitting in an Oslo datacenter connected to the NIX (Norwegian Internet Exchange), where public-facing interfaces are constantly scanned.

Do not just flush and pray. Use a script that establishes a known good state:

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

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

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

# SSH - Limit rate to prevent brute force even with keys
-A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set
-A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP
-A INPUT -p tcp --dport 22 -j ACCEPT

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

# Log dropped packets (Crucial for audit trails)
-A INPUT -j LOG --log-prefix "IPTables-Dropped: " --log-level 4
COMMIT

Save this to /etc/sysconfig/iptables on CentOS 6 systems. On CoolVDS instances, we ensure the virtual network interface driver (virtio-net) handles these packet filters with near-zero CPU overhead, unlike software-based limitations often found on shared hosting.

3. File Integrity Monitoring (FIM)

To comply with advanced security standards, you must know when a file changes. For this, we use AIDE (Advanced Intrusion Detection Environment). It creates a database of file hashes and compares them daily.

Install it immediately after provisioning your server:

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

Add a cron job to check this daily and email the delta to your security team. If /bin/login changes checksums overnight and you didn't patch it, you have a breach.

The Virtualization Trap

Here is the uncomfortable truth: You cannot fully harden a kernel you do not own. Many budget providers in Europe resell OpenVZ containers. In those environments, you cannot modify kernel modules or deeply tune sysctl.conf for network stack hardening (like disabling IPv6 if not used, or enabling SYN cookies against flooding).

At CoolVDS, we utilize KVM (Kernel-based Virtual Machine). Every instance runs its own isolated kernel. If you need to enable SELinux (and you should—set it to Enforcing, not Permissive), you can do so without asking for permission. This level of isolation is mandatory for any business handling sensitive Norwegian customer data.

Conclusion

Compliance is not a checkbox; it is a discipline. By automating your SSH configs, enforcing strict IPTables rules, and monitoring file integrity, you turn your infrastructure into a fortress. But software automation only works if the underlying platform respects your commands.

Don't gamble your compliance status on shared kernels. Deploy a dedicated KVM instance on CoolVDS today, leverage our low-latency connection to the Oslo backbone, and build a system that Datatilsynet would be proud of.