Cours MIT "Sécurité des systèmes informatiques". Conférence 13: Network Protocols, Part 2

Institut de technologie du Massachusetts. Cours magistral # 6.858. "Sécurité des systèmes informatiques." Nikolai Zeldovich, James Mickens. 2014 année

Computer Systems Security est un cours sur le développement et la mise en œuvre de systèmes informatiques sécurisés. Les conférences couvrent les modèles de menace, les attaques qui compromettent la sécurité et les techniques de sécurité basées sur des travaux scientifiques récents. Les sujets incluent la sécurité du système d'exploitation (OS), les fonctionnalités, la gestion du flux d'informations, la sécurité des langues, les protocoles réseau, la sécurité matérielle et la sécurité des applications Web.

Cours 1: «Introduction: modèles de menace» Partie 1 / Partie 2 / Partie 3
Conférence 2: «Contrôle des attaques de pirates» Partie 1 / Partie 2 / Partie 3
Conférence 3: «Débordements de tampon: exploits et protection» Partie 1 / Partie 2 / Partie 3
Conférence 4: «Séparation des privilèges» Partie 1 / Partie 2 / Partie 3
Conférence 5: «D'où viennent les systèmes de sécurité?» Partie 1 / Partie 2
Conférence 6: «Opportunités» Partie 1 / Partie 2 / Partie 3
Conférence 7: «Native Client Sandbox» Partie 1 / Partie 2 / Partie 3
Conférence 8: «Modèle de sécurité réseau» Partie 1 / Partie 2 / Partie 3
Conférence 9: «Sécurité des applications Web», partie 1 / partie 2 / partie 3
Conférence 10: «Exécution symbolique» Partie 1 / Partie 2 / Partie 3
Conférence 11: «Ur / Web Programming Language» Partie 1 / Partie 2 / Partie 3
Conférence 12: Sécurité du réseau, partie 1 / partie 2 / partie 3
Conférence 13: «Protocoles réseau», partie 1 / partie 2 / partie 3

Etudiant: le client ne peut pas décrypter ce ticket car il est crypté à l'aide de la clé de service.

Professeur: oui, c'est vraiment intelligent, non? Nous avons la clé Kc, s que le client peut recevoir, mais ici, sur le ticket Tc, s, il y a une autre copie de cette clé, chiffrée avec Ks.



La raison en est que le serveur Kerberos essaie en fait de sécuriser la communication du client avec l'autre gars. Par conséquent, Kerberos crée une clé aléatoire Kc, s et en donne une copie au client et une autre au serveur avec lequel le client va parler. Imaginez que Kerberos appelle simplement le service avec les mots: "hé, service, ce mec veut te parler, c'est la clé pour ça!" Ce serait regrettable car le serveur Kerberos accèderait encore et encore au service à chaque demande. KDS crée donc 2 copies de la clé de session: une pour le client et l'autre pour TGS.

Par conséquent, au lieu de cela, les développeurs ont trouvé une bonne astuce, où ils fournissent au client ce ticket, et il ne peut rien faire avec lui, sauf pour le contacter avec le bon service. Et si ce service a la bonne clé Ks, il la déchiffrera et dira: "Oui, c'est la même clé que je dois utiliser pour parler avec ce client." Ainsi, les deux participants à la connexion, le client et le service, établiront une clé commune pour protéger leur connexion.

Étudiant: alors qu'est-ce que TGS?

Professeur: Il y a deux points de vue sur ce qu'est le TGS. Du point de vue du client, ce n’est qu’un autre service pour lequel vous pouvez obtenir un ticket. Plus ce service offre de fonctionnalités, plus il offre de tickets. Il s'agit en fait d'un service de billetterie.

Étudiant: désolé, je voulais dire que nous avons un ticket appelé TGS.

Professeur: oh, oui, désolé, l'inscription tgs sous la flèche dans ce diagramme n'est qu'une abréviation pour l'ensemble du bloc d'enregistrement, à l'exception des index s dans le paramètre Tc, s, ce qui signifie que le nom réel de ce service est TGS. Vous pouvez imaginer que nous avons un serveur Kerberos, il y a ce service TGS et il y a un vrai service auquel vous voulez accéder. Vous devez donc d'abord demander à Kerberos de vous donner un ticket pour accéder à un service particulier.



Vous pouvez demander à Kerberos de vous donner un ticket directement sur le serveur de fichiers, et cela pourrait fonctionner. Mais pour cela, vous auriez besoin de votre Kc pour le décryptage et pour le reste du temps en utilisant le serveur. Au lieu de cela, vous obtenez un billet pour le service spécial TGS. Il ressemble à d'autres services, sauf qu'il est placé dans une boîte séparée. Et il se fera un plaisir de vous donner plus de billets plus tard sans fournir à nouveau votre clé client Kc d'origine.

Étudiant: c'est-à-dire que son idée est que dès que vous recevez un ticket TGS, vous pouvez simplement vous débarrasser de votre clé Kc?

Professeur: oui, ce qui est cool, c'est que dès que vous recevez ce ticket Tc, s du service TGS, vous vous débarrassez du mot de passe et de la clé Kc. Ainsi, dès que vous vous connectez au poste de travail Athena et après quelques secondes vous recevez un ticket T, s, votre mot de passe est supprimé de la mémoire. Donc, même si quelqu'un vous attrape, sélectionne l'ordinateur et s'enfuit avec lui, tout ce qu'il a, c'est votre ticket. C'est bien s'il peut accéder à vos informations pendant 10 heures, ou pour la durée du billet, mais pas plus longtemps, car le mot de passe n'a pas été enregistré et la prochaine fois que vous entrerez dans "Athena", vous devrez le ressaisir.

La seule fois où vous avez besoin d'un mot de passe, c'est lorsque vous envoyez une demande au serveur Kerberos, vous recevez cette réponse avec un ticket et la déchiffrez. Après cela, vous pouvez oublier le mot de passe. Mais bien sûr, vous ne pouvez pas supprimer le mot de passe avant de l'utiliser pour le déchiffrer.
Ainsi, la première interface supérieure C dans notre schéma est utilisée pour obtenir un ticket avec la clé initiale Kc, et la deuxième interface inférieure S est utilisée pour accéder aux services, mais sans avoir besoin d'obtenir la clé initiale Kc.



Nous avons donc déjà parlé de deux problèmes spécifiques du protocole Kerberos, qui sont pour ainsi dire intégrés, ce qui a causé quelques inconvénients. Premièrement, les créateurs ont supposé que le chiffrement fournirait également l'authentification ou l'intégrité des messages, mais cela ne s'est pas produit. Cette faille a été corrigée dans Kerberos version 5, où l'authentification explicite des messages est effectuée. Deuxièmement, pour les clients arbitraires, ils ont eu l'occasion de deviner les mots de passe d'autres personnes.

Comment résoudre ce problème? Comment prévenir les attaques en devinant le mot de passe dans des protocoles de ce type? Que pouvons-nous essayer?

Étudiant: Je ne suis pas sûr, mais vous pouvez essayer de «saler» le mot de passe.

Professeur: «saler» signifie simplement que le client peut avoir à hacher le mot de passe de différentes manières. Mais cela ne fait pas de mal d'essayer de le ramasser. Il pourrait donc être plus coûteux de créer un dictionnaire.

Etudiant: vous pouvez essayer de compliquer la fonction de calcul du mot de passe.

Professeur: oui, une autre bonne idée est de rendre le processus de hachage très coûteux. C'est peut-être raisonnable. Par conséquent, si cette fonction de hachage prend une seconde de temps de calcul, comme vous l'avez fait dans le deuxième laboratoire, dans ce cas, la sélection des mots de passe serait une tâche très coûteuse. Cela semble donc être un plan raisonnable - utiliser une combinaison de «salage» et de compliquer le processus de devinettes.

Une autre défense peut être de compliquer la réponse. Vous avez entendu que dans les premières versions du protocole, le serveur Kerberos ne savait pas si le bon client y accédait ou non. Ce que vous pourriez faire, c'est prouver que vous êtes le bon client, c'est-à-dire chiffrer l'horodatage actuel avec un hachage de mot de passe, ou quelque chose comme ça. Ensuite, le serveur Kerberos pourrait simplement vérifier si ces choses sont correctes et si elles correspondent, vous fournir un ticket.

Vous ne voudrez probablement pas ajouter d'autres étapes de test, mais cela pourrait fonctionner. Pour l'instant, supposons que vous pouvez prendre un horodatage et le hacher avec la clé Kc, et aussi simplement ajouter un horodatage.



Dans ce cas, le serveur peut voir qu'il a votre clé Kc et il peut également hacher l'horodatage actuel. S'il reçoit la même valeur, alors la demande est probablement faite par le bon utilisateur à qui le ticket peut être envoyé. Sinon, c'était le mauvais mot de passe.

Etudiant: vous pouvez simplement limiter l'émission de tickets si les serveurs enregistrent trop de demandes pour leur mise à disposition.

Professeur: très bien, nous pouvons introduire une restriction. Cependant, il n'y a aucune raison pour qu'un pirate demande un ticket sur le serveur plus d'une fois. Il demande simplement un utilisateur spécifique, reçoit ce bloc crypté de sa part et peut essayer de le décrypter hors ligne autant de fois qu'il le souhaite, avec des mots de passe différents sans deuxième demande. Par conséquent, je pense que tout le point de protection est que le serveur réagit en quelque sorte au nombre d'appels si l'attaquant demande à plusieurs reprises le serveur, essayant d'entrer dans le système sous différents mots de passe. Dans ce cas, la limite de requête peut être atteinte, ce qui offrira une meilleure protection contre le piratage.

Étudiant: comment un attaquant peut-il envoyer une requête au serveur Kerberos?

Professeur: Je pense qu'il pourrait reproduire le message de l'utilisateur correct, c'est-à-dire le voir, le copier, l'envoyer et également recevoir une réponse du serveur Kerberos. Si un pirate analyse le réseau, il peut intercepter le message pendant la transmission. La limitation du nombre de demandes est donc une mesure temporaire qui n'augmente que légèrement la sécurité. Mais, bien sûr, si vous regardez le réseau de quelqu'un d'autre, vous verrez comment ce paquet est retourné par le serveur indépendamment de ce qui s'est passé au stade de la formation de Tc, s. Ainsi, le pirate peut voir la réponse du serveur au client et essayer de l'attaquer.

Il y a probablement des schémas plus complexes que vous pourriez développer, mais je ne pense pas que Kerberos 5 implémente quelque chose de plus compliqué que le plan que nous avons examiné, ce qui semble assez bon pour empêcher des gens aléatoires d'essayer de casser quelque chose ou d'utiliser la brute- forcer à casser un mot de passe.

Étudiant: supposons que vous puissiez fournir une authentification ou autre chose pour établir une clé partagée. Et puis vous pouvez crypter cette chose et la clé partagée avec Kc.

Professeur: oui, ça l'est. Si vous le faites vraiment correctement, il existe pour cela un protocole appelé échange de clés authentifiées par mot de passe, PAKE, qui effectue l'authentification par mot de passe. C'est exactement ce qui se passe à Kerberos.



Vous pouvez consulter Google à quoi servent les protocoles SRP ou PAKE. Ces protocoles et leurs éléments associés font beaucoup mieux avec votre tâche, dans laquelle vous devez prouver aux deux parties que vous avez installé une nouvelle clé. Dans ce cas, les deux parties doivent être convaincues de l'exactitude de l'autre et de cela, et qu'il n'y a aucun moyen de deviner ce mot de passe hors ligne et d'attaquer l'ensemble des paquets réseau que vous observez, etc.

Ce sont des protocoles qui reposent fortement sur la cryptographie, il est donc difficile d'expliquer au tableau pourquoi ils fonctionnent.

Étudiant: L'une des raisons pour lesquelles les développeurs ont fait cela était qu'ils voulaient prendre en charge la possibilité d'envoyer uniquement un mot de passe. Et les protocoles ne vous permettent d'envoyer qu'une seule chose en tant qu'authentificateur.

Professeur: oui, il y a beaucoup d'exigences étranges que ces gars ont prises en compte. Bien sûr, dans la pratique, ces serveurs peuvent accepter à la fois les connexions Kerberos et non Kerberos. Et pour les connexions non Kerberos, vous obtenez l'image comme si quelqu'un se connectait à un serveur de messagerie mais n'utilisait pas un poste de travail Athena. Il veut juste envoyer son mot de passe.



Et puis, le client de messagerie ici, disons, va prendre ce mot de passe et obtenir un ticket en votre nom uniquement pour le vérifier, ce qui vous permettra d'utiliser ce client de messagerie. Vous souhaitez donc probablement que Kerberos vérifie lui-même les mots de passe Kerberos. Je ne pense pas que ce soit hors de question car bien sûr Kerberos 5 déploie ces hachages d'horodatage et tout ça.

Je pense qu'une autre chose à laquelle vous devez prêter attention dans les documents de cours est que les développeurs de Kerberos 4 ont choisi un schéma de cryptage - DES, l'algorithme de cryptage le plus populaire de l'époque. Il s'agit d'un chiffrement par bloc symétrique, assez rapide. À cette époque, il offrait une sécurité suffisante et ils l'ont simplement intégré au protocole.

Tout dans Kerberos était censé utiliser uniquement DES, ou du moins tout dans Kerberos version 4. Cela est devenu problématique, car maintenant, 25-30 ans plus tard, le cryptage DES peut être facilement piraté en utilisant la méthode de la force brute, car les clés de cryptage ont très petite taille - seulement 56 bits.

Par conséquent, vous pouvez simplement créer une sorte d'équipement utilisateur qui calculera de 2 à 56 degrés de combinaisons et découvrir le vrai mot de passe. C'est ce que vous voulez éviter dans tout protocole en cours de développement de nos jours.

Kerberos version 5 prend en charge plusieurs schémas de chiffrement différents, y compris AES et d'autres algorithmes cryptographiques. Cela semble donc être une bien meilleure façon d'assurer la sécurité. D'un autre côté, le MIT a continué à soutenir DES il y a 2 ans, mais maintenant il l'a refusé, donc aujourd'hui votre recteur est protégé, au moins contre ce type d'attaque. Voyons maintenant ce qui se passe dans le service TGS à partir duquel vous recevez un ticket. L'interaction avec ce service est un peu différente.

D'une part, en tant que client, vous allez lui parler comme si vous parliez à tout autre service compatible Kerberos. Considérez comment vous effectuez votre propre authentification avec un ticket pour une machine. Mais la réponse que vous allez renvoyer n'est qu'un billet vers un autre principe, sur la base duquel vous communiquerez, par exemple, avec un serveur de fichiers.

Par conséquent, les messages au niveau du protocole ressembleront à ceci - à droite, je dessinerai TGS, et à gauche - le client. Le client a déjà un ticket pour TGS, obtenu en utilisant le protocole indiqué en haut.



Maintenant, le client va envoyer une combinaison de messages prouvant qu'il est le bon client, et ces messages sont liés à l'émission d'une demande sur un principe spécifique via TGS.

Ainsi, le client va envoyer le message suivant à TGS: S est le service avec lequel il va communiquer davantage, il peut s'agir d'un serveur de messagerie ou de fichiers, puis cela inclut le ticket client Tc qu'il a reçu pour tgs, crypté à l'aide de la clé K tgs et un authentificateur chiffré avec la clé Kc, tgs commune au client et au service TGS. Voici à quoi ressemble le message que vous allez envoyer à TGS - il dit: "regardez ce message, faites-en quelque chose et répondez avec un ticket pour ce nouveau service S." La réponse ici semble presque la même que dans la figure ci-dessus, et en fait c'est la même chose - c'est un ticket entre le client et ce nouveau service, crypté en utilisant Ks. Mais maintenant, c'est devenu un peu différent.



Au lieu du chiffrement avec la clé Kc, que le client doit avoir oublié depuis lors, maintenant le chiffrement est effectué en utilisant la clé commune Kc, tgs entre le client et le service TGS.

Comment le serveur détermine-t-il ce que le client veut et comment le serveur authentifie-t-il le client? Le serveur TGS connaît sa propre clé Ktgs, donc il va d'abord décrypter ce message Tc, tgs, regarder à l'intérieur du ticket et découvrir ce qui se passe. Pourquoi avons-nous besoin de tous ces champs sur le ticket? Pourquoi est-il important d'avoir le nom de serveur S dans le ticket? Que se passerait-il si nous n'avions pas S?

Étudiant: s'il n'y en avait pas, vous pourriez potentiellement obtenir la permission d'utiliser n'importe quel serveur.

Professeur: oui, ça l'est. En général, c'est une bonne idée de faire les protocoles réseau afin que vous puissiez dire exactement ce que signifie ce message. Dans le cas où vous omettez S, vous pouvez compter sur le fait que si vous utilisez un ticket pour le mauvais S, alors vous aurez peut-être une autre clé Ks et il ne pourra pas effectuer le déchiffrement ou quelque chose comme ça. Il semble donc judicieux d'inclure le nom du service afin de s'assurer que le serveur qui reçoit ces tickets les déchiffre et vérifie s'il s'agit d'un ticket pour moi ou pour quelqu'un d'autre?

Étudiant: que fait le client avec la clé Ktgs reçue?

Professeur: bonne question! Le client n'a aucune idée de ce que c'est. Parce que c'est une clé top secrète. Si vous le saviez, vous seriez en mesure de casser tout Kerberos. Le client n'a donc aucune idée de ce qu'est Ktgs.

Étudiant: d' où vient ce Ktgs?

Professeur: le serveur Kerberos lui-même génère pour vous tout ce message, qui contient déjà Tc, tgs et Ktgs, vous ne le créez pas vous-même, mais le copiez simplement à partir d'ici.

Alors pourquoi le nom du client est-il si important? C'est facile à comprendre. Si vous ne mettez pas le nom du client sur le ticket, le serveur reçoit ce message, mais ne sait pas à qui il essaie de parler. Il ne sait pas pour qui il doit délivrer un billet - pour vous ou pour quelqu'un d'autre.

Et les autres domaines? Pourquoi les développeurs insèrent-ils l'adresse addr sur le ticket Tc, s? Il s'agit simplement de l'adresse IP du client, alors pourquoi ne pas l'utiliser directement?



Je pense que le sens de cette solution est le désir des développeurs d'augmenter la sécurité. Ils voulaient s'assurer que si le client se connectait à partir d'une adresse IP, tout le reste du même ticket proviendrait de la même adresse IP. Par exemple, si vous êtes connecté à partir d'une adresse IP, par exemple 18.26.4.9, chaque connexion à un serveur de fichiers ou de messagerie doit provenir de la même adresse IP. Sinon, le serveur doit rejeter votre connexion, car cela peut suggérer que quelqu'un a volé votre ticket. Ainsi, nous nous protégeons ici contre l'utilisation de billets volés. Si vous avez toujours le même ticket - très bien, mais si vous n'utilisez pas la même adresse IP, vous ne réussirez pas.

Cela semble être une idée fausse en ce moment, et Kerberos 5 utilise toujours une approche similaire, bien que ce ne soit pas nécessaire. En effet, vous devez simplement compter sur la cryptographie au lieu de sécuriser l'adresse IP.

Mais quelle est la signification de l'horodatage et de l'horodatage dans le ticket? À quoi servent-ils et à quoi servent-ils?

Étudiant: Ils sont nécessaires pour empêcher les attaques de rejeu.
Professeur: les attaques par rejeu nous aident à empêcher l'authentificateur, car cette chose est générée à chaque fois que vous faites une nouvelle demande. Mais d'un autre côté, le ticket reste le même, donc cela, bien sûr, n'interfère pas avec les attaques de rejeu.

Étudiant: cela empêche quelqu'un de voler votre billet et de l'utiliser ensuite à ses propres fins.
Professeur: oui, cela limite simplement la durée de validité du billet, de manière à réduire les dommages dus à son vol. L'horodatage est l'heure à laquelle vous avez reçu le ticket, et la durée de vie indique combien d'heures ce ticket est valide à partir de l'horodatage initial. Par conséquent, si vous essayez de l'utiliser trop tôt ou trop tard, tout serveur doit rejeter un tel ticket à l'aide du protocole Kerberos. Cela signifie que chaque serveur doit synchroniser son horloge.

Étudiant: Vous avez dit plus tôt qu'un client peut jeter sa clé initiale, jeter Kc, mais doit stocker les Kc reçus de TGS.

Professeur: oui, c'est le cas, le client laisse tomber Kc après s'être connecté, mais doit garder Kc, art.

Étudiant: donc, si quelqu'un vole Kc, s, alors il a accès ...

: , , ? , Kc,tgs, K?

: K,s, , K, .



: . , Kc,s — , , . , Tc,tgs, . , 56 Kc,s. . , Tc,tgs , Kc,s , - .

: , - — Tc,tgs, Kc,tgs, Kc,tgs, Kc — .

: , - , , , , 10 . Kc , .

, , , IP-, . - , , Kc,tgs, TGS. — , , , .

, , , . , , . TGS , , PO12, TGS PO12. , , Kc,s . , , . Kc,s.



, , Tc,mail, Kmail, , , , 5 – DELETE 5, Kc,mail.



, mail? Kmail, - , , Kc,s, Kerberos 5. : «, C , ».

: Kerberos Tc,tgs Kc,s. ?

: Ac . , Kc,s, , . , .



, Kerberos 4 , , , , , , , .

, , , , . , . , , . , , , , . , .
. Kerberos, , , Kerberos 4. , - .

, , , , , Kerberos 4, , , K,mail. , .



, , . , , . - : «, , DELETE 5, - ».

, Kerberos 5 -, . , , , , , .

: K,mail?

: .



, TGS , , S – mail, S Tc,s – mail, S Kc,s — mail. Kc,s K,mail. , .

: K,mail?

: , ? , , . K,mail ?

: ?

: , , ! Kmail, T,mail, , . , , .

, . . Kerberos , , 30 .
, , . , Kerberos 4 . , .

54:00

MIT « ». 13: « », 3


.

Merci de rester avec nous. ? Vous voulez voir des matériaux plus intéressants? Soutenez-nous en passant une commande ou en le recommandant à vos amis, une réduction de 30% pour les utilisateurs Habr sur un analogue unique de serveurs d'entrée de gamme que nous avons inventés pour vous: Toute la vérité sur VPS (KVM) E5-2650 v4 (6 cœurs) 10 Go DDR4 240 Go SSD 1 Gbps à partir de 20 $ ou comment diviser le serveur? (les options sont disponibles avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).

VPS (KVM) E5-2650 v4 (6 cœurs) 10 Go DDR4 240 Go SSD 1 Gbit / s jusqu'en décembre gratuitement en payant pour une période de six mois, vous pouvez commander ici .

Dell R730xd 2 ? Nous avons seulement 2 x Intel Dodeca-Core Xeon E5-2650v4 128 Go DDR4 6x480 Go SSD 1 Gbps 100 TV à partir de 249 $ aux Pays-Bas et aux États-Unis! Pour en savoir plus sur la création d'un bâtiment d'infrastructure. classe utilisant des serveurs Dell R730xd E5-2650 v4 coûtant 9 000 euros pour un sou?