Automating Compliance: Why Manual Server Hardening Will Get You Fired

It is 2013. If you are still logging into servers via SSH to manually edit /etc/ssh/sshd_config every time you spin up a new node, you are doing it wrong. Worse, you are creating a liability. In the high-stakes world of systems administration, "I forgot" is not a valid defense when the auditors from Datatilsynet (The Norwegian Data Protection Authority) come knocking.

We see this constantly. A developer provisions a quick VPS for a staging environment, disables iptables because "it was blocking the database connection," and then forgets to re-enable it. Six months later, that staging box is promoted to production with the security posture of a wet paper bag. Manual hardening scales linearly with headcount, which means it doesn't scale at all.

The only solution is to treat your infrastructure as code. In this guide, we are going to look at how to automate security compliance using Puppet and standard Linux tooling, ensuring that every server you deploy—whether it's a test box or a production database—meets the strict standards required by Norwegian law and common sense.

The "Compliance as Code" Philosophy

Compliance isn't a PDF checklist you sign once a year. It's the state of your infrastructure at any given second. In the context of the Personal Data Act (Personopplysningsloven), you need to prove that you have taken reasonable steps to secure data. If your security relies on a sysadmin remembering to run a script, you have failed.

We need to move from describing security to enforcing it programmatically. Tools like Puppet (currently on version 3.x) allow us to define the desired state of a system. If a junior admin accidentally changes a file permission, the agent runs and reverts it back within 30 minutes. That is resilience.

1. Hardening SSH Automatically

The first vector of attack is almost always SSH. Default installations of CentOS 6 or Debian 7 are often too permissive. We don't want to just edit the config; we want to ensure it stays edited.

Here is a Puppet class that enforces a strict SSH configuration. It disables root login, forces protocol 2, and ensures strict modes are active.

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

  service { 'ssh':
    ensure  => running,
    enable  => true,
    require => Package['openssh-server'],
  }

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

Inside your template (sshd_config.erb), you enforce the variables that matter:

# /etc/ssh/sshd_config managed by Puppet
Protocol 2
PermitRootLogin no
PasswordAuthentication no
X11Forwarding no
MaxAuthTries 3
AllowUsers deployer sysadmin

By applying this manifest across your fleet, you guarantee that no server allows root password logins. If someone tries to change it manually to "fix" something, Puppet will mercilessly overwrite their changes on the next run. This is the ruthlessness required for security.

2. The Kernel: Sysctl Hardening

Many VPS providers give you a slice of a kernel using container technology like OpenVZ. The problem? You often can't modify deep kernel parameters for security because you share the kernel with neighbors. This is a security nightmare for compliance.

Pro Tip: This is why serious architects choose KVM (Kernel-based Virtual Machine). At CoolVDS, we use KVM exclusively. This gives you your own isolated kernel, allowing you to enable IP spoofing protection and harden the networking stack without asking for permission.

Once you are on a KVM instance, you should deploy a sysctl.conf that mitigates common network attacks. Here is a configuration snippet you should push to /etc/sysctl.conf:

# IP Spoofing protection
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Ignore ICMP broadcast requests
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Disable source packet routing
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0

# Ignore bogus ICMP error responses
net.ipv4.icmp_ignore_bogus_error_responses = 1

# Log Martians
net.ipv4.conf.all.log_martians = 1

Apply these changes instantly without a reboot:

sysctl -p

3. File Integrity Monitoring (FIM)

Datatilsynet and PCI-DSS requirements often mandate that you track changes to system files. If an attacker manages to replace /bin/ls with a rootkit, how will you know? You need a baseline.

In 2013, AIDE (Advanced Intrusion Detection Environment) is the industry standard open-source tool for this. It takes a snapshot of your file hashes and compares them daily.

Install it on your CoolVDS instance:

apt-get install aide
aideinit
mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

However, simply installing it isn't enough. You need to automate the check. Create a cron job that runs nightly and emails the diff to your security team. Here is a simple wrapper script:

#!/bin/bash
# /opt/scripts/aide-check.sh

LOGFILE="/var/log/aide/aide.log"
/usr/bin/aide --check > $LOGFILE

if grep -q "found differences" $LOGFILE; then
    mail -s "SECURITY ALERT: File Integrity Change Detected on $(hostname)" security@yourcompany.no < $LOGFILE
fi

Data Sovereignty and The "Patriot Act" Problem

Automation solves configuration drift, but it doesn't solve jurisdiction. If your data physically resides on a server owned by a US company, it is subject to the USA PATRIOT Act, regardless of where the datacenter is located. This is a massive gray area for Norwegian companies handling sensitive customer data.

Using a provider like Amazon AWS or Rackspace introduces legal complexity regarding the EU Data Protection Directive (95/46/EC). While Safe Harbor exists, many legal experts in Norway argue it offers insufficient protection against foreign surveillance.

Latency Matters Too

Beyond the legalities, there is physics. If your customers are in Oslo, Bergen, or Trondheim, routing traffic through Frankfurt or London adds unnecessary milliseconds. Milliseconds cost money.

When you host on CoolVDS, your data stays in Norway. You get low latency VPS Norway performance and the peace of mind that comes with local legal adherence.

4. Firewalling with iptables

Finally, no server is compliant without a strict firewall. Do not rely on external cloud firewalls alone; you need host-level protection. Here is a concise iptables script that establishes a "default drop" policy—the only acceptable policy for a secure system.

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

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

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

# SSH (Limit to your office IP if possible)
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT

# Web
-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

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

Conclusion

Security is not a product; it is a process. But manual processes are prone to human error. By utilizing tools like Puppet for configuration management, AIDE for integrity checking, and hosting on a platform like CoolVDS that respects data sovereignty and provides true KVM isolation, you build a fortress that is easy to audit and difficult to breach.

Don't wait for a data breach to take compliance seriously. Audit your infrastructure today.

Ready to secure your stack? Deploy a hardened KVM instance on CoolVDS today and keep your data safely within Norwegian borders.