Berkeley Sockets Interface ou simplementsockets, est unensemble normalisé de fonctions de communication lancé par l'université de Berkeley au début des années 1980 pour leurBerkeley Software Distribution (abr.BSD). 30 ans après son lancement, cetteinterface de programmation est proposée dans quasiment tous leslangages de programmation populaires (Java,C#,C++, etc.)[1].
La notion sur laquelle est construite cette interface sont lessockets (en français « interfaces de connexion » mais aussi « ports,points de connexion,connecteurs logiciels »)[2],[3] par lesquelles une application peut se brancher à unréseau et communiquer ainsi avec une autre application branchée depuis un autre ordinateur.
Unsocket représente uneprise 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 desprotocoles réseau; le plus fréquent sont lessocketTCP/IP[4]. La première interface de programmation (anglaisAPI pourapplication programming interface) mettant en œuvre lessocket a été développée par l'université de Berkeley pour leur Unix, dans les années 1980. C'est un des premiers produitsopen source de l'histoire[4].
La fonctionsocket 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 exempleTCP/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 fonctionconnect permet à un client de demander la connexion à un serveur, et la fonctionaccept permet à un serveur d'accepter cette connexion. Le programme serveur utilisera préalablement la fonctionlisten pour informer lelogiciel sous-jacent qu'il est prêt à recevoir des connexions. Une fonctionclose 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 fonctionssend etrecv servent respectivement à envoyer et à recevoir des informations. Une fonction auxiliairegethostbyname permet d'obtenir l'adresse IP d'une machine en interrogeant leDNS, adresse qui sera utilisée par d'autres fonctions de l'API[5].
Chaque socket possède untype et un ou plusieurs processus qui lui sont associés. Il est également caractérisé par ledomaine 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 :
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 :
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 communicationIP. 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 (lemulticast).
Un socket réseau se caractérise par la combinaison des éléments suivants :
bind.Les sockets du domaineUNIX sont un moyen decommunication inter-processus utilisant lesystème de fichiers commeespace de nommage[7]. Ils rendent l'accès à un même service (DBus,X.org, ...) pour plusieurs clients plus facile qu'avec de simplestubes nommés. La communication se produit entièrement dans lenoyau du système d'exploitation.
Il est possible de réguler l'accès à ces sockets à l'aide despermissions UNIX (un socket du domaine UNIX reste uninode dans lesystème de fichiers). Le serveur peut également déterminer l'UID des programmes qui se connectent[8], permettant de réaliser uneauthentification sans mot de passe[9].
En plus d'envoyer des données, ces processus peuvent envoyer desdescripteurs de fichiers sur un socket du domaine UNIX à l'aide des API « sendmsg » et « recvmsg »[10].
Les socketsraw 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 socketsraw est de développer de nouveaux protocoles de couche transport enespace utilisateur[11].
Les socketsraw sont nécessaires aux protocoles qui sont directement encapsulés dansIP, sans passer parTCP niUDP. On peut par exemple citer le protocole de gestion de groupes de multidiffusionIGMP, le protocole de routage dynamiqueOSPF, ainsi que le protocoleICMP utilisé par la commandeping
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).
QuandMicrosoft a publiéWindows XP en 2001, l'interfaceWinsock prenait en charge les socketsraw. La presse a alors critiqué Microsoft, en affirmant que les socketsraw n'étaient utilisées que par despirates pour fabriquer de toutes pièces des paquets trafiqués. Ceux-ci peuvent ainsi par exemple lancer des attaques de réinitialisation des connexionsTCP 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 socketsraw par Winsock dans unpatch qui ne pouvait pas être retiré et n'a pas offert d'assistance ou proposé de contournements aux applications qui les utilisaient[12].
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 » auhotfix de Microsoft apparaisse[13]. 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, socketraw 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 deGoogle s'en sert, par exemple[14].
