Les guerres d'EFnet : netsplits, takeovers et survie

EFnet — Eris-Free Network — est le plus ancien réseau IRC encore actif. Fondé en 1990 à la suite d'une rupture avec le serveur eris.berkeley.edu, il a fonctionné pendant des années sans services centralisés (NickServ, ChanServ), sans enregistrement de canaux, sans mécanisme d'arbitrage. Cette absence de gouvernance formelle a produit un environnement où la propriété d'un canal se réduisait à un état éphémère : celui qui détenait le statut @ au moment où le dernier utilisateur quittait le canal perdait tout droit établi. Les conflits qui en ont découlé — netsplits, takeovers, floods — constituent une histoire technique et sociale dense, souvent mal documentée en dehors des communautés concernées.

Cet article ne prétend pas à l'exhaustivité. Il pose les faits techniques et contextuels qui permettent de comprendre pourquoi EFnet a été le théâtre de certains des conflits IRC les plus élaborés de l'histoire des réseaux informatiques grand public.

Anatomie d'EFnet : architecture et fragilités structurelles

EFnet repose sur le protocole IRC tel que défini dans la RFC 1459 (1993), puis amendé par les RFC 2810 à 2813 (2000). La topologie du réseau est celle d'un arbre acyclique de serveurs : chaque serveur entretient des liaisons avec un ou plusieurs pairs, et l'ensemble forme un graphe sans cycle. Cette architecture, choisie pour sa simplicité de routage des messages, introduit une vulnérabilité fondamentale : toute coupure d'un lien produit une partition du réseau.

EFnet n'a jamais adopté les services centralisés qui ont standardisé la gestion des canaux sur des réseaux concurrents comme DALnet ou Undernet. Les administrateurs de ces réseaux ont choisi d'implémenter ChanServ et NickServ précisément pour mettre fin aux takeovers. EFnet a refusé cette voie, au nom d'une philosophie de réseau décentralisé. Cette décision a eu des conséquences durables.

Jusqu'à l'adoption progressive des modes d'invitation permanente et des fonctionnalités offertes par des bots comme eggdrop, la seule manière de protéger un canal consistait à maintenir un opérateur présent en permanence. Un canal vide perdait tous ses modes. Un canal avec un seul utilisateur non-opérateur après un netsplit devenait immédiatement vulnérable.

La liste des serveurs EFnet a fluctué de manière considérable entre 1993 et 2005. À son pic, le réseau comptait plus de 200 000 utilisateurs simultanés répartis sur une soixantaine de serveurs. La concentration géographique — nombreux serveurs en Amérique du Nord et en Europe du Nord — rendait certains liens intercontinentaux structurellement instables.

Les netsplits : mécanisme, exploitation et conséquences

Un netsplit survient lorsqu'un lien entre deux serveurs est interrompu. Du point de vue de chaque partition, tous les utilisateurs connectés à l'autre moitié du réseau apparaissent comme ayant quitté simultanément, avec un message de départ au format serveur1.irc.exemple serveur2.irc.exemple. Lorsque le lien est rétabli (le netjoin), les utilisateurs réapparaissent.

Ce mécanisme a plusieurs conséquences exploitables :

• Canaux sans opérateur : Si tous les opérateurs d'un canal se trouvaient du côté séparé, le canal subsistait dans la partition survivante sans aucun @. Le premier utilisateur à rejoindre ce canal vide obtenait automatiquement le statut d'opérateur selon les règles IRC de l'époque.
• Nick collisions : Un utilisateur pouvait tenter de prendre un pseudonyme déjà utilisé de l'autre côté de la coupure. Au moment du netjoin, les deux instances du même nick entraient en collision, entraînant la déconnexion forcée de l'une ou des deux.
• Mode riding : Profiter du netjoin pour rejoindre un canal en mode invite-only (+i) ou mot de passe (+k) pendant la fraction de seconde où les modes n'avaient pas encore été rétablis.

L'exploitation délibérée des netsplits nécessitait une connaissance précise de la topologie du réseau et, dans les cas les plus élaborés, un accès ou une influence sur un serveur IRC. Des attaques DoS ciblées sur des liens spécifiques ont été documentées, visant à provoquer des netsplits au moment stratégique — par exemple lorsqu'un canal cible n'avait qu'un seul opérateur connecté du côté visé.

La fenêtre d'exploitation était mesurée en secondes. Des scripts automatisés — souvent en TCL pour eggdrop, ou en Perl pour des clients comme ircII — surveillaient les messages de netsplit et tentaient de rejoindre des canaux cibles immédiatement après la séparation. La course entre le bot défensif déjà en place et le script attaquant déterminait l'issue.

# Exemple de détection de netsplit dans un script eggdrop TCL
bind raw - QUIT netsplit_detect

proc netsplit_detect {from keyword arg} {
    # Un quit de netsplit contient deux hostnames séparés par un espace
    if {[regexp {^(\S+\.\S+) (\S+\.\S+)$} $arg]} {
        putlog "Netsplit détecté : $arg"
        # Activer la surveillance des canaux vulnérables
        foreach chan [channels] {
            if {[llength [chanops $chan]] == 0} {
                putlog "Canal sans ops après netsplit : $chan"
            }
        }
    }
}

L'introduction du mode +r (registered) sur certains serveurs EFnet, ainsi que l'implémentation de timestamp sur les modes de canal, a progressivement réduit l'exploitabilité des netsplits. Le mécanisme TS (timestamp) attribue un horodatage à la création du canal et aux attributions d'opérateurs ; au moment du netjoin, le serveur avec l'horodatage le plus ancien conserve la priorité. Cette mécanique, généralisée au milieu des années 1990, a rendu les takeovers par netsplit nettement plus difficiles sans les éliminer entièrement.

Takeovers de canaux : méthodes et contre-mesures

Un takeover désigne la prise de contrôle non autorisée d'un canal IRC. Sur EFnet, l'absence de ChanServ signifiait que la légitimité d'un opérateur reposait exclusivement sur la continuité de présence et la coopération des pairs. Plusieurs vecteurs d'attaque ont été documentés et utilisés à grande échelle.

Takeover par netsplit (décrit supra)

La méthode la plus connue, rendue difficile par le système TS mais jamais totalement impossible sur des serveurs anciens ou mal configurés.

Takeover par flood de déconnexion

En provoquant la déconnexion de tous les opérateurs légitimes d'un canal — via des attaques DoS sur leurs connexions ou via des clonebot floods déclenchant des G-lines automatiques — l'attaquant vidait le canal de ses défenseurs. Si un bot ou un utilisateur complice rejoignait le canal au bon moment, il obtenait les droits d'opérateur.

Social engineering et compromission de bot

Un eggdrop compromis ou dont le mot de passe owner avait été obtenu par ingénierie sociale permettait à l'attaquant d'émettre directement des commandes op via le bot. Une fois opérateur, il pouvait dévopper (/deop) les opérateurs légitimes et modifier les modes du canal pour en verrouiller l'accès.

Nick spoofing et usurpation d'identité

En l'absence de NickServ, rien n'empêchait un utilisateur de prendre le pseudonyme d'un opérateur de confiance pendant son absence, puis de demander à un bot automatique de lui accorder le statut d'opérateur. Les bots correctement configurés vérifiaient l'adresse IP ou le masque d'hôte (hostmask) plutôt que le seul pseudonyme, mais nombreux étaient ceux qui ne le faisaient pas.

Contre-mesures documentées

Face à ces vecteurs, les communautés EFnet ont développé plusieurs stratégies défensives :

• Réseau de bots redondants : Maintenir plusieurs instances d'eggdrop sur des serveurs géographiquement distincts, connectées à différentes parties du réseau EFnet pour éviter qu'un seul netsplit ne les isole toutes.
• Vérification par hostmask : Configurer les bots pour qu'ils n'accordent le statut d'opérateur qu'à des combinaisons nick+ident+host spécifiques, et non au seul pseudonyme.
• Modes de canal restrictifs : Maintenir +i (invite-only) avec une liste d'invitations gérée par bot, ou +k avec un mot de passe rotatif connu des seuls membres légitimes.
• Canaux fantômes : Certaines communautés maintenaient un canal de repli dont l'existence n'était pas publique, utilisé comme point de coordination en cas de takeover du canal principal.

Les guerres de serveurs : DoS, floods et expulsions

Les conflits sur EFnet ont rarement été limités au niveau des canaux. Les guerres de serveurs — impliquant des administrateurs, des IRCops et des groupes organisés — ont constitué une couche supplémentaire de complexité.

Attaques DoS sur les serveurs

Provoquer la déconnexion d'un serveur EFnet entier en le saturant de trafic réseau permettait d'induire un netsplit massif affectant potentiellement des dizaines de milliers d'utilisateurs. Ces attaques ont été particulièrement fréquentes entre 1997 et 2002, période pendant laquelle les accès haut débit domestiques commençaient à se généraliser, offrant une bande passante suffisante pour saturer des liens de serveurs modestes.

La réponse des administrateurs de serveurs a pris plusieurs formes : limitation du nombre de connexions par IP, mise en place de drones (connexions de surveillance), et coordination accrue entre IRCops via des canaux privés dédiés.

Clone floods et G-lines

Un clone flood consiste à ouvrir un grand nombre de connexions simultanées depuis la même adresse IP ou le même bloc d'adresses vers un serveur ou un canal. L'objectif peut être de saturer le serveur, de déclencher des limites automatiques frappant indistinctement les utilisateurs légitimes, ou de noyer un canal sous des messages.

EFnet dispose du mécanisme de G-line (global kill line) : une interdiction de connexion appliquée à l'échelle du réseau, émise par les IRCops. Son utilisation comme outil offensif a été documentée — des IRCops corrompus ou sous pression de groupes organisés ont émis des G-lines injustifiées contre des utilisateurs légitimes pour les expulser du réseau.

Les guerres d'IRCops

La gouvernance d'EFnet est décentralisée : chaque serveur est administré indépendamment, et les IRCops d'un serveur n'ont pas autorité sur les autres serveurs sauf dans le cadre de décisions collectives. Cette structure a favorisé des conflits entre groupes d'IRCops, parfois organisés en factions avec des intérêts territoriaux explicites autour de canaux spécifiques ou de communautés.

Des dissensions internes ont conduit à plusieurs scissions notables. La création d'IRCnet en 1996 résulte directement d'un conflit entre administrateurs européens et nord-américains sur la politique de connexion des serveurs et les droits de vote au sein du réseau. EFnet a perdu ce jour-là une partie significative de son infrastructure européenne.

# Exemple de configuration de G-line dans ircd-hybrid (format illustratif)
# /etc/ircd/hybrid.conf — section klines
kline {
    user = "*@192.0.2.0/24";
    reason = "Clone flood origin";
    duration = 86400;  /* 24 heures en secondes */
};

Le rôle des shells publics et des botnets

L'accès à des serveurs shell bon marché (ou compromis) a été un facteur déterminant dans l'escalade des conflits IRC. Un attaquant disposant de dix adresses IP distinctes pouvait maintenir dix bots, lancer des floods depuis des sources variées, et rendre la détection et le blocage significativement plus complexes.

À partir de 2000-2001, l'utilisation de machines compromises — les premiers botnets au sens contemporain — pour des opérations IRC a commencé à être documentée. Des groupes organisés maintenaient des réseaux de machines zombies utilisées aussi bien pour des attaques DoS que pour des floods de canaux IRC.

Survivre sur EFnet : protocoles défensifs éprouvés

Face à ces menaces, les communautés durables sur EFnet ont développé des pratiques défensives cohérentes. Ce qui suit est une synthèse des approches qui ont fait leurs preuves sur la durée.

1. Architecture de bots en réseau

Un canal sérieux maintenait un minimum de trois bots eggdrop connectés à des serveurs EFnet distincts, géographiquement séparés. Les bots formaient un réseau entre eux (fonctionnalité native d'eggdrop) et se conféraient mutuellement le statut d'opérateur à la reconnexion. La règle était simple : jamais moins de deux bots opérateurs actifs simultanément.

# eggdrop.conf — configuration réseau de bots
set botnet-nick "MonBot1"
set botnet-host "shell1.exemple.com"
set botnet-port 3333

# Bot pair
addbotaddr MonBot2 shell2.exemple.net 3334
addbot MonBot2 motdepassepartage

2. Surveillance des netsplits en temps réel

Les scripts de surveillance détectaient les messages QUIT au format netsplit et déclenchaient immédiatement une vérification du statut opérateur sur tous les canaux défendus. Si un canal se retrouvait sans opérateur après un netsplit, le bot tentait de rejoindre et d'auto-opper.

3. Gestion des hostmasks et listes d'accès

Les listes d'accès des bots étaient maintenues à jour avec les hostmasks réels des opérateurs légitimes. Chaque ajout d'opérateur était conditionné à une vérification manuelle de l'identité, souvent via un canal privé séparé. Les accès obsolètes étaient supprimés régulièrement.

4. Modes défensifs permanents

Les canaux importants maintenaient en permanence une combinaison de modes restrictifs :

• +m (modéré) : seuls les opérateurs et les utilisateurs avec voix pouvaient écrire, utilisé lors d'attaques de flood en cours.
• +i (invite-only) : limiter les entrées aux invitations explicites.
• +l (limite d'utilisateurs) : fixer une limite légèrement supérieure au nombre actuel d'utilisateurs légitimes pour bloquer les entrées massives de clones.
• +b (bans) : maintenir une liste de bans à jour contre les hostmasks d'attaquants connus.

5. Communication hors-bande

Les communautés ciblées maintenaient des canaux de communication alternatifs — courriels, canaux IRC sur d'autres réseaux, forums web — pour coordonner la réponse à une attaque sans dépendre du canal sous attaque. Cette redondance permettait de continuer à opérer pendant un takeover et d'organiser la reconquête.

6. Documentation et mémoire collective

Les attaques récurrentes provenaient souvent des mêmes individus ou des mêmes groupes. Les communautés ciblées tenaient des journaux détaillés des incidents — hostmasks, méthodes, chronologies — partagés entre administrateurs de canaux voisins ou alliés. Cette mémoire collective accélérait l'identification et le blocage lors d'attaques ultérieures.

L'héritage des conflits EFnet sur l'IRC moderne

Les conflits d'EFnet n'ont pas été sans conséquences sur l'évolution de l'IRC en général. Plusieurs innovations techniques et organisationnelles qui définissent les réseaux IRC contemporains sont directement issues de réponses aux problèmes posés par ces guerres.

La création des services centralisés

DALnet a été fondé en 1994 en partie comme réponse aux dysfonctionnements d'EFnet. Son implémentation de NickServ et ChanServ — permettant l'enregistrement permanent des pseudonymes et des canaux — était une réponse directe à l'instabilité et aux conflits de propriété qui caractérisaient EFnet. Undernet a suivi une trajectoire similaire.

Freenode (aujourd'hui Libera.Chat) et IRCnet ont adopté des approches différentes, mais tous ces réseaux ont en commun d'avoir tiré des leçons explicites de l'expérience EFnet.

Le système TS et ses successeurs

Le mécanisme de timestamp, développé spécifiquement pour EFnet, est devenu un composant standard du protocole IRC. Les implémentations modernes d'ircd intègrent des versions raffinées de ce système pour gérer les conflits d'état lors des netjoins.

L'émergence de la gestion de botnets comme compétence

La gestion d'un réseau de bots IRC défensifs a constitué pour de nombreux administrateurs système une introduction pratique à des concepts qui structurent aujourd'hui la gestion d'infrastructure : redondance géographique, failover automatique, surveillance en temps réel, authentification par attribut d'hôte plutôt que par identité déclarée.

L'influence sur la culture de la sécurité réseau

Plusieurs personnalités importantes dans le domaine de la sécurité informatique ont fait leurs premières armes sur IRC, et plus spécifiquement dans le contexte des conflits EFnet. La compréhension pratique des attaques DoS, du spoofing, de l'ingénierie sociale et des techniques d'exploitation de conditions de course (race conditions) — comme celles inhérentes aux netsplits — a constitué une formation accélérée que peu d'environnements de l'époque offraient.

EFnet reste actif en 2024, avec plusieurs milliers d'utilisateurs simultanés. Sa philosophie de non-gouvernance centralisée n'a pas changé. Les conflits y sont moins fréquents qu'à l'apogée du réseau, en partie parce que les enjeux sont moindres, en partie parce que les IRCds modernes ont réduit certaines surfaces d'attaque. Mais les mécanismes fondamentaux — l'absence de propriété garantie, la vulnérabilité aux netsplits, la dépendance aux bots pour la continuité — sont toujours présents.

Comprendre les guerres d'EFnet, c'est comprendre ce qui se passe lorsqu'un système distribué sans arbitre central rencontre des acteurs dont les intérêts divergent. Les solutions trouvées — techniques, organisationnelles, culturelles — préfigurent des problèmes que l'on retrouve dans des contextes très différents : gouvernance de protocoles peer-to-peer, coordination de communautés en ligne, résilience d'infrastructure distribuée.