Mon réseau

Mon réseau d’entreprise

12.4 Les connexions sécurisées

Précédent   Suivant

(image)Il ne faut pas confondre chiffré et sécurisé. JE me protège si JE chiffre mes communications, car JE dispose du secret. Par contre, si quelqu’un d’autre que moi chiffre, alors non seulement je ne suis pas sécurisé, mais il se peut que je courre un risque.

Prenons un exemple qui date de quelques années. Il y avait un logiciel qui permettait de faire de la téléphonie sur Internet avec de la vidéo. L’exécutable était chiffré, et donc difficilement décodable. Toutes les communications étaient chiffrées. Ce logiciel privatif pouvait lire le contenu du disque local. Il communiquait en permanence avec le site de l’éditeur et d’autres sites. Si l’éditeur n’était pas malveillant, il serait possible de croire que c’était pour le bien de l’utilisateur. Au delà de cette hypothèse, ce logiciel était vulnérable et donc des indélicats pouvaient utiliser ce logiciel pour communiquer secrètement. L’administrateur ne pouvait pas distinguer le flux légitime (sous l’hypothèse que l’éditeur n’était pas malveillant) d’un flux vraiment illégitime.

(image) L’équipe de sécurité devrait pouvoir vérifier que tous les flux qui transitent par son réseau sont légitimes.

Les connexions sécurisées à distance peuvent être établies par l’équipe système qui installe un serveur (couche réseau : IpSec ou couche application : openvpn). Elles peuvent être aussi établies à la demande avec un serveur ssh.

12.4.1 Le secure shell : ssh

Le logiciel ssh permet d’ouvrir un shell à distance. Cette connexion est considérée sécurisée.

(image)Les outils de sécurité ne sécurisent que si les hypothèses de leur mise en place sont respectées. Ce n’est pas la peine d’avoir une serrure de haute sécurité si vous laissez la clef dans la serrure.

Une connexion par ssh se fait entre deux ordinateurs. Peut importe le système d’exploitation. Il faut que le serveur ssh (paquet openssh-server) soit disponible sur un ordinateur, nommons le satanas et que le client (paquet openssh-client) soit disponible sur un autre, nommons le diabolo.

Il n’est pas nécessaire de disposer du même login sur les deux ordinateurs. L’utilisateur arno de l’ordinateur diabolo veut se connecter sur l’ordinateur satanas avec le compte stud. 

arno@diabolo:~$ ssh stud@satanas
The authenticity of host 'satanas (10.33.104.2)' can't be established.
ECDSA key fingerprint is
           SHA256:UyrfR//olfFATo21MOj0wrf44NQpuzYnXIUQ9DJ8sOY.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'satanas,10.33.104.2' (ECDSA)
                             to the list of known hosts.
stud@satanas's password:
Linux satanas 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1



The programs included with the Debian GNU/Linux system are free
software; the exact distribution terms for each program are described
in the individual files in /usr/share/doc/*/copyright.



Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
stud@satanas:~$ exit
d�connexion
Connection to satanas closed.
arno@diabolo:~$ ssh stud@satanas
stud@satanas's password:
Linux satanas 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1

...

permitted by applicable law.
Last login: Fri Sep 21 18:59:53 2018 from 10.33.104.3
stud@satanas:~$

Lors de la première connexion, arno@diabolo ne connaît pas satanas. La connexion ne peut donc pas aboutir. Le logiciel montre l’empreinte digitale le satanas. Si elle a été obtenue par un moyen sécurisé, alors l’utilisateur peut accepter la connexion.

(image) Si vous apprenez à répondre oui sans vérifier, alors ssh n’est pas sécurisé.

Ensuite ssh demande un mot de passe. Si celui-ci est entré sans erreur, alors la connexion est établie.

Lors de la seconde connexion, ssh reconnait la machine sur laquelle une connexion précédente s’était établie. Il ne redemande pas la vérification.

Nous avons vu que ssh permettait de vérifier l’identité de la machine de destination. Cependant, il arrive que la machine de destination soit réinstallée. L’empreinte de l’ordinateur a alors changé. Si l’administrateur est sérieux, alors il aura prévenu que la clef a changé.

(image) Les ordinateurs en Osaka sont installés quatre fois par jour. Lors de la séance suivante, les empreintes auront changé.

Si l’empreinte a changée et que vous en êtes sûr, il faut oublier la clef précédente.

(image)Les utilisateurs prennent vite l’habitude de ne plus faire confiance à l’adminstrateur si celui ne les prévient pas. Changer les clefs sans vérifications casse la sécurité de ssh. 

$ ssh rock
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!      @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:gmERGkOEgyo950SyyOYu4VIx7ll4TNKgvkqAKQP3wtY.
Please contact your system administrator.
Add correct host key in /home/arno/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/arno/.ssh/known_hosts:166
  remove with:
  ssh-keygen -f "/home/arno/.ssh/known_hosts" -R "rock"
ECDSA host key for rock has changed and you have requested strict checking.
Host key verification failed.

Le logiciel ssh est gentil il fournit la commande pour oublier la clef précédente. 

 ssh-keygen -f "/home/arno/.ssh/known_hosts" -R "rock"

Si vous utilisez un nom pour le serveur et pas une adresse ip, alors il faudra aussi oublier l’adresse ip.

12.4.2 La connexion sans mot de passe

Il est possible de se connecter sans mot de passe. Il faut alors utiliser un couple de clefs asymétriques.

Sur la machine source, il faut que l’utilsateur créé un couples de clefs : 

stud@william:~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/stud/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/stud/.ssh/id_rsa.
Your public key has been saved in /home/stud/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:e1Pk2+NGTmooc8cuU29cgFW7A/AUP6KWHqcleuSUs5M stud@william
The key's randomart image is:
+---[RSA 2048]----+
|           . o...|
|            + o .|
|            .* + |
|           o= + o|
|        S @oo + |
|         .B.@oo o|
|        ..oE.Bo. |
|        o.*.*.*. |
|         + *.o. |
+----[SHA256]-----+

Dans un premier temps, il est plus facile de ne pas utiliser de phrase de passe. La commande a créé deux fichiers : la clef privée et la clef publique (suffixe pub). 

stud@william:~$ ls .ssh/
id_rsa id_rsa.pub

Il faut alors transférer la clef publique et l’ajouter dans le fichier des clefs autorisées : .ssh/authorized_keys

Les connexions s’établieront alors sans devoir entrer le mot de passe.

12.4.3 Les copies à distance

Pour copier un fichier d’un ordinateur à l’autre, il faut avoir l’autorisation de chaque ordinateur (pouvoir lire sur la source et écrire sur la destination) et utiliser un protocole. L’outil openssh permet de réaliser cela. Certains des clients et tous des serveurs ssh ne le permettent pas.

Le paquet openssh-client fournit la commande scp qui permet de copier un fichier à distance. Il faut donc avoir un login sur l’ordinateur de départ et un sur l’ordinateur d’arrivée. Les logins n’ont pas besoin d’être les mêmes.

Il existe deux formes principales : envoyer un fichier à distance, ou récupérer un fichier distant.

(image) Dans le cas d’un environnement où le mot de passe est simple, comme en Osaka, il est facile pour un étudiant facétieux de se connecter sur la machine d’un collègue pour faire des blagues de potaches. C’est rigolo. Mais c’est mal ! C’est une violation des règles de l’université, passible de conseil de discipline.

(image) Un administrateur peut relativement facilement déterminer qui à fait la mauvaise action. Big Brother am watching you !

(image) Si il le faut, je peux rendre les connexions plus difficile en retirant l’accès aux ordinateurs.

Le manuel scp fournit une explication claire de la commande scp. 

SCP(1)              BSD General Commands Manual                  SCP(1)

NAME
       scp — secure copy (remote file copy program)

SYNOPSIS

 scp [-12346BCpqrv] [-c cipher] [-F ssh_config] [-i identity_file]
     [-l limit] [-o ssh_option] [-P port] [-S program]
     [[user@]host1:]file1 ... [[user@]host2:]file2
...

La commande prend beaucoup d’options, mais ce n’est pas la peine de les utiliser pour commencer.

Ce qui est remarquable c’est que la forme générale est : 

scp source destination

Il faut copier un fichier source vers une destination. Chacun des deux peut être local ou distant. Si les deux sont distants, cela se complique un petit peu. Si les deux fichiers sont locaux, alors la commande cp suffit.

Chacun des deux fichiers peut être désigné de la façon suivante : 

 [[user@]host:]file

Dans ce contexte, les crochets indique quelque chose de facultatif. Ce qui ne l’est pas, c’est le nom du fichier. Pour la destination, il est possible d’utiliser un nom de répertoire : “.” représente le répertoire d’accueil, /tmp représente un répertoire pour les fichiers temporaires.

Il est possible de rajouter un nom d’hôte. Il faut alors utiliser le caractère deux-points “ :” !

Enfin, il est possible d’utiliser un login différent, il faut alors utiliser le caractère “”.

Pour copier un fichier local vers une destination, voici quelques exemples : 

scp foo.qcow2 murdoch@thorin:
scp /usr/local/src/debian*.iso a1232364556@MACHINEDOSI.XX.fr:/tmp
12.4.4 Les transferts de port

Le client et le serveur openssh permettent de créer des tunnels. Cela peut être utilisé pour permettre une connexion graphique à distance avec le serveur X-Window. Cette utilisation est assez facile, il suffit d’ajouter -X à la commande ssh. Dans la figure fig :ssh-X, nous montrons un étudiant présent sur la machine joe qui se connecte sur thorin et lance une application graphique depuis thorin, affichée sur joe.

(image)

Fig. 12.2 : Transport de la connexion X-Window à travers ssh.

Pour les transferts de ports, il est possible de :

  • • ouvrir un port sur la machine locale (local) ;

  • • ouvrir un port sur la machine distante (remote) ;

  • • connecter ce port à un port de la machine (locale ou distante) ;

  • • connecter ce port à un port d’un ordinateur inaccessible autrement.

  • • ssh -R 2233:localhost:22 simon@DST sleep 3593

  • • le port 2233 local sur la machine DST est alors relié au port 22 (ssh) de la machine SRC. Il est ainsi possible depuis la machine DST de se connecter sur la machine SRC par la commande :

  • • ssh localhost -p 2233

  • • Le sleep final maintient la connexion ouverte pendant 3593 secondes. Pendant ce temps, la connexion en retour reste ouvert.

  • • L’option -g ouvre le tunnel aux autres hôtes ;

  • • L’option -f rend la main, le processus passant en arrière plan ;

  • • L’option -L, analogue au -R permet d’ouvrir des ports locaux sur la machite distante (Remote).

12.4.5 Le fichier de configuration

La ligne de commande est certes pratique, mais elle devient fastidieuse. GNU-Linux nos permet de nous libérer rapidement des tâches répétitives. Nous allons donc configurer ssh de manière permanente.

Le fichier de configuration est situé dans le répertoire ~/.ssh qui contient aussi les autres fichiers de ssh. Il s’appelle config et peut être créé par nano. 


host NOMDEMACHINEDOSICOURT
     hostname NOMDEMACHINEDOSI.FQDN
     user LOGINUNIVERSITAIRE
     port XXXX
     localForward 2222 139.124.38.1:22



host thorin
      hostname localhost
     user LOGINTHORIN
      port 2222
     localForward 8888 localhost:80

Précédent   Suivant