EFnet es la red IRC más antigua en funcionamiento continuo. Nació sin arquitectura de seguridad porque en 1990 nadie esperaba que la gente se peleara por salas de chat. Esa ingenuidad estructural se pagó cara durante toda la década de los noventa y parte de los dos mil: guerras de servidores, tomas masivas de canales, netsplits permanentes y una cultura de administración que combinaba parches de emergencia con ego a raudales. Este artículo reconstruye esa historia desde la perspectiva técnica.
Orígenes de EFnet y la primera fractura
IRC fue creado por Jarkko Oikarinen en 1988 como sistema de mensajería para el servidor tolsun.oulu.fi. La red creció de forma orgánica: cualquier administrador podía conectar su servidor enlazando con uno existente. No había autoridad central, no había proceso de admisión formal, no había autenticación entre servidores más allá de contraseñas en texto plano configuradas en C/N lines.
En 1990 la red tenía decenas de servidores. En 1992 tenía cientos. El protocolo IRC original (RFC 1459, formalizado en 1993) asume una topología en árbol: cada servidor conoce a todos los demás a través de una cadena de enlaces. Cuando cualquier enlace se rompe, la red se parte en dos subconjuntos que no pueden comunicarse. A esto se llama netsplit.
La primera gran fractura organizativa llegó en 1996. Un grupo de operadores, hartos de la ausencia de gobierno y de los abusos de algunos administradores de servidores con demasiado poder, decidió abandonar EFnet para crear IRCnet. La separación fue técnica y política a la vez: EFnet se quedó mayoritariamente con servidores norteamericanos, IRCnet con los europeos. Las razones concretas incluían desacuerdos sobre cómo manejar los canales vacíos y si implementar o no servicios de registro (NickServ, ChanServ). EFnet dijo no. IRCnet también dijo no, pero por razones distintas. Ambas redes siguieron sin servicios centrales, lo que las dejó vulnerables a los mismos problemas de siempre.
Lo que quedó de EFnet tras la ruptura era una red con memoria institucional fragmentada, servidores con políticas contradictorias y un protocolo que no había evolucionado para enfrentar usuarios hostiles a escala. El escenario estaba preparado para una década de guerras.
Qué es un netsplit y por qué destruye canales
Un netsplit ocurre cuando el enlace TCP entre dos servidores IRC se interrumpe. El protocolo trata esto como una partición de la red: los usuarios conectados a servidores del lado A no pueden ver ni comunicarse con los del lado B. Desde el punto de vista de cada usuario, los que estaban en el otro lado simplemente desaparecen del canal, todos a la vez, con un mensaje del tipo:
*** Netsplit: irc2.efnet.org irc.east.efnet.org (TS delta too large)
*** Signoff: nick1 (irc2.efnet.org irc.east.efnet.org)
*** Signoff: nick2 (irc2.efnet.org irc.east.efnet.org)
*** Signoff: nick3 (irc2.efnet.org irc.east.efnet.org)Cuando el enlace se restaura, los dos fragmentos intentan resincronizar su estado. Aquí entra el sistema TS (Timestamp) que EFnet implementó progresivamente durante los noventa para gestionar conflictos. La idea es simple: cada canal tiene un timestamp de creación. Cuando dos fragmentos de red se reúnen, el canal con el timestamp más antiguo gana; el otro pierde todos sus modos y, en versiones tempranas del protocolo, todos sus operadores.
El problema es que durante el netsplit, cualquier persona en el lado minoritario puede hacer /join a un canal vacío (desde su perspectiva) y obtener el estatus de operador automáticamente, porque el servidor le considera el fundador de un canal nuevo. Cuando la red se reúne, si el timestamp del lado del atacante es más reciente, pierde los modos. Pero en versiones antiguas del servidor, la lógica era más laxa y había formas de explotar la resincronización.
El parche TS fue introducido por varios equipos de desarrollo de ircd de forma independiente y no coordinada. Durante años coexistieron servidores con distintas versiones del sistema TS en la misma red, lo que creaba incompatibilidades que los atacantes aprendieron a explotar sistemáticamente.
Más allá del exploit técnico, los netsplits creaban problemas operativos cotidianos. Un canal con 200 personas podía quedarse con 15 durante un split prolongado. Si el canal tenía un bot de protección en el lado que se desconectaba, quedaba sin defensa. Los operadores humanos que gestionaban canales populares desarrollaron estrategias de distribución geográfica: mantener bots en servidores de distintas ciudades para que ningún split único pudiera dejar el canal sin operadores.
Guerras de canales: tomas, botnets y floods
El término «guerra de canales» (channel war) describe el conjunto de técnicas hostiles usadas para tomar el control de un canal IRC o para hacerlo inusable. En EFnet, sin servicios de registro que asociaran un canal a su fundador legítimo, la propiedad de un canal era simplemente cuestión de quién tenía más operadores activos en un momento dado.
Las técnicas principales evolucionaron en paralelo con las contramedidas:
Clone flooding
La técnica más básica: conectar decenas o cientos de clientes desde la misma IP o desde IPs distintas, llenar el canal de ruido, expulsar a los operadores legítimos si se conseguía acceso temporal, o simplemente hacer el canal inutilizable. Los servidores implementaron límites de conexiones por IP (max connections per host), pero con acceso a múltiples máquinas comprometidas esto era trivial de evadir.
Takeover mediante netsplit
El método más sofisticado. Requería acceso a un servidor o capacidad de interrumpir un enlace. El atacante esperaba o provocaba un netsplit, se unía al canal en el fragmento minoritario obteniendo ops automáticos, y luego esperaba la reunificación esperando que la lógica TS favoreciera su timestamp. En redes con implementaciones TS defectuosas, esto funcionaba con una frecuencia alarmante.
; Secuencia de ataque típica pre-TS robusto:
; 1. Detectar inminente netsplit o provocarlo
; 2. Conectarse al servidor que quedará aislado
; 3. /join #canal-objetivo (ahora vacío desde ese servidor)
; 4. Obtener @ops automáticamente como "fundador"
; 5. Esperar reunificación
; 6. En versiones vulnerables: el canal resincroniza con ops del atacante
; 7. /kick a todos los operadores legítimos
; 8. +i (invite only) o +k clave para bloquear el canalNick collisions
Durante un split, si alguien usaba el mismo nick que un operador del canal en el lado contrario, al reunificarse la red había una colisión de nick. El servidor mataba ambos clientes (los desconectaba). Si el atacante coordinaba esto para eliminar a todos los operadores simultáneamente en el momento de la reunificación, el canal podía quedar sin ops. Con suerte, algún bot sobrevivía. Sin suerte, el canal quedaba en estado opless: nadie podía operarse, y la única solución era esperar otro netsplit para que alguien se uniera al fragmento correcto y obtuviera ops.
Botnets IRC
A mediados de los noventa aparecieron los primeros eggdrops modificados con capacidades ofensivas. El eggdrop original, escrito por Robey Pointer, era un bot de gestión de canales. Sus forks hostiles añadieron capacidades de flood, clone management y coordinación de ataques. Para finales de los noventa existían redes de bots dedicadas exclusivamente a guerras de canales, controladas vía canales IRC privados.
El ciclo era predecible: un canal popular atraía atacantes, los defensores desplegaban más bots, los atacantes conseguían más máquinas comprometidas, los defensores pedían a los IRCops que banearan rangos de IPs, los atacantes usaban proxies abiertos. Los proxies abiertos se convirtieron en un problema tan severo que varios servidores de EFnet empezaron a hacer escáner activo de IPs entrantes, bloqueando las conexiones provenientes de puertos 1080 (SOCKS) y 3128 (HTTP proxy) abiertos.
DDoS contra servidores
La siguiente escalada fue directamente contra la infraestructura. Si un servidor albergaba los bots defensores de un canal objetivo, la solución era tirar el servidor. Los ataques DDoS contra servidores IRC de EFnet eran rutinarios a finales de los noventa. Varios servidores universitarios abandonaron EFnet precisamente porque no podían absorber el tráfico de ataque sin afectar el resto de su red.
Los administradores respondieron con null routing (descartar tráfico hacia la IP atacada a nivel de router), anycast en algunos casos, y rotación frecuente de IPs. Nada era completamente efectivo porque el coste de lanzar un flood era asimétrico: barato para el atacante, caro para el defensor.
Los grandes splits históricos
Más allá de los splits cotidianos, EFnet sufrió varias particiones a gran escala que reonfiguraron la red de forma permanente.
El gran split de 1996
La separación de IRCnet ya mencionada fue la más significativa en términos de usuarios perdidos. EFnet pasó de ser la red IRC dominante a nivel mundial a ser una de varias redes grandes. IRCnet se llevó la mayor parte de la comunidad europea, incluyendo servidores universitarios con miles de usuarios. EFnet quedó con una base predominantemente norteamericana.
La crisis de los servidores de 1998-2001
Este período fue especialmente turbulento. Los ataques DDoS contra servidores alcanzaron su pico. Varias instituciones educativas que albergaban servidores EFnet (universidades con buena conectividad y sin restricciones de uso de banda) decidieron desconectarse porque el tráfico de ataque colateral afectaba a estudiantes y personal. La red perdió docenas de servidores en este período.
Al mismo tiempo, la proliferación de servidores con implementaciones ircd divergentes creaba problemas de compatibilidad constantes. El proyecto ircd-ratbox, iniciado a finales de los noventa, intentó crear una base de código común, más robusta y con mejor implementación de TS. La adopción fue gradual y no universal.
El problema de los servidores «rogue»
Algunos servidores en EFnet eran operados por personas con objetivos cuestionables: facilitar ataques, proteger a atacantes específicos de bans, o simplemente acumular poder de operador de red (IRCop) para usarlo en guerras personales. El mecanismo de admisión de servidores en EFnet era informal: básicamente, si un servidor existente confiaba en ti y te enlazaba, entrabas en la red.
Esto creó una estructura donde eliminar un servidor problemático requería consenso entre administradores que frecuentemente no se ponían de acuerdo. Los procedimientos para desconectar servidores «rogue» eran lentos, politizados y a veces simplemente no funcionaban.
; Ejemplo de C/N line en ircd clásico (configuración de enlace servidor-servidor):
; C line: autorización para conectar a un servidor remoto
; N line: autorización para que ese servidor se conecte a ti
C:192.0.2.1:password_de_enlace:irc.example.net:6667:5
N:192.0.2.1:password_de_enlace:irc.example.net::5
; La clase 5 define límites de banda y reconexión
; Sin autenticación criptográfica: cualquiera que supiera
; la contraseña y controlara la IP podía suplantar el servidorLa autenticación basada únicamente en IP y contraseña en texto plano significaba que comprometer un enlace servidor-servidor era posible si se tenía acceso a la red del servidor legítimo o si se conseguía la contraseña por otros medios. Hubo casos documentados de servidores falsos conectándose a EFnet haciéndose pasar por servidores legítimos durante períodos de inestabilidad.
Cómo EFnet sobrevivió sin servicios centrales
La pregunta obvia es: ¿por qué EFnet no implementó simplemente NickServ y ChanServ como hicieron DALnet, Undernet y posteriormente Freenode/Libera? La respuesta es filosófica antes que técnica.
Una parte significativa de la comunidad de EFnet, especialmente los administradores de servidores veteranos, consideraba que los servicios centrales creaban un punto único de fallo y una autoridad central incompatible con el espíritu descentralizado de IRC. También había argumentos técnicos legítimos: un servidor de servicios caído podía dejar toda la red sin capacidad de autenticación. Y había argumentos prácticos: implementar servicios requería consenso entre administradores que raramente lo alcanzaban sobre nada.
Sin servicios, EFnet desarrolló mecanismos alternativos de supervivencia:
Channel ownership por bot
La práctica estándar en canales serios de EFnet era mantener un bot permanente con ops, idealmente varios, en servidores geográficamente distribuidos. El eggdrop se convirtió en la infraestructura de facto para gestión de canales. Comunidades con recursos suficientes mantenían bots en Estados Unidos, Europa y Asia simultáneamente para sobrevivir cualquier split regional.
Evolución del protocolo TS
La implementación progresiva y eventualmente robusta del sistema TS redujo drásticamente la efectividad de los ataques basados en netsplit. Con TS correcto, tomar un canal mediante split requería manipular los timestamps de forma detectable, lo que los servidores podían bloquear. No eliminó el problema, pero lo hizo mucho más difícil.
ircd-ratbox y la estandarización
La adopción progresiva de ircd-ratbox como servidor estándar de EFnet a partir de principios de los años 2000 redujo la heterogeneidad del código base. Menos variantes en producción significaba menos inconsistencias en el comportamiento del protocolo y menos superficie de ataque por incompatibilidades.
; ircd-ratbox introdujo varias mejoras de seguridad:
; - Implementación TS más estricta y consistente
; - Flood throttling mejorado
; - Mejor gestión de conexiones desde proxies abiertos
; - OPER blocks más granulares
; - Logging mejorado para auditoría post-incidente
; Fragmento de referconfig.conf de ratbox:
operator {
name = "admin";
user = "*@192.0.2.0/24";
password = "$1$hash_bcrypt_aqui";
flags = global_kill, rehash, routing, kline, gline;
snomask = +Zbfckrs;
};KLINE y GLINE coordinadas
Los IRCops desarrollaron procedimientos para coordinar bans a nivel de red (GLINE: G-line aplicada en todos los servidores) contra IPs problemáticas. Esto no era automático ni centralizado, dependía de comunicación entre operadores vía canales privados como #ircd-admins o #ircops. Lento, pero funcionaba para casos graves.
La reducción natural del problema
Una parte de la solución fue simplemente el tiempo. Las guerras de canales alcanzaron su pico de intensidad entre 1996 y 2003. Después de eso, la fragmentación de la comunidad IRC hacia múltiples redes (IRCnet, Undernet, DALnet, QuakeNet, Freenode), la aparición de plataformas de mensajería alternativas y el simple agotamiento de los participantes redujeron la frecuencia e intensidad de los ataques.
Los canales que sobrevivieron a las guerras lo hicieron porque tenían administradores dedicados que entendían los mecanismos de ataque y construyeron defensas en capas: bots distribuidos, procedimientos de recuperación documentados, relaciones con IRCops de confianza. No era elegante, pero era funcional.
EFnet a día de hoy es una fracción de su tamaño máximo. En el pico de finales de los noventa tenía más de cien mil usuarios simultáneos. Actualmente oscila entre cinco mil y diez mil dependiendo de la hora. Sigue sin servicios de registro. Sigue siendo técnicamente vulnerable a las mismas clases de ataque, aunque la escala reducida hace que los ataques sean menos frecuentes porque hay menos incentivo para tomarlos.
Lo que EFnet representa hoy es menos una red de chat operativa y más un artefacto técnico e histórico: la única red IRC grande que mantuvo su arquitectura original descentralizada a pesar de todos los problemas que eso causó. Hay algo coherente en eso, aunque sea difícil argumentar que fue la decisión correcta.
Preguntas frecuentes
¿Por qué EFnet nunca implementó NickServ o ChanServ?
La oposición fue mayoritariamente filosófica: los administradores veteranos consideraban que los servicios centrales eran contrarios al espíritu descentralizado de IRC y creaban un punto único de fallo. También había resistencia política: acordar quién controla los servicios centrales implica acordar quién tiene autoridad sobre la red, algo que la comunidad de EFnet históricamente no ha podido resolver. La decisión se mantuvo aunque otras redes como DALnet demostraron que los servicios eran viables y reducían significativamente las guerras de canales.
¿Qué es exactamente el sistema TS y cómo previene los takeovers?
TS (Timestamp) es un mecanismo por el que cada canal y cada nick en IRC tiene asociado un timestamp de creación. Cuando se produce un netsplit y los dos fragmentos se reúnen, el servidor usa estos timestamps para resolver conflictos: el canal con el timestamp más antiguo es el legítimo, y los modos (incluidos los operadores) del canal con timestamp más reciente se descartan. Esto previene el takeover clásico porque aunque alguien se una a un «canal vacío» durante el split y obtenga ops, su timestamp será más reciente que el del canal original, y perderá los ops al reunificarse la red. Las implementaciones defectuosas de TS en los años 90 fueron explotadas masivamente antes de que se estandarizara la implementación correcta.
¿Qué pasó con los canales que quedaban sin operadores (opless)?
Un canal opless en EFnet era una situación frustrante con pocas soluciones. No había mecanismo oficial para recuperar operadores en un canal sin ops porque EFnet no tiene servicios centrales. Las opciones eran: esperar un netsplit que dejara el canal vacío en algún fragmento (y que alguien de confianza estuviera conectado a ese fragmento para unirse y obtener ops automáticamente), o si se tenía acceso a un IRCop de confianza, pedirle que usara el comando OPMODE para forzar ops en el canal. Esto último dependía de la política de cada servidor y de la disposición del IRCop individual. En práctica, muchos canales opless simplemente se vaciaban porque sin moderación se volvían inutilizables, y la gente migraba a un canal con nombre similar recién creado.
¿EFnet sigue teniendo problemas de seguridad similares hoy?
La arquitectura fundamental no ha cambiado, así que las vulnerabilidades teóricas siguen existiendo. En práctica, la escala reducida de la red (menos usuarios, menos canales con valor para un atacante) hace que los ataques sean mucho menos frecuentes. Además, ircd-ratbox y sus sucesores implementan TS de forma robusta, lo que cierra los exploits más graves de los años noventa. Los ataques DDoS contra servidores siguen siendo posibles, y algunos servidores de EFnet han sufrido ataques en años recientes, aunque con menos frecuencia que en el período 1998-2003.