RHEL 9 CIS

Setting Up a RHEL 9 Machine for CIS Compliance

Based on CIS RedHat Enterprise Linux 9 Benchmark v1.0.0 - 11-30-2022

Need Help?

Lockdown Enterprise

Ansible Support

Community

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

Contributing

We welcome issues and pull requests! Please make sure all commits are signed and GPG-signed, as explained in the Contributing Guide.

Important Notes

This setup will change your system, which might lead to unexpected issues. It's not a tool for auditing, but for fixing problems found after an audit.

Check Mode isn't fully supported! While you can run the role in check mode without errors, it's not recommended. Use the RHEL8-CIS-Audit role or a compliance scanner instead for compliance checking.

This role is designed for a fresh install of the Operating System. If you apply it to an existing system, check for any specific changes you might need to make.

To use the stable version, point to the main branch and the relevant release for the CIS benchmark you want to work with.

Setting Security Levels for CIS

You can run only level 1 or level 2 controls for CIS by using the following tags:

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

Make sure this is reflected in the defaults section, as this determines the tests that run with the audit component.

Upgrading from a Previous Release

Each CIS release includes changes. It's a good idea to review the updates and variables available, as they have changed a lot since the initial Ansible-Lockdown release. This version supports Python 3 if it's set as the default interpreter and has specific prerequisites.

See the Changelog for more information.

Auditing (New Feature)

You can enable or disable auditing in the defaults/main.yml file using the setup_audit and run_audit variables, which are set to false by default. For more details, refer to the wiki. The defaults file also sets up goss checks to only verify enabled controls.

This new auditing system is lightweight and checks compliance with configuration and running settings.

The auditing uses a small (12MB) binary called goss along with configurations. This approach checks not only if the configuration is correct but also whether it's currently running as intended.

Check out RHEL9-CIS-Audit for more.

Documentation

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

Requirements

• RHEL 9
• AlmaLinux 9
• Rocky 9
• Oracle Linux 9

Ensure you can download or add the goss binary and content to the system if you are using auditing (alternative methods are available).

For CentOS Stream, although it may work, it's not officially supported and requires setting the following variable:

os_check: false

General Requirements:

• Basic Ansible knowledge. Here are some helpful links:
  • Main Ansible Documentation
  • Getting Started with Ansible
  • Tower User Guide
  • Ansible Community Information
• Ansible and/or Tower installed, configured, and functioning.
• Review task descriptions in this role to understand what each control does, as some tasks can disrupt a live system. Familiarize yourself with variables in the defaults/main.yml file too.

Technical Dependencies:

• Python3
• Ansible 2.10 or higher
• Python definition (should be included in RHEL 9)
• libselinux-python
• Required pip packages:
  • jmespath
• Collections found in collections/requirements.yml

Pre-commit is available if installed on your host to test pull requests.

Role Variables

This role is set up so end users typically don't need to edit tasks directly. All customization should be done by overriding the necessary variables in the defaults/main.yml file, such as using inventory, group_vars, or extra_vars.

Tags

Many tags are available for added control. Each control has its own tags indicating its level, whether it's scored, what OS element it pertains to, if it's a patch or an audit, and its rule number.

For example, if you set your run to skip tasks tagged with "services," those tasks will not run. Conversely, you can choose to run only tasks with a specific tag.

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

Community Contributions

We encourage community contributions. Please follow these guidelines:

• Work in your own branch. Ensure all commits are signed and GPG signed.
• Community pull requests go into the devel branch.
• Pull requests into devel will require confirmed GPG signatures and a functional test before approval.
• Once your changes are reviewed and approved, an authorized member will merge them into the main branch for a new release.

Known Issues

CIS 1.2.4 - The repo_gpgcheck isn't performed for Red Hat hosts as default repos lack this function. This does not affect Rocky and Alma.

Use the variable below to adjust:

rhel9cis_rhel_default_repo: true  # set to false if using a repo that supports this feature

Pipeline Testing

The pipeline utilizes:

• ansible-core 2.12
• Latest ansible collections based on the requirements file
• Runs the audit against the devel branch
• Executes pre-commit checks on pull requests to verify everything is in place
• This testing is automated for pull requests into 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 Tools

• A makefile is included for testing and setup.
• You can test and run pre-commit from within the directory with:

pre-commit run

Acknowledgments

The project is based on an original idea by Sam Doran.

A special thank you to the wonderful community and all its members, especially the original authors and maintainers:

Mark Bolwell, George Nalen, Steve Williams, Fred Witty.