- Les protocoles IP et TCP
- Les protocoles SMTP et IMAP
Sommaire
Les protocoles IP et TCP
Via ce cour d'OpenClassRoom, on s'intéresse un peu plus en détails aux protocoles IP et TCP.
Il s'agit d'une prise de note personnelle, je vous invite à suivre le cour directement sur OpenClassRoom.
Le protocole IP
L'en-tête fait 20 octets, dont voici quelques détails:
- Version: IPv4 ou IPv6
- HLEN: la longueur de l'en-tête (en morceau de 4 octets), historiquement cela peut varier, mais aujourd'hui on est sur 20 octets.
- TOS: peu utilisé aujourd'hui, servait à donner une priorité à un paquet.
- Total length: nombre total d'octets dans le datagramme IP.
- IPID: un ID qui permet d'identifier le datagramme d'origine
- Flags: au nombre de trois, coder sur 1 bits, indique si le datagramme doit être fragmenté ou non (DF), indique aussi si le fragment est le dernier d'un datagramme (MF)
- Fragment Offset: la place du fragment dans le datagramme d'origine.
- TTL: durée de vie, ça permet de rejeter/détecter les paquets "perdus" dans le réseau (erreur de routage). On cherche à éviter la saturation.
- Protocol 4: indique le protocole utilisé dans la couche 4, souvent TCP/UDP.
- Checksum: une somme de contrôle pour vérifier l'intégrité des données.
La fragmentation
Le datagramme passe la couche 3, on parle alors de paquet. Ce paquet pour passer en couche 2 doit être "découper" en fonction du MTU. On parle de Fragmentation.
Pour fonctionner, la fragmentation à besoin de: IPID, du flags et du FO.
Ainsi les fragments ne sont pas transmis dans un ordre précis. Grâce à l'encapsulation, on va retrouver dans l'en-tête les informations nécessaires pour ne pas "perdre" la donnée.
Je vous invite à voir le cour, qui est nettement plus détaillé, les explications sont détaillées.
Le Fragment Offset
C'est ce paramètre qui va nous indiquer la place du fragment dans le datagramme d'origine.
Le facteur 8
Pour comprendre le FO, il faut avoir en tête d'où vient le facteur 8 que nous allons voir tout de suite:
Le Datagramme est codé sur 16bits, contrairement au FO qui est sur 13bit, soit 3bits de différence et donc un facteur de 8 (2^3).
Soit la règle suivante:
La taille des données d’un paquet IP doit obligatoirement être un multiple de 8, sauf pour le dernier fragment d’un datagramme fragmenté, ou d’un paquet qui n’a pas du tout été fragmenté.
Exemple simple
Des réseaux différents, avec un MTU identique.
Exemple avancé
Des réseaux différents, avec un MTU différents.
Personnellement c'est ce second exemple qui ma permis de bien comprendre comment calculer le FO.
Le scan de Ports
Grossièrement, cela consiste à déterminer quels sont les ports "ouverts" sur une machine, c'est à dire un port qui va "accepter" une connexion. Un peu comme une porte d'entrée.
Scanner les ports d'une machine qui ne vous appartient pas est illégale.
Ici, l'objectif est ludique est vise à apprendre le fonctionnement du protocole IP.
nmap (nmap.org) est un outils pratique pour scanner les ports d'une machine.
nmap -sS _ADRESSE_IP_<= scan env. 1 750 ports via un segment SYNnmap -sU _ADRESSE_IP_<= scan les ports UDP
Un scan de port permets de savoir:
- les versions des services
- identifier l'OS et sa version
- détecter un firewall
- les ports ouverts
- règles de filtrage
- ...
idle port scan
L'idée est de scanner une machine en "se cachant" derriere une autre.
Ici, on explique une méthode obsolete, qui ne fonctionne que sur les anciennes machines. L'idée encore une fois est d'étudier le protocole IP, rien de plus.
Aujourd'hui les OS utilisent un IPID aléatoire.
IPID était initialement implémenté de manière incrémentale. A chaque nouveau datagramme IPID augmentait de 1.
Il suffit donc d'envoyer les requêtes en se faisant passer pour la machine "x" et de "surveiller" les IPID de "x" afin de déterminer les réponses de la machine ciblée.
Connaître un protocol permet de l'exploiter au maximum. D'un point de vue Cybersécurité c'est donc un élément important.
Le protocole TCP
Le protocol TCP (Transmission Control Protocol) à l'avantage de "contrôler" si tous les octets sont bien envoyés/reçus, il a pour rôle de suivre la connexion, octet par octet.
L'en-tête
Quelques détails:
- Data Offset: à partir de quel octet les données applicatives commencent
- Reserved: pour les utilisations avancées du protocole
- Windows: permet de faire de la QOS (Quality of Service): permet de prioriser l'échange au détriment d'un autre. Plus d'infos: RFC 793
- Urgent Pointer: Si URG est à 1, indique le pointeur sur les données urgents. C'est quasiment jamais utilisé.
Le suivit d'une connexion
Le numéro d’acquittement est augmenté de 1 pour toute réponse à un segment où le flag SYN ou FIN est positionné.
Le cour propose des exercices de suivi de connexion. Pour ma part, j'ai bien compris le principe, j'ai tout de même fait une erreur d’inattention .
Pour le suivi d'une connexion via Wireshark, it-connect.fr propose un cour complémentaire à celui-ci.
On peut également trouver d'autres articles a propos de Wireshark:
- it-connect - Wireshark, découverte de l'interface
- it-connect - Wireshark, personnaliser l'interface
- it-connect - Wireshark, analyse d'une connexion TCP et de ses options
Le blind IP spoofing
Intéressons-nous aux limites du protocole TCP, en analysant une ancienne attaque: l'attaque de Noël.
Le spoofing de l'adresse IP n'est n'y plus n'y moins que de l'usurpation d'adresse IP.
Pourquoi l'attaque de Noël, car c'est le jour choisit par Kevin Mitnick - (page wiki) pour mettre en oeuvre son "idée". Le principe est simple "attaquer" quand l'ennemi est "moins" vigilant comme le soir de Noël par exemple. Car ici, il s'agit d'une attaque ciblée sur une personne en particulier Tsutomu Shimomura - (page wiki).
Ce type d'attaque à l'époque n’existait pas, mais à été théorisée par Robert Tappan Morris - (page wiki) dans "A Weakness in the 4.2BSD Unix TCP/IP Software", disponible ci-après.
A Weakness in the 4.2BSD Unix - TCP/IP Software - Robert T. Morris - AT&T Bell Laboratories Murray Hill, New Jersey 07974 - 25 février 1985 - ( fichier pdf - 11Ko)
L’objectif est de mettre en avant les limites du protocole TCP en matière de sécurité, notamment au sein du système 4.2BSD Unix. Voici un "condensé" de cet écrit (merci au Chat - Mistral AI pour son aide).
1. Contexte et problème
Le système 4.2BSD permet à certains systèmes de confiance d'exécuter des commandes sur d'autres systèmes via un réseau TCP/IP sans fournir de mot de passe.
Cette confiance peut être exploitée pour permettre à des utilisateurs de systèmes non fiables de se faire passer pour des utilisateurs de systèmes fiables
2. La vulnérabilité
Le serveur d'exécution à distance de 4.2BSD écoute les demandes de connexion TCP sur le port 514.
Il vérifie que l'hôte source est fiable en comparant l'ID de l'hôte source dans l'en-tête IP avec une liste de systèmes de confiance.
La faiblesse réside dans le fait que l'hôte source remplit lui-même l'ID de l'hôte source dans l'en-tête IP, et il n'y a pas de moyen de vérifier la véritable origine d'un paquet.
"The 4.2BSD Unix TCP/IP software is very flexible and convenient, but places too much trust in a protocol which provides very little security.
Exploitation de la Vulnérabilité
Un utilisateur avec des privilèges peut créer des paquets IP avec des ID d'hôte source incorrects.
En utilisant une socket brute (SOCK_RAW), un utilisateur peut manipuler les structures de données du noyau pour modifier le numéro de protocole et l'ID de l'hôte source.
Cela permet de créer et de gérer une extrémité d'un circuit TCP sans utiliser le logiciel TCP du noyau Unix.
Un circuit TCP est une connexion bidirectionnelle entre deux points de terminaison (ou "sockets") sur un réseau. Chaque extrémité d'un circuit TCP est identifiée par une combinaison d'une adresse IP et d'un numéro de port.
Une extrémité d'un circuit TCP est l'un des deux points de terminaison de la connexion. Chaque extrémité est responsable de la gestion de sa partie de la communication, y compris l'établissement de la connexion, l'envoi et la réception des données, et la fermeture de la connexion.
Solutions Proposées
Rendre les numéros de séquence plus aléatoires pour rendre la prédiction plus difficile. Ce qui a priori le cas à notre époque.
Exiger que les réseaux fournissent des ID d'hôte source authentiques.
Ne faire confiance qu'aux hôtes sur le même réseau physique et modifier les passerelles pour rejeter les paquets qui prétendent provenir de réseaux non directement connectés.
- 0. On empêche la machine légitime de répondre via du SYN FLOOD.
- 1. On prend connaissance de l'ISN du serveur à un instant T.
- 2. On envoie un segment SYN avec IP source de la machine légitime
- 3. On envoie un segment ACK avec le bon numéro Acquittement.
J'ai résumé l'information, le cour lui détails étape par étape.
A partir de là, le serveur valide la connexion.
Cependant, on ne sera en mesure que d'envoyé un seul paquet. C'est toutefois suffisant pour reconfigurer un programme rsh, il permettait de se connecter à distance si la machine est autorisée. Via la commande echo ++ >/.rhosts, on écrase la configuration des machines "autorisées" par ++ <== n'importe qu'elle machine.
Cette attaque est aujourd'hui complètement obsolète.
En 2016, une attaque "similaire", plus complexe à été mise au point: Off-Path TCP Exploits.
Je l’étudierai plus tard en détails.
Les protocoles SMTP et IMAP
La suite du cour, nous invite à nous intéresser aux protocoles de messagerie. Enfin, surtout au deux principaux que sont SMTP et IMAP.
Ayant déjà mis en place un véritable serveur mail, son "univers" et bien plus complexe, mais on est ici pour apprendre les bases .
Le protocole SMTP
Vous avez dit SMTP? Oui, pour Simple Mail Transfert Protocol, soit un protocole simple de transfert de courrier.
Ce protocol vise à permettre l'échange de courriers, élaboré dans les années 1970, il n'a pas été conçus pour être utilisé de manière massive comme c'est le cas aujourd'hui.
De ce fait, on est obligé de lui accoler d'autres mécanismes/protocoles afin de le sécuriser. Ce qui a pour conséquence de rendre l'ensemble complexe.
Par exemple, pour le port 25 par défaut, on va utiliser le port 465 pour passer par le protocol SSL.
Je n'ai pas continué la suite du cour, j'ai lu en diagonale, j'ai fais et réussi le "Quizz" tout de même.
La suite du cour ne traite pas des protocols SMTP et IMAP en particulier, c'est plus un tutoriel très basique et incomplet de la mise en place d'une serveur mail. En décalage totale avec la première partie du cour.
C'est un projet complexe et très intéressant, j'ai deja mis en place ce genre de service, mais ici ce n'est pas mon objectif.