Re: Trou de securite Debian pour SSH/SSL

Page principale

Répondre à ce message
Auteur: Olivier Allard-Jacquin
Date:  
À: guilde
CC: guilde
Sujet: Re: Trou de securite Debian pour SSH/SSL
    Bonsoir,

Patrice Karatchentzeff a écrit :
> Le 20 mai 2008 23:42, Olivier Allard-Jacquin <olivieraj@???> a écrit :
>>        Salut Patrice,

>>
>>        je passe en discussion privée, je pense que l'enfilade doit commencer à
>> lasser sur la ML

>
> Tu as une drôle de façon de répondre en privé :)


    Oups, boulette...


>
> [...]
>
> Juste pour rire... le reste en privé.
>
>> OK, puisque tu le prends comme cela, je vais te parler de mes choix :
>> - toi, tu installes des serveurs SSH sur les postes que tu administres,
>> et tu te loggues dessus avec un mot de passe. N'est-ce pas ?
>> - 2 problèmes : Tu dois ouvrir un trou dans le firewall, voir dans le
>> routeur ADSL, et tu laisses un port (disons le 22) ouvert. Ce sont donc
>> 2 failles de sécurité potentielles.
>
> bof... premièrement, rien ne t'oblige à faire cela. Tu peux très
> ouvrir un autre port pour le daemon ssh (ce qui t'enlève 100% des
> attaques brutes)


    Sécurité par l'obscurification (*) ? C'est amusant, c'est ce que font
les softs closed-source, que tu apprécies si peu.


(*): Anglicisme barbare, j'en conviens:
http://www.allwords.com/word-obscurification.html

> et ensuite n'ouvrir ce port qu'à la demande de
> l'utilisateur en place...


    Sans oublier non plus de configurer le port forwading sur son routeur,
chose qui peut s'avérer pas forcément très simple. Personnellement, une
de mes utilisatrice est une "nomade", qui se connecte à Internet en
utilisant toutes sortes de connexions différentes. Quand je dois prendre
la main sur sa machine afin d'y assurer du support, je n'ai pas
l'occasion de lui faire modifier les réglages des FW derrière lesquels
elle se trouve.


> J'ai l'avantage de ta solution sans les inconvénients (i.e. les
> pass-phrases, qui sont de mon point de vue, une aberration en terme de
> sécurité, du fait de l'automatisation automatique de l'autorisation
> sans intervention humaine. L'humain n'est pas fiable mais c'est le
> seul qui sache prendre des décisions intelligentes).
>
> Tu peux retourner le problème dans tous les sens, mais mettre des
> pass-phrases (pour fabriquer des connexions admin) est un trou de
> sécurité à lui tout seul.


    Il y a un problème de terme, car nous ne parlons pas du tout de la même
chose : Les pass-phrase dont je parles, ce sont les mots de passe qui
sont utilisées afin de déverrouiller la clef privée, qui est utilisée
lors de l'authentification SSH. Raison pour laquelle je dis :


<extrait>
- l'usage de la clé (nda: "privée") peut-être restreint à l'utilisateur
en lui-même, si celui-ci l'a générée avec une "passphrase"
</extrait>

    Pour faire simple, lors d'une authentification SSH, l'utilisateur qui
se connecte doit utiliser sa clef privée. Or, celle-ci peut être placée
dans une "boîte", dont le verrou est cette fameuse "pass-pharse", qui
est uniquement connue par l'utilisateur.


    Dans le cas où un intrus prendrait la main sur le compte d'un admin
(avec tout son ~/.ssh/*), il ne pourrait pas s'authentifier sur les
machines que l'admin administre avec sa clef, car celle-ci lui
demanderai la "pass-phrase".


    Exemple chez moi :
olivier@phoenix:~/.ssh$ ll
total 8
drwx------  2 olivier olivier 4096 mai 21 18:27 .
drwx--x--x 97 olivier olivier 4096 mai 21 00:35 ..
/* J'ai supprimé toutes les clefs */


olivier@phoenix:~/.ssh$ ssh-keygen -t rsa -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/olivier/.ssh/id_rsa):
Enter passphrase (empty for no passphrase): ****
Enter same passphrase again: ****
Your identification has been saved in /home/olivier/.ssh/id_rsa.
Your public key has been saved in /home/olivier/.ssh/id_rsa.pub.
The key fingerprint is:
36:b2:fe:4f:10:65:ae:91:7f:09:cf:25:50:a7:00:74 olivier@phoenix
/* Une clé RSA est générée avec un mot de passe ("****") */

olivier@phoenix:~/.ssh$ cat id_rsa.pub > authorized_keys
/* J'autorise la connexion à mon compte en utilisant cette clé. Coté
serveur SSH, SEUL l'authentification par échange de clés est acceptée
("PasswordAuthentication no" dans le /etc/ssh/sshd_config) */

olivier@phoenix:~/.ssh$ ssh olivier@localhost
The authenticity of host 'localhost (127.0.0.1)' can't be established.
RSA key fingerprint is 7d:f7:60:7a:ae:2f:16:7b:78:9d:fc:48:36:e5:48:80.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'localhost' (RSA) to the list of known hosts.
Enter passphrase for key '/home/olivier/.ssh/id_rsa':**
/* Mot de passe non valid, je ne peux pas déverrouiller la clé privée */
Enter passphrase for key '/home/olivier/.ssh/id_rsa':****
Linux phoenix 2.6.22 #1 SMP Wed Feb 13 22:27:08 CET 2008 i686
/* La connexion fonctionne */

    Si je ne donne pas la pass-phrase, voila ce que l'on obtient :


olivier@phoenix:~/.ssh$ ssh olivier@localhost
Enter passphrase for key '/home/olivier/.ssh/id_rsa': *
Permission denied (publickey).
/* La connexion est refusée */

> À partir de là, le problème issu de Debian
> montre la limite en plus de ce genre de choix,


    A priori, tu as une méconnaissance du mécanisme de "pass-phrase" de
SSH., ce qui te fait arriver à de mauvaises conclusions.


> le mien restant plus sûr par ailleurs...


    Comme indiqué ici, le mécanisme de pass-phrase force l'utilisation d'un
mot de passe pour la connexion à un hôte
- On a donc *au moins* le même niveau de sécurité que le mot de passe
"classique" du /etc/shadow.
- En plus de cela, il y a les 4 autres arguments de sécurité indiqué
dans le mail précédemment.
- Et enfin, un argument dernier plus "philosophique" (ou "geek", c'est
selon) : Avec une authentification par clé+pass-phrase, la pass-phrase
ne sortira pas de la mémoire de l'ordinateur. Ce qui n'est pas le cas de
l'authentification par mot de passe, où celui-ci fini par passer,
encodé, dans la connexion réseau.


    Conclusion : L'authentification par clé SSH offre plus de mécanises de
sécurité que l'authentification par mot de passe. Charge à
l'administrateur de configurer cela correctement.


    Cordialement,


                            Olivier
-- 
~~~~~~~  _____/\_____  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phoenix /   _ \/ _   \    Olivier Allard-Jacquin
       /   / \  / \   \   Web:  http://olivieraj.free.fr/
      /___/  /  \  \___\  Mail: olivieraj@???
~~~~ /////  ///\\\  \\\\\ ~~~~~~~~~~~~~~~~~~~~~~~ Linux Powered !!