Solution transparente pour la constitution de réseaux privés virtuels (RPV)
INEO.VPN
Le protocole SSH (Secure Shell)
Tous droits réservés à INEOVATION. INEOVATION est une marque protégée
PLAN
Introduction
Bénéfice de SSH
L’architecture de SSH v2 SSH v1 vs SSH v2
La couche transport SSH (SSH-TRANS) La couche d’authentification (SSH-AUTH) La couche de connexion SSH (SSH-CONN) La couche de connexion SSH (SSH-CONN)
La phase d’initialisation de SSH v2
Les méthodes d’authentification avec SSH Les fonctionnalités de SSH
Les limites du protocole SSH
L’avenir de l’exploitation du protocole SSH
Introduction (1/2)
SSH Secure Shell est développé pour remplacer l’accès non-sécurisé des r-commandes de Unix
Les r-commandes (rlogin, rcp, rsh)
Les mots de passe à « usage unique »
19/04/2008 22:54
Les mots de passe à « usage unique » Telnet avec chiffrement
Début du travaille en 1995 développé par Tatu
Ylönen, chercheur dans le laboratoire informatique
de l’Université de Helsinki
Introduction (2/2)
Fait en 2 version , la version 2 est une réécriture complète de SSHv1( v1.3 et v1.5), c’est la version 2 qui a été accepter comme draft a l’IETF.
Actuellement V2 est en cours de normalisation à l’IETF par le groupe SECSH
(http://www.ietf.org/html.charters/secsh-charter.html)
SSH est un protocole couche transport qui travaille
au dessus de TCP est qui utilise la port 22
Bénéfice de SSH
Connexion à distance ( remplacement sécurisé de rlogin, rsh, rcp et telnet)
Évité la circulation du mot de passe en clair sur le réseau Authentification des machines et des clients
Redirection des sessions X11
19/04/2008 22:54
Redirection des sessions X11
Redirection de tous flux TCP dans le « tunnel » de la session Chiffrement ou même compression de cette session
Utilisations des infrastructure de certification (SPKI, X509,..) Implémentation très simple.
L’architecture de SSH v2
Le groupe de travail à l’IETF qui s’occupe de Secure Shell (SECSH WG), dirigé par Bill Sommerfeld, est alors lancé.
En 1997, ce groupe a fourni le premier draft IETF pour le protocole SSH v2. En 2006, il a réussi à normaliser le protocole SSH sous forme de trois « couches » :
1. SSH Transport Layer Protocol (SSH-TRANS) [RFC 4253] ; 1. SSH Transport Layer Protocol (SSH-TRANS) [RFC 4253] ; 2. SSH Authentication Protocol (SSH-AUTH) [RFC 4252] ; 3. SSH Connection Protocol (SSH-CONN) [RFC 4254].
L’architecture de SSHv2
Couche Description
Transport
Authentification du serveur, négociation des algorithmes, mise en place d’une clef de session, intégrité et confidentialité des
Les sous protocole de SSH v2
Transport place d’une clef de session, intégrité et confidentialité des données, compression, identification de session
Authentification Authentification du client (clef publique, mot de passe, clef d’hôte), changement du mot de passe
Connexion
Transfert de port TCP et transfert X, Transfert d’agent d’authentification
Gestion des sessions interactives, Exécution de programmes distants
Contrôle de flux, Gestion des terminaux (modes et tailles des fenêtres)
Compression des données
www.ineovation.fr
C’est quoi la différence entre SSH v1 et SSH v2 ?
SSHv1 SSHv2
Un seul protocole monolithique Séparation des protocoles de transport, d’authentification et de connexion
Un seul canal de données par session SSH
Nombre indéterminé de canaux de données par session SSH
Vérification faible de l’intégrité Vérification cryptographique forte de l’intégrité
- Possibilité de modifier le mot de passe
Mêmes algorithmes et clefs utilisés dans
les deux sens de la communication Les algorithmes de chiffrement, de calcul de contrôle cryptographique et de compression sont négociés séparément pour chaque sens de communication, avec des clefs indépendantes
Encodage fixé interdisant tout ajout de
nouveaux choix d’algorithmes Schéma de noms des algorithmes/protocoles extensible, permettant d’intégrer de nouveaux choix d’algorithmes nouveaux choix d’algorithmes permettant d’intégrer de nouveaux choix d’algorithmes
tout en préservant l’interopérabilité Confidentialité de la clé de session
transmise sur le réseau par la clef du serveur
Mise en place d’une clé de session basée sur Diffie- Hellman uniquement et donc inutilité de la clef du serveur SSH
- Reconnaissance des certificats de clefs publiques
Méthodes d’authentification des utilisateurs :
- Clef publique (RSA), RHostsRSA,
- Mot de passe
- Rhosts (à l’image de rsh dans Unix) - Kerberos (à base de tickets)
Méthodes d’authentification des utilisateurs :
- Clef publique (RSA, DSA, OpenPGP) associée à une machine,
- Mot de passe
- Clef d’Hôte (clef asymétrique permettant d’identifier les hôtes exécutant SSH, ou les instances du serveur SSH de la machine elle même)
Une seule forme d’authentification par
session Plusieurs méthodes d’authentification sont configurables pour un même utilisateur pour un même accès et le choix est fait lors de la phase d’initialisation (cf. section 2.2) L’authentification RhostsRSA est liée à
l’adresse de l’hôte client, ce qui limite son utilité
En principe, l’authentification basée sur l’hôte est indépendante de l’adresse réseau du client et peut ainsi fonctionner avec des mandataires, des clients mobiles, etc.
- Renouvellement périodique des clefs de session
•La couche transport SSH (SSH-TRANS)
C’est sur cette couche que reposent les deux autres couches SSH.
SSH-TRANS fournit l'authentification du serveur, la confidentialité et l'intégrité des données au moyen d'un chiffrement symétrique.
Elle fournit en option la compression des données de session en utilisant le mécanisme zlib (LZ77) défini dans les IETF RFC 1950 et 1951.
19/04/2008 22:54
1951.
Une fois que la couche transport a créé un tunnel sécurisé pour envoyer les informations entre les deux systèmes, le serveur indique au client les
différentes méthodes d'authentification prises en charge pour
l’authentification comme l'utilisation d'une clef asymétrique, ou l'entrée d'un mot de passe.
Packet length Padding length Payload
Random padding MAC
La couche d’authentification (SSH-AUTH)
Après l’échange des méthodes d’authentification supportées à travers la couche SSH-TRANS, la couche d’authentification (SSH-AUTH) permet de certifier l'identité du client auprès du serveur.
En effet, étant donné que les serveurs peuvent être configurés de façon à permettre différents types d'authentification, cette couche donne aux deux parties un niveau de contrôle optimal. Le serveur peut décider quelles
parties un niveau de contrôle optimal. Le serveur peut décider quelles méthodes d'authentification prendre en charge en fonction de son modèle de sécurité et le client peut choisir la méthode d'authentification à utiliser parmi celles qui sont disponibles.
Les messages échangés par cette couche sont sécurisés par la clef de chiffrement créée dans la couche SSH-TRANS. Après l'authentification du client auprès du serveur, de nombreux services peuvent être utilisés de façon sécurisée, tels qu'une session Shell interactive, des applications X11 et des ports TCP/IP tunnellisés
La couche de connexion SSH (SSH-CONN)
Cette couche s'appuie sur la couche d'authentification. Elle offre une variété de services riche aux clients en se servant de l’unique tunnel fourni par SSH-TRANS.
Ces services comprennent tout ce qu’il faut pour gérer plusieurs sessions interactives : exécution de programmes à distance (shell, applications commandes systèmes, etc.), multiplexage de plusieurs applications commandes systèmes, etc.), multiplexage de plusieurs flux (ou canaux), gestion des transferts X11, de port et d’agent.
Le transfert de port TCP permet d’encapsuler des protocoles applicatifs non sécurisés dans SSH de manière à apporter aux applications des services de chiffrement et d’intégrité de manière transparente.
www.ineovation.fr
La phase d’initialisation de SSH v2
La phase d’initialisation du protocole SSH v2
t (SSH-TRAN)Couche tansportCouche authentification (SSH-AUTH) Cette phase peut se répéter n fois jusqu’à que l’authentification réussi
Les méthodes d’authentification avec SSH
Trois méthodes d’authentification existent dans la version 2 normalisée à l’IETF :
Password
• Il s’agit de l’authentification « traditionnelle », où lors de la connexion et après avoir décliné son identité, l’utilisateur tape son mot de passe qui sera
19/04/2008 22:54
après avoir décliné son identité, l’utilisateur tape son mot de passe qui sera transmis de façon protégé au serveur.
• Ce dernier récupère le mot de passe, calcule son empreinte (condensât) et compare le résultat avec l’empreinte du mot de passe associé à l’utilisateur et stocké dans sa base de données.
• Notons que les mots de passe stockés sous Unix sont chiffrés à l’aide de l’algorithme DES (via la fonction crypt()). D’autres systèmes utilisent des fonctions de hachage telles que MD5 ou SHA-1.
Les méthodes d’authentification avec SSH
Trois méthodes d’authentification existent dans la version 2 normalisée à l’IETF :
Publickey
• L’authentification à l’aide d’une clef publique est basée sur la
• L’authentification à l’aide d’une clef publique est basée sur la cryptographique asymétrique des clefs RSA ou DSA où
aucun secret ne circule sur le réseau. En effet, la clef
publique de l’utilisateur doit tout d’abord être stockée sur le serveur SSH et sa clef privée doit être stockée sur sa
machine de façon sécurisée.
• Ce système possède un niveau de sécurité plus élevé que le précédent. Cependant, sa sécurité repose quasi
exclusivement sur un système de confiance « hors ligne ».
Les méthodes d’authentification avec SSH
Trois méthodes d’authentification existent dans la version 2 normalisée à l’IETF :
hostbased
• Il s’agit d’une authentification similaire à celle utilisée par les
19/04/2008 22:54
• Il s’agit d’une authentification similaire à celle utilisée par les rcommandes et les fichiers tels que /etc/rhosts et ~/.rhosts, qui « certifient » les sites clients en ayant préalablement enregistré leur adresse dans le serveur.
• Avec cette méthode d’authentification, quand le client
demande une connexion à un serveur SSH, ce dernier va chercher dans le fichiers rhosts un nom d’hôte qui
correspond à l’adresse source de la connexion réseau du client.
Les méthodes d’authentification avec SSH
L’authentification avec des certificats X.509
La seule méthode pour remédier aux problèmes des clés asymétriques est
l’utilisation des certificats X.509 basée sur une infrastructure de gestion de clefs (ou PKI). Un certificat X.509, fourni par une autorité de confiance (AC), permet à la fois d’authentifier un individu, un serveur, une entreprise, ou toute autre entité et d’associer l’identité de cette entité avec sa clef publique.
et d’associer l’identité de cette entité avec sa clef publique.
Un certificat X.509 fournit principalement à son émetteur deux services de sécurité : l’authentification forte et la non répudiation des transactions ou des données.
Dans le protocole SSH, même si l’authentification par certificat X.509 des deux entités communicantes n’est pas encore normalisée au niveau de l’IETF
[SSHX509], il existe des implémentations qui permettent l’utilisation de ces certificats pour l’authentification dans deux entités SSH.
Les fonctionnalités de SSH
L’accès à distance par le shell SSH
Le shell SSH (la commande SSH) est une version
sécurisée de rsh (et rlogin). SSH veut dire « Secure Shell
» à l’image de rsh qui veut dire « Remote Shell ».
Quand rsh permet d’obtenir un shell distant aisément,
Quand rsh permet d’obtenir un shell distant aisément,
mais sans mécanisme d’authentification satisfaisant (du point de vue de la sécurité), SSH procure le même service de façon sécurisée.
Ainsi, pour utiliser SSH, il suffit d’utiliser la commande ssh à la place des commandes telnet, rsh et rlogin. Donc, à la place d’utiliser la commande : % rlogin serveur, il suffit d’utiliser maintenant %ssh serveur.
www.ineovation.fr
Les fonctionnalités de SSH
Le transfert de fichiers par SFTP
SFTP (Secure File Transfer Protocol) est un sous
protocole séparé qui se situe au-dessus du protocole SSH. Il est utilisé dans le transfert sécurisé des fichiers.
SFTP a plusieurs avantages par rapport au protocole non SFTP a plusieurs avantages par rapport au protocole non sécurisé FTP.
• D'abord, SFTP chiffre le couple username/password ainsi que les données transférées en se basant sur les
algorithmes cryptographiques négociés dans la phase d’initialisation du protocole SSH.
• En second lieu, il utilise le même port que le protocole SSH, ce qui élimine la nécessité d'ouvrir un autre port sur les pare- feux. Ainsi, l’utilisation de SFTP résout également les
problèmes connus dans le protocole FTP avec la translation
des adresses NAT. www.ineovation.fr
Les fonctionnalités de SSH
Le tunneling
En plus de fournir l'équivalent des commandes rcp, rlogin et rsh de manière chiffrée avec une authentification bien plus sécurisée, les protocoles SSH permettent la mise en œuvre du tunneling de manière relativement simple.
Lorsque vous ouvrez une session sur un hôte ssh, vous pouvez également
ouvrir un canal de communication sécurisé pour tous les autres protocoles. Il est ouvrir un canal de communication sécurisé pour tous les autres protocoles. Il est indéniable que la plupart des protocoles envoient les informations en clair sur le réseau.
L'astuce ici est de se servir du canal ouvert par ssh pour encapsuler les informations en clair et les faire transiter d'une machine à l'autre.
www.ineovation.fr
Les fonctionnalités de SSH
La redirection de ports (Port forwarding)
SSH permet de rediriger n’importe quel flux TCP dans le « tunnel » de la session SSH. Cela veut dire que le flux de n’importe quelle application circulant entre les ports client et serveur habituels, pourra être « encapsulé » à l’intérieur du « serveur habituels, pourra être « encapsulé » à l’intérieur du « tunnel » créé par la session SSH.
Cette fonctionnalité permet d’établir, entre deux points, un canal sécurisé par lequel peut transiter n’importe quel type de donnée IP
Les fonctionnalités de SSH
La redirection de l’authentification (Agent Forwarding)
L'agent SSH est un mécanisme d’authentification auprès de multiples serveurs SSH qui reconnaissent la clef privée d’un client sans devoir retaper à chaque fois sur sa machine sa client sans devoir retaper à chaque fois sur sa machine sa passphrase .
Un agent SSH est un programme, qui s’appelle ssh-agent, qui garde les clefs privées en mémoire et qui fournit les services d’authentification aux clients SSH.
Cette méthode permet à un utilisateur d’introduire sa
passphrase lors de la première connexion à un serveur SSH.
L’ouverture d’une session sécurisée avec un nouveau serveur SSH se fait de manière transparente pour l’utilisateur.
www.ineovation.fr
SSH vs les autres solutions VPN
SSH IPSec SSL
Normalisation 2006 à l’IETF 1998 à l’IETF IETF
Principale utilisation Interconnections entre des utilisateurs nomades et le site de leur entreprise via Internet
Interconnections des sites d’entreprise via l’Internet Interconnections entre des utilisateurs nomades et le site de leur entreprise via une session Web
Niveau OSI Sécurisation des applications au dessus de
TCP Sécurité transparente pour les applications au
dessus d’IP Sécurisation des applications au dessus
de TCP Service de sécurité - Confidentialité
- Intégrité - Authentification
non rejeu des paquets (grâce aux cookies, et aux numéros aléatoires utilisés dans la phase d’initialisation du protocole (SSH-CONN), les
- Confidentialité - Intégrité - Authentification
non rejeu des paquets (grâce aux cookies, et aux numéros aléatoires utilisés dans la phase d’initialisation du protocole (IKE), les données
- Confidentialité - Intégrité - Authentification
non rejeu des paquets (grâce aux numéros aléatoires utilisés dans la phase handshake du protocole, les données d’initialisation du protocole (SSH-CONN), les
données envoyées ne peuvent pas être rejouées après un certain temps)
- Protection d’identité
- Autorisation, (c.a.d, contrôle d’accès aux comptes), tunnel sécurisé, ‘port forwarding’, service de SSO (Single Sign On)
d’initialisation du protocole (IKE), les données envoyées ne peuvent pas être rejouées après un certain temps)
- Protection d’identité
handshake du protocole, les données envoyées ne peuvent pas être rejouées après un certain temps)
Gestion des clefs Gestion des clefs à travers un échange Diffie-
Hellman Dépend du protocole externe IKE (basé sur DH ou
sur un chiffrement asymétrique)
SSL utilise une méthode de chiffrement asymétrique (RSA ou DSA) ou des clefs DH pour la création d’un secret partagé Méthodes d’authentification
définies dans les normes
Username/mot de passe, clef asymétrique Clef partagée, clef asymétrique, certificat X.509 Clef partagée (rfc 4279), certificat X.509
Mécanisme de filtrage Impossible après l’ouverture d’un tunnel SSH Par paquet (niveau réseau), lié aux politiques de sécurité définies par les administrateurs pour IPSec
Impossible après l’ouverture d’une session SSL
Contrôle d’accès Comme pour SSL, plus adapté pour l’accès sur demande des utilisateurs.
Sécurise tout le trafic entre le client et le serveur SSH. Contrôle d’accès au niveau serveur SSH basé sur un fichier de configuration statique
Solution idéale pour les environnements Unix.
Problème de gestion des clefs chez les utilisateurs et un manque d’interface complète
Plus adapté pour l'accès à un ensemble défini des utilisateurs.
Accès total pour les clients VPN à un segment d’un réseau.
Solution idéale pour la sécurisation au niveau réseau. Problème de complexité
Plus adapté pour l'accès sur demande des utilisateurs.
Sécurise tout le trafic du navigateur au serveur principal. Accès " oui non " au niveau d'application basé sur une liste d’accès statiques (ACL).
Solution limitée aux applications qui supportent une interface Web ou qui intègrent SSL/TLS
Les limites du protocole SSH
La première authentification non sécurisée du client avec le serveur SSH
Puisque SSH n’utilise pas de tiers de confiance pour distribuer les clefs publiques, la première fois qu’un client SSH se
connecte à une nouvelle machine distante, il effectue un travail connecte à une nouvelle machine distante, il effectue un travail supplémentaire en vérifiant lui-même la clef publique du
serveur, soit en comparant le hachage, soit en contactant l’administrateur du serveur distant.
Une fausse acceptation de la clef publique envoyée par le
serveur SSH peut laisser une personne malveillante détourner le trafic SSH en envoyant une fausse clef lors de la première connexion au serveur SSH.
www.ineovation.fr
Les limites du protocole SSH
Les attaques sur le mot de passe
En encapsulant les données applicatives dans des paquets SSH, ce dernier ajoute du bourrage à
chaque paquet (bourrage de taille fixe pour SSHv1, bourrage de taille variable en fonction des méthodes bourrage de taille variable en fonction des méthodes de chiffrement par blocs pour SSH v2) ;
SSH chiffre les données et les envoie en clair dans le champ plaintextlength. Ainsi, un attaquant passif,
espionnant le trafic SSH, est capable de détecter la
taille des données envoyées sur le réseau et ainsi de
mener à bien des attaques par analyse de trafic.
Les limites du protocole SSH
L’authentification non sûre par « hôte de confiance »
Par définition, l’authentification par hôte de confiance renvoie aux méthodes d’authentification Rhosts, RhostsRSA de SSH-1 et hôte de SSH-2 [Dbar02].
et hôte de SSH-2 [Dbar02].
Plutôt que de demander au client de prouver son identité à tous les hôtes qu’il visite, l’authentification par hôte de confiance
établit des relations de confiance entre les machines.
Même si l’authentification par hôte de confiance est pratique pour les utilisateurs et les administrateurs (car elle permet de mettre en place une authentification automatique entre des
hôtes), cette technique dépend lourdement d’une administration correcte et de la sécurité des hôtes concernés.
www.ineovation.fr
L’avenir de l’exploitation du protocole SSH
Même si SSH a pu contourner de nombreuses menaces à la sécurité liées au réseau, il reste rattaché, dans sa spécification, à une conception
logicielle plus qu’à un vrai protocole de sécurité. Même si SSH, dans sa version 2, est devenu plus modulaire et extensible, nous pouvons
remarquer que les fonctionnalités de chaque sous-protocole dépendent fortement des autres sous-protocoles.
Jusqu’à présent, la meilleure utilisation du protocole SSH était dans le cadre de la sécurisation des connexions à distance vers les serveurs
d’applications ou les machines réseaux telles que les routeurs et les points d’accès. Cependant, la plupart de ces équipements réseaux proposent actuellement un mécanisme d’accès simple basé sur une interface Web non sécurisée basée sur le protocole SSL/TLS.
La nouvelle version du protocole SSL/TLS (TLS-PSK) pourra sans doute un nouveau concurrent au protocole SSH
Nous contacter
Pour plus d'informations, consultez le site
www.ineovation.fr
