System Hardening Using Ansible

System Hardening Using Ansible

This is an old talk which I think is still fairly relevant in 2020. Apart from this talk I co-authored a book on the subject Security Automation with Ansible 2

System Hardening using Ansible

I presented this talk at AllDayDevOps 2016. It was fairly well received and the ideas presented here resonated with the audience.

If you are here for the materials, please follow the links

Talk Materials Links
Slides on Speakerdech Slides on Speakerdeck
Slides as PDF for download Slides as PDF
Video of the talk YouTube Video

![Application Deployment + Configuration Management + Continuous Delivery]()

Ansible offers a flexible approach to building a SecOps pipeline. System hardening can become just another software project. Using it we can do secure application deployment, configuration management and continuous monitoring. Security can be codified & attack surfaces reduced by using Ansible.

Ansible is tailor made for doing declarative security

  1. Ansible removes the need for an agent and uses SSH for all communication
  2. Ansible uses playbooks to execute a series of commands/modules on the target
  3. Managing Ansible inventory is a simple as editing a text file
  4. Ansible follows the concept of idempotent, which translates into describing the state that we would like the system to be in.

Ansible is for IT Security Automation

Secure Channel for data transmission and host authentication

Since Ansible is riding on SSH for transferring data and allows for ensuring that the host we are connecting to, is the host we wanted to connect to we can be assured that our data in transmission is safe and our commands are executing on the server we wanted to run them on.

Playbooks are structured instruction manuals

While each command on the server that we execute using Ansible is separate, we can define them in a sequence. Additionally we can define variables which are picked up when the playbook is running to create generic instruction manuals.

All playbooks are written in a YAML providing us with

  1. Structure that we can learn and train on
  2. Since playbooks are text files, we can use Git to do version control on them
  3. By using Git or another version control software, managing the playbooks is just like managing any software project.
  4. Therefore infrastructure as code but for security

Playbooks need to operate on hosts

Managing Ansible inventory is done by using text based files in which we define the servers and their categories. A structured text file with up to date inventory can be generated by hand (not desirable if the servers come and go), but they can be easily generated using any tool capable of giving us text output.

The concept of being idempotent

From http://docs.ansible.com/ansible/glossary.html#term-idempotency

The concept that change commands should only be applied when they need to be applied, and that it is better to describe the desired state of a system than the process of how to get to that state. Our job is now to ensure that we need to define what constitutes a secure and hardened system.

By using various best practices like

  1. DISA-STIG
  2. CIS Benchmarks
  3. NIST Guidelines
  4. Distribution specific guidelines
  5. Application security specific guidelines

Security Hardening

Security hardening is the process where we identify insecure default configuration present on a system and apply changes that will change the configuration to secure values.

The process can be applied to all the layers

Layer Description
Network Enable firewall with restrictive rule sets
Transport Enable TCP wrappers for a service/subnet matching
Application Enable web server configuration to allow white listed access to administration resources
Kernel networking parameters Enable defences for the networking stack that work at a host level

Application Deployment

Applications that get deployed using the DevOps paradigm sometimes can be insecure to begin with.

For example, a developer copies over the release folder from the git repository without removing the .git folder.

If additional hardening of the web server configuration is in place

  1. Disallow access to .git folder
  2. Disallow Directory Listing by default

Then this weakness can’t be exploited. Otherwise this can expose the entire source code of the application along with any additional secrets such as database username, passwords, API keys etc.

Configuration Management

Configurations change from dev to staging to prod. By ensuring the change is done at the playbook and the playbook is applied, configuration management is simplified considerably. Each change can become part of a git commit and if a security incident is being investigated, the incident responders can get a fair idea which commit may have caused the issue.

Continuous Monitoring

By scheduling regular scanning of the state of the system, based on playbooks already created, we can create a historical time line of various parameters that should be measured for security.

A tool like Ansible Tower, although a paid tool, can be useful. We can always evaluate other free and open source options to do the same.

Notes

This talks and demo is relevant and useful for any practitioner of DevSecOps.

  1. It introduces the concepts of declarative security
  2. Showcases one of the tools (Ansible) to embrace DevSecOps in a friction free no expense required manner
  3. Implements security architecture principles using a structured language (YAML) as part of the framework (playbooks) which is ‘Infrastructure As Code’
  4. Gives a clear roadmap on how to find the best practices for security hardening
  5. Covers how continuous monitoring can be applied for security
Akash Mahajan avatar
About Akash Mahajan
That Web Application Security Guy long time ago. Co-Founder @AppseccoUK | Community Manager @null0x00 | Author - Burp Suite Essentials, Security Automation with Ansible2. Writing about application security, being part of communities like null, OWASP and other technically inclined topics. Sometimes about my company and books