
Ce billet vise à obscurcir les informations liées au protocole SSH ainsi que renforcer le "login" au serveur SSH par l’utilisation d’une authentification forte de type One Time Password. Ces informations ne se substituent pas à une procédure de hardening de l’OS et du service SSH (cf. Hardening OpenSSH Guide).
1. Cacher la version de SSH
Offusquer la version du protocole SSH utilisée force l’attaquant à effectuer des analyses plus poussées pour déterminer la version, élément important pour construire une attaque contre ce protocole.
Editer le fichier version.h du répertoire ssh :
#define SSH_VERSION "ce que vous voulez"
Ensuite, il est nécessaire de recompiler SSH pour que la modification soit prise en compte.
2. Offuscation Handshake
Le handshake entre le client et le serveur étant en clair, un attaquant observant le handshake peut en déduire la version du protocole SSH et ainsi l’attaquer. Le but de ce module est de chiffrer le handshake via un secret partagé.
Attention : ce mode est fortement déconseillé pour les réseaux devant être hautement performant et le tunneling.
Vous pouvez télécharger le module sur le site https://github.com/brl/obfuscated-openssh.
Suivez la procédure habituelle :
Editez le fichier sshd_config :
2. Offuscation Handshake
Le handshake entre le client et le serveur étant en clair, un attaquant observant le handshake peut en déduire la version du protocole SSH et ainsi l’attaquer. Le but de ce module est de chiffrer le handshake via un secret partagé.
Attention : ce mode est fortement déconseillé pour les réseaux devant être hautement performant et le tunneling.
Vous pouvez télécharger le module sur le site https://github.com/brl/obfuscated-openssh.
Suivez la procédure habituelle :
- dézip/tarez le
- configure
- make
- make install
- make clean
Editez le fichier sshd_config :
ObfuscatedPort 35003
ObfuscateKeyword ‘mon_password_pour_obfusquer’
Du côté client, il faudra alors ajouter l’option -z et -Z lors de la connexion :
ssh -z -Z mon_password_pour_obfusquer -p 35003 toto@monhost
3. Chiffrement / Hardening
Il est conseillé de ne pas utiliser le mode d’opération ECB. En effet, ce mode est à bannir en sécurité informatique car deux blocs de contenus identiques sont chiffrés de la même manière. De plus, il est souhaitable de ne garder que les chiffrements symétriques dits “sûrs” couplés avec une "grosse" taille de clé.
Editez le fichier sshd_config :
Ciphers aes256-cbc, aes256-ctr, blowfish-cbc
3. Authentification forte OTP / Time Based (TOTP)
La mise en place d’une authentification forte pour SSH requiert plusieurs éléments :
Figure 1 : Fonctionnement authentification OTP pour SSH
3.1 Création des utilisateurs côté serveur pour l’OTP
Il s’agit de créer des utilisateurs pour votre application personnelle de calcul de l’OTP à partir d’une graine partagée avec votre token. Elle contient le même algorithme de calcul de l’OTP que votre token. Il est plus simple d’utiliser les mêmes noms utilisateurs OTP et SSH. Pour notre classe, nous vous invitons à consulter l’annexe pour la création des utilisateurs.
3.2 Installation et configuration du serveur Radius
Freeradius est disponible dans les repositories habituels.
yum install Freeradius2 Freeradius2-utils
Modifier le secret_radius dans le fichier/etc/raddb/clients.conf
client ip{
secret = votre_secret_radius
shortname= server_name
nastype=other
}
Si vous utiliser le mode proxy, le secret_radius est à mettre dans le fichier /etc/raddb/proxy.conf
realm NULL{
type= radius
authhost=ip_server :port
secret= secret_radius
}
Modifier les droits sur les fichiers suivants :
chmod a-rwx,u+r /etc/raddb/proxy.conf
chmod a-rwx,u+r /etc/raddb/clients.conf
3.3 Configuration pour faire le lien avec l’application OTP
Freeradius va appeler notre application de la manière suivante :
vi /etc/raddb/users
DEFAULT Auth-Type := Accept
Exec-Program-Wait = "/usr/bin/php ${PATH}/multiotp.php %{User-Name} %{User-Password}",
Fall-Through = Yes,
Reply-Message = "Hello, %{User-Name}"
Nous pouvons tester la configuration avec la commande radtest :
cd /etc/raddb/
radiusd –X (debug mod)
radtest username pincode+tokencode ip_server_radius port radius_secret
Le signe + correspond à l’opérateur de concaténation.
3.4 Installation et construction de la librairie pam_radius_auth
Pam_radius_auth est une librairie dynamique, utilisée par pam, qui permet de faire appel au serveur radius pour la phase d’authentification d’un service donné, ici sshd.
yum install pam-devel
wget ftp://ftp.freeradius.org/pub/radius/pam_radius-1.3.17.tar.gz
tar –zxvf pam_radius-1.3.17.tar.gz
make
cp pam_radius_auth.so /lib/security
cp pam_radius_auth.conf /etc/raddb/server
vi /etc/raddb/server
ip_server secret_radius 3
3.5 Installation et configuration de pam
yum install pam
cd /etc/pam.d/
vi sshd
Ajouter en première ligne le chemin de la bibliothèque et désactiver la seconde ligne :
auth required /lib/security/pam_radius_auth.so
#auth include system-auth
Ainsi, lorsque le service sshd est appelé, pam authentifie l’utilisateur via le mode d’authentification spécifié, soit le serveur radius (appel au serveur radius réalisé par la librairie pam_radius_auth.so). Le serveur radius fait appel à notre application qui indique si l’otp entré par l’utilisateur est correcte.
Activer pam dans SSH :
vi /etc/ssh/sshd_conf
UsePAM yes
service /etc/init.d/sshd restart
Dès lors, vous pouvez vous authentifier fortement par OTP pour le protocole SSH.
Anne Gosselin (Msc Cryptograpie et Sécurité - MARET Consulting) , smaret
5 commentaires:
Merci pour ce billet très intéressant, j'ai cependant une question sur la détermination de la version du SSH et sur l'écoute du Handshake.
A ma connaissance, seule la version 1 du SSH est vulnérable et à moins d'utiliser des clés de chiffrement très faibles (asymétrique pour l'échange de clé et symétrique pour le chiffrement des flux), il est quasi-impossible d’arriver au bout de ce protocole.
Il est sûr que l'OTP apporte une couche de sécurité supplémentaire, mais je souhaiterais savoir qu'elles sont les attaques réelles possibles contre ce protocole.
Merci !
Le protocole SSH est, à ma connaissance, dit « sûr » algorithmiquement. Ses vulnérabilités proviennent entres autres de défauts d’implantations, de l’acceptation de choses obsolètes pour raison de compatibilité (tel que le protocole 1, de vieux algorithmes, …). Le hardening et l’utilisation de la version la plus récente permettent de restreindre au mieux la surface d’attaque. Toutefois, l’erreur (ou l’oubli) étant humaine ou encore l’apparition de vulnérabilités méconnues n’étant pas à exclure, la furtivité permet de cacher toute information susceptible de mettre un attaquant sur la voie d’une vulnérabilité potentielle du protocole mis en place.
Les attaques contre le protocole SSH sont multiples et il est difficile de dresser une liste représentative. Pour fixer les idées quant à ces attaques possibles contre openssh, par exemple, le site suivant fait un résumé de l’historique des vulnérabilités liées aux versions obsolètes : http://www.openssh.org/fr/security.html. Le chiffrement du handshake vise à éviter qu’un attaquant puisse facilement identifier une version obsolète du protocole utilisé, un chiffrement faible ou autre information qui permettrait d’utiliser une application automatisant l’attaque.
En espérant que cela réponde à vos interrogations.
Pour confirmer cela:
OpenSSH 3.5p1 Remote Root Exploit For FreeBSD http://packetstormsecurity.org/files/102683 #exploit
This is an old exploit in OPIE, the one-time password library on FreeBSD, not OpenSSH. See http://seclists.org/fulldisclosure/2011/Jul/0 and http://site.pi3.com.pl/adv/libopie-adv.txt
For a better two-factor implementation for OpenSSH (that works with pubkey auth as well - PAM does not), check out http://www.duosecurity.com
Full disclosure: I'm a co-founder of Duo Security - and an OpenSSH author. :-)
Thanks Dug, I will have a look
Sylvain
Enregistrer un commentaire