Forge Home


This module hardens Linux servers to CIS security compliance


469 latest version

4.7 quality score

We run a couple of automated
scans to help you access a
module's quality. Each module is
given a score based on how well
the author has formatted their
code and documentation and
modules are also checked for
malware using VirusTotal.

Please note, the information below
is for guidance only and neither of
these methods should be considered
an endorsement by Puppet.

Version information

  • 4.0.0 (latest)
  • 3.2.1
  • 3.1.3
  • 3.1.2
  • 3.1.0
  • 3.0.0
  • 2.1.18
  • 2.1.17
  • 2.1.16
  • 2.1.15
  • 2.1.14
  • 2.1.13
  • 2.1.12
  • 2.1.11
  • 2.1.10
  • 2.0.10
  • 2.0.6
  • 2.0.5
  • 2.0.4
  • 1.0.17
  • 1.0.16
  • 1.0.15
  • 1.0.14
  • 1.0.13
  • 1.0.12
  • 1.0.11
  • 1.0.10
  • 1.0.9
  • 1.0.8
  • 1.0.7
  • 1.0.5
  • 1.0.1
  • 1.0.0
released Nov 22nd 2022
This version is compatible with:
  • Puppet Enterprise 2019.8.x, 2019.7.x, 2019.5.x, 2019.4.x, 2019.3.x, 2019.2.x, 2019.1.x, 2019.0.x, 2018.1.x, 2017.3.x
  • Puppet >= 5.0.0 < 7.0.0
  • , , , , , , ,
  • secure_linux_cis

Start using this module

  • r10k or Code Manager
  • Bolt
  • Manual installation
  • Direct download

Add this module to your Puppetfile:

mod 'fervid-secure_linux_cis', '4.0.0'
Learn more about managing modules with a Puppetfile

Add this module to your Bolt project:

bolt module add fervid-secure_linux_cis
Learn more about using this module with an existing project

Manually install this module globally with Puppet module tool:

puppet module install fervid-secure_linux_cis --version 4.0.0

Direct download is not typically how you would use a Puppet module to manage your infrastructure, but you may want to download the module in order to inspect the code.



fervid/secure_linux_cis — version 4.0.0 Nov 22nd 2022

Build Status


Table of Contents

  1. Description
  2. Setup - The basics of getting started
  3. Usage - Configuration options and additional functionality
  4. Limitations - OS compatibility, etc.
  5. Development - Guide for contributing to the module


This Puppet module implements security controls defined in the Center for Internet Security (CIS) benchmarks for the following operating systems and benchmark versions:

Operating System Benchmark Version
AlmaLinux 8 2.0.0
Amazon 2 2.0.0
CentOS 7 3.1.2
Debian 10 1.0.0
Debian 11 1.0.0
Oracle 7 3.1.1
RedHat 6 3.0.0
RedHat 7 3.1.1
RedHat 8 2.0.0
Rocky 8 1.0.0
SLES 15 1.1.1
Ubuntu 18.04 2.1.0
Ubuntu 20.04 1.1.0
Ubuntu 22.04 1.0.0

CIS Benchmarks can be found here.


What secure_linux_cis affects

This module touches the:

  • Kernel settings
  • Bootloader configuration
  • Update settings
  • Firewall
  • TCP wrappers
  • File and directory permissions

These are good things. They keep you safe.

But, please run tests before slamming it into productions.

Beginning with secure_linux_cis

To start with Secure Linux and harden your server to CIS standards, declare the secure_linux_cis: class.

NOTE: you will want to open up at least one firewall port. See Opening firewall ports.

Three parameters are required:

  • time_sync Specify choice of 'ntp' or 'chrony'

  • time_servers Specify your enterprise's time server(s)

  • profile_type It will be workstation or server

  • allow_users At least one user needs to ssh in. NOT root

class {'::secure_linux_cis':
   time_servers  => ['', ''],
   profile_type  => 'server',
   allow_users   => 'trusteduser',


Opening firewall ports

This module opens up port 22. Everythings else is shut down by default.

If using iptables (Everything but RedHat family version 8) you will need to add firewall rules.

For example we want to open up for 8080 for tomcat:

  firewall { '010 tomcat http port':
    chain  => 'INPUT',
    dport  => 8080,
    state  => 'NEW',
    action => 'accept',
    proto  => 'tcp',
    tag    => 'cis_firewall_rule',

Notice the tag parameter. Include this on all firewall rules.

It ensures firewall rules are implemented in the proper order.

TCP wrappers

This module is very generous with tcp controls. It relies on firewall rules for enforecment.

You should tighten them down.

TODO: TCP wrapper example

Disabling rules with Hiera (Not applicable to 3.0.0 descriptive based 'rules' .pp files)

As of enforcement for the Redhat 7 OS, there are 223 CIS rules that are either enforced or documented. Each rule relates to a class which can be turned on or off according to the needs of the system. By default, all vulnerabilities are turned ON to ensure maximum security out-of-box. This is how you would disable enforcement of a particular recommendation using Hiera:

# hieradata/common.yaml
secure_linux_cis::rules::ensure_mounting_of_squashfs_filesystems_is_disabled::enforced: false

Enabling rules with Hiera (Not applicable to 3.0.0 descriptive based 'rules' .pp files)

Some recommendations are not enforced by default. For example, to enforce password-protected bootloader, a hash value for password must be present:

# hieradata/common.yaml
secure_linux_cis::rules::ensure_bootloader_password_is_set::enforced: true
secure_linux_cis::rules::ensure_bootloader_password_is_set::grub_username: root
secure_linux_cis::rules::ensure_bootloader_password_is_set::grub_pbkdf2_password_hash: grub.pbkdf2.sha512.10000.7D81626...ABC0123C616C3210CBA

NOTE: Don't use the example pbkdf2 string value. It needs to be a hash you've generated with the intended password.

See Limitations for a list of vulnerabilities that might not apply to certain system configurations

Any parameters that need to be explicitly defined can be done so in init.pp

Include usage examples for common use cases in the Usage section. Show your users how to use your module to solve problems, and be sure to include code examples. Include three to five examples of the most important or common tasks a user can accomplish with your module. Show users how to accomplish more complex tasks that involve different types, classes, and functions working in tandem.

No-Op Mode

It is possible to run the module in "No-Op Mode", which identifies detected Configuration Drifts without implementing any actual changes. This is useful for auditing the state of your system without making any changes.

puppet agent -t --noop


RedHat family '8' OSes are not fully covered. Almost, but not quite.

Help getting this out the door would be appreciated. Also, we do not have acceptance testing completed for OracleLinux, Aliyun, or Amazon Linux.

Same deal. Any help appreciated.


Please ensure PDK validation and unit tests pass.

Ideally make sure litmus tests pass too, but we understand this will be out of scope for some.