Retrouvez cet article dans : Linux Magazine 91

Beaucoup d’entre vous connaissent l’IRC et l’utilisent fréquemment pour communiquer autour de la communauté du Libre. Je me propose de faire une explication technique de l’IRC, après avoir fait un bref historique de ce dernier.

Avant-propos

Cet article ne se veut en aucun cas être un guide de l’utilisateur, mais permet d’expliquer quels sont les principes de l’IRC et son fonctionnement au niveau protocolaire et serveurs. Il est recommandé d’avoir des notions d’IRC.

1. Qu’est-ce que l’IRC ?

IRC est un programme écrit initialement en 1988 par Jarkko Oikarien, alias WiZ, inspiré de Bitnet Relay Chat, dont le but est de relier des serveurs de différentes localités par Internet afin de permettre des échanges textuels entre des gens à travers le monde. Au début, un seul réseau existait réunissant principalement des universitaires. Chaque serveur relié était indépendant, le réseau unique IRC était anarchique et les IRC Opérateurs avaient peu de pouvoir. Chaque serveur pouvait linker avec d’autres, dans la mesure où ces derniers étaient reconnus par une H-line (les désignant comme hub). Des discussions étaient lancées pour essayer de restreindre les acceptations de serveurs, mais un serveur nommé " Eris " était contre et voulait linker avec n’importe qui. Ce fut la première utilisation d’une Q-line (ligne dans la configuration refusant la connexion d’un serveur) contre Eris. Il delinka et créa le réseau Anet (Anarchy Network), qui eut peu de succès et succomba très rapidement. Par la suite, de plus en plus de serveurs furent lancés, et beaucoup étaient rejetés. Un réseau se créa parallèlement, Undernet (Underground Network), et IRCD, le programme développé par Jarkko Oikarien et utilisé sur IRCnet, fut cloné pour la première fois en " IRCU ". IRCD était, à l’époque, à la version 2.7 et venait à peine d’acquérir les salons ‘#’. Dalnet naquit également. Cependant, en été 1996, les désaccords continuèrent dans le réseau IRCnet. Le premier était sur la question des abus suite aux netsplits qui n’étaient pas négligeables (takeovers et prises d’identité). Deux solutions furent alors envisagées : Le Nick/Channel Delay, qui empêchait de prendre un pseudo ou de joindre un salon supprimé X minutes avant sa suppression, et le timestamp, qui marquait chaque user et salon de son heure de création et qui, lors du link d’un serveur, si deux users avaient le même pseudo, déconnectait le plus jeune connecté, et qui, si jamais deux salons n’avaient pas le même timestamp, redonnait tous les paramètres du plus vieux, notamment en enlevant le statut d’opérateur des opérateurs du plus jeune salon. Le second désaccord résidait dans le pouvoir des IRC Opérateurs. Les Européens cherchaient à laisser les salons s’autogérer et à donner le moins de pouvoir aux IRC Opérateurs, alors que les IRC Opérateurs des États-Unis refusaient de perdre leur pouvoir de /kill (déconnecter un user d’un serveur). Ceci créa une frontière Atlantique. En effet, un gros hub des USA partageait le second avis par rapport au pouvoir des IRC Opérateurs, et les petits serveurs des États-Unis, craignant de perdre leur link, prirent la même position. Le propriétaire du hub était très désavoué particulièrement en Europe à cause de son jeune âge et de problèmes antérieurs. De plus, il menaçait une rupture USA/Europe, empêchant donc toute progression n’allant pas dans son sens. C’est pourquoi les principaux serveurs de l’opposition commencèrent un projet secret de " nouveau réseau ", dans le but de réunir la majeure partie des serveurs actuels et de se débarrasser du hub en question. Cependant, ils furent trahis et le projet échoua. Une nuit, alors que l’" opposition " avait une discussion sur un canal concernant le projet pour essayer de fixer une date, le possesseur du hub le sut et delinka avec l’Europe sans prévenir quiconque. Les serveurs durent prendre partie, et l’Amérique et l’Europe de l’Ouest se rallièrent au nouveau réseau du hub, qui se nomma " Efnet ". De l’autre côté, les serveurs notamment Finlandais décidèrent de garder l’appellation IRCnet, en raison des origines finlandaises d’IRC. Cet épisode notable s’appelle le " Grand Split ", semblant sorti de Dallas :). Avec le décollage d’Internet, de très nombreux réseaux virent le jour, et la liste actuelle est innombrable. Les réseaux principaux internationaux sont Quakenet, IRCnet, Undernet et EFnet.

2. Quels programmes ?

Avant de démarrer une description détaillée de l’IRC, voici la liste des programmes à utiliser :

• clients : mIRC, xchat, irssi, bitchx, Konversation (kde), Trillian, d’autres... [1] ;
• serveurs : IRCU, bahamut, UnrealIRCD, et plein d’autres... [2]

Tous ces programmes sont compatibles Linux, sauf mIRC, que j’ai tout de même cité dans cette liste, étant le client le plus utilisé et le plus complet existant.

3. Le principe

3.1 Pour les utilisateurs

Toute personne utilisant IRC saura qu’un utilisateur peut être reconnu par une chaîne sous forme pseudo!ident@hostname :

• Le pseudo choisi par l’utilisateur.
• L’ident donné en réponse de son identd (port 113), et sans réponse de celui-ci, un mot configurable dans le client.
• L’hostname de l’utilisateur. Suivant le programme serveur utilisé par le réseau, celui ci peut être partiellement crypté.

Le protocole est basé sur des espaces de discussion appelés des " canaux " (autres appellations : channels/salons/chans). Toute personne peut créer un canal en le rejoignant et bénéficie d’un statut " opérateur " qui lui donne des privilèges sur les autres utilisateurs rejoignant son canal, permettant entre autres de nommer d’autres opérateurs, éjecter (kicker), voire bannir (sur un mask sous forme pseudo!ident@hostname), inviter des utilisateurs, et mettre des " modes " dont voici une liste non exhaustive :

• t : donne l’autorisation uniquement aux opérateurs de changer le sujet (le topic).
• m : donne l’autorisation uniquement aux opérateurs et aux voices (statut particulier d’utilisateur sur le canal) de parler.
• i : on ne peut rejoindre un salon que si l’on est invité par un opérateur.
• n : on ne peut parler qu’en étant dans ce salon.
• k <clef> : on ne peut rejoindre le salon qu’en connaissant la clef.
• l <limite> : limite le nombre d’utilisateur dans le canal à la limite instituée.
• s : le salon est secret et n’apparaît pas dans la liste des salons ou dans le profil d’un utilisateur.
• p : le salon est privé et a, au final, la même fonction que le mode ‘s’.

Ceci sont les modes que l’on trouve en commun sur tous les programmes serveurs (nommés couramment " IRCD ", de IRC daemons), sachant que suivant le programme, il peut y en avoir d’autres ou pas. Notez en particulier sur certains le statut halfop (semi-opérateur) qui ne donne que le pouvoir d’éjecter et de bannir à celui qui le possède, statut que l’on retrouve uniquement sur peu d’IRCD, UnrealIRCD par exemple. Il existe plusieurs types de salons, reconnaissables par leur préfixe :

• # (global) : les salons les plus utilisés, que tout le monde connaît, et qui correspondent à la description effectuée ci-dessus.
• & (local) : ce sont les salons locaux. Ils ne sont pas transmis aux autres serveurs, vous ne verrez donc que les utilisateurs de *votre* serveur.
• + (modeless) : ces salons ne sont plus utilisés. Ils avaient la particularité de ne pas avoir de modes. Pas d’opérateurs, de voices, de modes, de possibilité d’éjection, ces salons mettaient tout le monde à égalité, mais empêchaient la répression des abus. Notez que vous pouvez reproduire un tel salon en créant un canal #, puis en vous enlevant le statut d’opérateur.
• Encore une fois, ceci est une liste non exhaustive, d’autres types de salons existent. D’ailleurs, actuellement, pour la petite anecdote, sur le programme " IRCU " d’Undernet, on réfléchit à la création d’un type de salon spécial pour les modes ‘A’ et ‘U’, créés sur ce même programme, il y a quelques années (et non appliqués (encore ?) sur Undernet), qui permettent à un opérateur de mettre un mot de passe sur un salon qui peut être utilisé pour se redonner le statut opérateur.

Il est à noter, qu’au début, les canaux étaient représentés par des numéros, on ne pouvait en rejoindre qu’un seul en même temps, et le seul moyen de partir du salon était de " rejoindre " le canal 0. C’est le topic qui permettait de donner une identité à un canal. Par la suite, ce sont d’abord les canaux ‘+’ (modeless), puis les canaux # qui apparurent, afin de supprimer définitivement les canaux numérotés. Le nom de " canal " vient de là. L’utilisateur peut également discuter directement à quelqu’un en " privé " ou en " notice ", ces deux biais étant fonctionnellement identiques, mais que le client interprète de manière différente : notice dans la fenêtre actuelle, message privé dans une fenêtre particulière à l’utilisateur qui l’envoie.

3.2 Pour les IRC Opérateurs

Chaque serveur possède des utilisateurs qui ont un statut d’" IRC Opérateurs ". Ceux-ci sont généralement désignés soit par un comité principal du réseau, soit par le propriétaire du serveur en question, suivant le mode de fonctionnement choisi par le réseau (voir chapitre sur le mode de fonctionnement). Ils ont le pouvoir de déconnecter quelqu’un du serveur, voire de le bannir de tout le réseau. Leur but en général est d’éviter toute attaque (voir chapitre sur la sécurité), la publicité massive, de s’assurer de la stabilité du serveur en général (sa connexion avec les autres serveurs), et non pas de régler les petits soucis tels que des insultes ou autres qui peuvent être évités en ignorant la personne concernée avec la commande /silence.

3.3 Pour les serveurs

L’IRC est un protocole client/serveur. Le principe est de relier plusieurs serveurs entre eux, ce qui permet à un utilisateur de se connecter à un serveur près de chez lui sans subir de lag (de temps de réponse excessif, supérieur à une seconde) et de pouvoir discuter avec les utilisateurs d’autres serveurs, et donc d’autres localisations, en temps réel. En effet, les serveurs étant eux sur des connexions généralement  beaucoup plus rapides que celles des clients, les messages sont transmis entre eux très rapidement.

Le but également est de permettre à chaque serveur de ne pas recevoir de surcharge d’utilisateurs. En outre, chaque message n’est transmis qu’aux serveurs nécessiteux de le connaître. Dans l’exemple, le message qui transite de User FR à User USA ne sera jamais envoyé au serveur Allemagne. Seuls les serveurs ayant un but de transmission auront connaissance de ce message. Ces principes ont un avantage principalement pour les très gros réseaux tels que Quakenet ou Undernet qui ont des millions d’utilisateurs, et dont le but est d’éviter toute surcharge inutile. En outre, ça permet de ne pas compter sur une seule machine (en cas de plantage du programme, de la machine, perte de connexion de celle-ci, ou DDOS). Note Un crash est quelque chose de très improbable dans le sens où les IRCD sont des projets matures et programmés en général par des experts, testés sans cesse avant la mise en production.

4. Les Channel Services

4.1 Présentation

Tels que présentés dans le chapitre 3, les salons posent un vrai problème : une fois déconnecté, un opérateur ne peut récupérer son statut d’opérateur que par le biais d’un autre opérateur, et lorsqu’un salon n’a plus d’opérateur, il est impossible de récupérer le statut sans que tout le monde parte du salon (ce qui entraîne sa destruction), puis que quelqu’un le rejoigne. C’est pourquoi une solution fut trouvée. L’idée est qu’un programme se connecte à un serveur, se faisant passer pour un serveur lui-même, mais qui ne reçoit pas de connexion, et fait croire aux autres serveurs qu’un user existe avec un statut particulier (le mode +k sur IRCU par exemple, que personne ne peut se paramétrer soi-même). Ceci permet à la fois au serveur de pouvoir mettre son utilisateur (son " robot ") opérateur sur tous les salons, d’avoir un accès IRC Opérateur, et d’être protégé contre toute forme de deop/kick de la part d’un autre opérateur. Une fois ces pouvoirs acquis, ce robot peut donc recevoir des requêtes d’enregistrement de salons, et il suffira à la personne en question d’émettre une commande d’identification au robot pour que celui-ci le mette opérateur sur le salon en question. Ceci est le principe de base, et de nombreuses fonctionnalités plus ou moins utiles existent, comme la possibilité de passer par le robot pour toute forme d’opération sur le salon, la protection des opérateurs ayant un accès, des opérations de masse facilitées, une protection anti mass-join, etc. L’avantage également de passer par un programme à part plutôt que d’inclure ça dans l’IRCD est qu’il y a une seule instance qui gère le tout, alors que dans le cas contraire chaque IRCD devrait se synchroniser, ainsi que de s’encombrer d’une base de donnée...

4.2 L’exemple de Z

À partir de ce principe de base, des services de plus en plus complets ont été créés. Sur le réseau francophone IRCube, l’équipe CoderZ, dont les membres sont David Cortier (alias Cesar) et moi-même, eut le projet de créer un service reprenant les idées des autres services existants, tels que l’unicité de robot de Gnuworld (X sur Undernet), la protection de pseudo de Epona (NickServ sur freenode), et la multiplicité des fonctionnalités de CS (IriX de entrechat). Ce robot, dont le nom est Z, réunit de très nombreuses fonctionnalités, dont certaines plus ou moins inédites : commandes pour que toutes vos actions sur un salon passent par le robot, possibilité de taper directement la commande sur le salon précédée du caractère de reconnaissance ‘!’, la protection des opérateurs ayant un accès, des opérations de masse facilitées, une protection anti mass-join, envoi de mémos sauvegardés, système de votes organisés par un administrateur du robot, historique des commandes accessible par les administrateurs, etc. Ce sont ces services de plus en plus complets qui permettent une accessibilité plus importante à l’utilisateur lambda qui ne cherchera pas à comprendre tous les principes d’IRC et qui préférera avoir un outil beaucoup plus intuitif.

5. La sécurité

5.1 Les splits

Lorsqu’il y a une perte de connexion entre deux serveurs, la difficulté est de faire en sorte d’assurer la resynchronisation entre les serveurs pour que chacun puisse retrouver sa place et éviter la prise de pouvoir sur un salon par exemple. Ceci est très bien géré par les IRCD. Nous prendrons le cas d’IRCU, dont le système de synchronisation se fait par envoi successif de tous les utilisateurs, tous les salons (sur une ligne : timestamp, modes, opérateurs, voices, bans), ainsi que tous les topics. Il en a déjà été question dans le premier paragraphe, lors de la guerre entre les timestamp et Nick/Channel Delay. Le principe du timestamp est que chaque salon et chaque user a stocké en mémoire la date de création ou de connexion. Pour les salons, lors de la resynchronisation des serveurs, si le timestamp des deux salons à merger est identique, on fait confiance aux opérateurs et modes présents des deux cotés, et on synchronise les deux en remettant les OPS et modes de l’autre serveur. En revanche, si l’un des deux salons a un timestamp supérieur à l’autre, c’est que celui-ci est plus récent et ainsi a été recréé pendant le split. Dans ce cas-là, ce sont tous les opérateurs et modes de l’ancien salon qui seront gardés et tous les opérateurs du salon le plus récent perdront leur statut. Pire encore, si jamais il y a sur le salon le plus vieux un mode d’inaccessibilité direct au salon, tel que le +i (invite only) ou le +k (key requiered), tous les utilisateurs du nouveau salon seront éjectés. En ce qui concerne les utilisateurs, ça se base sur le même principe. Lors d’une resynchronisation des serveurs, si jamais deux utilisateurs possèdent le même pseudo, celui qui a le timestamp le plus gros, c’est-à-dire l’utilisateur qui s’est connecté le plus récemment, sera déconnecté du serveur.

5.2 Les DDOS

Le DOS (Denial Of Service) est un envoi de flux très important d’un point à un autre, visant la saturation de la ligne employée. Le DDOS (Distributed Denial Of Service) est l’application parallèle de multiples DOS contre un point (un serveur), en provenance d’un maximum d’origine, causant ainsi la saturation d’un très grand nombre de lignes différentes en direction de ce serveur. Ceci est un problème assez important sur IRC, et les manières de le résoudre ne sont pas très nombreuses ni forcément très efficaces :

• Avoir un nombre de serveurs relativement élevés, de différents fournisseurs d’accès, voire dans des pays différents, afin de limiter le DDOS que sur un nombre réduit de serveurs.
• Avoir une meilleure connexion que l’attaquant, ce qui empêchera la saturation, mais provoquera tout de même un ralentissement (moins de bande passante disponible).
• Repérer au fur et à mesure, lors d’une attaque, les hosts des machines effectuant trop de requêtes, et les bloquer par le firewall.
• Avoir des contacts avec des Fournisseurs d’Accès à Internet ou la police :).

De manière générale, il faut un maximum d’anticipation pour éviter que, lors d’un DDOS, le réseau ne soit [trop] atteint.

5.3 Les attaques de proxys

Contrairement aux DDOS, les attaques de proxys sont beaucoup plus faciles à éviter, dans le sens où ce sont des clients qui se connectent directement au réseau. Leur but n’est pas la saturation de la machine (sauf si le nombre de proxys est vraiment très élevé), mais plutôt de faire du flood sur les salons. Suivant la façon dont l’attaquant procède, il peut être plus ou moins facile de contrer ces attaques. Voici ce dont doit être doté le service qui s’occupera de détecter les attaques de ce type :

• Vérification des ports ouverts du client (1080, 8080, 80, 3128, ports les plus utilisés par les proxys). Notez que la vérification du port 80 peut poser problème si un utilisateur héberge un HTTPD sur sa machine.
• Détection de connexions en masse. Valable plutôt sur les petits réseaux où il n’est pas habituel d’y avoir beaucoup de connexions d’un coup. Il vaut mieux cependant afficher un message d’avertissement aux administrateurs plutôt que de prendre les mesures automatiquement.
• Il existe un système intitulé " BOPM ", qui permet de partager une blacklist entre différents réseaux. Malheureusement, la liste n’est plus maintenue et ce programme est obsolète. Cependant, il est toujours intéressant de faire des alliances avec d’autres réseaux pour faire sa propre blacklist.
• Détection sur l’ident. En effet, il est fréquent que l’ident du programme utilisé soit généré de manière aléatoire (par exemple u1564 (une lettre, quatre chiffres)). En général, quand le regex est bien fourni, ça devient très efficace.
• Commande pour gline (bannir du réseau) tous les membres d’un salon (il est fréquent que les clones se retrouvent sur un salon créé par le pirate avant d’attaquer, peut être pour permettre à celui-ci d’admirer la beau botnet qu’il possède :)).
• Émettre un avertissement, lorsqu’un grand nombre de personnes joignent un salon d’un coup, limite gline directement.
• " Autolimite ", une protection sur le service de protection des salons, qui paramètre toutes les X minutes la limite +l à nombre de membres du salon + Y pour empêcher qu’il y ait plus de Y personnes qui joignent le salon d’un coup.

Ainsi que vous pouvez le constater, la liste des solutions est assez vaste et peut être encore agrandie.

Conclusion

En conclusion, on peut considérer qu’IRC est un protocole qui a des caractéristiques plutôt élaborées, et n’a cessé d’être amélioré durant ses 18 années d’existence (il est né en même temps que moi :p). Cependant, la limite commence à être atteinte. Il est difficile de concurrencer les messageries instantanées qui proposent le son, l’image et la vidéo, fonctionnalités qu’on ne pourra jamais retrouver sur IRC. En effet, le plus gros problème réside dans le fait que, de par la multiplication des clients IRC, il sera impossible de pouvoir faire des modifications fondamentales dans le protocole client<->serveur, au risque de rendre le serveur inutilisable par les clients actuels. Néanmoins, IRC reste quand même très répandu, notamment chez les acteurs du Libre, pour les avantages des salons pas suffisamment développés sur les messages instantanées, et par son caractère plus sobre (passons sur les horribles couleurs que l’on doit à mIRC:p).  Références

• [1] http://fr.wikipedia.org/wiki/Liste_de_clients_IRC
• [2] http://fr.wikipedia.org/wiki/Ircd

Retrouvez cet article dans : Linux Magazine 91