Introduction
Dans cet article, je vais aborder la robustesse d’OpenSSH version 10.X, de la méthode à mettre en place pour garantir une robustesse à toute épreuve.
C’est quoi OpenSSH ?
OpenSSH (Open Secure Shell) est une implémentation libre et open source du protocole SSH (Secure Shell) créé en 1995 par le Finlandais Tatu Ylönen .
Le protocole SSH-2 est le plus utilisé dans le monde de l’informatique car il répond à plusieurs besoins d’affaires tels que l’administration de systèmes, en DevOps Ect.
Utilisable sans aucune licence, Il est natif sur la quasi-totalité des distributions Linux.
Pourquoi la version 10.X est-elle une avancée majeure ?
En plus de corriger les bogues des versions antérieures, la version 10.X est désormais résistante à l’informatique quantique, car elle utilise par défaut l’algorithme hybride mlkem768x25519-sha256.
Quelle est la meilleure stratégie de défense ?
Pour assurer une robustesse à toute épreuve, il est indispensable de disposer d’une surface d’attaque réduite au minimum.
La stratégie de défense en profondeur est essentielle, et elle s’appuie sur ces quatre piliers :
Utilisation d’une autorité de certification SSH CA sur Yubikey avec des rôles à l’aide des Principals.
Activation d’algorithmes hybrides postquantique (PQ) avec désactivation des algorithmes légacy.
Contrôle d’accès (whitelist).
Surveillance en temps réel des journaux à l’aide de Fail2Ban.
Pourquoi je recommande cette stratégie ?
la menace “Harvest Now, Decrypt Later” est adressée via l’activation du ML-KEM (PQ).
Les attaques à la Terrapin sont adressées suite à la désactivation des algorithmes legacy et à la mise en place du mode “Strict KEX”.
Le serveur SSH ne connait qu’une seule entité, la CA, ce qui garantit qu’en cas d’un algorithme cassé, la Yubikey et la whitelist bloquent l’accès.
L’utilisation des principals empêche les mouvements latéraux grâce au rôle scellé dans le certificat.
Si un acteur malveillant tente une action malicieuse, Fail2Ban le bannit.
Mise en place de cette stratégie
Utilisation du protocole FIDO2, et des clés sk pour générée la clé privée à l’interieur de la YubiKey.
Configuration de la YubiKey pour qu’elle exige un code PIN pour chaque siganature de certificat + un toucher physique.
Utilisation d’une machine Air-Gapped comme station de signature.
Signer un certificat avec la YubiKey en utilisant le principe du “Short-lived certificates” et le fameux drapeau -V.
Copie de la clé publique du CA sur le serveur.
Modification du fichier de configuration du démon SSH sur le serveur avec l’ajout du chemin pour TrustedUserCAKeys, AuthorizedPrincipalsFile Etc.
Copie du certificat SSH sur le client.
Validation de la configuration
Avec quelques lignes de commande, il est possible de valider la configuration du serveur SSH.
#Validation des algorithmes
$ sudo sshd -T | grep -E "kex|ciphers|macs|hostkeyalgorithms"
[sudo] Mot de passe de toto :
ciphers [email protected],[email protected]
macs [email protected],[email protected]
kexalgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256
hostkeyalgorithms [email protected],ssh-ed25519,rsa-sha2-512,rsa-sha2-256
# Le scan de conformité (Audit de sécurité) avec l'outil ssh-audit
$ ssh-audit -p 4444 localhost
# general
(gen) banner: SSH-2.0-OpenSSH_10.2
(gen) software: OpenSSH 10.2
(gen) compatibility: OpenSSH 9.9+, Dropbear SSH 2020.79+
(gen) compression: enabled ([email protected])
# key exchange algorithms
(kex) mlkem768x25519-sha256 -- [info] available since OpenSSH 9.9
`- [info] hybrid key exchange based on post-quantum resistant algorithm and proven conventional X25519 algorithm
(kex) sntrup761x25519-sha512 -- [info] available since OpenSSH 9.9
`- [info] default key exchange since OpenSSH 9.9
`- [info] hybrid key exchange based on post-quantum resistant algorithm and proven conventional X25519 algorithm
(kex) curve25519-sha256 -- [info] available since OpenSSH 7.4, Dropbear SSH 2018.76
`- [info] default key exchange from OpenSSH 7.4 to 8.9
(kex) ext-info-s -- [info] available since OpenSSH 9.6
`- [info] pseudo-algorithm that denotes the peer supports RFC8308 extensions
(kex) [email protected] -- [info] pseudo-algorithm that denotes the peer supports a stricter key exchange method as a counter-measure to the Terrapin attack (CVE-2023-48795)
# host-key algorithms
(key) rsa-sha2-512 (3072-bit) -- [info] available since OpenSSH 7.2
(key) rsa-sha2-256 (3072-bit) -- [info] available since OpenSSH 7.2, Dropbear SSH 2020.79
(key) ssh-ed25519 -- [info] available since OpenSSH 6.5, Dropbear SSH 2020.79
# encryption algorithms (ciphers)
(enc) [email protected] -- [info] available since OpenSSH 6.5, Dropbear SSH 2020.79
`- [info] default cipher since OpenSSH 6.9
(enc) [email protected] -- [info] available since OpenSSH 6.2
# message authentication code algorithms
(mac) [email protected] -- [info] available since OpenSSH 6.2
(mac) [email protected] -- [info] available since OpenSSH 6.2
# fingerprints
(fin) ssh-ed25519: SHA256:x3rrvG1zAJNlG9zpkX47kEpKP6m55+BIqldvKrPlNJ0
(fin) ssh-rsa: SHA256:nTX3D094ewrf6banQXUuCX/UTq8IG47RU99eIYvt4ss
# additional info
(nfo) Be aware that, while this target properly supports the strict key exchange method (via the [email protected] marker) needed to protect against the Terrapin vulnerability (CVE-2023-48795), all peers must also support this feature as well, otherwise the vulnerability will still be present. The following algorithms would allow an unpatched peer to create vulnerable SSH channels with this target: [email protected]. If any CBC ciphers are in this list, you may remove them while leaving the *[email protected] MACs in place; these MACs are fine while paired with non-CBC cipher types.
👉 Le serveur SSH a été mise en production il y a moins de 48 heures !
# La vérification du "Filtre Actif" (Fail2Ban)
$ sudo fail2ban-client status sshd
[sudo] Mot de passe de toto :
Status for the jail: sshd
|- Filter
| |- Currently failed: 0
| |- Total failed: 455
| `- Journal matches: _SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
|- Currently banned: 25
|- Total banned: 36
`- Banned IP list: 180.76.247.183 216.45.50.28 176.120.22.13 91.202.233.33 176.120.22.47 94.72.116.78 47.251.243.187 47.252.35.152 180.76.248.242 8.215.41.147 23.82.99.105 47.250.48.27 62.169.28.111 125.122.156.134 43.103.24.145 185.197.250.178 47.85.49.48 87.121.84.78 167.99.72.161 154.58.233.195 182.43.19.187 8.220.192.64 128.199.225.7 47.253.5.130 47.250.122.222
# Vérification IP source à l'aide de l'outil geoiplookup
$ geoiplookup 180.76.247.183
GeoIP Country Edition: CN, China
$ geoiplookup 23.82.99.105
GeoIP Country Edition: US, United States
Conclusion
La stratégie repose sur une configuration “Zero Trust” avec un modèle basé sur une “Défense en profondeur”.
En l’absence d’une vulnérabilité de type “Zero Day” ou d’un processus défaillant, la probabilité de se faire compromettre est faible.
Commentaires et Discussion
Partagez et discutez
💬 Je suis Yannick Vollenberg , si vous souhaitez participer à la discussion sur les réseaux sociaux. C'est le meilleur moyen de me faire part de vos commentaires et de partager l'article.