Automating Compliance: Why Manual Hardening is Killing Your Business

If you are still manually editing /etc/ssh/sshd_config on every server you spin up, you aren't just wasting time—you are creating a legal liability. In the wake of the Safe Harbor invalidation last year and the implementation of the new EU-US Privacy Shield just two months ago, the regulatory landscape in Norway and Europe has shifted beneath our feet. The Norwegian Data Protection Authority (Datatilsynet) is signaling stricter enforcement, and we are staring down the barrel of the proposed General Data Protection Regulation (GDPR) set for 2018.

As a CTO, my job isn't just to ensure uptime; it's to ensure we don't get fined into oblivion. Security compliance is no longer a yearly audit checkbox. It must be a continuous, automated state of being. Whether you manage five servers or five hundred, the principle is the same: Immutable Infrastructure.

The Myth of the "Secure" Default Install

Let’s be honest. A fresh installation of CentOS 7 or Ubuntu 16.04 LTS is functional, not secure. It is designed for compatibility, not for resisting a focused brute-force attack or meeting PCI-DSS standards. In a recent audit for a fintech client in Oslo, we found that 40% of their "secure" VPS instances still allowed root login over SSH. That is unacceptable.

When you provision a server, specifically high-performance NVMe instances like those we use at CoolVDS, the first 5 minutes are critical. This is the window where automated bots scanning IP ranges will find you.

Step 1: The Baseline Hardening (Manual vs. Scripted)

The old way involves logging in and running commands. The new way—the only way for a scalable business—is configuration management. But first, let's look at what actually needs to change in your sshd_config.

# The "Must-Haves" for any public facing server
Protocol 2
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
X11Forwarding no
MaxAuthTries 3
AllowUsers deploy_user

Changing the port is security by obscurity, but disabling PasswordAuthentication is non-negotiable. If you are relying on passwords in 2016, you have already lost.

Automating with Ansible: Infrastructure as Code

We switched our entire fleet management to Ansible 2.1 earlier this year. Unlike Puppet or Chef, Ansible requires no agents—just SSH. This is perfect for the Norwegian market where we often manage hybrid environments across different providers before consolidating them onto our CoolVDS private clouds.

Here is a production-ready Ansible task snippet that we use to enforce SSH security across all nodes. This ensures that even if a junior sysadmin manually reverts a change, the next playbook run fixes it.

- name: Secure SSH Configuration
  hosts: all
  become: yes
  tasks:
    - name: Disable 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

Pro Tip: Always validate your syntax with ansible-playbook --syntax-check site.yml before running it against production. I once saw a typo take down SSH access for an entire cluster in Bergen. Don't be that person.

Network Level Compliance: Iptables and Fail2Ban

While hardware firewalls are great, host-based firewalls are a requirement for granular compliance. On CentOS 7, firewalld is the default, but many of us still prefer the raw predictability of iptables for high-traffic web servers.

We configure Fail2Ban on every single CoolVDS instance we deploy. It monitors log files and bans IPs that show malicious signs. Here is a configuration for protecting Nginx, which is crucial if you are hosting e-commerce sites.

# /etc/fail2ban/jail.local
[nginx-req-limit]
enabled = true
filter = nginx-req-limit
action = iptables-multiport[name=ReqLimit, port="http,https", protocol=tcp]
logpath = /var/log/nginx/error.log
findtime = 600
bantime = 7200
maxretry = 10

This simple config protects your application layer from automated scrapers that eat up your CPU and I/O resources.

Data Residency: Why "The Cloud" isn't Enough

This is where the legal aspect hits the technical reality. Under the current Norwegian regulations and the developing EU framework, you are the data controller. If you host customer data on a US-controlled cloud, even if the datacenter is in Europe, you are navigating a legal minefield regarding the Privacy Shield agreement.

Latency and Sovereignty
Beyond the legalities, there is physics. If your customers are in Norway, routing traffic through a datacenter in Frankfurt or Amsterdam adds 20-30ms of latency. Hosting in Oslo ensures latency as low as 2-5ms via the NIX (Norwegian Internet Exchange).

At CoolVDS, we made a strategic decision to focus on KVM (Kernel-based Virtual Machine) virtualization rather than OpenVZ. Why? Isolation.

• OpenVZ (Container): Shared kernel. If the host kernel has a vulnerability, your data is at risk. Compliance auditors hate this.
• KVM (CoolVDS Standard): Full hardware virtualization. You run your own kernel. You can enable SELinux without restrictions. You have dedicated NVMe I/O queues that neighbors cannot steal.

Auditing Your Infrastructure with OpenSCAP

How do you prove to Datatilsynet that you are secure? You need logs and audit trails. We recommend using OpenSCAP (Security Content Automation Protocol) to scan your systems against the standard security profiles (like PCI-DSS or STIG).

Installing it on RHEL/CentOS 7 is straightforward:

yum install openscap-scanner scap-security-guide

# Run a scan against the standard profile
oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_standard \
  --results /tmp/scan-results.xml \
  --report /tmp/scan-report.html \
  /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml

This command generates an HTML report showing exactly where you fail compliance. Run this weekly via cron, and you have a historical record of your compliance posture.

Conclusion: Control is the Only Option

The era of "set it and forget it" is over. With the complexity of modern web applications and the tightening grip of data privacy laws in Europe, you need full control over your stack. That means dedicated resources, automated hardening, and strict data residency.

Don't rely on a cloud provider's "shared responsibility" model to save you. Take ownership. Script your security. And if you need a platform that respects your need for raw performance and absolute isolation, we built our infrastructure to support exactly that.

Ready to audit your stack? Deploy a compliant-ready KVM instance on CoolVDS in Oslo today and drop your latency to single digits.