Verificare la conformità di un sistema Linux alla guida ANSSI BP-028

Cyberwatch valuta la conformità dei sistemi Linux alla guida ANSSI-BP-028 v2.0 «Recommandations de configuration d’un système GNU/Linux», pubblicata dall’ANSSI.

Il benchmark ANSSI_BP028_Linux copre le 80 raccomandazioni della guida, suddivise in 176 regole di conformità: 164 vengono verificate automaticamente e 12 vanno verificate manualmente. Si applica a tutte le distribuzioni Linux supportate dal modulo di conformità: Debian, Ubuntu, Red Hat Enterprise Linux e le sue derivate (AlmaLinux, Rocky Linux, Oracle Linux, CentOS), Fedora, SUSE Linux Enterprise Server e openSUSE Leap, Amazon Linux e Photon OS.

Framework

La guida classifica ogni raccomandazione in uno dei suoi quattro livelli: Minimo, Intermedio, Rafforzato ed Elevato (vedere l’interpretazione dei livelli). Questi livelli sono cumulativi: le raccomandazioni si applicano dal livello minimo fino al livello desiderato. Ogni framework di livello contiene quindi le regole di questo livello e dei livelli inferiori:

Framework	Livello desiderato	Raccomandazioni	Regole verificate automaticamente
`ANSSI_BP028_level_1`	Minimo	11	19
`ANSSI_BP028_level_2`	Intermedio	40	110
`ANSSI_BP028_level_3`	Rafforzato	58	140
`ANSSI_BP028_level_4`	Elevato	80	164

Il framework ANSSI_BP028 contiene tutte le regole del benchmark, come ANSSI_BP028_level_4.

Per valutare un asset, aggiungervi il framework del livello desiderato, e solo quello: aggiungere più livelli non aggiunge alcuna regola. Questi framework sono presenti per impostazione predefinita in Cyberwatch, ma non sono assegnati ad alcun asset. Per assegnarli automaticamente, ad esempio a tutti i server Linux, utilizzare le regole degli asset.

Organizzazione delle regole

Ogni regola ha un riferimento nel formato ANSSI-BP028-R<n>-<nnn>, dove R<n> è il numero della raccomandazione nella guida, ad esempio ANSSI-BP028-R12-001.
La categoria della regola riprende il numero e il titolo della raccomandazione, ad esempio «R12 – Paramétrer les options de configuration du réseau IPv4»: consente di filtrare le regole per raccomandazione.
Una raccomandazione conta una regola per ogni parametro da verificare (un parametro del kernel, un’opzione di montaggio, una direttiva sudo), in modo che ogni parametro possa essere corretto o ignorato separatamente. Le raccomandazioni da R15 a R27, che riguardano le opzioni di compilazione del kernel, fanno eccezione: una regola per raccomandazione.
Il livello di una regola è sempre quello della sua raccomandazione nella guida.
Il titolo, la descrizione, l’obiettivo e la remediation delle regole sono redatti in inglese. La descrizione precisa cosa verifica la regola, dove lo legge, e il comportamento predefinito delle distribuzioni.

Tipi di regole

Regole automatizzate: la regola verifica ciò che richiede la guida.
Controlli parziali: quando una raccomandazione è in parte organizzativa, la regola ne verifica la parte tecnica. La sua descrizione inizia con ciò che viene verificato e ciò che non lo è («This rule checks… It does not check…»). Ad esempio, la regola di R80 verifica che un firewall locale sia attivo, ma non che ogni servizio sia in ascolto solo sulle interfacce di rete necessarie.
Regole manuali: la raccomandazione non può essere verificata sul sistema. La regola non viene valutata su alcun asset e non appartiene ad alcun framework. È elencata con la dicitura «Regola manuale» nella pagina del benchmark ANSSI_BP028_Linux, in Amministrazione > Benchmark.

Le raccomandazioni da verificare manualmente sono le seguenti:

Raccomandazione	Livello
R2 – Configurer le BIOS/UEFI	Intermedio
R4 – Remplacer les clés préchargées	Elevato
R51 – Changer les secrets et droits d’accès dès l’installation	Rafforzato
R58 – N’installer que les paquets strictement nécessaires	Minimo
R60 – Utiliser des dépôts de paquets durcis	Rafforzato
R64 – Configurer les privilèges des services	Rafforzato
R65 – Cloisonner les services	Rafforzato
R66 – Durcir les composants de cloisonnement	Elevato
R70 – Séparer les comptes système et d’administrateur de l’annuaire	Intermedio
R77 – Protéger la base de données des scellés	Elevato
R78 – Cloisonner les services réseau	Rafforzato
R79 – Durcir et surveiller les services exposés	Intermedio

Leggere i risultati

Le regole vengono eseguite con i diritti di amministratore. Un asset analizzato senza agent deve quindi disporre di un account di scansione con i diritti sudo (vedere i prerequisiti dell’account di scansione).

Gli stati delle regole sono gli stessi degli altri framework:

Successo: l’asset è conforme alla regola
Non superato: l’asset non è conforme alla regola
Saltata: l’asset è stato analizzato senza diritti sudo
Non applicabile: la regola non si applica all’asset, ad esempio una regola di partizionamento in un container, una regola sudo senza sudo installato, o una regola di avvio sicuro su un’architettura senza UEFI; l’output inizia allora con N/A: seguito dal motivo
Anomalia: il controllo non ha potuto essere eseguito

L’output di ogni regola, visibile nella scheda «Conformità» dell’asset, dettaglia ciò che è stato constatato. Per gli script specifici del framework, la prima riga fornisce il verdetto (PASSED, FAILED o N/A: <motivo>), seguito dal valore atteso e dal valore constatato.

Le regole R53-001, R54-001, R54-002, R56-001 e R57-001 percorrono i file system locali. Ognuna si interrompe dopo 5 minuti: è allora nello stato Non superato, e il suo output indica il file system in cui il percorso si è interrotto.

Prerequisiti dell’account di scansione agentless

Senza agent, Cyberwatch eleva i propri diritti con sudo -n, senza terminale, poi avvia una shell che esegue altri programmi. L’account di scansione deve avere i diritti sudo descritti in Informazioni tecniche sulle connessioni agentless per i sistemi Linux, ad esempio cyberwatch ALL=(ALL) NOPASSWD:ALL.

Diverse raccomandazioni della guida limitano sudo o l’accesso al sistema, e possono bloccare questo account. Durante la loro implementazione, prevedere le eccezioni seguenti, sostituendo cyberwatch con il nome dell’account di scansione:

R38 (gruppo dedicato a sudo): aggiungere l’account di scansione al gruppo autorizzato a eseguire sudo, altrimenti non può più elevare i propri diritti:
```
usermod -aG sudogrp cyberwatch
```
R39 (direttive di configurazione sudo): le direttive noexec e requiretty impediscono l’analisi. Aggiungere per l’account di scansione le due sovrascritture seguenti, su due righe distinte:
```
Defaults:cyberwatch !noexec
Defaults:cyberwatch !requiretty
```
sudo-rs, il sudo predefinito a partire da Ubuntu 25.10, ignora qualsiasi riga Defaults che contiene un’impostazione che non conosce: una riga unica Defaults:cyberwatch !noexec,!requiretty verrebbe ignorata, !noexec compreso. sudo-rs non conosce requiretty: su un asset in cui è l’unico sudo installato, aggiungere solo la riga !noexec, perché il suo visudo rifiuta la seconda. Le regole di R39 elencano queste sovrascritture nel loro output, senza contarle come scostamenti.
Da R40 a R44 (specifiche sudo): le regole ignorano le specifiche il cui elenco di utenti è esattamente l’account che esegue l’analisi. La riga cyberwatch ALL=(ALL) NOPASSWD:ALL non le fa quindi fallire.
R47 (confinamento SELinux degli utenti): un utente SELinux user_u non può utilizzare sudo. Prima di associare gli utenti predefiniti a user_u, associare l’account di scansione a unconfined_u:
```
semanage login -a -s unconfined_u cyberwatch
```
R80 (superficie di attacco dei servizi di rete): autorizzare SSH prima di attivare il firewall, per non interrompere le analisi.

L’agent Cyberwatch, eseguito per impostazione predefinita come root, non è interessato da queste eccezioni.

Raccomandazioni ad alto impatto

Alcune raccomandazioni non si correggono con una semplice modifica della configurazione, oppure possono ostacolare l’operatività. Prima di applicarle, fare riferimento alla guida e alla remediation di ogni regola:

Da R15 a R27 (livello Elevato): opzioni di compilazione del kernel. I kernel delle distribuzioni non attivano tutte queste opzioni: l’unica correzione è ricompilare il kernel o cambiarlo.
R10 (livello Rafforzato): con kernel.modules_disabled = 1, il kernel rifiuta qualsiasi caricamento di modulo fino al riavvio successivo, anche per root. I moduli necessari (driver di storage, di rete o USB, file system) devono essere caricati all’avvio.
R28 (livello Intermedio): partizionamento tipo. Creare una partizione dopo l’installazione richiede di spostare dei dati, se non addirittura di reinstallare il sistema.
R39 (livello Intermedio): la direttiva noexec fa fallire i comandi sudo che avviano altri programmi (gestori di pacchetti, script, riavvii di servizi) finché non vengono autorizzati uno per uno con l’etichetta EXEC.

Quando uno scostamento è accettato, la regola può essere ignorata, con un commento che giustifica questa scelta.

Differenze con gli altri framework

Security_Best_Practices

Il framework Security_Best_Practices è una base di best practice assegnata per impostazione predefinita ai server e alle postazioni di lavoro. Per Linux, conta 45 regole, di cui una parte riprende raccomandazioni della guida BP-028, ma non implementa la guida: i suoi livelli sono scelti in base allo sforzo di correzione previsto, e non in base al livello della raccomandazione.

I framework ANSSI_BP028 coprono l’intera guida, con il livello di ogni raccomandazione. Entrambi possono essere assegnati allo stesso asset: quando una regola ANSSI riprende il controllo di una regola Security_Best_Practices, danno lo stesso risultato.

Importazione di un DataStream ComplianceAsCode

Il progetto ComplianceAsCode (pacchetto scap-security-guide) pubblica profili ANSSI BP-028 nei suoi DataStream. Questi possono essere importati come benchmark, ma Cyberwatch non ne applica i profili: tutte le regole del DataStream vengono importate, qualunque sia il profilo, e solo una parte dei loro controlli è supportata. ComplianceAsCode non propone inoltre alcun profilo ANSSI per Ubuntu.

Per valutare un sistema Linux rispetto alla guida, Cyberwatch consiglia i framework ANSSI_BP028.