Automating Compliance: How to harden your Norwegian VPS without losing your mind

The Era of the Manual Checklist is Dead

If you are still securing your servers by copying and pasting commands from a text file into a terminal, you are already breached. It’s 2015. The sheer volume of automated attacks targeting SSH ports and unpatched glibc vulnerabilities (we all remember Ghost, right?) means that manual hardening is no longer just inefficient—it is professional negligence.

As a CTO or Lead Sysadmin operating in Norway, you have a second headache: Datatilsynet (The Norwegian Data Protection Authority). With the current discussions in Brussels regarding the new Data Protection Regulation (the looming replacement for Directive 95/46/EC), regulatory scrutiny is tightening. If you are handling customer data on Norwegian soil, you need audit trails, not promises.

Here is how we move from "I think it's secure" to "I can prove it's secure," using infrastructure automation and the right virtualization layer.

1. Infrastructure as Code: The Ansible Advantage

Puppet and Chef have served us well, but for many teams, the agentless architecture of Ansible is winning the war in 2015. It pushes configuration over SSH, which fits perfectly with a secure VPS environment.

Instead of manually editing /etc/ssh/sshd_config on every new node, define your compliance state in a playbook. This ensures that every server you spin up—whether it's a testbed or production—adheres to the exact same standard.

Here is a battle-tested snippet for securing SSH on a CentOS 7 instance. This disables root login and enforces key-based authentication, a requirement for even basic compliance standards.

- name: Secure SSH configuration
  hosts: all
  become: yes
  tasks:
    - name: Disable SSH Root Login
      lineinfile:
        dest: /etc/ssh/sshd_config
        regexp: '^PermitRootLogin'
        line: 'PermitRootLogin no'
        state: present
      notify: restart ssh

    - name: Disable Password Authentication
      lineinfile:
        dest: /etc/ssh/sshd_config
        regexp: '^PasswordAuthentication'
        line: 'PasswordAuthentication no'
        state: present
      notify: restart ssh

  handlers:
    - name: restart ssh
      service: name=sshd state=restarted

2. The POODLE Hangover: SSL is not optional

After the POODLE vulnerability last year, SSLv3 is dead. Yet, I still see default Nginx configurations allowing it. Compliance isn't just about the OS; it's about the transport layer.

If you are hosting e-commerce sites (Magento or Prestashop), you are likely dealing with the newly released PCI-DSS v3.1 (April 2015). This update explicitly kills off SSL and early TLS. You must configure your web servers to support TLS 1.1 or 1.2 exclusively.

Inside your nginx.conf, explicitly set:

ssl_protocols TLSv1.1 TLSv1.2;
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:kEDH+AES128:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK';
ssl_prefer_server_ciphers on;

3. The Virtualization Layer Matters: OpenVZ vs. KVM

Automation handles the software, but what about the foundation? This is where many providers cut corners. In the budget VPS market, OpenVZ is common. It shares the host kernel across all containers.

Pro Tip: From a security compliance perspective, shared kernels are a nightmare. If a vulnerability exists in the kernel (like the recent heavy hitters), a container escape could theoretically compromise your data from a neighbor's instance.

This is why at CoolVDS, we exclusively use KVM (Kernel-based Virtual Machine). KVM provides full hardware virtualization. Your OS kernel is yours. Your memory space is yours. This isolation is critical when you are explaining your security architecture to an auditor or a skeptical enterprise client. It allows you to enable kernel-level hardening features (like SELinux) that are often disabled or broken in container-based hosting.

4. Data Residency and the "Safe Harbor" Risk

We are seeing a massive shift in trust. With the ongoing revelations about mass surveillance, many Norwegian companies are wary of hosting data with US-based providers, regardless of the "Safe Harbor" framework. The legal ground is shaking.

Hosting locally in Norway or Northern Europe isn't just about lower latency (though pinging Oslo in 3ms is nice); it's about data sovereignty. By keeping your data on CoolVDS infrastructure, you ensure that your bits reside within a jurisdiction that respects the Personopplysningsloven.

Conclusion: Automate or Expire

The days of the cowboy sysadmin are over. Complexity has won. To survive, you must treat your infrastructure as code and your compliance as a continuous process, not a one-time event.

Start with a clean slate. Deploy a KVM instance on CoolVDS today—it takes less than a minute—and run your Ansible hardening playbook against it. If it passes, you’re ready for production. If it doesn't, terminate it and fix your code. That is the power of modern infrastructure.