CIS

This plugin will bring a set of directives to help auditing the CIS benchmark with Rudder. All directives will be provided in Audit mode enabled to prevents any unwanted changes on your systems.

The plugin brings a sizable number of directives (>100) and may obfuscate your current set of techniques and directives. Until it is better organized we strongly recommend to test the plugin in a dedicated test Rudder Server.

The directives set is not meant to be used in Enforce mode without manual customization of the provided configurations. Without any changes, it will most likely break your system.

Currently, the plugin is still in a Beta version and only support parts of the RedHat7 and Debian9 benchmarks. It is still in active development and may not behave as you expect. Check the troubleshooting section below.

Prerequisites

This plugin needs the package rudder-api-client and python3-requests to be installed on your Rudder Server.

Usage

The plugin provides one rule to help you audit the target benchmark with Rudder. We recommend to not modify the rules provided by the plugin and to apply them to your audit wanted groups of nodes. For most commons cases, skipping items on a per node basis as described below should be enough to adapt the rule set to your needs and will make eventual plugin upgrade much more easier.

Installation

Installing the plugin will install a set of Techniques, Directives and Rules to your Rudder Server. All of them are tracked by the plugin and can be removed at any time by removing the plugin from the Server.

Uninstallation

When removing the plugin, you will be asked for each Rule/Directive/Technique if you want to remove it. Except if you did customize the Techniques or Directives distributed with the plugin, we recommend to always wipe all the content distributed with it when asked for.

How it works

Each benchmark item will be translated as one or more directives with the following:

The directive name follows the syntax: CIS - <item name> (<extra infos if any>)
- Where extra infos is optional and only used when a single benchmark item needs multiple directives to be audited.
- For the RHEL7 benchmark with the item: "3.2.4 Ensure suspicious packets are logged (Scored)" This items is declined in two directives, called: "CIS - Ensure suspicious packets are logged (net.ipv4.conf.all.log_martians)" and "CIS - Ensure suspicious packets are logged (net.ipv4.conf.default.log_martians)".

The directives are all tagged based on the benchmarks:

If we take one of the two directives descrive above we will have the following tags to help you organize and quickly search for specific items:

{
"cis-redhat7" : ["3", "3.2", "3.2.4"], #Based on the benchmark item number
"cis-server" : "1",                    #Based on the benchmark level for server
"cis-workstation" : "1"                #Based on the benchmark level for workstation
}

Each directive is based on techniques written from the Technique Editor, this will let you modify them easily if needed.

Test a subset of the benchmark

In most cases you will not want to test every single items of the CIS benchmarks on your servers. You can skip items on a node basis without changing the rules provided.

To do it:

For a specific node, identify the CIS-directives that you want to be skipped and note their Directive Rudder ID found in their respective page under show technical details in the directive tree.

Add a JSON node property named skip on the target node containing keys corresponding to the previously noted Directives Rudder ID.

# An example of the skip property value to skip the "Ensure suspicious packets are logged" item
{
  "0b8e988c-fa02-42a0-813c-e07ff6eafb9a": "True",
  "0b8e988c-fa02-42a0-813c-e07ff6eafb9a": "True"
}

The skipping process is more detailed in the section below.

Troubleshootings

After install, the generation status in the Rudder UI may be in error, stating about some missing bundles, try to run a rudder agent update on your server, and force a Policy Regeneration in the UI.
Since the CIS plugin audits hundreds of components, you may come across some journald limitations, which may stop syslog before the end of the agent execution. This lead to non reporting nodes, and messages in /var/log/messages before the end of the agent execution like:
```
Oct  1 08:41:40 localhost systemd: Stopping System Logging Service...
```
This can be fixed by removing the burst limits in your journald configuration:
```
# In /etc/systemd/journald.conf
RateLimitInterval=0
RateLimitBurst=0
```

Extend, improve the directives

Install the plugin
Modify or create the directives or techniques you want to add to the plugin

Export them by running:

/opt/rudder/bin/rudder_synchronize export rule <rule-id> <destination-file>

And add the content of <destination-file>/directives and <destination-file>/rules to the plugin repo under the src folder.
You may need to run a build and a clean to normalize the newly added jsons.

Each added Technique should be as generic as possible to limit their number. Each one of them must start with a condition from variable existence defined as follows:

Each generic methods used in the Technique should then be guarded by the condition:

skip_item_${report_data.directive_id}_false

← Change validation Consul →