Automating Security Compliance: Surviving the Year of Vulnerabilities

If you are reading this in December 2014, you are likely exhausted. This year has been an absolute gauntlet for those of us managing server infrastructure. First, we had Heartbleed exposing our private keys. Then came Shellshock (Bash bug), turning our command lines against us. Just recently, POODLE killed off SSLv3. If you are still manually SSH-ing into servers to run yum update, you are playing a dangerous game with your data integrity.

For those of us hosting in Norway, the stakes are even higher. We aren't just battling hackers; we are navigating the strict requirements of the Data Inspectorate (Datatilsynet) and the Personopplysningsloven (Personal Data Act). The post-Snowden era has made one thing clear: data sovereignty matters. But sovereignty means nothing if your server is wide open to a script kiddie using a simple Bash exploit.

In this guide, we are going to stop fighting fires and start building fireproof buildings. We will look at automating security compliance using Ansible (which is rapidly maturing this year) and configuring strict auditing to satisfy Norwegian regulations. We will also discuss why the underlying virtualization technology of your VPS provider—specifically KVM versus OpenVZ—is critical for security isolation.

The "Patch Tuesday" Nightmare is Over. Welcome to Continuous Configuration.

The old way of securing a server involved a checklist. You install the OS, you harden SSH, you configure iptables, and you pray you didn't forget anything. In 2014, with vulnerabilities being weaponized within hours of disclosure, checklists are dead. You need code.

We are seeing a shift towards tools like Puppet, Chef, and lately, Ansible. Unlike Puppet, Ansible doesn't require an agent installed on the target node, which makes it perfect for managing a lean VPS environment where every megabyte of RAM counts. It works over SSH, leveraging the keys you already manage.

Scenario: Patching Shellshock Across 50 Servers

When CVE-2014-6271 (Shellshock) dropped in September, I saw admins panic. They were logging into servers one by one. Meanwhile, those of us with configuration management solved the problem in five minutes.

Here is a simple Ansible playbook compatible with version 1.7+ that ensures your systems are patched against Shellshock and that the vulnerable SSLv3 protocol (POODLE) is disabled in Nginx.

---
- hosts: norway_nodes
  remote_user: root
  tasks:
    - name: Ensure Bash is updated (Mitigate Shellshock)
      yum:
        name: bash
        state: latest

    - name: Disable SSLv3 in Nginx (Mitigate POODLE)
      lineinfile:
        dest: /etc/nginx/nginx.conf
        regexp: 'ssl_protocols'
        line: '    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;'
        state: present
      notify:
        - restart nginx

  handlers:
    - name: restart nginx
      service: name=nginx state=restarted

Running this script updates every node in your inventory instantly. This isn't just convenience; it's due diligence. If you are audited by Datatilsynet, showing a Git commit log of your security patches is far more convincing than saying "I think I patched that one."

Auditing and Logging: The Norwegian Context

Norwegian privacy laws place a heavy emphasis on access control and accountability. It is not enough to secure the data; you must prove who accessed it. Standard syslogs are often insufficient. We need auditd.

The Linux Audit Daemon allows us to write rules that log specific system calls. For a compliant setup, you should be tracking unauthorized access attempts and changes to system time (a common tactic to hide intrusions).

Here is a robust /etc/audit/audit.rules configuration for a CentOS 6/7 system:

# First rule - delete all
-D

# Increase the buffers to survive stress events.
# Make this larger for busy systems
-b 8192

# Set failure mode to syslog
-f 1

# Monitor changes to the time
-a always,exit -F arch=b64 -S adjtimex -S settimeofday -k time-change
-a always,exit -F arch=b32 -S adjtimex -S settimeofday -k time-change

# Monitor changes to user/group information
-w /etc/group -p wa -k identity
-w /etc/passwd -p wa -k identity
-w /etc/gshadow -p wa -k identity
-w /etc/shadow -p wa -k identity

# Monitor usage of privileged commands (sudo)
-a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged

With these rules, any attempt to change user passwords or manipulate the system clock is logged to /var/log/audit/audit.log. This creates an immutable trail required for forensic analysis.

The Architecture of Trust: Why KVM Matters

Software automation is useless if the foundation is rotten. This brings us to a critical architectural decision: Virtualization Type.

Many budget hosts in Europe still rely heavily on OpenVZ. OpenVZ uses a shared kernel. This means all VPS instances on the physical host share the same Linux kernel version. If a vulnerability exists in that kernel (and 2014 has proven that kernels are not invincible), an attacker could theoretically escape their container and access your memory space.

Pro Tip: Check your virtualization type by running virt-what or uname -a. If you see "stab" or strict resource counters in /proc/user_beancounters, you are likely on OpenVZ. For high-security workloads, migrate immediately.

This is where CoolVDS takes a different stance. We utilize KVM (Kernel-based Virtual Machine). With KVM, your VPS acts like a dedicated server with its own isolated kernel. You can load your own kernel modules, set your own sysctl flags, and most importantly, you are isolated from the "noisy neighbors" and security slips of other tenants. In a year defined by kernel-level exploits, KVM is not a luxury; it is a security requirement.

Hardening Network Access

Finally, we must secure the door. While many are moving to dynamic firewalls, good old iptables remains the gold standard for performance and reliability in 2014. We want to drop everything by default and only allow what is necessary.

Do not just open port 80. Limit SSH access to known IP ranges if possible.

# Flush existing rules
iptables -F

# Set default chain policies
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# Accept on localhost
iptables -A INPUT -i lo -j ACCEPT

# Allow established sessions
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Allow SSH (Change 22 to your custom port)
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# Allow Web Traffic
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Log dropped packets (Crucial for debugging)
iptables -A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7

# Save rules
service iptables save

Conclusion: Sleep Better with CoolVDS

The regulatory landscape in Europe is shifting. With the Data Retention Directive recently invalidated by the ECJ (April 2014), the focus on privacy is sharper than ever. Hosting your data in Norway, outside the immediate reach of the US Patriot Act, offers a significant legal advantage. But location alone isn't security.

You need a provider that understands the technical depth required to withstand the modern threat landscape. You need full root access, KVM isolation, and the raw I/O performance to handle encrypted traffic without latency. CoolVDS offers exactly that—a professional-grade canvas for your secure infrastructure.

Don't wait for the next Heartbleed. Audit your infrastructure today.

Ready to harden your stack? Deploy a KVM-based instance in Oslo in under 60 seconds with CoolVDS.