Différences

Ci-dessous, les différences entre deux révisions de la page.

--- issue95:securite [2015/04/27 13:05] – andre_domenech
+++ issue95:securite [2015/04/28 14:56] (Version actuelle) – andre_domenech
@@ Ligne 7: / Ligne 7: @@
 In the early days, if you wanted to log on to a remote computer to do some work, you would probably use a program called Telnet to do this. Telnet would let you log in to a remote Unix machine if you had an account on it, and, once logged in, you could do anything your account was authorized to do. And if you had root access, it could be just about anything. I recall my first introduction to this in the 1990s when I was managing the website of my university. I was given a shell account on our Red Hat server that also housed the web site, and sternly warned not to do anything to screw it up. I would Telnet into the server from my desktop to do things like chmod the CGI scripts and similar things we needed to do with websites in those days. This worked reasonably well, but the problem with Telnet is that it was never designed to create a secure connection, and since this server had our Website, it was perforce exposed to the whole Internet. If you combine an unsecure connection with a man-in-the-middle attack, or with vulnerabilities in the Telnet program that allowed an attacker to get in, and even escalate their privileges, you can see why this became an issue.**
-Une des choses les plus intéressantes concernant l'Internet est que ce n'était pas conçu pour la sécurité et que c'est arrivé, pour ainsi dire, presque par accident. Les chercheurs du début, des gens comme JCR Licklider et Vint Cert, voulaient surtout faciliter la communication entre des chercheurs universitaires ; ils supposaient donc que quiconque avec qui ils avaient des contacts était un autre « mec bien ». Ce n'est que quand le développement de l'Internet s'est intensifié dans les années 1980 et 1990 que certains ont commencé à prêter attention à ce genre de choses. Des technologies comme Javascript et SSL furent introduites par Netscape, par exemple, bien que, depuis, ils ont été adoptés par tout le Net.
+Une des choses les plus intéressantes concernant l'Internet est que ce n'était pas conçu pour la sécurité et que c'est arrivé, pour ainsi dire, presque par accident. Les chercheurs du début, des gens comme JCR Licklider et Vint Cert, voulaient surtout faciliter la communication entre des chercheurs universitaires ; ils supposaient donc que quiconque avec qui ils avaient des contacts était un autre « mec bien ». Ce n'est que quand le développement de l'Internet s'est intensifié dans les années 1980 et 1990 que certains ont commencé à prêter attention à ce genre de choses. Des technologies comme Javascript et SSL furent introduites par Netscape, par exemple, bien que, depuis, ils aient été adoptés par tout le Net.
 Intro
@@ Ligne 147: / Ligne 147: @@
 Comment cela fonctionne
-Pour commencer, toutes les connexions SSH sont initialisées par le client. C'est vous, en tant que client, qui allez au serveur demander « S'il vous plaît, monsieur, pourrais-je avoir une connexion shell ? » Et, en général, vous le ferez en utilisant le port 22. Sur le serveur, il y a un démon qui écoute ce port et c'est lui qui doit répondre à votre demande. Si vous avez le même nom de compte sur le client et le serveur, alors il vous suffit de vous connecter au serveur. Si le nom est différent, vous devez saisir votre nom de compte. Ces exemples supposent que vous utilisez un terminal.
+Pour commencer, toutes les connexions SSH sont initialisées par le client. C'est vous, en tant que client, qui allez au serveur demander : « S'il vous plaît, monsieur, pourrais-je avoir une connexion shell ? » Et, en général, vous le ferez en utilisant le port 22. Sur le serveur, il y a un démon qui écoute ce port et c'est lui qui doit répondre à votre demande. Si vous avez le même nom de compte sur le client et le serveur, alors il vous suffit de vous connecter au serveur. Si le nom est différent, vous devez saisir votre nom de compte. Ces exemples supposent que vous utilisez un terminal.
 Premier exemple :
@@ Ligne 178: / Ligne 178: @@
 Et après, le « Binary Packet Protocol » démarre. Il spécifie chacun des champs du paquet envoyé en utilisant SSH. Si vous voulez tous les détails, regardez RFC 4253, mais c'est sans doute quelque chose d'inutile si vous n'allez pas écrire votre propre client.
-Puis c'est au tour du Serveur de s'identifier en transmettant sa clé publique. Si c'est la première fois que vous essayez de vous connecter à ce serveur, vous verrez quelque chose comme ceci :
+Puis c'est au tour du serveur de s'identifier en transmettant sa clé publique. Si c'est la première fois que vous essayez de vous connecter à ce serveur, vous verrez quelque chose comme ceci :
 The authenticity of host 'myserver.host.com' can't be established. (Impossibilité d'établir l'authenticité du serveur hôte..)
@@ Ligne 186: / Ligne 186: @@
 Are you sure you want to continue connecting (yes/no)? (Êtes-vous certain de vouloir continuer la connexion (oui/non) ?)
-Puisque c'est la première fois que vous essayez de vous connecter, vous ne savez pas avec certitude que c'est vraiment le serveur que vous voulez. C'est ici que pourrait avoir lieu une attaque de l'homme-au-milieu. Par exemple, si vous étiez assis dans un café avec wifi gratuit, quelqu'un à une autre table pourrait intercepter le trafic et répondre avec sa propre clé publique - autrement dit, il piraterait votre session. Cela ne devrait se passer que la première fois que vous vous connectez à cette machine précise, car la clé publique devrait être stockée à titre de référence ultérieure dans un fichier qui s'appelle « known_hosts » (hôtes connus). Sur une machine Linux, on la trouve généralement dans ~/.ssh/known_hosts. Sous Windows 7, il se trouve habituellement dans %USERPROFILE%\ssh ou %USERPROFILE%\.ssh. Mais si vous avez un nouvel ordinateur portable, vous devez passer par cette connexion initiale avec chacun des sites auxquels vous vous connectez.
+Puisque c'est la première fois que vous essayez de vous connecter, vous ne savez pas avec certitude que c'est vraiment le serveur que vous voulez. C'est ici que pourrait avoir lieu une attaque de l'homme-au-milieu. Par exemple, si vous étiez assis dans un café avec W ifi gratuit, quelqu'un à une autre table pourrait intercepter le trafic et répondre avec sa propre clé publique - autrement dit, il piraterait votre session. Cela ne devrait se passer que la première fois que vous vous connectez à cette machine précise, car la clé publique devrait être stockée à titre de référence ultérieure dans un fichier qui s'appelle « known_hosts » (hôtes connus). Sur une machine Linux, on la trouve généralement dans ~/.ssh/known_hosts. Sous Windows 7, il se trouve habituellement dans %USERPROFILE%\ssh ou %USERPROFILE%\.ssh. Mais si vous avez un nouvel ordinateur portable, vous devez passer par cette connexion initiale avec chacun des sites auxquels vous vous connectez.
 ===== 9 =====
@@ Ligne 193: / Ligne 193: @@
 The next step depends on whether you are using SSH v.1 or SSH v.2. Since the vulnerability in SSH v.1 was found long ago in Internet time, you probably should question what is happening if you see it used today. SSH v.2 was adopted in 2006, which makes it comparatively old and stable. As Michael W. Lucas put it in his book SSH Mastery: “SSH-1 permits man-in-the-middle attacks and session hijacking, as discussed in Chapter 1. If someone insists on using SSH-1, practice saying “I told you so.” His book is excellent, and the e-book is only $10, and worth every cent. In particular, if you need to set up an SSH server, which I won’t really cover much of, this book is mandatory reading. Among the changes introduced by SSH v.2 are:**
-C'est, sans aucun doute, une faiblesse, alors comment les administrateurs serveurs peuvent-ils l'empêcher ? L'empreinte vous fut rendue lorsque vous avez essayé de vous connecter et c'est donc la clé du problème, si vous voulez bien excuser le double-sens. Vous ne voudriez sans doute pas l'afficher publiquement sur un site Web non sécurisé, par exemple, puisque les méchants pourraient éventuellement trouver un moyen de la contrefaire. Et le courriel engendre les mêmes risques. Dans un environnement d'entreprise, vous pourriez peut-être l'afficher sur un site Web chiffré derrière un pare-feu et exiger que les employés utilisent leurs identifiants pour y accéder.
+C'est, sans aucun doute, une faiblesse, alors comment les administrateurs serveurs peuvent-ils l'empêcher ? L'empreinte vous fut rendue lorsque vous avez essayé de vous connecter et c'est donc la clé du problème, si vous voulez bien excuser le double sens. Vous ne voudriez sans doute pas l'afficher publiquement sur un site Web non sécurisé, par exemple, puisque les méchants pourraient éventuellement trouver un moyen de la contrefaire. Et le courriel engendre les mêmes risques. Dans un environnement d'entreprise, vous pourriez peut-être l'afficher sur un site Web chiffré derrière un pare-feu et exiger que les employés utilisent leurs identifiants pour y accéder.
-La prochaine étape diffère selon que vous utilisez SSH v.1 ou SSH v.2. Puisque la vulnérabilité dans SSH v.1 fut découverte il y a très longtemps (en temps Internet), vous devriez sans doute vous posez des questions sur ce qui se passe, si vous constatez qu'il est utilisé de nos jours. SSH v.2 fut adopté en 2006, ce qui fait qu'il est relativement ancien et stable. Comme Michael W. Lucas l'a dit dans sans livre //SSH Mastery// : « SSH-1 permet des attaques du type homme-au-milieu et le piratage de sessions, comme présenté dans le premier chapitre. Si quelqu'un persiste à vouloir l'utiliser, vous pouvez vous entraîner à dire "Je vous l'avais bien dit." ». Son livre est excellent ; la version électronique ne coûte que $10 et elle les vaut bien. En particulier, si vous avez besoin de créer un serveur SSH, ce dont je ne vais guère parler, lire ce livre est obligatoire. Parmi les modifications introduites par SSH v.2, il y a :
+La prochaine étape diffère selon que vous utilisez SSH v.1 ou SSH v.2. Puisque la vulnérabilité dans SSH v.1 fut découverte il y a très longtemps (en temps Internet), vous devriez sans doute vous poser des questions sur ce qui se passe, si vous constatez qu'il est utilisé de nos jours. SSH v.2 fut adopté en 2006, ce qui fait qu'il est relativement ancien et stable. Comme Michael W. Lucas l'a dit dans son livre //SSH Mastery// : « SSH-1 permet des attaques du type homme-au-milieu et le piratage de sessions, comme présenté dans le premier chapitre. Si quelqu'un persiste à vouloir l'utiliser, vous pouvez vous entraîner à dire "Je vous l'avais bien dit." ». Son livre est excellent ; la version électronique ne coûte que 10 $ et elle les vaut bien. En particulier, si vous avez besoin de créer un serveur SSH, ce dont je ne vais guère parler, lire ce livre est obligatoire. Parmi les modifications introduites par SSH v.2, il y a :
 ===== 10 =====
@@ Ligne 220: / Ligne 220: @@
 Kevin is a geek, Linux enthusiast, a certified Project Manager by day, and in general a tech lover. His blog is at: http://www.zwilnik.com **
-•  Des normes de chiffrement améliorées, y compris 3DES et AES
+•  Des normes de chiffrement améliorées, y compris 3DES et AES.
-•  La certification de clés publiques pour les clients (je vais en parler plus tard)
+•  La certification de clés publiques pour les clients (je vais en parler plus tard).
-•  L'utilisation d'algorithmes cryptographiques « Message Authentication Code (MAC) » solides pour vérifier l'intégrité
+•  L'utilisation d'algorithmes cryptographiques « Message Authentication Code (MAC) » solides pour vérifier l'intégrité.
-•  SSH v.1 était monolithique, ce qui veut dire que tous les protocoles nécessaires pour le chiffrement, l'authentification, etc. faisaient partie d'un seul grand protocole incorporé dans SSH v.1. Dans SSH v.2 chaque protocole est distinct et défini dans un RFC séparé, tels que
+•  SSH v.1 était monolithique, ce qui veut dire que tous les protocoles nécessaires pour le chiffrement, l'authentification, etc. faisaient partie d'un seul grand protocole incorporé dans SSH v.1. Dans SSH v.2 chaque protocole est distinct et défini dans un RFC séparé, tels que :
-••  Transport Layer Protocol (Le protocole de couche de transport)
+••  Transport Layer Protocol (Le protocole de couche de transport).
-••  Connection Protocol (Le protocole de connexion)
+••  Connection Protocol (Le protocole de connexion).
-••  Authentication Protocol (Le protocole d'authentification)
+••  Authentication Protocol (Le protocole d'authentification).
 Je ne veux pas prendre le temps d'examiner le fonctionnement de SSH v.1, et, puisqu'il y quelques différences, je vais me concentrer ici sur SSH v.2 uniquement.
-Une vois que vous aurez accepté la Clé publique du serveur, c'est à vous, le client de répondre. Vous le faites d'abord en générant une clé symétrique (appelé la clé de la session) qui servira à chiffrer tout le trafic. Souvenez-vous des tutoriels précédents, que des paires de clé asymétriques entraînent de très grands calculs supplémentaires et ne sont donc utilisées habituellement que pour configurer une connexion et échanger la clé symétrique. Le client crée cette clé, puis, en utilisant l'échange de clé Diffie-Hellman-SHA1 la renvoie au serveur.
+Une vois que vous aurez accepté la clé publique du serveur, c'est à vous, le client de répondre. Vous le faites d'abord en générant une clé symétrique (appelé la clé de la session) qui servira à chiffrer tout le trafic. Souvenez-vous des tutoriels précédents, que des paires de clé asymétriques entraînent de très grands calculs supplémentaires et ne sont donc utilisées habituellement que pour configurer une connexion et échanger la clé symétrique. Le client crée cette clé, puis, en utilisant l'échange de clé Diffie-Hellman-SHA1 la renvoie au serveur.
 NOTA : Le protocole contient une disposition pour l'attestation de la validité des clés publiques utilisées par une Autorité de certification. Cela aiderait énormément à empêcher une attaque homme-au-milieu à laquelle vous êtes vulnérables lors de votre première connexion, puisque la CA vous inspirerait confiance dans la validité de la clé publique du serveur. Mais, actuellement, tous les serveurs ne l'utilisent pas, en partie parce que les certificats sont chers.