5 ways to harden a new system with Ansible

This article discusses some common hardening tasks and how they can be accomplished in a repeatable way with Ansible. I provide a sample Ansible playbook at the end of the article that you can run against your systems on first boot to harden them. You can extend this playbook to include additional hardening tasks as you discover them.

Introduction

Every sysadmin has a checklist of security-related tasks that they execute against each new system. This checklist is a great habit, as it ensures that new servers in your environment meet a set of minimum security requirements. However, doing this work manually is also slow and error-prone. It's easy to encounter configuration inconsistencies due to the manual series of steps, and there's no way to address configuration drift without manually re-running your checklist.

Implementing your security workflow in Ansible is a great way to automate some "low hanging fruit" in your environment. This article discusses some of the basic steps that I take to harden a new system, and it shows you how to implement them using Ansible. The automations in this article aren't earth-shattering; they're probably little things that you already do to secure your systems. However, automating these tasks ensures that your infrastructure is configured in a consistent, repeatable way across your environment.

Before I get started, I'll quickly show you my environment so that you can follow along. I'm using a simple directory structure with a single Ansible playbook (main.yml) and one host in my inventory:

$ tree
.
├── files
│   └── etc
│       ├── issue
│       ├── motd
│       ├── ssh
│       │   └── sshd_config
│       └── sudoers.d
│           └── admin
├── inventory.ini
└── main.yml

4 directories, 6 files

$ cat inventory.ini
nyc1-webserver-1.example.com

Patch software

The first thing that I like to do on a newly-imaged system is ensure that its software is fully patched. An incredible amount of attack surface can be eliminated by merely staying vigilant about patching. Ansible makes this easy. The task below fully patches all of your packages, and can easily be run regularly using cron (or Ansible Tower, in a larger environment):

- name: Perform full patching
  package:
    name: '*'
    state: latest

Secure remote access

Once my host is patched, I quickly secure remote access via SSH. First, I create a local user with sudo permissions so that I can disable remote login by the root user. The tasks below are just an example, and you will probably want to customize them to meet your needs:

- name: Add admin group
  group:
    name: admin
    state: present

- name: Add local user
  user:
    name: admin
    group: admin
    shell: /bin/bash
    home: /home/admin
    create_home: yes
    state: present

- name: Add SSH public key for user
  authorized_key:
    user: admin
    key: "{{ lookup('file', '~/.ssh/id_rsa.pub') }}"
    state: present

- name: Add sudoer rule for local user
  copy:
    dest: /etc/sudoers.d/admin
    src: etc/sudoers.d/admin
    owner: root
    group: root
    mode: 0440
    validate: /usr/sbin/visudo -csf %s

These tasks add a local "admin" user and group, add an SSH public key for the user, and add a sudo rule for the admin user that permits passwordless sudo. The SSH key will be the same public key for the user that is locally executing the Ansible playbook, as shown by the file lookup call.

There are many ways to customize sshd to meet your unique security goals, but my fellow sudoer Nate Lager's post is a great start. Specifically, his post discusses configuration directives (such as disabling password authentication) in the sshd configuration file. Ansible can be used to create a known-good configuration for all of the servers in your environment. This goes a long way toward enforcing a consistent security posture for one of your most critical services, especially if you remain vigilant about regularly executing Ansible across your hosts.

Ansible's copy module is used to lay down this configuration file on remote systems:

- name: Add hardened SSH config
  copy:
    dest: /etc/ssh/sshd_config
    src: etc/ssh/sshd_config
    owner: root
    group: root
    mode: 0600
  notify: Reload SSH

The SSH configuration file that I use is below. It's mostly a default file with some additional tuning, such as disabling password authentication and barring root login. You will likely develop your own configuration file best practices to meet your organization's needs, such as only permitting a specific set of approved ciphers.

$ cat files/etc/ssh/sshd_config
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
SyslogFacility AUTHPRIV
AuthorizedKeysFile	.ssh/authorized_keys
PasswordAuthentication no
ChallengeResponseAuthentication no
GSSAPIAuthentication yes
GSSAPICleanupCredentials no
UsePAM yes
X11Forwarding no
Banner /etc/issue.net
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS
Subsystem	sftp	/usr/libexec/openssh/sftp-server
PermitRootLogin no

PermitRootLogin no

Finally, notice that I use a handler to trigger a refresh of the sshd service. That handler is found in the handlers section of the playbook. For more info about handlers and what they do, see the docs.

handlers:
  - name: Reload SSH
    service:
      name: sshd
      state: reloaded

Once you have SSH locked down from a configuration perspective, it's time to restrict SSH to only permitted IP addresses. If you're using the default firewalld, this is easily done by moving the SSH service to the internal zone and establishing a list of allowed networks. Ansible makes this simple with the firewalld module. Here is an example:

- name: Add SSH port to internal zone
  firewalld:
    zone: internal
    service: ssh
    state: enabled
    immediate: yes
    permanent: yes

- name: Add permitted networks to internal zone
  firewalld:
    zone: internal
    source: "{{ item }}"
    state: enabled
    immediate: yes
    permanent: yes
  with_items: "{{ allowed_ssh_networks }}"

- name: Drop ssh from the public zone
  firewalld:
    zone: public
    service: ssh
    state: disabled
    immediate: yes
    permanent: yes

This task uses a with_items loop with the allowed_ssh_networks variable. That variable is defined in the vars section of the playbook:

vars:
  allowed_ssh_networks:
    - 192.168.122.0/24
    - 10.10.10.0/24

In this case, the module restricts access to the internal zone to the 10.10.10.0/24 and 192.168.122.0/24 networks. The immediate and permanent parameters tell the module to apply the rules immediately and add them to firewalld's permanent rules to persist on reboot. You can confirm the configuration by looking at the generated rules. For more information about firewalld and its configuration, check out Enable Sysadmin's firewalld post.

[root@nyc1-webserver-1 ~]# firewall-cmd --list-all --zone=public
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eth0
  sources: 
  services: dhcpv6-client
  ports: 
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 
	
[root@nyc1-webserver-1 ~]# firewall-cmd --list-all --zone=internal
internal (active)
  target: default
  icmp-block-inversion: no
  interfaces: 
  sources: 192.168.122.0/24 10.10.10.0/24
  services: dhcpv6-client mdns samba-client ssh
  ports: 
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 

Disable unused software and services

With access to SSH locked down, I turn my attention to removing unused software and disabling unnecessary services. Ansible's package and service modules are up to the challenge, as seen below:

- name: Remove undesirable packages
  package:
    name: "{{ unnecessary_software }}"
    state: absent

- name: Stop and disable unnecessary services
  service:
    name: "{{ item }}"
    state: stopped
    enabled: no
  with_items: "{{ unnecessary_services }}"
  ignore_errors: yes

There are two things to notice about these tasks. First, I again use variables (and loops, for the service task) to keep my playbook short and reusable. These variables have been added to the vars section of the playbook:

vars:
  allowed_ssh_networks:
    - 192.168.122.0/24
    - 10.10.10.0/24
  unnecessary_services:
    - postfix
    - telnet
  unnecessary_software:
    - tcpdump
    - nmap-ncat
    - wpa_supplicant

Second, I set ignore_errors to yes for the service task. This prevents the playbook run from failing if a service doesn't exist on the target machine (which is acceptable). For example, many servers probably don't have the telnet service. But if they do, I want to make sure it's disabled. By ignoring errors, I can successfully run this playbook against a host even if it doesn't have the telnet service installed. If you're concerned with this approach, you could write more complex conditionals to only try disabling a service if it already exists on the remote system.

Security policy improvements

You've now performed several very concrete tasks that improve your newly-provisioned system's security posture. The last thing that I like to do on my systems isn't a technical security improvement—it's a process and legal-oriented control. I always ensure that my systems have a login banner and message of the day to alert users about my acceptable use policy. This ensures that there is no doubt that access to a system is restricted: it's printed right in the login banner and MOTD.

Installing these files is a perfect activity for Ansible's file module since they rarely change across all of my servers. For more discussion about when to use the file or copy module, check out my recent article.

- name: Set a message of the day
  copy:
    dest: /etc/motd
    src: etc/motd
    owner: root
    group: root
    mode: 0644

- name: Set a login banner
  copy:
    dest: "{{ item }}"
    src: etc/issue
    owner: root
    group: root
    mode: 0644
  with_items:
    - /etc/issue
    - /etc/issue.net

The contents of the actual files are a simple, terse explanation of authorized access and acceptable use. You will want to work with your company's legal team to ensure that the messaging is right for your organization.

$ cat files/etc/issue
Use of this system is restricted to authorized users only, and all use is subjected to an acceptable use policy.

IF YOU ARE NOT AUTHORIZED TO USE THIS SYSTEM, DISCONNECT NOW.

$ cat files/etc/motd
THIS SYSTEM IS FOR AUTHORIZED USE ONLY

By using this system, you agree to be bound by all policies found at https://wiki.example.com/acceptable_use_policy.html. Improper use of this system is subject to civil and legal penalties.

All activities are logged and monitored.

Wrap up

This article shows you how to bring together several server-hardening tasks into a single Ansible playbook to run against new systems (and continue running against existing systems) to improve your security posture. By leveraging some of the tips that you learned and combining them with your own security runbook, you can use Ansible to ensure quick, easy, and repeatable security configurations across your environment. This is a great way for the Ansible novice to begin automating a common workflow. It's also a perfect way for the experienced Ansible user to leverage their favorite tool to improve their organization's security posture.

The full playbook used in this article is included below:

---

- hosts: all
  vars:
    allowed_ssh_networks:
      - 192.168.122.0/24
      - 10.10.10.0/24
    unnecessary_services:
      - postfix
      - telnet
    unnecessary_software:
      - tcpdump
      - nmap-ncat
      - wpa_supplicant
  tasks:
    - name: Perform full patching
      package:
        name: '*'
        state: latest

    - name: Add admin group
      group:
        name: admin
        state: present

    - name: Add local user
      user:
        name: admin
        group: admin
        shell: /bin/bash
        home: /home/admin
        create_home: yes
        state: present

    - name: Add SSH public key for user
      authorized_key:
        user: admin
        key: "{{ lookup('file', '~/.ssh/id_rsa.pub') }}"
        state: present

    - name: Add sudoer rule for local user
      copy:
        dest: /etc/sudoers.d/admin
        src: etc/sudoers.d/admin
        owner: root
        group: root
        mode: 0440
        validate: /usr/sbin/visudo -csf %s

    - name: Add hardened SSH config
      copy:
        dest: /etc/ssh/sshd_config
        src: etc/ssh/sshd_config
        owner: root
        group: root
        mode: 0600
      notify: Reload SSH

    - name: Add SSH port to internal zone
      firewalld:
        zone: internal
        service: ssh
        state: enabled
        immediate: yes
        permanent: yes

    - name: Add permitted networks to internal zone
      firewalld:
        zone: internal
        source: "{{ item }}"
        state: enabled
        immediate: yes
        permanent: yes
      with_items: "{{ allowed_ssh_networks }}"

    - name: Drop ssh from the public zone
      firewalld:
        zone: public
        service: ssh
        state: disabled
        immediate: yes
        permanent: yes

    - name: Remove undesirable packages
      package:
        name: "{{ unnecessary_software }}"
        state: absent

    - name: Stop and disable unnecessary services
      service:
        name: "{{ item }}"
        state: stopped
        enabled: no
      with_items: "{{ unnecessary_services }}"
      ignore_errors: yes

    - name: Set a message of the day
      copy:
        dest: /etc/motd
        src: etc/motd
        owner: root
        group: root
        mode: 0644

    - name: Set a login banner
      copy:
        dest: "{{ item }}"
        src: etc/issue
        owner: root
        group: root
        mode: 0644
      with_items:
        - /etc/issue
        - /etc/issue.net

  handlers:
    - name: Reload SSH
      service:
        name: sshd
        state: reloaded

[ Need more on Ansible? Take a free technical overview course from Red Hat. Ansible Essentials: Simplicity in Automation Technical Overview. ]