Configurazione di RHEL 8 per la conformità alle policy di crittografia correlate alla modalità Cipher Block Chaining

In questo articolo illustreremo un esempio di configurazione di una policy di crittografia di Red Hat Enterprise Linux (RHEL) 8 che rimuove la modalità Cipher Block Chaining (CBC). Iniziamo con qualche informazione di base su CBC e sulla policy di crittografia predefinita di RHEL 8.

A livello operativo, la maggior parte di noi ha sperimentato situazioni in cui il sistema presenta una configurazione complessa, con informazioni eccessive, insufficienti o in ogni caso poco comprensibili. 

Potresti, ad esempio, imbatterti in una dichiarazione simile a: "Il tuo server supporta cifrature CBC non consigliate e vulnerabili"; successivamente ti viene chiesto se hai la necessaria protezione da una nuova vulnerabilità, se puoi segnalare l'evento il prima possibile e applicare le necessarie correzioni ai sistemi della tua azienda eventualmente interessati. 

Quali strumenti utilizzerai? Quali controlli intendi effettuare? Il sistema è stato configurato correttamente? I server sono privi di vulnerabilità note?

Puoi rispondere a queste domande con le tecnologie disponibili in RHEL 8 per migliorare l'efficienza operativa, promuovere la sicurezza e comprendere meglio gli strumenti di crittografia. 

Analisi del problema

Facciamo un passo indietro e analizziamo il problema in questione con l'aiuto di questo articolo di Wikipedia, 

in cui si legge che la modalità CBC è una delle molte modalità di utilizzo di una cifratura a blocchi, quella che, nello specifico, esegue lo XOR tra il blocco di testo cifrato corrente e il blocco di testo precedente prima di crittografarlo. La CBC viene quindi definita "la modalità operativa più utilizzata" e "una delle due modalità di cifratura a blocchi consigliate da Niels Ferguson e Bruce Schneier". 

L'articolo fa risalire l'invenzione della modalità al 1976, il che potrebbe suggerire che questa sia obsoleta e insicura. Tuttavia, essere datati non significa automaticamente essere poco sicuri. Anche lo scambio di chiavi Diffie-Hellman risale al 1976, ma è ancora ampiamente utilizzato e non è considerato insicuro.

Tutte queste informazioni non aiutano a capire quale sia la situazione. È molto probabile che l'indagine sia partita dall'avviso di uno strumento di scansione delle vulnerabilità automatizzato che ha rilevato l'intenzione del server OpenSSH di utilizzare le modalità di crittografia CBC, citando come motivo la CVE-2008-5161. Il riferimento era forse a questo documento o ad altri, altrettanto criptici. La frase: "È quindi altamente improbabile che una sessione interattiva possa essere attaccata sfruttando questa vulnerabilità del protocollo: prima di riuscire, l'aggressore dovrebbe attendere 11.356 tentativi di interruzione della connessione" può sembrare tranquillizzante, ma lascia forse intendere che questo problema di sicurezza di un decennio fa non è ancora stato risolto in RHEL?

Red Hat lavora in modo proattivo per monitorare e mitigare le vulnerabilità presenti nei suoi prodotti. Di fatto, la pagina citata del NIST relativa alla CVE-2008-5161 mette in evidenza una dichiarazione in cui Red Hat afferma che il problema è stato risolto già in RHEL 5. Red Hat fornisce anche una soluzione alternativa per disabilitare la cifratura CBC dalla configurazione sshd.

L'articolo chiarisce inoltre che la correzione in questione prevedeva l'applicazione di patch upstream, riducendo ulteriormente la probabilità di riuscita dell'attacco. Uno strumento di scansione delle vulnerabilità non è tuttavia a conoscenza di queste informazioni perché si limita a verificare la presenza di versioni specifiche dei pacchetti, che confronta con le versioni interessate per poi segnalare il risultato. Questi strumenti non sono perfetti e non sono in grado di rilevare la presenza di correzioni. 

Se ci sono dubbi sulla sicurezza di un particolare algoritmo, non è meglio fare uno sforzo in più e disabilitarlo del tutto? Ogni modifica deve tuttavia essere valutata, perché può generare problemi di compatibilità. 

Le cifrature CBC possono essere l'unico linguaggio comune in termini di interoperabilità con client e server SSH meno recenti; compensare impostazioni predefinite più sicure con la compatibilità è responsabilità di chi realizza la distribuzione. 

Fedora 33, ad esempio, disabilita le cifrature CBC per l'utilizzo con SSH, come indica questa richiesta di unione upstream. In quanto distribuzione enterprise rilasciata un anno prima, RHEL 8 ha invece deciso di mantenerle abilitate per impostazione predefinita, sottolineando tanto la presenza delle correzioni quanto ragioni di compatibilità, come segnalato nel bugzilla: 1818103 – SSH Server CBC Mode Ciphers Enabled in RHCOS.

Che le impostazioni predefinite siano bilanciate è importante, ma sono anche pensate per essere modificate. Ogni utente ha una situazione unica e deve poter prendere le proprie decisioni come meglio crede. Per questo RHEL 8 ha adottato un nuovo meccanismo centralizzato per disabilitare/abilitare l'utilizzo degli algoritmi crittografici: le policy di crittografia. Esaminiamo ora come utilizzare le policy di crittografia per disabilitare le cifrature CBC.

Funzionalità e configurazione delle policy di crittografia in RHEL 8

L'analisi della policy predefinita in RHEL 8 ci aiuta a comprendere meglio la situazione:

sudo less /usr/share/crypto-policies/policies/DEFAULT.pol 
# A reasonable default for today's standards. It should provide 
# 112-bit security with the exception of SHA1 signatures needed for DNSSec 
# and other still prevalent legacy use of SHA1 signatures.

Sono disponibili altre policy da configurare in RHEL 8 per soddisfare requisiti di sicurezza aggiuntivi relativi alle policy di crittografia: 

• FIPS.pol: una policy che utilizza solo algoritmi FIPS approvati.

• FUTURE.pol: fornisce sicurezza a livello conservativo; si ritiene che sia in grado di contrastare qualsiasi attacco futuro nel breve termine. 

• LEGACY.pol: fornisce le impostazioni per garantire la massima compatibilità con i sistemi esistenti.

È inoltre possibile modificare queste policy creando policy secondarie o policy personalizzate ex novo. Un precedente articolo del blog di Red Hat presentava lo strumento update-crypto-policies, le sue funzionalità e le indicazioni di utilizzo.

Per RHEL 8 è disponibile altra documentazione relativa all'argomento: "Utilizzo di policy di crittografia a livello di sistema in Red Hat Enterprise Linux 8."

Come configurare la policy di crittografia di RHEL 8 per rimuovere la modalità CBC

Tornando al problema iniziale, l'auditor ha fornito ulteriori informazioni a supporto e lo strumento di valutazione della vulnerabilità ha segnalato il problema: "Vulnerability Name: SSH CBC Mode Ciphers Enabled, Description: CBC Mode Ciphers are enabled on the SSH Server."

Occorre fare una distinzione. Come emerge dai commenti online, molti utenti sono in grado di configurare il proprio sistema e di correggere il problema dopo aver effettuato la scansione delle vulnerabilità. In pratica, configurano il processo sshd in modo che non utilizzi le cifrature correlate a CBC, ovvero impediscono a sshd di utilizzarle. Sono anche presenti alcune istruzioni su come applicare questo tipo di soluzione. 

Questi metodi sono validi solo per il processo sshd e non per l'intero server; agiscono infatti a livello di processo anziché a livello di sistema. In altre parole, anche se si supera il controllo sulla modalità CBC SSH, alcune cifrature CBC restano nel server. È buona norma apportare la modifica a livello di sistema, ed è esattamente ciò che consente di fare lo strumento update-crypto-policies.

Innanzitutto, osserviamo la policy di crittografia attualmente in uso nel server RHEL 8:

update-crypto-policies --show 
DEFAULT

Poiché abbiamo stabilito che RHEL 8 utilizza la policy di crittografia DEFAULT, possiamo provare a individuare le cifrature correlate a CBC in /usr/share/crypto-policies/policies/DEFAULT.pol

tls_cipher = ... AES-256-CBC ...AES-128-CBC 
cipher = ... AES-256-CBC CAMELLIA-256-CBC AES-128-CBC CAMELLIA-128-CBC

(Per maggior chiarezza, le cifrature non correlate sono state rimosse.)

Nella policy DEFAULT sono presenti sei cifrature correlate a CBC.

Qui le cose diventano più complicate. Al momento della stesura di questo documento, non sono presenti file di policy che mostrano esempi di una configurazione aggiuntiva della policy di crittografia ssh_cipher. Tale policy è citata nella pagina man: man crypto-policies (... ssh_cipher: Optional; list of allowed symmetric encryption algorithms (including the modes) for use with the SSH protocol. If absent, the value is derived from cipher...). 

Ma ssh_cipher esiste e, sebbene non sia esplicitamente visibile nella policy DEFAULT, deve essere esplicitamente esclusa dalla policy secondaria se vogliamo rimuovere in modo efficace tutte le cifrature correlate a CBC.

Possiamo creare una policy secondaria che modifichi la policy DEFAULT in uso. A tale scopo, è necessario creare un file per la policy secondaria

 /etc/crypto-policies/policies/modules/DISABLE-CBC.pmod

Nota: la convenzione di denominazione è importante; è necessario utilizzare solo maiuscole per il nome della policy secondaria e solo minuscole per il nome dell'estensione (.pmod).

Il file deve contenere le modifiche da apportare alla policy DEFAULT.

Per rimuovere le cifrature CBC dal server modificando il profilo DEFAULT, occorre aggiungere quanto segue:

tls_cipher = -AES-256-CBC -AES-128-CBC 
cipher = -AES-128-CBC -AES-256-CBC -CAMELLIA-256-CBC -CAMELLIA-128-CBC 
ssh_cipher = -AES-128-CBC -AES-256-CBC

Per rimuovere l'algoritmo CBC dal server, solo per sshd:

ssh_cipher = -AES-128-CBC -AES-256-CBC

Nota: poiché non ci sono esempi per ssh_cipher, possiamo presumere che il valore sia:

ssh_cipher = -AES-128-CBC -AES-256-CBC -CAMELLIA-256-CBC -CAMELLIA-128-CBC

In realtà, non specifichiamo gli algoritmi -CAMELLIA, poiché non è chiaro se siano commercializzati o utilizzati da sshd, come dimostra l'esecuzione di man sshd_config | grep -i cbc

                   3des-cbc                    
                   aes128-cbc                    
                   aes192-cbc                    
                   aes256-cbc )

neanche 3des-cbc è commercializzato dal server RHEL 8.2, come dimostra l'esecuzione di ssh -vv e la ricerca in "Their offer": aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr, aes128-gcm@openssh.com,aes128-ctr).

Occorre impostare la policy secondaria con la relativa configurazione che rimuove le cifrature CBC:

sudo update-crypto-policies --set DEFAULT:DISABLE-CBC

Verifichiamo che l'impostazione sia corretta: 

sudo update-crypto-policies --show  
DEFAULT:DISABLE-CBC

Affinché la policy e la policy secondaria vengano attivate, è necessario riavviare il server.

A questo punto, non dovrebbero più essere presenti cifrature CBC utilizzabili dal server. Per verificarlo, eseguiamo un controllo tramite sshd, avviando il seguente comando da un server RHEL 8

ssh -vv -oCiphers=aes128-cbc,aes256-cbc 127.0.0.1 

Il comando dovrebbe restituire le informazioni di accesso e l'utente dovrebbe essere in grado di connettersi utilizzando credenziali valide.

Se la cifratura CBC non è disponibile per sshd, il risultato dovrebbe indicare

Unable to negotiate with 127.0.0.1 port 22: no matching cipher found. 

Il processo sshd mostra quindi le cifrature offerte da quel server, ad esempio:  "Their offer: aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes128-gcm@openssh. com,aes128-ctr"

Riepilogo

In questo articolo del blog abbiamo illustrato come configurare un server RHEL 8 affinché sia conforme a un determinato requisito delle policy di crittografia. Abbiamo mostrato come rimuovere le cifrature relative a CBC da un server, dopo aver verificato i problemi di sicurezza. Abbiamo utilizzato strumenti come update-crypto-policies per soddisfare alcuni requisiti di conformità della sicurezza in modo corretto, a livello del server e non dei singoli componenti.