Configuration sécurisée des chiffrements / MAC / Kex disponible en SSH
Dans la foulée de la question précédemment publiée ici, Taxonomie des chiffrements/MAC/Kex disponible en SSH? , j'ai besoin d'aide pour obtenir les objectifs de conception suivants:
- Désactivez tous les algorithmes HMAC 96 bits.
- Désactivez tous les algorithmes HMAC basés sur MD5.
- Désactivez les chiffrements en mode CBC et utilisez les chiffrements en mode CTR.
À cette fin, voici la liste par défaut des chiffrements pris en charge:
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour
Je cherchais à le changer en ceci:
Ciphers aes256-ctr,aes192-ctr,aes128-ctr,[email protected],[email protected],arcfour256
Ensuite, pour le HMAC, il prend en charge les éléments suivants:
[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-sha1-96,hmac-md5-96
Et je cherchais à le changer en ceci:
[email protected],[email protected],hmac-sha2-512,hmac-sha2-256,[email protected],hmac-sha1,[email protected],[email protected],[email protected],[email protected],hmac-ripemd160
Cela apportera-t-il le plus d'avantages en termes de sécurité tout en atténuant les faiblesses et les attaques connues contre les configurations SSH courantes? Notez que cette question ne concerne pas les jours 0 ou d'autres défauts liés dans le code SSH et concerne spécifiquement la meilleure disposition et configuration possibles des chiffres, des KexAlgorithms et des MAC. Si la commande est erronée, veuillez suggérer une meilleure méthode pour les organiser. Cela vaut également pour le fichier sshd_config et non pour les connexions client.
En ce moment, il n'y a pas de faiblesse connue avec le chiffrement MD5 ou CBC ou MAC 96 bits car ils sont utilisés dans SSH. Il n'y a donc, au sens strict, aucun avantage de sécurité à appliquer les modifications de configuration que vous proposez. On pourrait faire valoir que la suppression de la prise en charge de certains algorithmes pourrait entraîner des problèmes de sécurité car cela peut empêcher certains clients de se connecter, obligeant ainsi l'utilisateur à trouver des solutions de contournement qui pourraient être moins sécurisées (par exemple si scp n'est plus possible, envoyez le fichier par email ...).
Le moins irrationnel de vos objectifs de conception est l'interdiction de la CBC. La sécurité CBC nécessite une gestion appropriée des vecteurs d'initialisation; dans le cas de SSH, l'IV est extrait du dernier bloc du paquet précédent (voir la norme ), ce qui est bien tant que l'attaquant n'est pas dans une situation "d'attaque en texte clair choisie". En pratique, les données qui entrent dans le tunnel SSH ne sont pas hostiles, contrairement à ce qui se passe dans les contextes HTTPS où le code client malveillant (en Javascript) est une possibilité certaine. De même, le remplissage des attaques Oracle sur SSH est difficile à exploiter (en supposant que le code client ou serveur n'est pas correctement protégé), car SSH est orienté connexion et a gagné 't (ré) ouvre automatiquement la connexion a échoué (là encore, contrairement à ce qui se passe avec HTTPS).
De même, HMAC/MD5 est, à notre connaissance, aussi solide que jamais. Les attaques par collision connues sur MD5 n'ont aucune incidence sur la sécurité de HMAC, sauf dans les sens les plus flous (qui peuvent être résumés comme suit: "MD5 pue"). En ce qui concerne la troncature des valeurs HMAC à 96 bits, il n'y a encore aucune raison de discriminer contre cela: un attaquant réussira à contourner une valeur MAC de 96 bits avec la probabilité 2-96, ce qui est extrêmement faible et impossible à exploiter dans la pratique car any Une défaillance MAC sur une seule connexion SSH est signalée avec un message d'erreur assez visible. C'est encore la façon dont SSH est utilisé qui le protège contre le niveau d'automatisation des attaques qui peut être appliqué à HTTPS.
Par conséquent, on pourrait dire que l'élagage des algorithmes de la liste est au bénéfice de vos sentiments de sécurité, la bonne liste est celle qui vous fera vous sentir le plus en sécurité. C'est subjectif, par définition, donc vous êtes le seul à pouvoir définir cette "meilleure" liste. Quant à moi, je suis assez content des défauts.
Quant à order, considérez cet extrait de section 7.1 de la RFC 425 :
encryption_algorithms A name-list of acceptable symmetric encryption algorithms (also known as ciphers) in order of preference. The chosen encryption algorithm to each direction MUST be the first algorithm on the client's name-list that is also on the server's name-list.
Ainsi, l'algorithme choisi sera l'algorithme préféré du client . L'ordre de préférence du serveur n'est qu'un commentaire glorifié; cela n'affectera pas l'algorithme réellement choisi. Par conséquent, l'ordre dans /etc/sshd_config n'est pas important.
Tous ceux qui sont vraiment préoccupés par la sécurité de SSH voudront probablement lire cette page:
https://stribika.github.io/2015/01/04/secure-secure-Shell.html
Il passe par tous les échanges de clés, authentifications de serveur, chiffrements et MAC pris en charge par OpenSSH, puis jette tout ce qui ne peut plus vraiment être considéré comme sécurisé, fournissant une justification valable pour tout ce qu'il élimine. Avec cette configuration, vous êtes solide comme le roc!
TL; DR? Les gagnants pour la plus haute sécurité sont:
Échange de clés: curve25519-sha256
(se retirer: diffie-hellman-group-exchange-sha256)
Authentification du serveur: Ed25519 with SHA512
(se retirer: RSA with SHA1 4096 Bits)
Chiffre: chacha20-poly1305
(se retirer: aes256-ctr)
MAC: hmac-sha2-512-etm
(se retirer: hmac-sha2-512)
Le repli est ce que vous trouverez sur la plupart des serveurs SSH, pas tout à fait aussi sécurisé, mais toujours suffisamment sécurisé selon les normes d'aujourd'hui.
Un seul commentaire de mon côté: si vous utilisez également SSH pour copier des données (scp ou rsync) ou pour la redirection de port X11 ou VNC, les performances et la latence ne sont pas sans importance. Dans ce cas, aes128-ctr offrira les meilleures performances (parmi les chiffres connus pour être sécurisés à ce jour) et vous pouvez envisager d'utiliser [email protected], comme même MD5 a été cassé, HMAC-MD5 n'a pas jusqu'à aujourd'hui et MD5 bat SHA-1 en vitesse et SHA-2 même de loin. Pour avoir une idée des vitesses d'algorithme, consultez cette page:
https://www.cryptopp.com/benchmarks.html
À mon humble avis, c'est un compromis acceptable: échanger de la sécurité contre beaucoup plus de vitesse.
Qu'en est-il de chacha20-poly1305? Je n'ai pas non plus de repères pour chacha20-poly1305 jusqu'à présent, je ne peux pas non plus dire que c'est sûr. Il est censé remplacer RC4 (alias arcfour), il est donc probablement encore plus rapide que aes128-ctr dans les logiciels, mais les processeurs Intel modernes peuvent calculer AES128 dans le matériel, donc si votre implémentation SSH en fait usage, vous pouvez vous attendre à ce que AES128 soit très rapide. ChaCha est peut-être plus rapide mais c'est la sécurité qui n'a pas encore fait ses preuves qui m'inquiète un peu; trop peu d'attaques ont été essayées et même si elle existe depuis 2008, ce n'est que récemment que ChaCha est devenu populaire quand il a été révélé que le NSA peut rompre les connexions RC4 SSL/TLS en temps réel. ChaCha doit corriger cela et remplacer RC4 dans TLS mais ce n'est pas une preuve de sa sécurité.
Ne vous inquiétez jamais de l'échange de clés ou de l'authentification du serveur, leur vitesse ne joue un rôle qu'à la connexion initiale et chaque fois que la clé doit être renouvelée (quand cela se produit dépend du chiffrement choisi et de la quantité de données que vous transférez ... chaque chiffrement a une limite de données et une fois celle-ci atteinte, une nouvelle clé est échangée, car rester avec la clé existante affaiblirait le cryptage à partir de ce moment-là), mais les renouvellements ne se produisent pas si souvent, donc pour ces deux, je choisirais toujours la plus haute sécurité et ignorer complètement la vitesse.
Et n'utilisez jamais les hachages tronqués (-96) pour MD5 ou SHA-1. Ils ne vous procurent aucun avantage réel autre que d'économiser quelques octets par paquet (4 pour MD5, 8 pour SHA-1). Le hachage prendra également autant de temps à calculer/vérifier (aucun avantage de vitesse) et la troncature ne fait qu'affaiblir la sécurité (aucun avantage de sécurité). La troncature serait payante pour SHA-2 car ils sont beaucoup plus grands (32, 48, 64 octets par paquet) et de tels hachages n'ont aucun sens compte tenu de la taille maximale d'un paquet de transmission, mais pour ces troncatures, ce n'est pas une option.
Afin de supprimer les chiffres cbc, ajoutez ou modifiez la ligne "Ciphers" dans/etc/ssh/sshd_config comme ci-dessous: Ciphers aes128-ctr, aes192-ctr, aes256-ctr, arcfour256, arcfour128, arcfour
Afin de supprimer HMAC MD5 Ajoutez ou modifiez la ligne MAC dans/etc/ssh/sshd_config comme ci-dessous: MAC hmac-sha1, hmac-ripemd160
Redémarrez SSHD pour appliquer les modifications: redémarrage sshd du service