N'utiliser que des algorithmes de chiffrement robustes
Restreint le serveur SSH aux seuls algorithmes de chiffrement symétrique robustes (Ciphers), AES en modes CTR et GCM ainsi que chacha20-poly1305@openssh.com, en excluant CBC et les autres algorithmes faibles.
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
Les recherches sur le protocole de transport SSH (RFC 4253) ont montré que le mode CBC (Cipher Block Chaining) présente des faiblesses permettant de récupérer jusqu'à 32 bits de texte clair à partir d'un bloc de chiffré. Les algorithmes en mode compteur (CTR) (RFC 4344) et les chiffrements AEAD modernes (GCM, ChaCha20-Poly1305) ne sont pas vulnérables à ces attaques et sont recommandés pour un usage standard. Laisser CBC ou arcfour activés expose la session à des attaques de récupération de texte clair et de déclassement contre le tunnel chiffré.
Ce que vérifie Pavois
Pavois exécute sshd -T et compare la ligne ciphers effective à la liste robuste. sshd -T indique le jeu d'algorithmes réellement résolu par le démon, après tous les Include, blocs Match et drop-ins de /etc/ssh/sshd_config.d/, de sorte qu'un algorithme CBC réactivé par un drop-in est détecté. N'analyser que /etc/ssh/sshd_config manquerait ces inclusions et donnerait un faux négatif.
describe command('sshd -T') do
its('stdout') { should match(/^ciphers\s+aes128\-ctr,aes192\-ctr,aes256\-ctr,chacha20\-poly1305@openssh\.com,aes256\-gcm@openssh\.com,aes128\-gcm@openssh\.com$/i) }
endComment vérifier qu’elle est appliquée
Exécutez sshd -T | grep -i '^ciphers'. Sortie attendue :
ciphers aes128-ctr,aes192-ctr,aes256-ctr,chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
Aucun algorithme -cbc ou arcfour ne doit être présent.
Inspecter et investiguer
Les événements de connexion et de négociation SSH se trouvent dans /var/log/auth.log (ou journalctl -u ssh). Un client ne proposant qu'un algorithme faible est rejeté avec no matching cipher found, ce qui fait apparaître les clients hérités dans ces journaux.
Remédiation
Le plan de durcissement de Pavois écrit la directive Ciphers (ressource sshd_setting) avec la liste d'algorithmes robustes dans la configuration drop-in SSH puis recharge sshd. Appliquez-le avec pavois harden apply. La nouvelle liste prend effet à la prochaine connexion ; les sessions en cours restent actives.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| directive | Ciphers |
|---|---|
| notify | action: reload, service: ssh.service |
| resource | sshd_setting |
| value | aes128-ctr,aes192-ctr,aes256-ctr,chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com |
| verify | sshd -t -f %{path} |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Désactiver les algorithmes CBC/arcfour peut casser d'anciens clients SSH, de vieux équipements réseau ou des hôtes rebond sans support CTR/GCM. Avant d'appliquer, vérifiez vos clients (tout OpenSSH récent négocie déjà ces algorithmes robustes) et gardez une seconde session ou console ouverte. Après application, ouvrez une nouvelle connexion SSH dans un autre terminal pour confirmer l'accès avant de fermer la session d'origine, cela évite tout verrouillage.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 5.1.6 | direct | per OS, see the benchmark table | 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.