6/17/2011

OpenSSH: Furtivité et Hardening avec une authentification forte OTP (OATH - TOTP)



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 :
  1. dézip/tarez le
  2. configure
  3. make
  4. make install
  5. 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 :
  • Un serveur Radius. Il s’occupera de vérifier la validité des OTPs des utilisateurs en exécutant l’application de calcul des OTPs.
  • PAM. Il s’occupera de faire appel au serveur Radius lorsque le protocole SSH est utilisé.
  • La bibliothèque pam_radius_auth.so. Elle s’occupera de faire le lien entre PAM et le serveur Radius.
  • Une application qui calcule les OTPs côté serveur pour comparer l’OTP entré par l’utilisateur. Nous avons choisi une classe PHP, celle de M. André Liechti.










  • 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:

    chevalier3as a dit…

    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 !

    Anne Gosselin a dit…

    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.

    smaret a dit…

    Pour confirmer cela:

    OpenSSH 3.5p1 Remote Root Exploit For FreeBSD http://packetstormsecurity.org/files/102683 #exploit

    Dug a dit…

    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. :-)

    smaret a dit…

    Thanks Dug, I will have a look

    Sylvain