Automating Security Baselines: Why Manual Hardening is a Liability

I watched a junior sysadmin manually edit /etc/ssh/sshd_config on a production cluster last week. He thought he was being diligent. I saw a ticking time bomb.

In the current climate, with the EU Data Protection Directive under intense scrutiny and the Safe Harbor agreement looking shakier by the day, "security" is no longer just about firewalls. It's about auditability. If you cannot prove the exact state of your infrastructure at any given second, you are not compliant. Manual hardening is unverifiable, prone to human error, and frankly, unprofessional.

This guide cuts through the noise. We aren't talking about expensive "enterprise suites." We are talking about using accessible tools like Ansible and standard Linux primitives to enforce a security baseline that satisfies even the strictest auditors at Datatilsynet (The Norwegian Data Protection Authority).

The "Safe Harbor" Trap and Data Sovereignty

Let’s address the elephant in the server room. Many of you are hosting customer data on US-owned clouds (AWS, Rackspace, etc.). You rely on the Safe Harbor framework to legally transfer data out of the EEA. But if you've been following the Maximilian Schrems case against Facebook, you know the European Court of Justice is taking a hard look at US mass surveillance.

If Safe Harbor falls—and legal experts suggest it might later this year—hosting data on US soil becomes a legal nightmare. The pragmatic move for any CTO targeting Norwegian or European users is strict Data Sovereignty. Keep the data in Norway. Keep it under Norwegian jurisdiction.

Pro Tip: Physical location matters. Latency from Oslo to a datacenter in Frankfurt is decent (~25ms), but latency to a local Oslo datacenter is <3ms. That difference is massive for database transaction locking. CoolVDS infrastructure is physically located in Oslo, solving both the legal headache and the latency problem.

Automating the Baseline: Ansible & CentOS 7

We are seeing a shift from Puppet/Chef toward Ansible for ad-hoc compliance tasks because it's agentless. You don't need a heavy Ruby stack on every node. You just need SSH.

Here is a "Battle-Hardened" baseline. This isn't theoretical; this is what we run on high-value CoolVDS instances to lock them down immediately after provisioning.

1. The SSH Lockdown

Stop allowing root login. It is 2015. There is no excuse. Also, change the default port to reduce log noise from script kiddies.

# tasks/security.yml
---
- name: Disallow root SSH access
  lineinfile:
    dest: /etc/ssh/sshd_config
    regexp: "^PermitRootLogin"
    line: "PermitRootLogin no"
    state: present
  notify: restart ssh

- name: Disable Password Authentication (Keys Only)
  lineinfile:
    dest: /etc/ssh/sshd_config
    regexp: "^PasswordAuthentication"
    line: "PasswordAuthentication no"
    state: present
  notify: restart ssh

2. The Kernel Hardening (sysctl)

Default Linux network stacks are tuned for compatibility, not security. We need to prevent IP spoofing and mitigate SYN floods. On a CoolVDS KVM instance, you have full control over your kernel parameters (unlike OpenVZ containers where you are at the mercy of the host node).

# /etc/sysctl.d/99-security.conf

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

# Ignore ICMP broadcast requests
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Disable source packet routing
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0

# SYN Flood Protection
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 2048
net.ipv4.tcp_synack_retries = 2

3. Killing SSLv3 (POODLE Mitigation)

The POODLE vulnerability (CVE-2014-3566) rendered SSLv3 unsafe. Yet, I still see Nginx configs supporting it. If you are handling credit card data, this is an automatic fail on your PCI-DSS scan.

Update your Nginx config to strictly enforce TLS:

ssl_protocols TLSv1 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:kEDH+AES256:kEDH+AES128:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK';
ssl_prefer_server_ciphers on;

Why Infrastructure Choice Affects Compliance

Automation is useless if the underlying hardware is unstable or insecure. This is where the "noisy neighbor" effect destroys your compliance posture. If another VM on the same host is under a DDoS attack, and your CPU steal time spikes, your logging services might time out. Gaps in logs = failed audit.

Containerization vs. Virtualization:
There is a lot of hype around Docker right now (version 1.8 just dropped). Containers are great for deployment, but for security isolation, they share the kernel. A kernel panic in one container can take down the host.

The Verification Step

Once you have run your Ansible playbook, do not trust it. Verify it. Use OpenSCAP (Security Content Automation Protocol) to scan your CentOS 7 box against the standard profiles.

yum install scap-security-guide
oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_common --results /tmp/results.xml /usr/share/xml/scap/ssg/content/ssg-centos7-ds.xml

If you see red, fix it in the Ansible playbook, not manually. Never manually.

Conclusion

The era of the "Cowboy Sysadmin" is over. In 2015, if it isn't automated, it doesn't exist. By combining tools like Ansible with the strict data sovereignty provided by Norwegian hosting, you insulate your business from both hackers and lawyers.

You need a foundation that respects these requirements. We built CoolVDS on pure KVM with local NVMe storage specifically for professionals who can't afford to fail an audit.

Ready to lock it down? Deploy a CentOS 7 instance in Oslo on CoolVDS today and run your first compliance scan in under 5 minutes.