Check the compliance of a Linux system with the ANSSI BP-028 guide

Cyberwatch evaluates the compliance of Linux systems with the guide ANSSI-BP-028 v2.0 “Configuration recommendations of a GNU/Linux system”, published by the ANSSI.

The ANSSI_BP028_Linux benchmark covers the 80 recommendations of the guide, split into 176 compliance rules: 164 are checked automatically and 12 must be checked manually. It applies to all the Linux distributions supported by the compliance module: Debian, Ubuntu, Red Hat Enterprise Linux and its derivatives (AlmaLinux, Rocky Linux, Oracle Linux, CentOS), Fedora, SUSE Linux Enterprise Server and openSUSE Leap, Amazon Linux and Photon OS.

Repositories

The guide classifies each recommendation in one of its four levels: Minimal, Medium, Reinforced and High (see the interpretation of the levels). These levels are cumulative: the recommendations apply from the minimal level up to the targeted level. Each level repository therefore contains the rules of this level and of the lower levels:

Repository	Targeted level	Recommendations	Rules checked automatically
`ANSSI_BP028_level_1`	Minimal	11	19
`ANSSI_BP028_level_2`	Medium	40	110
`ANSSI_BP028_level_3`	Reinforced	58	140
`ANSSI_BP028_level_4`	High	80	164

The ANSSI_BP028 repository contains all the rules of the benchmark, like ANSSI_BP028_level_4.

To evaluate an asset, add to it the repository of the targeted level, and only this one: adding several levels does not add any rule. These repositories are present by default in Cyberwatch, but are not assigned to any asset. To assign them automatically, for example to all Linux servers, use assets rules.

Organization of the rules

Each rule has a reference of the form ANSSI-BP028-R<n>-<nnn>, where R<n> is the number of the recommendation in the guide, for example ANSSI-BP028-R12-001.
The category of the rule repeats the number and the French title of the recommendation, which allows filtering the rules by recommendation. For example, the category R12 – Paramétrer les options de configuration du réseau IPv4 groups the rules of R12.
A recommendation has one rule per setting to check (a kernel parameter, a mount option, a sudo directive), so that each setting can be fixed or ignored separately. Recommendations R15 to R27, which relate to the kernel compilation options, are an exception: one rule per recommendation.
The level of a rule is always the level of its recommendation in the guide.
The title, description, objective and remediation of the rules are written in English. The description specifies what the rule checks, where it reads it, and the default behavior of the distributions.

Types of rules

Automated rules: the rule checks what the guide requires.
Partial checks: when a recommendation is partly organizational, the rule checks its technical part. Its description starts with what is checked and what is not (“This rule checks… It does not check…”). For example, the rule of R80 checks that a local firewall is active, but not that each service only listens on the necessary network interfaces.
Manual rules: the recommendation cannot be checked on the system. The rule is evaluated on no asset and belongs to no repository. It is listed with the “Manual rule” mention on the page of the ANSSI_BP028_Linux benchmark, in Administration > Benchmarks.

The recommendations to check manually are the following:

Recommendation	Level
R2 – Configuring the BIOS/UEFI	Medium
R4 – Replacing of preloaded keys	High
R51 – Changing the secrets and access rights as soon as possible	Reinforced
R58 – Installing only strictly necessary packages	Minimal
R60 – Using hardened package repositories	Reinforced
R64 – Configuring the privileges of the services	Reinforced
R65 – Partitioning the services	Reinforced
R66 – Hardening the partitioning components	High
R70 – Separating the system accounts and directory administrator	Medium
R77 – Protecting the sealing database	High
R78 – Partitioning the network services	Reinforced
R79 – Hardening and monitoring the exposed services	Medium

Read the results

The rules run with administrator privileges. An asset scanned without an agent must therefore have a scan account with sudo rights (see the prerequisites of the scan account).

The states of the rules are the same as for the other repositories:

Success: the asset complies with the rule
Failed: the asset does not comply with the rule
Skipped: the asset was scanned without sudo rights
Not applicable: the rule does not apply to the asset, for example a partitioning rule in a container, a sudo rule without sudo installed, or a secure boot rule on an architecture without UEFI; the output then starts with N/A: followed by the reason
Anomaly: the check could not run

The output of each rule, visible in the “Compliance” tab of the asset, details what was observed. For the scripts specific to the repository, the first line gives the verdict (PASSED, FAILED or N/A: <reason>), followed by the expected value and by the observed value.

Rules R53-001, R54-001, R54-002, R56-001 and R57-001 browse the local file systems. Each of them stops after 5 minutes: it is then failed, and its output indicates the file system where the browsing stopped.

Prerequisites of the agentless scan account

Without an agent, Cyberwatch elevates its privileges with sudo -n, without a terminal, then starts a shell that runs other programs. The scan account must have the sudo rights described in Technical information on agentless connections for Linux systems, for example cyberwatch ALL=(ALL) NOPASSWD:ALL.

Several recommendations of the guide restrict sudo or access to the system, and can block this account. When implementing them, plan the following exceptions, replacing cyberwatch with the name of the scan account:

R38 (group dedicated to sudo): add the scan account to the group allowed to run sudo, otherwise it can no longer elevate its privileges:
```
usermod -aG sudogrp cyberwatch
```
R39 (sudo configuration directives): the noexec and requiretty directives prevent the analysis. Add the two following overrides for the scan account, on two separate lines:
```
Defaults:cyberwatch !noexec
Defaults:cyberwatch !requiretty
```
sudo-rs, the default sudo starting with Ubuntu 25.10, ignores any Defaults line that contains a setting it does not know: a single line Defaults:cyberwatch !noexec,!requiretty would be ignored, !noexec included. sudo-rs does not know requiretty: on an asset where it is the only sudo installed, only add the !noexec line, as its visudo rejects the second one. The rules of R39 list these overrides in their output, without counting them as deviations.
R40 to R44 (sudo specifications): the rules ignore the specifications whose list of users is exactly the account that runs the analysis. The line cyberwatch ALL=(ALL) NOPASSWD:ALL therefore does not make them fail.
R47 (SELinux confinement of users): a user_u SELinux user cannot use sudo. Before mapping the default users to user_u, map the scan account to unconfined_u:
```
semanage login -a -s unconfined_u cyberwatch
```
R80 (attack surface of network services): allow SSH before enabling the firewall, so as not to interrupt the analyses.

The Cyberwatch agent, run as root by default, is not concerned by these exceptions.

High-impact recommendations

Some recommendations cannot be fixed by a simple configuration change, or may hinder operations. Before applying them, refer to the guide and to the remediation of each rule:

R15 to R27 (High level): kernel compilation options. The kernels of the distributions do not enable all these options: the only fix is to recompile the kernel or to change it.
R10 (Reinforced level): with kernel.modules_disabled = 1, the kernel refuses any module loading until the next reboot, including for root. The necessary modules (storage, network or USB drivers, file systems) must be loaded at boot.
R28 (Medium level): typical partitioning. Creating a partition after the installation requires moving data, or even reinstalling the system.
R39 (Medium level): the noexec directive makes sudo commands that start other programs fail (package managers, scripts, service restarts) as long as they are not allowed one by one with the EXEC tag.

When a deviation is accepted, the rule can be ignored, with a comment that justifies this choice.

Differences with the other repositories

Security_Best_Practices

The Security_Best_Practices repository is a baseline of best practices assigned by default to servers and workstations. For Linux, it contains 45 rules, part of which follow recommendations of the BP-028 guide, but it does not implement the guide: its levels are chosen according to the expected remediation effort, and not according to the level of the recommendation.

The ANSSI_BP028 repositories cover the whole guide, with the level of each recommendation. Both can be assigned to the same asset: when an ANSSI rule takes up the check of a Security_Best_Practices rule, they give the same result.

Import of a ComplianceAsCode DataStream

The ComplianceAsCode project (scap-security-guide package) publishes ANSSI BP-028 profiles in its DataStreams. These can be imported as benchmarks, but Cyberwatch does not apply their profiles: all the rules of the DataStream are imported, whatever the profile, and only part of their checks is supported. ComplianceAsCode does not provide any ANSSI profile for Ubuntu either.

To evaluate a Linux system against the guide, Cyberwatch recommends the ANSSI_BP028 repositories.