Cours MIT "Sécurité des systèmes informatiques". Conférence 12: Sécurité du réseau, partie 1

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

Aujourd'hui, nous parlerons de la sécurité du réseau, en particulier, nous discuterons d'un article de Stephen Bellovin intitulé "Retour sur les" problèmes de sécurité dans la suite de protocoles TCP / IP "". Ce gars travaillait pour AT&T et travaille maintenant en Colombie. Ce qui est intéressant dans ce travail, c'est qu'il est relativement ancien - il a plus de 10 ans, et en fait, ce sont des commentaires sur un article paru une décennie plus tôt en 1989.

Beaucoup d'entre vous demandent pourquoi nous étudions cela si la plupart des problèmes décrits ici ont été résolus dans les versions d'aujourd'hui du protocole TCP.



Il est vrai que certains des problèmes décrits par Stephen ont depuis été résolus, et certains restent encore des problèmes. Dans cet esprit, nous allons les trier et voir ce qui se passe. Vous vous demandez peut-être pourquoi les gens n'ont pas résolu tous ces problèmes en premier lieu lors de la conception de TCP? À quoi pensaient-ils?

Et ce n'est en fait pas clair. Que pensez-vous? Pourquoi le protocole TCP n'avait-il pas la sécurité nécessaire, compte tenu de toutes ces considérations? Des suggestions?

Étudiant: À cette époque, Internet était un endroit beaucoup plus crédule.

Professeur: oui, c'était littéralement une citation de l'article de ce type. Oui, à cette époque en général ... un ensemble de protocoles Internet a été développé, je pense, il y a environ 40 ans. Les exigences étaient complètement différentes. Il était juste nécessaire de connecter un groupe de sites relativement crédules qui se connaissaient par leur nom à un réseau commun.

Je pense que cela se produit souvent dans tout système qui réussit - il a besoin de changements. C'était un protocole pour un petit nombre de sites, maintenant ce protocole couvre le monde entier. Et vous ne savez plus par le nom de toutes les personnes connectées à Internet. Vous ne pouvez pas les appeler s'ils font quelque chose de mal, etc.

Par conséquent, je pense que cette histoire est la même pour de nombreux protocoles que nous envisageons. Et bon nombre d'entre vous posent une question du genre: «Qu'est-ce que ces gars pensaient? C'est tellement imparfait! " Mais en réalité, ils ont conçu un système complètement différent, ils l'ont simplement adapté aux besoins modernes.

La même chose, et Internet, comme nous l'avons vu au cours des deux dernières semaines, a été conçu dans un but complètement différent. Mais il s'est élargi et nous avions de nouvelles préoccupations sur la façon d'adapter ce protocole aux exigences modernes.

Il y a une autre chose qui s'est produite un peu soudainement, à savoir que les gens ont dû surestimer la gravité du problème de sécurité. Auparavant, vous ne compreniez vraiment pas toutes les choses dont vous deviez vous inquiéter, car vous ne saviez pas ce que l'attaquant pouvait faire avec votre système.



Je pense que c'est en partie pour cette raison qu'il sera intéressant de voir ce qui est arrivé à la sécurité TCP, ce qui a mal tourné, comment pouvons-nous y remédier, etc. En conséquence, nous devons découvrir quels types de problèmes devraient être évités lors de l'élaboration de nos propres protocoles, ainsi que ce qui constitue une bonne réflexion sur les attaques de ce type. Comment savez-vous ce qu'un attaquant est capable de faire dans votre propre protocole lorsque vous le développez pour éviter de tels pièges?

D'accord, laissons le préambule de côté et parlons de cet article.

Alors, comment devrions-nous penser à la sécurité du réseau? Je pense que nous pourrions commencer par le premier principe et essayer de comprendre quel est notre modèle de menace. Que peut donc faire un attaquant sur notre réseau?

Il a probablement la capacité d'intercepter des paquets, et peut-être est-il capable de les modifier. Ainsi, si vous envoyez un paquet sur le réseau, il est sage de supposer qu'un méchant verra votre paquet et pourra le changer avant qu'il n'atteigne sa destination. Il peut également être en mesure de le supprimer et d'utiliser la possibilité de saisir des packages personnalisés avec un contenu arbitraire que vous n'avez jamais envoyé.



Mais le plus dangereux est la possibilité que des méchants interfèrent avec vos protocoles décrits dans l'article. L'attaquant a son propre ordinateur, qu'il contrôle complètement. Même si tous les ordinateurs auxquels vous faites confiance se comportent correctement, le méchant qui a son propre ordinateur peut interférer avec votre protocole ou votre système.

Donc, si vous avez un protocole de routage qui implique que beaucoup de gens se parlent, et qu'une certaine mise à l'échelle est probablement impossible à garder les méchants à l'extérieur. Si un protocole de routage avec 10 participants est en cours d'exécution, vous pouvez peut-être simplement les appeler tous et dire ensuite: "Eh bien, oui, les gars, je vous connais tous."

Mais à l'échelle d'Internet aujourd'hui, il est impossible de savoir directement qui les autres membres du réseau utilisent ce protocole. Donc, probablement, un méchant va participer à vos protocoles ou systèmes distribués. Par conséquent, il est important de concevoir des systèmes distribués qui, néanmoins, peuvent faire quelque chose de raisonnable avec cela.

OK, alors quelles sont les implications de tout cela? Je pense que nous allons parcourir la liste. L'interception de paquets est généralement facile à comprendre, vous ne pouvez pas envoyer de données importantes sur le réseau si vous vous attendez à ce que le méchant les intercepte, ou du moins ne les envoie pas en texte brut. Vous devriez peut-être crypter vos données.



Cela semble relativement facile à comprendre, même si vous devez toujours en tenir compte lors du développement de protocoles. L'introduction ou l'injection de packages conduit à un plus large éventail de problèmes intéressants, qui sont abordés dans cet article. En particulier, les attaquants peuvent injecter des paquets qui peuvent usurper l'identité de paquets de tout autre expéditeur. Puisque le chemin de transmission de données est basé sur l'utilisation d'IP, le paquet lui-même a un en-tête qui indique l'IP source du paquet et l'IP de destination. Cependant, personne ne vérifie que la source est nécessairement correcte. Il y a du filtrage de nos jours, mais ce n'est pas parfait et il est difficile de s'y fier.

Ainsi, en première approximation, un attaquant peut insérer n'importe quelle adresse IP à l'intérieur en tant que source et l'envoyer à la bonne destination. Il est intéressant de découvrir ce qu'un attaquant peut faire avec la possibilité d'envoyer des paquets arbitraires.

Au cours des semaines précédentes, nous avons examiné les problèmes de dépassement de tampon en termes de sécurité Web. Nous avons examiné comment un attaquant peut utiliser une erreur d'implémentation telle que des dépassements de tampon. Fait intéressant, l'auteur de cet article n'était pas vraiment intéressé par les erreurs de mise en œuvre; il est plus intéressé par les erreurs de protocole.

Alors, qu'est-ce qui est si spécial à ce sujet? Pourquoi n'a-t-il pas prêté attention aux erreurs de mise en œuvre, alors que nous avons passé plusieurs semaines à les examiner? Pourquoi est-ce important?

Etudiant: car il faut exclure ces erreurs lors de la rédaction du protocole.

Professeur: oui, c'est vraiment un gros échec à cause d'une erreur dans la conception du protocole car il est difficile de changer. Donc, si vous avez une erreur d'implémentation et que vous avez memcpy ou une impression qui n'a pas vérifié la plage de mémoire, vous ne pouvez pas remarquer cette erreur. Mais si vous avez une vérification de plage et que cela fonctionne toujours, alors les débordements de tampon peuvent être évités, donc c'est génial.

Mais si vous avez une sorte d'erreur dans la spécification du protocole, dans la façon dont le protocole devrait fonctionner, la correction d'une telle erreur nécessitera la correction de l'ensemble du protocole, ce qui signifie un impact potentiel sur tous les systèmes qui parlent ce protocole. Donc, si nous trouvons une sorte de problème dans le protocole TCP, ce sera potentiellement très destructeur. Parce que chaque machine utilisant TCP devra apporter des modifications, car il est potentiellement très difficile de rendre un protocole modifié compatible avec l'ancienne machine.

Les erreurs de protocole TCP qui préoccupaient tant Stephen étaient fondamentales, alors il a décidé d'en parler. Dans le premier exemple, il examine le fonctionnement des numéros TCP SN.

Étudiant: c'est un peu hors sujet, mais je suis juste curieux. Supposons que vous trouviez une erreur dans TCP. Comment y apportez-vous des modifications? Comment dites-vous à tous les ordinateurs du monde que cela doit être changé?

Professeur : oui, je pense que c'est un énorme problème. Que faire si vous trouvez une erreur dans TCP? Eh bien, on ne sait pas quoi faire. Je pense que l'auteur ici est aux prises avec cela. Si vous pouviez repenser TCP, bon nombre de ces erreurs sont relativement faciles à corriger si vous savez à l'avance ce qu'il faut rechercher.

Mais comme TCP est assez difficile à corriger ou à modifier, ce qui suit se produit finalement: les développeurs essaient de trouver des paramètres rétrocompatibles qui permettent aux anciennes implémentations d'être utilisées conjointement avec la nouvelle implémentation, ou ajoutent un champ supplémentaire qui rend la connexion quelque peu plus sûre.



Mais c'est un gros problème. S'il s'agit d'une sorte de problème de sécurité profondément enraciné dans TCP, cela deviendra un problème énorme pour tout le monde, car il est très difficile même de passer simplement à la version TCP, supposons n plus 1.

IPv6 peut être considéré comme un exemple que cela ne se produit pas, et nous savons que ce problème se posera pendant encore 15 ou 20 ans. IPv6 existe depuis plus de 10 ans, mais il est difficile de convaincre les gens de s'éloigner d'IPv4. IPv4 leur suffit, cela semble fonctionner, et ils pensent que le passage à un nouveau protocole Internet sera trop cher. Ils disent: "plus personne ne parle IPv6, alors pourquoi devrais-je commencer à parler de cet étrange protocole avec lequel personne ne me parle?" En tout cas, c'est une sorte de mouvement en avant, mais je pense que cela prendra beaucoup de temps. Il y aura vraiment une certaine motivation pour la migration, et la compatibilité descendante dans ce cas aide beaucoup.

IPv6 possède de nombreuses options de compatibilité descendante, par exemple, vous pouvez parler à un hôte IPv4 en utilisant IPv6. Par conséquent, les développeurs tentent de concevoir tout ce support, mais il est toujours difficile de convaincre les gens de mettre à niveau.

Donc, compte tenu des numéros de séquence TCP, nous allons réellement considérer deux problèmes liés au fonctionnement de la négociation TCP. Voyons donc comment une connexion TCP est initialement établie.

Trois paquets sont envoyés pour établir une nouvelle connexion TCP. Notre client génère un package pour se connecter au serveur, qui dit que voici l'adresse IP de mon client, je l'envoie au serveur. Dans le même temps, il existe une structure d'en-tête de paquet composée de différentes zones, mais nous nous intéresserons à la zone du numéro de série. Ici, nous aurons l'indicateur SYN disant: «Je veux synchroniser l'état et établir une nouvelle connexion», et il inclut le numéro de série du client SNc.



Puis, lorsque le serveur reçoit ce paquet, il dit: "le client veut se connecter à moi, donc je vais renvoyer le paquet à cette adresse, peu importe qui dit qu'il essaie de me contacter." Ainsi, le serveur enverra le paquet au client, où il comprend son propre numéro de séquence de synchronisation de serveur SN et son numéro de confirmation de client ACK (SNc). Enfin, dans le troisième paquet, le client répond au serveur, confirmant la synchronisation et envoyant au serveur le numéro de confirmation du serveur ACK (SN). Le client peut maintenant commencer à envoyer des données.

Ainsi, afin d'envoyer des données, au début de la connexion, le client doit inclure certaines données dans le paquet et joindre le numéro de série du client SNc pour indiquer qu'il s'agit réellement de données client légitimes. Il souligne, par exemple, que ce ne sont pas des données de messages ultérieurs qui viennent d'arriver maintenant, car le serveur a raté certaines des premières parties des données.



Ainsi, en règle générale, tous ces numéros de série sont conçus pour fournir la livraison de paquets. Si le client transmet deux paquets, celui qui a le numéro de séquence de départ est le premier élément de données, le numéro de séquence suivant est l'élément de données suivant. Il est également utile pour fournir certaines exigences de sécurité.

Avant cela, j'ai donné un exemple de l'évolution de ces exigences. Par conséquent, au départ, personne ne pensait que TCP devrait fournir des fonctionnalités de sécurité. Mais ensuite, le TCP a commencé à utiliser des applications, et ils semblaient s'appuyer sur ces connexions TCP, estimant qu'elles ne pouvaient être interrompues par aucun attaquant ou que l'attaquant n'était pas en mesure d'injecter des données malveillantes dans la connexion TCP existante. Comme si tout à coup ce mécanisme, qui n'était à l'origine destiné qu'à la commande de colis, commençait à garantir un semblant de sécurité pour ces connexions.

Par conséquent, dans ce cas, je suppose que le problème est lié à ce que le serveur aurait pu suggérer concernant cette connexion TCP. Typiquement, le serveur suppose - implicitement, comme vous pouvez l'imaginer - que cette connexion est établie avec le client souhaité à cette adresse IP C, et il est naturel pour lui de le penser. Mais y a-t-il une raison pour une telle hypothèse? Si le serveur reçoit un message contenant des données sur cette connexion client-serveur et qu'il a un numéro de séquence C, pourquoi le serveur conclut-il que le vrai client a envoyé ces données?

Étudiant: parce que le numéro de série est difficile à deviner.
Professeur: c'est vrai, c'est donc une sorte de chose implicite, impliquant qu'il doit y avoir un numéro de séquence SNc correct. Et pour que cette connexion soit établie, le client doit avoir un numéro de série de serveur SN confirmé et le numéro de série du serveur est envoyé par le serveur uniquement à l'adresse IP du client.

Étudiant: combien de bits sont disponibles pour le numéro de séquence?

Professeur: Le numéro de séquence TCP est long de 32 bits, et bien que ce ne soit pas un nombre aléatoire, il n'est pas facile à deviner, cela prendrait beaucoup de bande passante.

Étudiant: le numéro de série est-il supérieur au numéro de série initial?

Professeur: oui, en principe, ces choses augmentent. Par conséquent, chaque fois que vous envoyez SYN, il est considéré comme 1 octet de plus que votre numéro de séquence. Autrement dit, si dans la première ligne, nous avions l'argument (SNc), alors dans la quatrième, il y en aura déjà (SNc + 1), puis la numérotation se poursuit à partir d'ici. Ainsi, si vous transférez 5 octets, la valeur (SNc) +6 sera la suivante. Il compte simplement les octets que vous envoyez, chaque SYN comptant 1 octet. La spécification TCP recommande de choisir ces numéros de série afin que leur incrément se produise à une vitesse à peu près fixe. Les documents de travail initiaux du protocole RFC suggéraient que vous augmentiez ces choses d'environ 250 000 unités plus 250 000 par seconde.



La raison pour laquelle cela n'a pas été complètement aléatoire est que ces numéros de séquence sont en fait utilisés pour empêcher les paquets de ne pas intervenir ou pour mélanger les paquets des connexions précédentes avec de nouvelles connexions. Chaque fois que vous établissez une nouvelle connexion, vous choisissez un numéro de série complètement aléatoire. Dans le même temps, il est possible que si vous installez une série de connexions à plusieurs reprises, un paquet de la connexion précédente aura un numéro de séquence assez similaire au numéro de séquence de votre nouvelle connexion et sera donc accepté par le serveur comme une partie valide des données pour la nouvelle connexion.

C'est donc ce qui inquiétait les développeurs TCP - ces paquets non ordonnés ou paquets retardés. En conséquence, ils voulaient vraiment que ces numéros de séquence soient une séquence temporelle assez monotone même entre les composés.

Si j'ouvre une connexion, elle peut avoir la même source et la même destination, les mêmes numéros de port, adresses IP, etc. Mais depuis que j'ai établi cette connexion maintenant, et pas plus tôt, les paquets des messages précédemment envoyés, je l'espère, ne coïncideront pas avec les numéros de séquence que j'ai pour ma nouvelle connexion. Il s'agissait donc d'un mécanisme pour éviter la confusion entre les connexions répétitives.

Étudiant: si vous ne savez pas exactement quelle sera l’étape de la séquence de colis, comment savez-vous que le colis que vous recevez est le suivant et ne fait pas partie du précédent que vous ...

Professeur: En règle générale, vous vous souvenez du dernier paquet reçu. Et le numéro de séquence suivant est exactement le prochain paquet de la séquence. Ainsi, par exemple, le serveur sait que j'ai vu exactement une partie des données de date (SNc +1), alors le suivant sera le paquet SYN (SNc +1), car le paquet précédent au début de la connexion était SYN (SNc).

Etudiant: vous dites donc que lorsque vous définissez le numéro de série, même après cela, vous ...

Professeur: bien sûr, ces numéros de série, initialement, lorsque vous les installez, sont sélectionnés selon un plan. Nous parlerons de ce plan. Vous pourriez penser qu'ils sont aléatoires, mais au fil du temps, ils devraient représenter un flux séquentiel de changements dans les numéros de séquence initiaux pour la connexion.

Mais dans une seule connexion, tout se termine dès qu'il est établi - les numéros de série sont fixes. Et ils signalent simplement cette connexion lorsque des données y sont envoyées.

Il y avait des plans qui proposaient de gérer ces numéros de série. , . , , , .

, - , 250000. , , , 64k 128k, . , – , SYN .

, 64 . , .

, . , , , , IP-.
, , , , , . , , .

, ? , , , — SNc. , , - , , , .

, . ACK (SNs).

- .



SNs , , , IP- C.

, . , : , , , data (SNc +1).



(SNs). ?

: , ?

: . , , , , . , , , , .

: , , ?

: . , ?

, . , , 32 , , .

, .

: , , , . …

: , TCP .

: , .

: , .

: , , .

: , , , . , , 1000 , 2 32 .

, - , , . . , .



: - , ?

: , . , , IP-, ?

: ?

: — ? , . ?

: , , , , - .

: , , , , , . IP-, TCP , , , .

TCP , - , , , C RST (SN…), , .



- , , C , .

, C , . , S , : «, , , ».

, , , , , C .

, «» C , . , «» C , . , TCP.

: , . , SYN , .

: , , . , , , , NAT, . , NAT RST , . , , , , , Comcast , RST .

: ?

: , , TCP. , . , , , . /, .

, data (SNc +1). , IP- , : « », , S.



SYN (SNs) (SNs) , . — , IP-, . , SNS SNS .

25:50

Cours MIT "Sécurité des systèmes informatiques". 12: « », 2


.

Merci de rester avec nous. Aimez-vous nos articles? 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 Cores) 10GB DDR4 240GB SSD 1Gbps , .

Dell R730xd 2 fois moins cher? 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?