Surviving the Audit: Automating Server Security and Compliance in a Post-PRISM World

Let’s be honest with each other. The last week has changed everything. With the recent revelations about PRISM and widespread NSA surveillance, the concept of "data sovereignty" has shifted from a legal checkbox to a critical business requirement. If you are a CTO or Lead Sysadmin in Norway right now, you are likely fielding panicked emails from legal regarding where your customer data actually lives.

It is no longer enough to just have a server. You need a fortress. And more importantly, you need a fortress that resides legally and physically within the jurisdiction of the EEA, preferably right here in Norway to satisfy the strict requirements of Datatilsynet (The Norwegian Data Protection Authority).

But security cannot be a manual process. If you are manually editing /etc/ssh/sshd_config on twenty different servers, you have already failed. Humans make mistakes; scripts do not. In this guide, we are going to look at how to automate compliance and security hardening using Puppet and standard Linux tools, ensuring your infrastructure is audit-ready from the moment it boots.

The "War Story": Why State Management Matters

I recently consulted for a frantic Oslo-based fintech startup. They were running a mix of OpenVZ containers and dedicated boxes scattered across three different providers. Their "security policy" was a Word document that nobody had opened since 2011. When they tried to land a contract with a major Norwegian bank, the due diligence audit tore them apart. Root logins were enabled, MySQL was listening on public interfaces, and half their kernels were two years old.

We migrated them to a standardized KVM architecture on CoolVDS. Why KVM? Because unlike OpenVZ, KVM gives us a true hardware virtualization layer. We can compile our own grsec-patched kernels if necessary, and we don't suffer from the "noisy neighbor" resource contention that plagues cheaper container-based hosting. We implemented a strict Puppet-based configuration management system. The result? They passed the re-audit in 48 hours.

Phase 1: The Base Hardening (The Stuff You Automate)

Before we even touch the application layer, the OS needs to be locked down. Whether you are using Debian 7 Wheezy or CentOS 6.4, the principles are identical. We want to disable anything that isn't strictly necessary.

1. SSH Configuration

Password authentication is a relic of the past. If you aren't using SSH keys, you are begging to be brute-forced. Here is the standard we enforce across all nodes via automation:

2. Network Filtering with iptables

We don't wait for a hardware firewall to save us. Every node must defend itself. Below is a standard stateful firewall configuration. Note that we drop everything by default—a whitelist approach is the only acceptable security posture in 2013.

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

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

# Allow established connections (keep your SSH session alive!)
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# SSH - LIMIT RATE to prevent aggressive scanning
-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 -m state --state NEW -j ACCEPT

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

# ICMP (Ping) - Limit to prevent flood
-A INPUT -p icmp -m limit --limit 1/sec -j ACCEPT

COMMIT

Pro Tip: Always test your iptables rules with iptables-apply or schedule a cron job to flush rules every 10 minutes before you apply them permanently. Locking yourself out of a remote server is a rite of passage, but it’s one you want to avoid on a Friday afternoon.

Phase 2: Automating Compliance with Puppet

Manual scripts are fine for one server. For infrastructure, we use Puppet. It ensures that if a junior admin accidentally changes a permission or opens a port, Puppet will revert it back to the secure state on the next run (usually every 30 minutes).

Here is a basic Puppet manifest that ensures our SSH configuration is immutable and the service is running:

class ssh_hardening {

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

  file { '/etc/ssh/sshd_config':
    ensure  => file,
    owner   => 'root',
    group   => 'root',
    mode    => '0600',
    source  => 'puppet:///modules/ssh/sshd_config_secure',
    require => Package['openssh-server'],
    notify  => Service['ssh'],
  }

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

By defining this state, we create a self-healing infrastructure. This is crucial for compliance with Personopplysningsloven. You can demonstrate to an auditor that your security policy isn't just a document; it is code that actively enforces itself.

Phase 3: Kernel Tuning for DDoS Resilience

While we can't stop a massive volumetric attack without upstream help, we can harden the TCP stack to resist SYN floods and other common annoyances. These settings go into /etc/sysctl.conf.

Apply these with sysctl -p. These tweaks are standard on all CoolVDS images, but knowing why they are there sets you apart from the "apt-get install" crowd.

The Hardware Reality: Latency and Jurisdiction

All the software hardening in the world won't help you if your data is sitting on a physical drive in a jurisdiction that allows warrantless seizure. This is where the physical layer meets compliance.

When we architect solutions for Norwegian clients, we emphasize CoolVDS not just for the specs, but for the topology. Being physically connected to the NIX (Norwegian Internet Exchange) ensures that local traffic stays local. It doesn't route through Stockholm or London unless it has to.

Furthermore, we utilize high-performance SSD storage in RAID-10 arrays. In 2013, database performance is almost always I/O bound. Moving from mechanical SAS drives to SSDs typically yields a 10x performance increase for MySQL queries involving temporary tables. When you combine KVM isolation with raw SSD throughput, you eliminate the I/O wait times that usually kill high-traffic applications.

Conclusion

Security is not a product you buy; it is a process you automate. The landscape in June 2013 is volatile. Between the new EU cookie laws and the NSA leaks, relying on "security through obscurity" is professional suicide.

By leveraging tools like Puppet for state management and hosting on transparent, high-performance KVM infrastructure like CoolVDS, you protect not just your servers, but your company's reputation.

Ready to lock down your infrastructure? Don't leave your data drifting in the cloud. Deploy a hardened, SSD-backed KVM instance on CoolVDS today and keep your data strictly on Norwegian soil.