Automating Configuration and Hardening 50 Linux VPS Simultaneously via Ansible and CIS Benchmark

The Challenge of Scale and Security in Modern Infrastructure

In an era where cloud infrastructure scales exponentially, managing individual Virtual Private Servers (VPS) manually is no longer viable. For system administrators and DevOps engineers, provisioning 50 Linux VPS instances simultaneously introduces severe challenges: configuration drift, human error, and inconsistent security postures. Leaving standard default configurations on your servers exposes your network to automated botnets, brute-force attacks, and sophisticated exploits.

To mitigate these risks, organizations turn to the Center for Internet Security (CIS) Benchmarks—the gold standard for prescriptive, consensus-based security configuration guides. However, manually applying hundreds of CIS recommendations across 50 distinct servers is an operational nightmare. This is where Ansible, an open-source automation engine, becomes indispensable. By combining Ansible's agentless orchestration with CIS compliance rules, you can harden your entire infrastructure rapidly, consistently, and reliably.

Why Choose Ansible for Bulk CIS Hardening?

Ansible operates on an agentless architecture, utilizing standard SSH to connect to target nodes. This eliminates the overhead of installing and maintaining management software on all 50 target systems. Key benefits of utilizing Ansible for security hardening include:

Idempotency: Ansible ensures that operations are only executed if the system state deviates from the defined policy, preventing unnecessary re-configurations.
Declarative Language: Playbooks written in YAML act as living documentation, making security policies transparent and easily auditable by compliance teams.
Parallel Execution: By leveraging Ansible forks, tasks can run concurrently across dozens of servers, turning a multi-day manual operation into a five-minute automated execution.

Architecture and Prerequisites

Before executing our bulk hardening playbook, a structured environment must be prepared. The architecture consists of one centralized Ansible Control Node securely connected to 50 Managed Nodes (the Linux VPS instances).

System Requirements & Initial Setup

Control Node: A secure Linux machine with Ansible 2.15+ and Python 3 installed.
Managed Nodes: 50 Linux VPS instances (e.g., Ubuntu 22.04 LTS or RHEL 9) with SSH access configured via public-key authentication.
Privileged Access: A dedicated deployment user on target systems configured with passwordless sudo privileges to allow deep system modifications.

Security Best Practice: Never use the root user directly for remote automation. Implement a dedicated service account and strictly restrict its access using sudoers configuration.

Step-by-Step Implementation Guide

1. Organizing the Inventory File

The inventory file informs Ansible about the targets and defines grouping for parallel execution. Create a file named hosts.ini:

[vps_servers]
vps-node-[01:50].yourdomain.com ansible_user=deploy_user ansible_ssh_private_key_file=~/.ssh/id_rsa_deploy

2. Tuning Ansible for Concurrent Execution

To ensure all 50 servers are updated simultaneously without bottlenecks, modify the ansible.cfg file to increase the default fork limit:

[defaults]
inventory = hosts.ini
forks = 50
host_key_checking = False
pipelining = True

Pipelining reduces the number of SSH operations required to execute a module, drastically speeding up bulk operations.

3. Crafting the CIS Hardening Playbook

The following playbook targets core areas defined by the CIS Benchmarks, including SSH daemon securing, firewall configuration, network stack optimization, and user account auditing.

--- 
- name: Bulk Linux VPS Hardening to CIS Benchmark Standards
  hosts: vps_servers
  become: true
  vars:
    allowed_ssh_users: "deploy_user admin_team"
    sysctl_settings:
      net.ipv4.conf.all.accept_redirects: 0
      net.ipv4.conf.all.send_redirects: 0
      net.ipv4.conf.all.accept_source_route: 0
      net.ipv6.conf.all.disable_ipv6: 1
  tasks:
    - name: Section 1 - Update and Upgrade System Packages
      apt:
        update_cache: yes
        upgrade: dist
        autoremove: yes
      when: ansible_os_family == "Debian"

    - name: Section 2 - Enforce Secure SSH Daemon Configuration
      template:
        src: templates/sshd_config.j2
        dest: /etc/ssh/sshd_config
        owner: root
        group: root
        mode: '0600'
      notify: Restart SSHD

    - name: Section 3 - Optimize Network Parameters via Sysctl
      sysctl:
        name: "{{ item.key }}"
        value: "{{ item.value }}"
        state: present
        reload: yes
      loop: "{{ sysctl_settings | dict2items }}"

    - name: Section 4 - Install and Configure UFW Firewall
      block:
        - name: Allow SSH Traffic
          ufw:
            rule: allow
            port: '22'
            proto: tcp
        - name: Enable UFW and Set Default Deny Policy
          ufw:
            state: enabled
            policy: deny
            direction: incoming
      when: ansible_os_family == "Debian"

  handlers:
    - name: Restart SSHD
      service:
        name: sshd
        state: restarted

Deep Dive into CIS Security Controls Applied

Secure Shell (SSH) Hardening

Our Jinja2 template (sshd_config.j2) enforces critical compliance settings. It explicitly disables root logins (PermitRootLogin no), mandates SSH protocol 2, deactivates password authentication (PasswordAuthentication no), and configures explicit idle timeout intervals to automatically terminate abandoned sessions.

Network Stack Protection (Sysctl)

Default Linux kernel settings prioritize connectivity over security. The playbook overwrites these rules by modifying /etc/sysctl.conf. Disabling IP packet redirects prevents the infrastructure from being leveraged in Man-in-the-Middle (MitM) and source-routing spoofing attacks.

Automated Firewalls & Access Control Lists

A closed infrastructure is a safe infrastructure. The playbook guarantees that only explicitly permitted ports (such as port 22 for secure SSH management) are accessible, blocking all other unauthorized ingress connections across all 50 virtual environments simultaneously.

Validation, Testing, and Continuous Compliance

Once deployment finishes, verifying compliance is paramount. You can utilize automated security scanners like Lynis or open-source tools such as OpenSCAP to run post-hardening audits against the CIS profiles.

Integrating this playbook into a GitOps workflow (via GitLab CI or GitHub Actions) ensures that anytime a configuration changes, the pipeline auto-runs the playbook. This architecture guarantees your infrastructure permanently maintains its hardened security baseline, completely eliminating configuration drift over time.