Server Hardening & Compliance: Automating Security for the Norwegian Cloud

The Era of Manual Security is Over

If you are still SSHing into individual servers to run yum update or manually editing /etc/ssh/sshd_config, you represent the biggest security risk to your company. It is a harsh truth, but in a post-Snowden world where the Datatilsynet (Norwegian Data Protection Authority) is tightening its grip, inconsistent configuration is a liability you cannot afford.

I remember the Shellshock vulnerability of 2014 vividly. We didn't sleep for 30 hours. The teams that suffered were the ones manually patching hundreds of boxes. The teams that slept? They had configuration management. In 2015, infrastructure is code. If it's not in a repository, it doesn't exist.

The "Data Residency" Headache

Let's address the elephant in the server room: Safe Harbor. With the current legal climate in Europe, relying on US-based giants for hosting sensitive Norwegian customer data is becoming a legal minefield. The EU Data Protection Reform is looming, and scrutiny on data transfers is at an all-time high.

For a Norwegian CTO, the safest bet is physical sovereignty. Data stays in Oslo. This isn't just about latency (though pinging NIX at 1ms is nice); it is about being able to look an auditor in the eye and say, "The physical disk is located in a datacenter subject to Norwegian law, not the US Patriot Act."

Automating Hardening with Ansible

We are seeing a massive shift from heavy agents like Puppet to lightweight, agentless tools like Ansible. It communicates over SSH, which you already have. Here is a practical example. Instead of hoping your junior admin remembered to disable root login, enforce it.

Below is a snippet for a standard CentOS 7 hardening playbook. This ensures that no matter how many VPS instances you spin up, they all meet the same baseline security standard instantly.

- name: Secure SSH
  lineinfile:
    dest: /etc/ssh/sshd_config
    regexp: "^{{ item.key }}"
    line: "{{ item.key }} {{ item.value }}"
    state: present
  with_items:
    - { key: 'PermitRootLogin', value: 'no' }
    - { key: 'PasswordAuthentication', value: 'no' }
    - { key: 'Protocol', value: '2' }
    - { key: 'AllowUsers', value: 'deploy_user' }
  notify:
    - restart sshd

The Infrastructure Variable: KVM vs. OpenVZ

You can have the best automation in the world, but if your virtualization layer leaks, you are vulnerable. Many budget providers pushing "Cheap VPS Norway" offers are still running legacy OpenVZ containers. This is a shared kernel environment. If a kernel exploit hits the host, your container is compromised. It is that simple.

This is why we standardized on KVM at CoolVDS.

Architect's Note: When auditing a provider, ask for their virtualization technology. If they say "Container-based" or avoid the question, run away. For true isolation and compliance, you need a hypervisor like KVM that allocates dedicated RAM and distinct kernel space.

Furthermore, automation tools generate high I/O when provisioning. Running an Ansible playbook that installs a LAMP stack, configures firewalld, and compiles modules requires burst performance. On a crowded node with standard SATA drives, this takes minutes. On our NVMe-backed KVM instances, it takes seconds. Time is money, but more importantly, faster provisioning means faster recovery during a disaster.

Configuration Flags That Matter

Beyond SSH, you must lock down the network stack. In 2015, we are still seeing servers deployed with IPv6 enabled but unconfigured, creating a silent attack vector. Disable it if you aren't using it.

In your /etc/sysctl.conf:

# Disable IPv6 if not required
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

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

Conclusion: Audit-Proof Your Stack

The goal is to make compliance boring. When the auditors come asking about your patch management or access controls, you shouldn't be digging through emails. You should be pointing them to your Ansible repo and your hosting provider's SLA.

Don't let legacy infrastructure or manual processes be your downfall. Secure your data on Norwegian soil with hardware designed for the task.

Ready to harden your stack? Deploy a KVM instance on CoolVDS today and test your playbooks against real NVMe performance.