RHEL 7 CIS

Setting Up a RHEL/CentOS 7 Machine to Meet CIS Standards

Reference: CIS RedHat Enterprise Linux 7 Benchmark v4.0.0 - 21-12-2023

Need Help?

Lockdown Enterprise

Ansible Support

Community

Join our Discord Server to ask questions, discuss features, or chat with other users of Ansible-Lockdown.

Important Notes

This role will change your system, which might lead to unexpected issues. It is meant for fixing problems after an audit, not for auditing by itself.

Warning: Check Mode is not fully supported! While it may seem to run without errors, it's not reliable and should be used carefully. For compliance checks, use the RHEL7-CIS-Audit role or a compliance scanner instead.

This role is meant for a fresh OS install. If you're using it on an existing system, please review it for necessary adjustments.

For stable releases, use the main branch and the specific release related to the CIS benchmark you want to apply.

Security Level Settings for CIS

You can choose to run only level 1 or level 2 controls. Use the following tags for management:

• level1-server
• level1-workstation
• level2-server
• level2-workstation

The controls in the defaults section also need to match these for accurate auditing.

Upgrading from a Previous Version

CIS releases change frequently. It's highly recommended to review new references and variables, as many have changed since the first release of ansible-lockdown.

Now, this is compatible with Python3 if it's the default interpreter, which requires certain configurations.

See the Changelog for more details.

New Auditing Feature

You can enable or disable auditing in the defaults/main.yml file with the variable rhel7cis_run_audit, which is set to false by default. Refer to the wiki for more information. The defaults file also configures checks for only the enabled controls within the Ansible role.

This new audit approach is quick and lightweight, checking configuration compliance and live settings where possible.

It uses a small (12MB) Go binary called goss for checking configurations without extra infrastructure or tools. This audit checks not just whether the config is set correctly, but also if it is actively running that way, reducing false positives.

Documentation

• Read The Docs
• Getting Started
• Customizing Roles
• Per-Host Configuration
• Maximizing Role Benefits

Requirements

General:

• Basic knowledge of Ansible. Here are helpful links to get started if you're new to Ansible:

  • Main Ansible Documentation
  • Ansible Getting Started Guide
  • Tower User Guide
  • Ansible Community Info

• A working Ansible and/or Tower setup, including all necessary configurations and packages.

• Review the tasks in this role to understand what each one does. Some tasks may disrupt a live system. Also, get familiar with the variables in the defaults/main.yml file.

Technical Dependencies:

• Running Ansible/Tower setup (This role is tested with Ansible version 2.9.1 and newer)
• Python3 Ansible execution environment
• python-def (should be included in RHEL/CentOS 7) - The first task sets up prerequisites for Python3 and Python2 (if required).
  • libselinux-python
  • python3-rpm (used by Python3 to manage RPM packages)

Role Variables

This role is designed so that users do not need to edit the tasks directly. Customization should be done through the defaults/main.yml file or additional variables within your project, job, or workflow.

Tags

There are many tags available for precise control. Each control has its own tags indicating the level, whether it’s scored or not, the OS element it pertains to, if it’s a patch or an audit, and the rule number.

For example, if you set your run to skip all controls tagged with "services," those tasks will be ignored. Conversely, you can run only tasks tagged with "services."

      tags:
      - level1-workstation
      - level1-server
      - automated
      - avahi
      - services
      - patch
      - rule_2.2.4

Community Contribution

We encourage community contributions to this role. Please follow these rules:

• Work in your own branch. Ensure all commits are Signed-off and GPG signed before merging.
• Community Pull Requests go into the devel branch.
• All PRs into devel must have a GPG signature, be Signed-off, and pass functional tests before approval.
• After merging and reviewing changes, an authorized member will move your changes to the main branch for a new release.

Pipeline Testing

Uses:

• ansible-core 2.12
• ansible collections - pulls the latest version based on the requirements file
• Runs audits using the devel branch
• Automated tests occur on pull requests to devel

Local Testing

• Ansible

  • ansible-base 2.10.17 - python 3.8
  • ansible-core 2.13.4 - python 3.10
  • ansible-core 2.15.1 - python 3.11

Additional Features

You can test and run pre-commit from within the directory

pre-commit run

Acknowledgments

Special thanks to the amazing community and all its members.

A heartfelt thank you also to the original authors and maintainers: Josh Springer, Daniel Shepherd, Bas Meijeri, James Cassell, Mike Renfro, DFed, George Nalen, Mark Bolwell.