N'utiliser que des chiffrements validés FIPS 140-2
Restreindre les Ciphers de sshd à l'ensemble validé FIPS, ordonné du plus fort au plus faible : aes256-ctr,aes256-gcm@openssh.com,aes128-ctr,aes128-gcm@openssh.com.
Vérifié sur l’état résolu en cours d’exécution (ex. sshd -T, sysctl, systemctl show), attrape les drop-ins et Include qu’une lecture de fichier raterait. Réserve : runtime ≠ persistance ; une valeur correcte maintenant peut ne pas survivre à un redémarrage.
Pavois vérifie la configuration effective, l’état résolu et réellement appliqué, pas un fichier. Les scanners basés fichier (OVAL/SCAP, Lynis) ratent les Include, drop-ins et défauts runtime ; ce check voit ce qui est réellement en vigueur.
Un mapping est une référence croisée vers l’endroit où chaque norme situe cette exigence, ancrée et recoupée, pas une affirmation d’équivalence. Un check réussi est une preuve vers ces références, comment le lire.
Pourquoi cette règle
Seuls des chiffrements symétriques validés FIPS 140-2 peuvent protéger la session SSH. Des chiffrements non approuvés ou faibles ne garantissent ni la confidentialité ni l'intégrité, si bien que le trafic qu'ils protègent peut être lisible ou falsifiable. La liste est ordonnée du plus fort au plus faible (aes256-ctr, aes256-gcm@openssh.com, aes128-ctr, aes128-gcm@openssh.com) car sshd négocie le premier chiffrement serveur que le client propose aussi, cet ordre garantit le choix de l'algorithme le plus robuste pris en charge des deux côtés.
Ce que vérifie Pavois
Pavois vérifie que la sortie effective de sshd -T liste exactement ciphers aes256-ctr,aes256-gcm@openssh.com,aes128-ctr,aes128-gcm@openssh.com, dans cet ordre. Interroger le démon en cours d'exécution reflète la valeur après fusion de tous les Include, des drop-ins de /etc/ssh/sshd_config.d/ et de toute politique cryptographique système, lire le seul sshd_config peut manquer un drop-in ou une politique réintroduisant un chiffrement faible.
describe command('sshd -T') do
its('stdout') { should match(/^ciphers\s+aes256\-ctr,aes256\-gcm@openssh\.com,aes128\-ctr,aes128\-gcm@openssh\.com$/i) }
endComment vérifier qu’elle est appliquée
Exécuter sshd -T | grep -i '^ciphers'. Sortie attendue :
ciphers aes256-ctr,aes256-gcm@openssh.com,aes128-ctr,aes128-gcm@openssh.com
Inspecter et investiguer
Le chiffrement négocié par session est journalisé au niveau VERBOSE dans /var/log/auth.log (Debian/Ubuntu) ou via journalctl -u ssh. Les clients ne proposant que des chiffrements non approuvés sont refusés avec no matching cipher found, également visible dans ces journaux.
Remédiation
Pas de remédiation automatique pour cette règle, à appliquer manuellement selon la norme.
Impact & précautions
Restreindre la liste des chiffrements peut exclure d'anciens clients dépourvus de ces algorithmes (bibliothèques SSH héritées, équipements embarqués, vieux rebonds). Avant d'appliquer, recensez les clients qui se connectent à cet hôte et vérifiez qu'ils prennent en charge AES-CTR/AES-GCM ; validez avec sshd -t et gardez une seconde session ouverte. Notez qu'une politique cryptographique système (p. ex. update-crypto-policies) peut aussi contraindre ou supplanter la liste effective.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| DISA STIG | UBTU-22-255050 | direct | per OS STIG release | haute |
Chaque référence est une référence croisée ancrée dans le benchmark amont et recoupée avec le SCAP Security Guide et ansible-lockdown, pas une affirmation d’équivalence. Direct = une exigence prescriptive au niveau de la ligne ; support = une famille de contrôle abstraite (NIST) vers laquelle le check apporte une preuve. Comment lire un mapping.