Cours MIT "Sécurité des systèmes informatiques". Conférence 12: Sécurité du réseau, partie 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

Étudiant: vous avez peut - être toujours un problème de conflit d'intérêts car vous pouvez utiliser 32 bits pour les adresses de pairs et vous disposez de nombreux ports pour chacun d'eux. Vous avez probablement un conflit de numéros de séquence de toutes ces connexions que vous obtenez?

Professeur: il s'avère que ces numéros de séquence sont spécifiques à l'adresse IP et au numéro de port de la paire source / destination. Donc, s'il s'agit de ports différents, ils n'interfèrent pas du tout. Plus précisément, les ports ont des numéros de série inférieurs.



Etudiant: si les numéros de série sont globaux, l'attaquant peut-il se connecter à d'autres clients?

Professeur: oui, c'est un bon point. En fait, si le serveur augmente le numéro de série, par exemple, de 64 Ko pour chaque connexion, vous vous connectez au serveur, puis 5 autres personnes s'y connectent, et ici vous pouvez organiser une attaque. Dans une certaine mesure, vous avez raison, c'est un peu gênant. D'un autre côté, vous pourriez probablement faire en sorte qu'un colis de la dernière ligne de S-> A soit livré immédiatement avant ce colis dans la première ligne de C-> S. Si vous envoyez vos paquets les uns après les autres, il y a de fortes chances qu'ils arrivent également sur le serveur un par un.

Le serveur recevra S-> A et répondra avec ce numéro de séquence (SN). Il sera différent de celui des (SN) sur la deuxième ligne, mais avec le numéro de série qui le suivra immédiatement. Et puis vous saurez exactement quel numéro de séquence (SN) doit être inclus dans le troisième paquet de votre séquence.
Par conséquent, je pense que ce n'est pas un moyen très fiable de se connecter au serveur, il est basé sur des hypothèses. Mais si vous organisez soigneusement vos colis de la bonne manière, vous pouvez facilement deviner la séquence. Ou peut-être essaierez-vous plusieurs fois et vous aurez de la chance.

Étudiant: même si les nombres sont générés par hasard, vous devez deviner l'un des 4 milliards de nombres possibles. Ce n'est pas trop, non? Je pense que d'ici un an, vous pourrez probablement pénétrer ce réseau.

Professeur: oui, vous avez absolument raison. Vous ne devez pas trop compter sur TCP en termes de sécurité. Parce que vous avez raison, ce ne sont que 4 milliards de suppositions. Et vous pouvez probablement envoyer beaucoup de paquets pendant la journée si vous avez une connexion assez rapide.

Nous avons donc ici une sorte d'argument intéressant sur la non-fiabilité de TCP, car nous n'avons que 32 bits. Nous ne pouvons en aucun cas le sécuriser. Mais je pense que de nombreuses applications qui s'appuient suffisamment sur ce protocole ne pensent pas du tout à la sécurité, et cela devient vraiment un problème.

Mais vous avez absolument raison. En pratique, vous souhaitez utiliser une sorte de cryptage en plus pour obtenir des garanties plus sérieuses que personne n'a falsifié vos données, car vous utilisez des clés de cryptage de plus de 32 bits. Dans la plupart des cas, cela est toujours efficace pour empêcher la falsification de la connexion TCP.

Voyons maintenant pourquoi c'est mauvais si les gens peuvent simuler des connexions TCP à partir d'adresses arbitraires?

L'une des raisons pour lesquelles cela est mauvais est que cela peut affecter l'autorisation basée sur l'adresse IP lorsque le serveur vérifie l'adresse d'où provient la demande. Si un serveur décide d'autoriser ou de refuser la connexion en fonction de l'adresse IP, cela pourrait potentiellement être un problème pour un attaquant qui a falsifié la connexion à partir d'une adresse source arbitraire.

Ainsi, un exemple où c'était un problème, aujourd'hui ce problème est essentiellement résolu, est l'utilisation d'une famille de commandes r, telles que rlogin. Auparavant, vous pouviez exécuter quelque chose comme rlogin pour un ordinateur sur, disons, athena.dialup.mit.edu. Et si votre connexion provient de l'hôte MIT, cette commande rlogin réussira si vous dites: "oui, je suis l'utilisateur d'Alice sur cet ordinateur, permettez-moi de me connecter en tant qu'utilisateur d'Alice à un autre ordinateur." Et cette opération sera autorisée, car tous les ordinateurs du réseau mit.edu sont dignes de confiance pour faire de telles déclarations.

Je dois dire que l'accès à distance n'a jamais eu ce problème. Ce composé a utilisé Cerberus dès le début. Mais d'autres systèmes, bien sûr, avaient de tels problèmes. Et ceci est un exemple d'utilisation d'une adresse IP dans un mécanisme d'authentification de connexion lorsque le système vérifie si le client appelant le serveur est fiable. Donc, ce qui était un problème n'est plus un problème. Mais s'appuyer sur IP semble toujours être un mauvais plan.



Maintenant que rlogin n'est plus utilisé, il a récemment été remplacé par le shell SSH sécurisé, qui est un excellent protocole de couche réseau. D'un autre côté, il existe de nombreux autres exemples de protocoles qui reposent sur une autorisation basée sur l'adresse IP. L'un d'eux est SMTP. Lorsque vous envoyez des e-mails, vous utilisez SMTP pour parler à un serveur de messagerie afin d'envoyer des messages. Pour éviter le spam, de nombreux serveurs SMTP n'acceptent que les messages entrants provenant d'une adresse IP source spécifique. Par exemple, le serveur de messagerie Comcast accepte uniquement le courrier provenant d'adresses IP Comcast. Il en va de même pour les serveurs de messagerie MIT - ils n'accepteront que le courrier provenant d'adresses IP MIT. Mais nous avions au moins un serveur qui ne fonctionnait pas comme il se doit, utilisant l'authentification IP.

Tout n'est pas si mal ici. Dans le pire des cas, vous enverrez du spam via le serveur de messagerie. C'est probablement pourquoi ils utilisent toujours rlogin, alors que les choses qui vous permettent de vous connecter à un compte arbitraire ont cessé d'utiliser l'authentification basée sur IP.

Alors pourquoi un tel mécanisme d'authentification est-il un mauvais plan? Supposons que certains serveurs utilisent rlogin. Que feriez-vous pour attaquer? Quel mal pourrait arriver?

Étudiant: un attaquant peut simplement pénétrer dans votre ordinateur, truquer un utilisateur qui va entrer dans le réseau avec votre nom d'utilisateur et accéder au réseau.

Professeur: oui, fondamentalement, un attaquant prend le contrôle d'un ordinateur. Il synthétise des données qui ressemblent à un ensemble valide de commandes rlogin qui disent: «Connectez-vous en tant qu'utilisateur et exécutez cette commande dans mon shell Unix».

Vous synthétisez ces données (SNc + 1), montez toute l'attaque et envoyez ces données comme si un utilisateur légitime avait interagi avec le client rlogin, puis vous pouvez continuer.



Eh bien, c'est l'une des raisons pour lesquelles vous ne voulez pas que vos numéros de séquence TCP soient devinés. Un autre problème est que ces attaques de réinitialisation réinitialisent l'attaque. De la même manière que nous pourrions envoyer un paquet SYN, si nous connaissons le numéro de série de quelqu'un, nous pouvons envoyer un paquet de réinitialisation de la même manière.

Nous avons brièvement mentionné un client légal qui envoie un faux paquet de réinitialisation de connexion qu'un attaquant a établi. Un attaquant pourrait tout aussi bien essayer d'envoyer des paquets de rejet pour une connexion existante s'il sait que votre numéro de séquence est dans cette connexion. En fait, il n'est pas clair de l'ampleur de ce problème.

À un certain niveau, vous devez supposer que toutes vos connexions TCP peuvent être interrompues dans tous les cas et à tout moment, c'est-à-dire qu'il ne semble pas que votre réseau soit fiable. Par conséquent, vous devriez peut-être vous attendre à une déconnexion.

Dans le cas où les routeurs "parlent" entre eux, cette hypothèse est particulièrement critique. Si vous avez de nombreux routeurs qui communiquent entre eux à l'aide de certains protocoles de routage, il existe des connexions physiques entre eux. Mais en plus de ces connexions physiques, ils communiquent via un protocole réseau qui fonctionne via TCP. En fait, dans chacune de ces connexions physiques que les routeurs utilisent pour échanger des informations de routage, une session TCP est lancée. Le protocole BGP est utilisé ici, dont nous parlerons plus tard.

Ce protocole BGP utilise le fait que si la connexion TCP est active, la connexion physique est également active. Donc, si une connexion TCP est rompue, le routeur pense que la connexion est rompue et commence à recompter toutes ses tables de routage.



Par conséquent, si l'adversaire veut organiser une sorte d'attaque par déni de service DoS, il peut essayer de deviner les numéros de série de ces routeurs et abandonner ces sessions. Si la session TCP entre les deux routeurs est désactivée, les deux routeurs considèrent que cette connexion est morte et ils doivent recompter toutes les tables de routage, ce qui entraînera la modification des itinéraires. Après cela, l'attaquant peut réinitialiser une autre connexion, etc.

Ainsi, il s'agit d'une attaque quelque peu alarmante, et non pas parce qu'elle viole le secret de quelqu'un d'autre et ainsi de suite, du moins pas directement, mais parce qu'elle cause vraiment beaucoup de problèmes d'accès pour les autres utilisateurs du système.

Étudiant: si vous êtes un attaquant et que vous souhaitez organiser une attaque ciblée contre un utilisateur spécifique, pourriez-vous simplement continuer à envoyer des demandes de connexion au serveur au nom de son adresse IP et l'obliger à réinitialiser la connexion au serveur?

Professeur: supposons que j'utilise Gmail et que vous vouliez m'empêcher de recevoir des informations de Gmail, alors envoyez simplement des paquets à ma machine, en faisant semblant de provenir d'un serveur Gmail. Dans ce cas, vous devez deviner les numéros de port source et destination corrects.

Le numéro de port de destination est probablement 443 car j'utilise HTTPS. Mais le numéro de port source sera une chose aléatoire de 16 bits. De plus, les numéros de série varient. Par conséquent, si vous ne devinez pas le numéro de séquence qui se trouve dans ma fenêtre TCP et qui est des dizaines de kilo-octets, vous ne réussirez pas.

Il faut donc deviner pas mal de choses. Il n'y a pas d'accès Oracle ici. Vous ne pouvez pas simplement demander au serveur le numéro de série de ce type. C'est la raison pour laquelle cela ne fonctionnera pas non plus.

Ainsi, beaucoup de ces problèmes ont été corrigés, y compris cette chose basée sur RST, en particulier pour les routeurs BGP. Il y avait en fait deux corrections drôles. Une chose montre vraiment comment vous pouvez exploiter des choses existantes ou les utiliser pour résoudre des problèmes spécifiques. Il utilise la propriété que ces routeurs communiquent uniquement entre eux et non avec quiconque sur le réseau. Par conséquent, si le paquet n'arrive pas à partir d'un routeur situé à l'autre extrémité de la connexion, ce paquet est rejeté.

La mise en œuvre réussie des développeurs de ces protocoles est une merveilleuse zone dans le package appelé la "durée de vie", ou TTL. Il s'agit d'un champ de 8 bits qui est décrémenté par chaque routeur pour garantir que les paquets ne se retrouvent pas dans une boucle infinie. La valeur TTL maximale est de 255 et diminue encore.

Alors qu'est-ce que je fais ces protocoles intelligents? Ils rejettent tout paquet dont la valeur TTL n'est pas égale à 255. Parce que si le paquet a une valeur de 255, il ne peut provenir que d'un routeur de l'autre côté de cette connexion. Et si l'adversaire tente d'injecter tout autre paquet dans la connexion BGP existante, il aura une valeur TTL inférieure à 255, car cette valeur sera réduite par d'autres routeurs situés le long du chemin de routage, y compris ce routeur. Par conséquent, ce colis sera simplement rejeté par le destinataire.

C'est donc un exemple d'une combinaison intelligente de techniques rétrocompatibles qui résolvent ce problème très spécifique.



Étudiant: le routeur inférieur droit n'envoie-t - il pas quelque chose avec un TTL de 255?

Professeur: Ceci est un routeur physique. Et il sait que ce sont des connexions distinctes, donc il regarde à la fois TTL et d'où vient le paquet. Donc, si le paquet provenait du routeur supérieur gauche, il ne l'acceptera pas pour une connexion TCP entre lui et le routeur supérieur droit.

Pour la plupart, ces routeurs font confiance à leurs voisins immédiats, et ce processus peut être contrôlé à l'aide du mécanisme de routage multi-chemins Auto Pan.

D'autres correctifs pour BGP consistent à implémenter une certaine forme d'en-tête d'authentification, y compris un en-tête d'authentification MD5. Mais en réalité, les développeurs se sont concentrés sur cette application particulière, pour laquelle une attaque de réinitialisation est particulièrement critique.

Ce problème persiste aujourd'hui. S'il y a une connexion à long terme et que je veux l'interrompre, je n'ai qu'à envoyer un grand nombre de paquets RST, environ des centaines de milliers, mais probablement pas 4 milliards. Parce que les serveurs sont en fait quelque peu vulnérables au numéro de séquence qu'ils acceptent pour la réinitialisation.

Il peut s'agir de n'importe quel package dans une fenêtre spécifique. Dans ce cas, l'attaquant pourrait rompre cette connexion sans trop d'effort. C'est encore un problème pour lequel il n'y a pas vraiment de bonne solution.

Et la dernière mauvaise chose qui peut arriver en raison de la prévisibilité des numéros de séquence est l'injection de données dans les connexions existantes. Supposons que nous ayons un protocole hypothétique similaire à rlogin, qui n'effectue pas réellement d'authentification basée sur IP, vous devez donc entrer votre mot de passe pour vous connecter.

Le problème est que dès que vous entrez votre mot de passe, votre connexion TCP est peut-être simplement établie et peut accepter des données arbitraires. L'attaquant a donc juste besoin d'attendre que l'un de vous se connecte à l'ordinateur en entrant votre mot de passe.

L'attaquant ne sait pas quel est le mot de passe, mais dès que vous établissez une connexion TCP, il essaiera immédiatement de deviner votre numéro de série et de saisir des données dans votre connexion existante. Donc, si je peux deviner correctement votre numéro de série, cela me permettra de prétendre que ce n'est pas moi, mais vous avez entré une commande après avoir été correctement authentifié avec un mot de passe.



Tout cela indique pourquoi vous ne voulez vraiment pas vous fier à ces numéros de séquence 32 bits dans un sens de sécurité. Mais voyons ce que les piles TCP modernes font réellement pour atténuer ce problème. Une approche du problème que nous aborderons dans les 2 prochaines conférences consiste à implémenter un certain degré de sécurité au niveau de l'application. À ce niveau, nous utiliserons la cryptographie pour authentifier, crypter, signer et vérifier les messages sans grande implication TCP.

Certaines des applications existantes aident également à résoudre les problèmes de sécurité, ou du moins rendent plus difficile pour un attaquant d'exploiter ces problèmes. Les gens mettent cela en pratique aujourd'hui, par exemple, sur Linux et Windows, en conservant des numéros de séquence initiaux différents pour chaque paire source / destination.

Ainsi, la plupart des implémentations TCP SYN calculent toujours ce numéro de séquence ISN initial de la même manière que nous l'avons fait auparavant. C'est donc un vieux style ISN, disons-le. Et afin de générer réellement un numéro de série pour une connexion particulière, nous ajoutons à cet ISN à l'ancienne un décalage aléatoire de 32 bits. Autrement dit, nous y ajoutons une fonction - quelque chose comme une fonction de hachage ou SHA-1, ou quelque chose de mieux.



Cette fonctionnalité comprend l'adresse IP source, le numéro de port source, l'adresse IP de destination, le numéro de port de destination et une clé secrète que seul le serveur connaît. Ainsi, nous créons une bonne opportunité pour toute connexion particulière de déterminer l'adresse IP et le port pour la paire source / destination, tout en préservant toutes les bonnes propriétés de cet ancien algorithme d'attribution de numéro de séquence de style.

Mais si vous disposez de connexions provenant de différents ensembles source / destination, rien ne vous permet de connaître la valeur exacte du numéro de série d'un autre ensemble de connexions. En fait, vous devez deviner cette clé pour calculer cette valeur.

J'espère que le noyau du système d'exploitation serveur stocke cette clé quelque part dans sa mémoire et ne la donne à personne. C'est ainsi que la plupart des piles TCP résolvent aujourd'hui ce problème particulier dans le domaine des numéros de séquence 32 bits courants. Ce n'est pas trop grand, mais ça marche.

Étudiant: pourriez-vous répéter cela? À propos de l'unicité de la clé ...

Professeur: lorsque ma machine démarre, ou lorsqu'une machine démarre, elle génère une clé aléatoire. Chaque fois que vous le rechargez, il génère une nouvelle clé. Cela signifie que chaque fois que les numéros de série d'une paire source / destination particulière changent avec la même fréquence de décalage. Ainsi, pour une paire source / destination donnée, les paramètres de fonction sont fixes. Vous suivez donc la séquence lorsque les nombres évoluent en fonction de vos numéros de séquence initiaux pour les nouveaux composés, changeant selon un algorithme spécifique. Ainsi, une protection contre l'injection d'anciens paquets des connexions précédentes dans de nouvelles connexions est fournie, ainsi qu'une protection contre la réaffectation des paquets.

La seule chose pour laquelle nous avons besoin de ce numéro de série de l'ancien échantillon est le choix de l'algorithme pour éviter les problèmes avec ces paquets en double. Plus tôt, nous avons considéré que si vous obtenez un numéro de série pour une connexion A: A -> S: SYN (...), vous pouvez ensuite tirer une conclusion sur le numéro de série de la connexion ACK (SN).



, 32- , F. , , .

: ?

: , . F, , F , , , .

: , …

: , F - -, . -, , . , , , , . , F .

, TCP, . , , - .

, . , TCP , DNS, . , DNS UDP – . UDP — , , . UDP . , , , . , , . DNS-. DNS?



, DNS- C: C53 -> S53 mit.edu, 53.

S: S53 -> C53 IP-, – .

, , , , . , mit.edu, .

, DNS- . IP-, , . IP- mit.edu IP-. , , , , . , .



, , . IP-. , , DNS- . , , IP- mit.edu.

: , , ?

: , . , , . DNS-, , . 2 . — , 16 . , 16 . ID, 16 , .

, , 32 . , , , , .



, , .

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

origin. DNS , IP-, : „, “. , , , , , , . , , ?

, – DNS- , . , , . -, DNS-, . , DNS SEC, , , DNS- . DNS- , , , – , .

DNS SEC , NSEC. , . , NSEC , foo.mit.edu, goo.mit.edu, , .



, , , , , , „, “.

. , foo.mit.edu -> goo.mit.edu — >…. : » , , gooa.mit.edu". , , .

, DNS . NSEC3, – - , - .

52:00

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


.

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?