Automated Hardening Scripts (PowerShell DSC, Ansible, Bash)

#Automate Once, Harden Thousands—Script Your Baseline#link

Hardening a single server manually takes hours and is error-prone. PowerShell Desired State Configuration (DSC), Ansible playbooks, and Bash scripts turn hardening into code: repeatable, testable, and version-controlled. This lesson will teach you to write idempotent hardening scripts that enforce CIS settings, configure services, and audit compliance—so every new server is born secure.

PowerShell DSC: Declarative Windows Hardening

DSC defines a desired state for Windows features, registry settings, and services. For example, the 'Registry' resource ensures a key has a specific value; 'Service' ensures a service is stopped and disabled. DSC can be pushed or pulled via a configuration server. Combine DSC with the 'SecurityPolicyDsc' module to manage User Rights Assignment and Audit Policy. The configuration becomes a MOF file applied to nodes.

# DSC configuration to disable Print Spooler and set UAC registry
Configuration HardeningBaseline {
    Import-DscResource -ModuleName PSDesiredStateConfiguration
    Node localhost {
        Service Spooler {
            Name = "Spooler"
            State = "Stopped"
            StartType = "Disabled"
        }
        Registry UACEnableLUA {
            Key = "HKLM:\Software\Microsoft\Windows\CurrentVersion\Policies\System"
            ValueName = "EnableLUA"
            ValueData = "1"
            ValueType = "Dword"
        }
    }
}
HardeningBaseline -OutputPath C:\DSC\mof
Start-DscConfiguration -Path C:\DSC\mof -Wait -Verbose

The above DSC configuration ensures Print Spooler is disabled and UAC is enabled. Running it idempotently means it can be reapplied without errors.

Ansible: Cross-Platform Declarative Hardening

Ansible uses YAML playbooks and modules to manage Linux, Windows, and macOS. The 'ansible-hardening' role (OpenStack) and 'CIS Ubuntu' role implement many CIS recommendations. You write tasks that check if a configuration is already set, and only modify if needed. Ansible's idempotency makes it ideal for continuous hardening. Store playbooks in Git and run them in CI/CD pipelines against golden images.

# Ansible task to disable root SSH login
- name: Ensure PermitRootLogin is no
  lineinfile:
    path: /etc/ssh/sshd_config
    regexp: '^PermitRootLogin'
    line: 'PermitRootLogin no'
    validate: 'sshd -t -f %s'
  notify: restart sshd

Bash Hardening Scripts: Simplicity with Guard Clauses

For cloud-init or simple VMs, a Bash script with conditional checks works. Use 'grep -q' to check if a setting already exists, or 'sysctl -w' to set kernel parameters. Always write scripts that are safe to run multiple times. Example: check if a line exists in /etc/sysctl.conf before appending. Combine with 'set -e' to fail early.

• ▪Adopt a configuration management tool (Ansible, DSC) for hardening.
• ▪Write idempotent tasks—check state before modifying.
• ▪Version-control your hardening code in Git; use CI to test against fresh VMs.
• ▪Include validation steps (e.g., sshd -t) to prevent breaking changes.