N'utiliser que des MAC validés FIPS 140-2
Restreindre les MACs de sshd à l'ensemble SHA-2 validé FIPS, ordonné du plus fort au plus faible : hmac-sha2-512,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha2-256-etm@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
Le code d'authentification de message (MAC) de SSH protège l'intégrité de chaque paquet ; un MAC faible permet à un attaquant d'altérer le trafic ou de rejouer des paquets sans être détecté. Seules des fonctions de hachage approuvées FIPS sont acceptables, ce qui pour SSHv2 désigne la famille SHA-2, les MAC basés sur MD5 et SHA-1 ne doivent pas être proposés. La liste est ordonnée du plus fort au plus faible (hmac-sha2-512, hmac-sha2-512-etm@openssh.com, hmac-sha2-256, hmac-sha2-256-etm@openssh.com) afin de négocier le MAC le plus robuste commun ; les variantes -etm (encrypt-then-MAC) sont préférées pour leur construction plus solide.
Ce que vérifie Pavois
Pavois vérifie que la sortie effective de sshd -T liste exactement macs hmac-sha2-512,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha2-256-etm@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, un scan de fichiers peut manquer un drop-in ou une politique réintroduisant un MAC faible (SHA-1/MD5).
describe command('sshd -T') do
its('stdout') { should match(/^macs\s+hmac\-sha2\-512,hmac\-sha2\-512\-etm@openssh\.com,hmac\-sha2\-256,hmac\-sha2\-256\-etm@openssh\.com$/i) }
endComment vérifier qu’elle est appliquée
Exécuter sshd -T | grep -i '^macs'. Sortie attendue :
macs hmac-sha2-512,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha2-256-etm@openssh.com
Inspecter et investiguer
La négociation du MAC est journalisée au niveau VERBOSE dans /var/log/auth.log (Debian/Ubuntu) ou via journalctl -u ssh. Un client ne proposant que des MAC non approuvés est refusé avec Unable to negotiate ... no matching MAC found, visible dans les mêmes journaux.
Remédiation
Pas de remédiation automatique pour cette règle, à appliquer manuellement selon la norme.
Impact & précautions
Restreindre les MAC peut exclure des clients ne proposant que des MAC basés sur SHA-1 ou umac (bibliothèques SSH anciennes, équipements embarqués). Recensez les clients atteignant cet hôte et vérifiez la prise en charge de SHA-2 avant d'appliquer, validez avec sshd -t, gardez une seconde session ouverte, et notez qu'une politique cryptographique système peut encore contraindre la liste effective.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| DISA STIG | UBTU-22-255055 | 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.