Aller au contenu

Berkeley sockets

Un article de Wikipédia, l'encyclopédie libre.

Berkeley Sockets Interface ou simplement sockets, est un ensemble normalisé de fonctions de communication lancé par l'université de Berkeley au début des années 1980 pour leur Berkeley Software Distribution (abr. BSD). 30 ans après son lancement, cette interface de programmation est proposée dans quasiment tous les langages de programmation populaires (Java, C#, C++, etc.)[1].

La notion sur laquelle est construite cette interface sont les sockets (en français « interfaces de connexion » mais aussi « ports, points de connexion, connecteurs logiciels »)[2],[3] par lesquelles une application peut se brancher à un réseau et communiquer ainsi avec une autre application branchée depuis un autre ordinateur.

Fonctionnalités

[modifier | modifier le code]

Un socket représente une prise par laquelle une application peut envoyer et recevoir des données. Cette prise permet à l'application de se brancher sur un réseau et communiquer avec d'autres applications qui y sont branchées. Les informations écrites sur une prise depuis une machine sont lues sur la prise d'une autre machine, et inversement. Il existe différents modèles de prises, en fonction des protocoles réseau; le plus fréquent sont les socket TCP/IP[4]. La première interface de programmation (anglais API pour application programming interface) mettant en œuvre les socket a été développée par l'université de Berkeley pour leur Unix, dans les années 1980. C'est un des premiers produits open source de l'histoire[4].

La fonction socket de cette API sert à créer un certain type de prise. Le type de prise sera choisi en fonction de la technologie de communication à utiliser (par exemple TCP/IP). L'API permet à un logiciel serveur de servir plusieurs clients simultanément.

Une connexion est établie entre le client et le serveur en vue de permettre la communication. La fonction connect permet à un client de demander la connexion à un serveur, et la fonction accept permet à un serveur d'accepter cette connexion. Le programme serveur utilisera préalablement la fonction listen pour informer le logiciel sous-jacent qu'il est prêt à recevoir des connexions. Une fonction close permet de terminer la connexion. Lorsqu'un des deux interlocuteurs termine la connexion, l'autre est immédiatement avisé[5].

Une fois la connexion établie, les fonctions send et recv servent respectivement à envoyer et à recevoir des informations. Une fonction auxiliaire gethostbyname permet d'obtenir l'adresse IP d'une machine en interrogeant le DNS, adresse qui sera utilisée par d'autres fonctions de l'API[5].

Chaque socket possède un type et un ou plusieurs processus qui lui sont associés. Il est également caractérisé par le domaine de communication dans lequel il se trouve. Ce dernier est une abstraction qui permet de regrouper les processus ayant des propriétés communes et communiquant par l'intermédiaire de sockets. Normalement, un socket ne peut échanger des données qu'avec un socket se trouvant dans le même domaine de communication.

La communication inter-processus de 4.3BSD supportait trois domaines de communication :

  • le domaine Unix dans lequel deux processus se trouvant sur la même station Unix uniquement peuvent communiquer[6] ;
  • le domaine Internet pour les processus utilisant le protocole TCP/IP pour communiquer entre eux ;
  • le domaine NS pour les processus échangeant des données en utilisant le protocole standard de Xerox.

Types de sockets

[modifier | modifier le code]
Cette section ne cite pas suffisamment ses sources (décembre 2016). 
Pour l'améliorer, ajoutez des références de qualité et vérifiables (comment faire ?) ou le modèle {{Référence nécessaire}} sur les passages nécessitant une source.

Les différents types de sockets dépendent de quelques propriétés visibles par le programmeur. Rien n'empêche deux sockets de types différents de communiquer entre eux si le protocole utilisé le supporte — même si les processus sont supposés communiquer uniquement par des sockets de même type.

Il existe généralement quatre types de sockets :

  • Un socket stream permet une communication bidirectionnelle, sûre, séquencée et un flux de données sans duplication pouvant entraîner une fragmentation des paquets transmis. Dans le domaine Internet, il s'agit du protocole TCP.
  • Un socket datagram permet une communication bidirectionnelle qui n'est pas séquencée, pas sûre, et peut éventuellement entraîner une duplication des données. Un processus utilisant ce type de socket peut donc recevoir les données dans un ordre différent de l'ordre de départ. Dans le domaine Internet, il s'agit du protocole UDP.
  • Un socket raw permet d'accéder au contenu brut des paquets de données. Les sockets raw ne sont pas destinés aux utilisateurs courants — seul l'utilisateur root peut y avoir accès sur la plupart des systèmes UNIX — et sont utilisés par exemple pour analyser le trafic d'un réseau.
  • Un socket sequenced packet, qui ressemble à un socket stream sauf qu'il n'utilise pas de fragmentations de paquets.

Socket réseau

[modifier | modifier le code]
Cette section ne cite pas suffisamment ses sources (décembre 2016). 
Pour l'améliorer, ajoutez des références de qualité et vérifiables (comment faire ?) ou le modèle {{Référence nécessaire}} sur les passages nécessitant une source.

Les sockets réseau sont utilisés pour communiquer avec des services hébergés sur d'autres machines (site web, imprimante réseau, ...). Ils sont utilisés dans le cadre d'une communication IP. Selon la manière dont ils sont configurés, ils peuvent émettre et recevoir des messages vers et depuis plusieurs ordinateurs sur le même réseau (le multicast).

Un socket réseau se caractérise par la combinaison des éléments suivants :

  • Adresse locale : Coordonnées du socket pour les autres ordinateurs, il s'agit en général d'une adresse IP et d'un numéro de port. Ce numéro de port permet au système d'exploitation de rediriger les paquets entrant vers le bon programme (navigateur web, ...). L'adresse locale est définie à l'aide de la fonction bind.
  • Adresse distant : Analogue à l'adresse locale pour l'ordinateur distant. Cette fois, le numéro de port sera en général un des ports connus (80 pour HTTP, ...).
  • Un protocole de la couche réseau (IPv4, IPv6, ...), il définit comment est adressé le réseau et le routage des paquets.
  • Un protocole de la couche transport (TCP, UDP, ...), il définit comment sont échangés les données. Certains comme TCP impose l'établissement d'une connexion et vérifie l'acheminent des paquets. D'autres comme UDP envoie juste le paquet sans garantir son acheminement, ni l'établissement d'une connexion.

Socket UNIX

[modifier | modifier le code]

Les sockets du domaine UNIX sont un moyen de communication inter-processus utilisant le système de fichiers comme espace de nommage[7]. Ils rendent l'accès à un même service (DBus, X.org, ...) pour plusieurs clients plus facile qu'avec de simples tubes nommés. La communication se produit entièrement dans le noyau du système d'exploitation.

Il est possible de réguler l'accès à ces sockets à l'aide des permissions UNIX (un socket du domaine UNIX reste un inode dans le système de fichiers). Le serveur peut également déterminer l'UID des programmes qui se connectent[8], permettant de réaliser une authentification sans mot de passe[9].

En plus d'envoyer des données, ces processus peuvent envoyer des descripteurs de fichiers sur un socket du domaine UNIX à l'aide des API « sendmsg » et « recvmsg »[10].

Socket raw

[modifier | modifier le code]

Les sockets raw reçoivent les paquets bruts avec leur en-tête, et elles n'ajoutent automatiquement un en-tête lorsque l'on envoie les paquets que si on le demande dans une option de la socket. Une utilisation possible des sockets raw est de développer de nouveaux protocoles de couche transport en espace utilisateur[11].

Les sockets raw sont nécessaires aux protocoles qui sont directement encapsulés dans IP, sans passer par TCP ni UDP. On peut par exemple citer le protocole de gestion de groupes de multidiffusion IGMP, le protocole de routage dynamique OSPF, ainsi que le protocole ICMP utilisé par la commande ping[12].

Enfin, on peut s'en servir pour créer des paquets TCP ou UDP inhabituels. En particulier, un pirate informatique pourra contrefaire des paquets dans l'intention de nuire ou de s'introduire dans un système (voir plus bas).

Les sockets raw, un outil de piratage ?

[modifier | modifier le code]

Quand Microsoft a publié Windows XP en 2001, l'interface Winsock prenait en charge les sockets raw. La presse a alors critiqué Microsoft, en affirmant que les sockets raw n'étaient utilisées que par des pirates pour fabriquer de toutes pièces des paquets trafiqués. Ceux-ci peuvent ainsi par exemple lancer des attaques de réinitialisation des connexions TCP en cours, en créant des segments TCP contenant le bit RST (reset). Trois ans plus tard, Microsoft a, sans l'annoncer, limité la prise en charge des sockets raw par Winsock dans un patch qui ne pouvait pas être retiré et n'a pas offert d'assistance ou proposé de contournements aux applications qui les utilisaient[13].

On peut s'interroger sur l'opportunité de mettre ainsi des bâtons dans les roues des pirates, sachant qu'un informaticien déterminé trouvera toujours le moyen de « forger » (contrefaire) des paquets. De fait, il n'a fallu que quelques jours pour qu'un « correctif » au hotfix de Microsoft apparaisse[14]. Les paquets réseau ne sont en effet jamais que des suites arbitraires d'octets, le vrai problème des attaques de type RST se niche dans le protocole TCP lui-même et pas dans le moyen pratique de contrefaire les paquets, socket raw ou autre.

Par ailleurs, il existe des utilisations légitimes de certains paquets « forgés », même dans le cas d'un paquet TCP ayant le bit RST. Le mécanisme d'équilibrage de charge des serveurs de Yahoo! et de Google s'en sert, par exemple[15].

Notes et références

[modifier | modifier le code]
  1. ↑ (en) Jean J. Labrosse; Jack G Ganssle; Robert Oshana; et Colin Walls; Embedded Software: Know It All, Elsevier, 2008, (ISBN 9780750685832)
  2. ↑ « Le Grand Dictionnaire terminologique », sur www.granddictionnaire.com (consulté le )
  3. ↑ « Termium », sur www.btb.termiumplus.gc.ca (consulté le )
  4. ↑ a et b (en) Michael J. Donahoo; Kenneth L. Calvert; TCP/IP Sockets in C: Practical Guide for Programmers, Morgan Kaufmann, 2009, (ISBN 9780123745408)
  5. ↑ a et b M. Tim Jones; Gnu/Linux Application Programming, Cengage Learning, 2005, (ISBN 9781584503712)
  6. ↑ Les processus communiquant via NFS ne font pas partie de ce domaine.
  7. ↑ (en) « unix(7) - Linux man page », sur linux.die.net (consulté le )
  8. ↑ (en) « 16.3. UNIX domain socket authentication », sur docs.fedoraproject.org (consulté le )
  9. ↑ (en) « Authentication Plugin - Unix Socket », sur MariaDB KnowledgeBase (consulté le )
  10. ↑ (en) « Section 17.4.  Passing File Descriptors », sur poincare.matf.bg.ac.rs (consulté le )
  11. ↑ (en) Linux man page raw(7)
  12. ↑ (en) Raw IP Networking FAQ
  13. ↑ (en) Microsoft Tightens the Noose on Raw Sockets, 23 avril 2005
  14. ↑ (en) Neeharika Buddha; Denial of Service attack, 22 octobre 2009
  15. ↑ (en) Nicholas Weaver; Robin Sommer; et Vern Paxson; Detecting Forged TCP Reset Packets, 23 février 2009

Annexes

[modifier | modifier le code]

Articles connexes

[modifier | modifier le code]

Liens externes

[modifier | modifier le code]
Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Berkeley_sockets&oldid=216043969 ».