Rapport de TP de sécurité des systèmes et des réseaux TP 5 - Sécurité réseau : SSH par : Gaël CUENOT M1-RIA - Groupe 2 21 décembre 2006
Exercice 5.1 Première connexion. Question 5.1.1 La clé publique du serveur SSH est stockée dans le chier known_hosts crée automatiquement dans le répertoire.ssh du home de l'utilisateur qui a eectué une connexion SSH. ~/.ssh/known_hosts Lorsqu'on répond 'yes', on associe l'emprunte DSA reçue, au serveur sur lequel on essaye de se connecter. Cela implique qu'on considère que le serveur est le bon, bien qu'il soit impossible d'en être vraiment sûr. En espionnant les connexions, il serait possible d'intercepter la clé publique, lors du premier échange. Avec cette clé, il serait alors possible par la suite de décrypter les packages capturés lors d'échanges entre le client et le serveur SSH. Question 5.1.2 Filtre tcpdump qui capture les paquets SSH uniquement entre mon client et mon serveur. tcpdump -i eth1 \ '(src host 130.79.59.137 && dst host 130.79.59.152 && dst port 22) \ (src host 130.79.59.152 && src host 130.79.59.137) && tcp' \ -XX -w q5.1.2.cap La seule partie de l'échange qui n'est pas crypté est la première connexion, lors de l'échange de clé. Exercice 5.2 Paire de clés et ssh-agent. Question 5.2.1 Les 2 chiers générés par ssh-keygen sont id_dsa et id_dsa.pub. -rw------- 1 cuenot cuenot 736 2006-11-17 14:47 id_dsa -rw-r--r-- 1 cuenot cuenot 604 2006-11-17 14:47 id_dsa.pub 2
On constate logiquement, que la clé privée n'est accessible en lecture (et écriture) que par le propriétaire (owner) alors que la clé publique est accessible en écriture par le propriétaire (owner) mais en lecture par tout le monde. Tout cela est normal étant donné que le but de la clé publique est d'être échangé avec d'autres utilisateurs/machines pour s'authentier. La phrase secrète est utilisée pour valider la clé privée mais elle n'intervient pas lors de la connexion avec le serveur. Une fois la connexion établie avec le serveur, le client SSH recherche la présence de la clé publique : debug1: Connection established. debug1: identity file /home/cuenot/.ssh/identity type -1 debug1: identity file /home/cuenot/.ssh/id_rsa type -1 debug1: identity file /home/cuenot/.ssh/id_dsa type 2 Une fois la clé trouvée, le client et serveur SSH s'échangent des informations sur leur version pour se mettre d'accord sur la version de protocole à utiliser. debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3p2 Debian-5.1 debug1: match: OpenSSH_4.3p2 Debian-5.1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 Une fois mis d'accord sur la version de protocole à utiliser, le client s'assure que l'hote du serveur est "connu" et est le bon : debug1: Host '130.79.59.152' is known and matches the RSA host key. debug1: Found key in /home/cuenot/.ssh/known_hosts:1 debug1: ssh_rsa_verify: signature correct Enn, si toutes les étapes précdentes se sont bien passées, le client ore sa clé privée au serveur qui l'acceptera si tout est correct : debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Trying private key: /home/cuenot/.ssh/identity debug1: Trying private key: /home/cuenot/.ssh/id_rsa debug1: Offering public key: /home/cuenot/.ssh/id_dsa debug1: Server accepts key: pkalg ssh-dss blen 434... debug1: Authentication succeeded (publickey). debug1: channel 0: new [client-session] debug1: Entering interactive session. Question 5.2.1 SSH-agent crée une socket unix-domain, le nom de cette socket est stockée dans la variable d'environnement SSH_AUTH_SOCK La variable d'environnement SSH_AGENT_PID contient 3
l'identiant de processus (process ID) de l'agent. SSH-agent permet d'établir une connexion ssh sans avoir à tapper de mot de passe. C'est un processus qui tourne en tâche de fond et que le client SSH peut contacter à l'aide des informations décrites ci-dessus. Le problème de sécurité que pose ce procédé est qu'il sut de s'emparer du chier contenant la clé pour être capable d'accéder à tous les sites sur lesquels elle est reconnue. La seule façon de remédier à une fuite de ce type est de générer une nouvelle clé pour remplacer l'ancienne. Il pourrait arriver qu'une personne mal intentionnée parvienne, via une faille de sécurité ou un script web mal écrit, à exécuter du code lui permettant de lister le contenu du chier contenant la clé privée. Cette personne serait alors en mesure de l'utiliser pour se connecter à n'importe quel serveur SSH sur lequel la victime utilise cette clé. Exercice 5.3 SSH et X11. Question 5.3.1 Sans connexion SSH, la variable DISPLAY vaut :0.0. Après une connexion SSH mais sans redirection X11, la variable DISPLAY est vide et xauth list ne donne rien. Le chier d'autorité.xauthority est créé dans le répertoire home de l'utilisateur. Après une nouvelle connexion au serveur SSH mais cette fois avec redirection X11 (ssh -X ), la variable d'environnement DISPLAY vaut localhost:10.0. Cette fois, la commande xauth list ache : pc3c152/unix:10 MIT-MAGIC-COOKIE-1 9a81ab5751d15095ac9313c68a791c04 Le serveur SSH se comporte comme un serveur X11, les applications se connectent donc dessus et les événements X11 sont transmis à travers le tunnel SSH qui s'établit quand on se connecte avec l'option -X de SSH. De cette façon, l'achage est déporté vers le client SSH et toute la communication s'eectue via le tunnel SSH, de façon sécurisée. Exercice 5.4 SSH et la redirection de port. 4
Question 5.4.1 Exécution d'un serveur ssh qui écoute sur le port 80 (ipv4 forcé) : /usr/sbin/sshd -p 80-4 L'option du client SSH permettant de réaliser la redirection souhaitée est -L -L [bind_address:]port:host:hostport Les deux premiers arguments bind_address:port correspondent à l'adresse et au port local. Si l'adresse n'est pas spéciée, localhost est utilisé. Les deux arguments suivants (host:hostport) correspondent à l'adresse et au port de la machine distante. Schéma du principe utilisé dans cet exercice : Port 9999 Tunnel SSH Port 80 Port 143 Client SSH 130.79.59.136 Firewall Serveur SSH 130.79.59.137 Serveur IMAP mailhost.u-strasbg.fr Le serveur SSH est exécuté sur la machine qui a pour adresse IP 130.79.59.137 sur le port 80 /usr/sbin/sshd -p 80-4 Le client est exécuté sur la machine qui a pour adresse IP 130.79.59.136, son port d'écoute 9999. Les requètes sur ce port seront exécutées par le serveur SSH vers le port 143 de la machine mailhost.u-strasbg.fr ssh -p 80 -f -L 9999:mailhost.u-stasbg.fr:143 130.79.59.137 sleep 100 L'option -f permet de lancer le tunnel ssh en background et l'option sleep 100 permet au tunnel de s'arrêter après 100 secondes d'inactivité. Exercice 5.5 SSH et PPP. 5
Question 5.5.1 Cette commande crée une connexion SSH entre deux machines puis crée (via pppd) une liaison point-à-point à travers la connexion SSH entre les 2 machines. L'option pty permet d'indiquer la commande qui sera utilisée pour former la liaison point-àpoint, pour permettre aux deux points de communiquer. Composition globale d'une trame Ethernet de 1500 octets : Entête IP Entête TCP Entête SSH Entête PPP Données 20 20 environ 20 16 environ 1424 On constate dans le tableau ci-dessus que les entêtes IP, TCP, SSH et PPP ajoutent environ 75 octets à une trame Ethernet, soit une charge d'environ 5 6