GuiGui's Show

Résumé : « ssh-rsa », l'algorithme de signature et de vérification de la clé publique de type RSA d'un serveur SSH, est déprécié à cause des récentes attaques pratiques contre SHA-1, l'algorithme d'intégrité utilisé en interne. Il sera désactivé dans une version future d'OpenSSH. Il est temps de le désactiver au profit de rsa-sha2-* qui utilisent SHA-256 ou SHA-512 : HostKeyAlgorithms -ssh-rsa dans sshd_config. Attention : ça casse les vieux bouzins qui se connectent au serveur genre un OpenWRT Backfire.

Pour valider mes nouvelles configurations TLS renforcées, j'ai utilisé le testeur TLS/SSH Cryptcheck. Quand j'ai testé mes serveurs SSH, tout était OK… ou presque :

• Échange de clé de session EDH (diffie-hellman-group-exchange-sha256). Oui, je pourrais utiliser EECDH, mais je préfère EDH car je comprends le problème mathématiquee isoluble (en un temps fini) sous-jacent et que la seule alternative crédible est Curve25519, que je trouve trop déployée (on est en train de fabriquer une monoculture) ;
  
  
• Chiffrement + intégrité (aes256-gcm@openssh.com). Si tu ne peux pas utiliser GCM (chiffrement intègre), n'oublie pas de configurer un algorithme d'intégrité un peu chiadé donc de type Encrypt Then Pad Then Mac (etm) genre hmac-sha2-256-etm@openssh.com ou hmac-sha2-512-etm@openssh.com ;
  
  
• Absence de compression ;
  
  
• Clés : ssh-rsa est en orange.

Au début, je me dis qu'Aeris est dans le mouvement qui consiste à dire que les courbes elliptiques sont potentiellement plus robustes que RSA même si l'on en sait trop rien. Mais, dans ce cas, pourquoi existe-t-il aussi rsa-sha2-256 et rsa-sha2-512 ? RSA est un format de clé, non ?

J'ai trouvé la réponse chez tonton Bortzmeyer. Je cite : « (Petit point au passage, dans SSH, le format de la clé ne désigne que la clé elle-même, alors que l'algorithme désigne un format de clé et des procédures de signature et de vérification, qui impliquent un algorithme de condensation. Ainsi, ssh-keygen -t rsa va générer une clé RSA, indépendamment de l'algorithme qui sera utilisé lors d'une session SSH. Le registre IANA indique désormais séparement le format et l'algorithme.) ».

D'accord ! ssh-rsa = RSA + SHA-1. Or, la robustesse de SHA-1 a pris de sacrés coups ces dernières années (attaque de collisions pour moins de 50 000 $). C'est pour ça qu'Aeris a choisi de le marquer au fer rouge. Fin mai 2020, dans les notes de la version 8.3, le projett OpenSSH a annoncé que ssh-rsa sera désactivé dans une future version.

Cette vérification concerne la clé avec laquelle le serveur se présente afin que le client l'authentifie, pas les clés des utilisateurs du serveur. Dans mon cas, il s'agit d'une clé de type RSA 4096 bits.

Je pourrais configurer mon serveur SSH pour utiliser une clé de type ed25519, mais, comme je l'ai déjà écrit, je trouve que les algorithmes de l'équipe de chercheurs autour de djb sont trop utilisées partout sans discernement, ce qui peut créer un dangereux monopole de fait / une dangereux monoculture. Une clé ECDSA avec des paramètres normalisés au NIST, organisme état-unien peu transparent, ne me tente pas plus.

Il me reste une possibilité : désactiver ssh-rsa et utiliser les algorithmes de signature et de vérifications RSA dépourvus de SHA-1 que sont rsa-sha2-256 et rsa-sha2-512.

Pour ce faire, j'ajoute ceci dans mon fichier /etc/ssh/sshd_config : HostKeyAlgorithms rsa-sha2-512. Attention : si ton serveur SSH peut se présenter avec d'autres formats de clés (ed25519, ecdsa, etc.), active les algorithmes correspondants en les concatenant avec une virgule. Tu peux aussi désactiver uniquement ssh-rsa : HostKeyAlgorithms -ssh-rsa (note le « - »).

Attention : si tu as de vieux bouzins qui doivent se connecter à ton serveur SSH (genre un OpenWRT Backfire), ils ne doivent sûrement pas prendre en charge rsa-sha2-*. ;)

Au final, la configuration de mon serveur SSH est :

# Le serveur se présente avec une clé de type RSA
HostKey /etc/ssh/ssh_host_rsa_key
# Pour vérifier la clé du serveur, le client doit utiliser tel algo
HostKeyAlgorithms rsa-sha2-512
# Échange de clé EDH
KexAlgorithms diffie-hellman-group-exchange-sha256
# Chiffrement symétrique AEAD
Ciphers aes256-gcm@openssh.com
# Intégrité encrypt-then-pad-then-mac. 
# Inutile : on utilise GCM, donc pas besoin d'un autre algo d'intégrité que celui intégré.
MACs hmac-sha2-512-etm@openssh.com
# On désactive la compression, même si le client la réclame (ssh -C)
Compression no

La même, mais qui permet la connexion d'un OpenWRT Backfire :

# Le serveur se présente avec une clé de type RSA
HostKey /etc/ssh/ssh_host_rsa_key
# Pour vérifier la clé du serveur, le client doit utiliser tels algos (ssh-rsa pour OpenWRT…)
HostKeyAlgorithms rsa-sha2-512,ssh-rsa
# Échange de clé EDH (diffie-hellman-group14-sha1 pour OpenWRT)
KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
# Chiffrement symétrique (aes256-ctr pour OpenWRT)
Ciphers aes256-gcm@openssh.com,aes256-ctr
# Intégrité (hmac-sha1 pour OpenWRT, hmac-sha2-512-etm@openssh.com au cas où on utiliserait aes256-ctr)
MACs hmac-sha2-512-etm@openssh.com,hmac-sha1
# On désactive la compression, même si le client la réclame (ssh -C)
Compression no

Résumé : epmd, l'un des bidules erlang dont dépend le serveur XMPP ejabberd, écoute le monde entier sur le port tcp/4369 en utilisant le mécanisme d'activation par socket de systemd (à la inetd / xinetd). Pour le faire écouter uniquement en local, il faut modifier la configuration de la socket systemd epmd.socket, changer la configuration de ejabberdctl a aucun effet.

Sur un de mes serveurs, je regarde tous les ports ouverts / en écoute avec ss -ltupn (je rappelle que netstat est déprécié depuis de nombreuses années, ss utilise les """"nouvelles"""" fonctions du noyau et est capable d'afficher plus d'informations ‒ tous les processus qui utilisent une socket, les options de la socket genre ipv6only, les timers dans un format lisible, l'algo de contrôle de la congestion, la pmtu, la mss, etc. ‒) et je vois ceci :

tcp    LISTEN    0    128    0.0.0.0:4369    0.0.0.0:*     users:(("systemd",pid=1,fd=47)) ino:11367904 sk:166 <->

Pourquoi systemd écoute-t-il sur le port tcp/4369 ? Une recherche sur le web montre qu'il s'agit en fait d'epmd, un démon Erlang qui utilise le mécanisme d'activation par socket de systemd (à la inetd / xinetd). Pourquoi epmd n'apparaît pas dans la liste des utilisateurs de la socket (ss fait ça d'habitude, contrairement à netstat ;) ) ? Car, à ce moment-là, j'avais arrêté (systemctl stop) ejabberd, donc epmd n'était plus en activité.

Le seul bidule Erlang que j'utilise est ejabberd. Lisons la doc' : « epmd (Erlang Port Mapper Daemon) is a small name server included in Erlang/OTP and used by Erlang programs when establishing distributed Erlang communications. ejabberd needs epmd to use ejabberdctl and also when clustering ejabberd nodes. This small program is automatically started by Erlang, and is never stopped. »

J'ai un seul serveur derrière mon service Jabber et j'ose espérer qu'on peut piloter son serveur avec un ejabberdctl exécuté localement. Pas besoin d'être ouvert à tous les vents.

Lisons encore la doc' : « You should block the port 4369 in the firewall in such a way that only the programs in your machine can access it, or configure the option ERL_EPMD_ADDRESS in the file ejabberdctl.cfg. ». Non, ça ne fonctionne pas.

Lisons encore : « It is also possible to configure in ejabberdctl.cfg the network interface where the Erlang node will listen and accept connections. The Erlang command-line parameter used internally is, for example: erl ... -kernel inet_dist_use_interface "{127,0,0,1}" ». Non, changer la valeur de la variable « INET_DIST_INTERFACE » ne fonctionne pas non plus.

Au final, j'ai suivi ce tuto (mais pour obtenir le résultat inverse) et j'ai fait la modification côté systemd :

• systemctl edit epmd.socket ;
  
  

• Contenu :

  [Socket]
  ListenStream=127.0.0.1:4369

  
  

• systemctl daemon-reload ;
  
  
• systemctl restart epmd.socket ejabberd ;

J'étais persuadé que ce changement est intervenu avec Buster, mais, non, j'observe ce comportement dans une machine virtuelle Jessie… Ça doit dater du passage à systemd. Vache, toutes ces années sans rien voir. :O