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

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

Étudiant: existe-t-il une sorte de signature pour les domaines de premier niveau inexistants?

Professeur: Je pense que oui. Un domaine ponctuel n'est qu'un autre domaine et il met en œuvre le même mécanisme. Donc, les domaines "dot" et "dot.com" utilisent de nos jours le DNS SEC, et il y a tous ces enregistrements qui disent, par exemple, que .in est le nom de domaine qui existe, et le nom "dot" existe aussi, et il n'y a plus rien entre eux. Donc, dans les domaines de premier niveau, toutes ces choses sont présentes.



Étudiant: outre le danger des attaques DoS, pourquoi nous soucions-nous tant de la répétition des noms de domaine au sein de mit.edu?

Professeur: Je n'en suis pas sûr. Quoi qu'il en soit, AFS dispose d'un fichier texte qui répertorie tous ces noms de domaine MIT. Mais je pense qu'en général, certaines entreprises se sentent un peu gênées dans ce sens, car elles ont souvent des noms internes qui sont dans le DNS et qui ne peuvent pas être donnés à des étrangers. Je pense qu'en fait, il s'agit d'un domaine flou qui n'a jamais été formalisé et qui n'explique pas exactement ce que les utilisateurs DNS garantissent. Habituellement, les gens supposent que si un nom confidentiel existe, alors dans le cas du DNS, il ne sera pas divulgué.

Je pense que c'est un autre endroit où ce système n'a pas de spécification claire quant à ce qu'il devrait ou ne devrait pas fournir.

Etudiant: est- il possible de fixer la durée de validité d'une signature en la mettant en évidence d'une certaine manière?

Professeur: ces choses ont une date d'expiration, par exemple, vous pouvez signer que cet ensemble de noms est valide pendant une semaine, puis les clients, s'ils ont une horloge synchronisée, peuvent rejeter les anciens messages signés.

Donc, nous pouvons supposer que nous avons discuté des attaques en devinant les numéros de séquence TCP SYN. Un autre problème intéressant concernant TCP est l'attaque DDoS, qui exploite le fait que le serveur est dans un certain état. Si vous regardez cette poignée de main, qui a été dessinée sur la carte plus tôt, vous verrez que lorsque le client établit une connexion avec le serveur, le serveur doit se souvenir du numéro de série du client SNc. Ainsi, le serveur doit prendre en charge une certaine structure de données dans un bloc séparé, ce qui montre que ce numéro de séquence est utilisé pour cette connexion.



Il s'agit d'une sorte de tableau dans lequel le numéro de séquence SN est stocké et où la connexion client-serveur a le numéro de séquence SNc. La raison pour laquelle le serveur doit conserver cette table est que le serveur doit déterminer ce que le numéro de séquence SNc correct devrait prendre plus tard, par exemple, SNc + 1. En outre, le serveur doit également stocker les numéros de SN, qui sont beaucoup plus importants, car ils montrent au serveur que la connexion est établie avec le «bon gars».

Le problème est que cette table n'a pas de véritable frontière. De cette façon, vous pouvez obtenir des paquets d'une machine sans même savoir qui les envoie. Vous obtenez simplement un paquet qui ressemble à C-> S avec une adresse source qui prétend être C. Pour accepter potentiellement cette connexion à partir de cette adresse IP, vous devez créer une entrée dans le tableau. De plus, ces enregistrements existent depuis longtemps, car, peut-être, quelqu'un établit une connexion avec vous depuis un endroit très éloigné et en même temps de nombreux paquets sont perdus. Dans le pire des cas, cela peut prendre, par exemple, une minute avant que quelqu'un termine cette négociation TCP. Vous devez donc conserver cet état sur la pile TCP pendant une durée relativement longue, et il n'y a aucun moyen de deviner s'il sera valide ou non.

Ainsi, l'attaque DoS la plus courante contre la plupart des piles TCP que les utilisateurs ont inventées est la simple transmission d'un grand nombre de paquets. Si je suis un attaquant, j'envoie simplement un grand nombre de paquets SYN à un serveur spécifique et je fais déborder cette table.

Le problème est que, au mieux, un attaquant utilise simplement la même adresse IP source. Dans ce cas, vous pouvez simplement dire que chaque client n'a droit qu'à deux entrées, ou quelque chose comme ça. Et puis l'attaquant peut utiliser un maximum de 2 deux entrées dans le tableau.

Le problème, bien sûr, est qu'un attaquant peut truquer les adresses IP des clients et les faire paraître aléatoires. Ensuite, il sera très difficile pour le serveur de distinguer qui essaie d'établir une connexion avec lui - un attaquant ou un client dont le serveur n'a jamais entendu parler auparavant.

Donc, si vous regardez un site qui devrait accepter des connexions de n'importe où dans le monde, ce sera un gros problème. Parce que soit vous refusez l'accès à tout le monde, soit vous devriez pouvoir stocker l'état pour la plupart des fausses tentatives de connexion.

Il s'agit donc d'un problème à la fois pour TCP et la plupart des protocoles qui permettent une sorte d'initiation de connexion, dans laquelle le serveur doit enregistrer l'état. Mais il y a quelques correctifs implémentés dans TCP dont nous parlerons dans une seconde, et ils essaieront de résoudre ce problème, qui est appelé SYN Flooding dans TCP.



En général, c'est un problème que vous devez connaître et essayer d'éviter dans tout protocole que vous développez. Vous devez spécifier que le serveur ne doit pas enregistrer l'état tant qu'il ne peut pas authentifier et identifier le client. Car ce n'est qu'après l'authentification du client que l'on peut décider s'il est autorisé à se connecter, par exemple, une seule fois, auquel cas le serveur n'a pas besoin de sauvegarder l'état de cette connexion.

Le problème est que vous garantissez la préservation de l'État avant même de savoir qui se connecte à vous. Voyons comment nous pouvons contrer l'attaque par inondation SYN Flooding, qui est que le serveur accumule trop d'état.

Vous pouvez modifier TCP à nouveau, par exemple, le réparer assez facilement avec la cryptographie ou autre chose, ou changer ce qui est responsable de la sauvegarde d'un état. Mais le fait est que nous devons utiliser TCP tel quel. Pourrions-nous résoudre ce problème sans modifier le protocole TCP existant?

Ceci, encore une fois, est un exercice pour essayer de comprendre exactement quelles astuces nous pourrions effectuer, ou plutôt, quelles hypothèses nous pourrions laisser de côté et continuer à adhérer au format d'en-tête TCP existant lorsque nous travaillons avec elles.

Et l'astuce consiste à trouver un moyen intelligent de créer un serveur sans état, afin qu'il n'ait pas à stocker cette table en mémoire. Cela peut être fait en choisissant soigneusement les SN, c'est-à-dire qu'au lieu de la formule que nous avons considérée précédemment et où nous avons dû ajouter cette fonction, nous choisirons les numéros de série d'une manière complètement différente. Je vais vous donner la formule exacte, puis nous expliquerons pourquoi elle est vraiment intéressante et quelles sont ses bonnes propriétés.

Si le serveur détecte qu'il subit une attaque de ce type, il passe dans le mode où il sélectionne les SN en utilisant la formule avec la même fonction F que nous avons considérée précédemment.



Cette fonction a l'adresse IP source, l'adresse IP de destination, les mêmes choses qu'auparavant - port source, port de destination, horodatage et clé. Et nous allons combiner cette fonction avec un horodatage, plutôt «à grain grossier», de quelques minutes. Il y a une séparation entre ces deux parties de l'en-tête - la fonction et l'horodatage, qui n'a pas besoin de beaucoup de bits. J'ai oublié comment ce protocole fonctionne exactement sur un vrai ordinateur, mais vous pouvez imaginer que l'horodatage prend 8 bits et que le reste de la formule du numéro de séquence est de 24 bits.

Alors, pourquoi est-ce un bon plan? Que se passe-t-il ici? Pourquoi cette formule bizarre est-elle nécessaire? Vous devez vous rappeler ce que nous avons essayé d'obtenir des numéros de série. Deux choses se produisent ici.

Le premier est la protection contre les paquets en double. Il restait sur la carte un circuit avec ce numéro de série à l'ancienne, auquel nous ajoutons une fonction pour éviter la duplication des packages des connexions précédentes.



Il s'avère que les gens ne pouvaient pas trouver un meilleur moyen de se protéger contre des attaques comme SYN Flooding, sauf pour utiliser ce plan d'action, qui fonctionne bien dans certaines situations. C'était un plan, mais un autre plan était une fonction horodatée où nous avons abandonné cette composante de l'ancien style. Au lieu de cela, nous nous efforcerons de nous assurer que si quelqu'un nous fournit ce numéro de séquence ACK (SN) en réponse au paquet, cette personne sera le «bon» client.

Vous vous souvenez que pour empêcher les attaques d'usurpation d'adresse IP, nous nous appuyons en quelque sorte sur cette valeur (SN). En effet, si le serveur envoie cette valeur de SN au client dans la deuxième étape, nous nous attendons à ce que seul ce client soit en mesure de nous envoyer la valeur de SN corrigée dans la troisième étape, complétant la connexion.

C'est pourquoi vous avez dû stocker ce numéro de série dans une table, car sinon, comment sauriez-vous s'il s'agit d'une vraie réponse ou d'une fausse? La raison d'utiliser cette fonction F est que maintenant nous ne pouvons pas enregistrer cette table en mémoire.

Au lieu de cela, lorsque la tentative de connexion est affichée, ce qui est indiqué dans la première étape, dans la deuxième étape, nous calculons les SN à l'aide de cette formule et nous les renvoyons simplement au client qui souhaite nous contacter, puis oublions cette connexion.



Ensuite, lorsque le troisième paquet arrive et que sa valeur (SN) correspond à ce que nous attendons, cela signifie que quelqu'un a reçu notre réponse dans la deuxième étape et nous l'a finalement envoyée. Enfin, après cette troisième étape, nous pouvons mettre en mémoire l'enregistrement réel de cette connexion TCP. Il s'agit d'un moyen de différer la persistance du serveur jusqu'à ce que le client envoie la valeur exacte du numéro de série. La construction d'une telle construction permet de vérifier que le client a envoyé au serveur exactement la réponse attendue de lui, et non une valeur arbitraire.

Étudiant: le SNc ne dure-t-il qu'un temps limité?

Professeur: oui, le serveur ne stocke pas la valeur SNc de façon permanente, et ce n'est pas trop bon. Je ne l'ai pas montré dans le diagramme, mais ici, à la fin de la troisième ligne, il y a un champ qui montre que ce paquet n'a pas de données, mais il inclut le numéro de séquence SNc uniquement parce qu'il a ce champ.



Ainsi, le serveur peut restaurer la valeur de SNc, car le client va de toute façon l'inclure dans ce package. Auparavant, cela n'avait pas d'importance, mais maintenant c'est comme pertinent. Nous n'allons rien vérifier ici, mais l'existence d'un tel champ est en soi une bonne chose. Cependant, cela a de tristes conséquences. Par exemple, si vous utilisez des choses compliquées dont vous pouvez abuser ici. Mais ce n'est pas aussi mauvais que le débordement de mémoire du serveur avec les demandes des clients.

Parce que la seule chose qui nous inquiète est de libérer le stockage de cette table et la confiance que les connexions sont établies avec de véritables clients. Et si ce client établit un million de connexions avec moi, je ne vais plus accepter les demandes de lui, c'est assez simple. Le problème est qu'il est difficile de distinguer les fausses adresses des véritables adresses des clients.

Étudiant: dois-je conserver un horodatage?

Professeur: oui, il y a une chose intelligente! Lorsque nous obtenons la valeur des SN à la troisième étape, nous devons comprendre comment calculer les données d'entrée pour cette fonction F afin de vérifier que cette valeur est correcte. Par conséquent, nous prenons l'horodatage situé à la fin du package et l'utiliser pour calculer à l'intérieur de la fonction. Tout ce que nous pouvons restaurer d'autre. Nous savons qui vient de nous envoyer la troisième étape et le package, nous avons tous ces champs et notre clé, qui, encore une fois, est toujours secrète, et l'horodatage des 8 derniers bits de la séquence. Dans ce cas, il peut arriver que nous excluions des horodatages trop anciens en interdisant simplement les anciennes connexions.

Étudiant: Je crois que vous l'utilisez lorsque vous êtes attaqué, uniquement parce que vous perdez 8 bits de sécurité, ou pour une autre raison?

Professeur: oui, ce n'est pas très bon, il a beaucoup de mauvaises propriétés. D'une certaine manière, nous perdons vraiment 8 bits de sécurité. Parce que maintenant la partie incontestable n'est plus que de 24 bits au lieu de 32.

Un autre problème est ce qui se passe si vous perdez certains packages? Dans TCP, il est généralement admis que si le troisième paquet est perdu, le client n'attend rien. Ou, excusez-moi, le protocole que nous exécutons au-dessus de cette connexion TCP est peut-être un protocole qui suppose que le serveur a initialement l'intention de dire quelque chose, alors je me connecte et j'écoute simplement la réponse. Et dans SMTP, par exemple, le serveur doit m'envoyer quelque chose comme un message d'accueil via le protocole. Supposons que je me connecte au serveur SMTP, envoie le troisième paquet, je pense que j'ai tout fait et attend juste que le serveur me réponde, par exemple:

"Salut, c'est un serveur SMTP, envoyez-moi votre email!"

Donc, ce troisième paquet peut être perdu. Dans le vrai TCP, le serveur se souvient qu'à la deuxième étape, il a répondu au client, mais n'a jamais reçu de lui un troisième paquet de réponse. Par conséquent, le serveur enverra à nouveau au client un deuxième paquet pour redémarrer le troisième paquet. Bien sûr, si le serveur ne stocke aucun état, il ne sait pas quoi envoyer. Cela rend l'établissement d'une connexion quelque peu problématique, car les deux parties s'attendront à une étape réciproque l'une de l'autre. Le serveur ne sait même pas que le client attend une réponse de celui-ci, et le client attend la réponse du serveur, bien qu'il ne va pas répondre car il ne stocke pas l'état. Par conséquent, c'est une autre raison pour laquelle vous n'utilisez pas le mode productif du serveur en permanence.

Étudiant: vous pouvez également subir une perte de données si vous établissez deux connexions de très courte durée à partir d'un hôte immédiatement après l'autre.

Professeur: oui, bien sûr. Une autre chose est que nous avons refusé d'utiliser cet ancien style de numéro de séquence ISN, ce qui a augmenté l'indépendance de ces multiples connexions en peu de temps les unes par rapport aux autres. Je pense qu'il y a un certain nombre de compromis ici, nous venons d'en parler de trois, il y a donc encore quelques raisons de s'inquiéter.

Si nous pouvions développer un protocole à partir de zéro, en s'efforçant pour le mieux, nous pourrions simplement avoir un bon volume 64 bits séparé pour la fonction F et un volume 64 bits pour l'horodatage, puis nous pourrions l'utiliser en permanence, sans abandonner toutes ces belles choses.

Étudiant: les SN des deuxième et troisième étapes devraient-ils être les mêmes?

Professeur: bien sûr, car sinon le serveur ne pourra pas conclure que ce client a bien reçu notre colis. Si le serveur ne vérifie pas que ce SN a la même signification qu'auparavant, cela pourrait être encore pire - car je pourrais simuler une connexion à partir d'une adresse IP arbitraire dans la première étape, puis obtenir cette réponse dans la deuxième étape. Ou je n'obtiendrais même pas cette réponse car elle est dirigée vers une adresse IP différente. Ensuite, dans la troisième étape, j'établis une connexion à partir d'une autre adresse IP. Dans ce cas, le serveur prend en charge la connexion établie, attend que j'envoie des données, etc.



Étudiant: mais l'horodatage sera différent, non? Comment le serveur peut-il raconter cela en utilisant un nouvel horodatage s'il ne stocke pas l'état?

Professeur: comme je l'ai dit, ces horodatages sont assez «grossiers» et sont classés en quelques minutes. Si vous vous connectez à la même minute, alors tout est en ordre, si vous vous connectez à la frontière de la minute - c'est dommage.

Un autre problème avec ce circuit est qu'il est imparfait à bien des égards. Mais la plupart des systèmes qui fonctionnent, y compris Linux, ont des moyens de détecter trop d'entrées dans ce tableau. Et lorsque la menace de son débordement se produit, le système passe à un autre schéma.

Élève: si un attaquant contrôle un grand nombre d'adresses IP et fait ce que vous avez dit, même si vous changez ...

Professeur: oui, vous pouvez vraiment faire peu. La raison pour laquelle ce plan nous tenait tant à cœur était que nous voulions filtrer ou faire une distinction entre les attaquants et les «bons gars». Si un attaquant a plus d'adresses IP et contrôle simplement plus de machines que les bons, alors il peut se connecter à notre serveur, demander plusieurs pages Web ou rester en contact.

Ensuite, il sera très difficile pour le serveur de déterminer si des demandes sont reçues de clients légitimes ou s’agit-il simplement d’un attaquant qui lie les ressources du serveur. Vous avez donc tout à fait raison. Ce schéma ne fonctionne que si l'attaquant possède un petit nombre d'adresses IP et souhaite obtenir un effet.

Et cela est préoccupant, car aujourd'hui, certains attaquants contrôlent un grand nombre d'ordinateurs piratés par des utilisateurs ordinaires. Cela leur permet de créer un DoS avec une flotte de machines situées dans le monde entier, et il est assez difficile de se défendre contre lui.

Je veux mentionner une autre chose intéressante - le déni du service DoS est mauvais en soi, mais encore pire lorsque les protocoles eux-mêmes facilitent une telle attaque. L'attaquant le sait et attaque principalement les systèmes avec des protocoles tels que DNS. Le protocole DNS inclut un client envoyant une demande au serveur, et le serveur renvoie une réponse au client. Et dans de nombreux cas, la taille de réponse en octets est beaucoup plus grande que le volume de demande.



Vous avez posé des questions sur le serveur mit.edu. , , mit.edu — , mit.edu, , DNS SEC, .

100 , — 1000 . , «» - . , DNS- . 100 - DNS-, , , 1000 .

, . , TCP SYN Flooding, DNS- , . , , « ».

DNS. . , DNS-. , . .

: DNS- …

: , DNS- , - .

: , ?

: , DNS-, . DNS-, . 10 DNS-, , , , , . . , , DNS-, .

, DNS , , , . , .

, , , – , , , . , , . .

DNS- , . , , .

, : «, , »! , , DNS- .

, . - -, . DoS , . , , , , .



, , . , , , .

, , . .

, DHCP, . , , IP-. , , MIT DHCP, , , , IP-, , DNS-, , .

, DHCP DHCP-, , DHCP-. , , . , DHCP IP-, : «, DNS- »! DNS .

, . , BGP, IP-, . , , BGP, : «, IP-!», : „, , “.



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

DNS SEC. , , DNS, , . , , , , DNS SEC.

, , , . : , , , , , DoS — . .

Par conséquent, vous devez vous efforcer d'éviter des choses telles que les attaques SYN Flooding et les attaques RST qui vous permettent de déconnecter un utilisateur de réseau arbitraire. Ce sont des choses qui sont vraiment nuisibles à un bas niveau et qui sont difficiles à réparer à un haut niveau. Mais plus ou moins assurer l'intégrité et la confidentialité des données en utilisant le cryptage. Nous parlerons de la façon de procéder dans la prochaine conférence sur Cerberus.


La version complète du cours est disponible ici .

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 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 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?