IRCd para niños

Un IRCd, o Internet Relay Chat daemon (demonio) es un software que permite crear una red donde la gente puede conectarse para mantener conversaciones en tiempo real en la red mediante el protocolo IRC.

Funcionamiento general de una red de IRC

Una red de IRC está compuesta por uno o más nodos de acceso cada uno de los cuales ejecuta un IRCd compatible con el resto, que en general suele ser el mismo para todos los nodos (no necesariamente la misma versión) pero en el caso de algunas redes no todos los nodos ejecutan el mismo IRCd sino diferentes implementaciones cuyos protocolos sean compatibles. El protocolo IRC básico está descrito en el RFC 1459 no obstante con el tiempo han ido surgiendo otros RFC como el RFC 2810, RFC 2811, RFC 2812 y RFC 2813 junto con otras modificaciones propias de cada rama (la mayoría de IRCd's en producción en la actualidad descienden de una base de código común, a base de forks del IRCd original y sus descendientes). Esto no es demasiado importante puesto que como hemos apuntado por lo general todos los nodos de una misma red de IRC utilizan versiones de una misma implementación del software servidor, siendo la interfaz cliente-servidor la más delicada puesto que a ninguna red de IRC le interesa hacer su software servidor incompatible con los clientes de IRC existentes en el mercado, los programas que permiten a los usuarios conectarse a la red y hacer uso de sus servicios.

Por lo general los servidores de IRC tienen habilitada una serie de clases de conexión para clientes y servidores indicando cada una de ellas parámetros como el máximo de usuarios, puerto de conexión, opciones de enlace en el caso de servidores, etc. En la conexión entre dos servidores de IRC uno actúa como hub y el otro como leaf, se dice que el primero es el Uplink del segundo, su enlace con el resto de la red. En la interconexión de los nodos de una red de IRC no hay redundancia y por este motivo es posible (y frecuente en el caso de algunas redes) experimentar el fenómeno de los netsplits, separaciones temporales entre los nodos de la red por fallos de conexión o caída de alguno de los nodos que la confrman, resultando esto a la vista de los usuarios en la desaparición repentina y en bloque de todos los usuarios conectados a uno de los servidores que se encuentran en la parte de red de la que ha sido desconectado aquel que les da servicio. En los últimos tiempos una causa bastante frecuente de este tipo de problemas han sido los ataques de denegación de servicio sufridos por alguno o varios de los nodos de la red precisamente con el objetivo de molestar a sus usuarios y crearle mala fama a la red en cuestión. Cuando dos servidores se conectan por primera vez o reconectan tras un netsplit, se desarrolla el proceso conocido como netburst (en la terminología de algunas implementaciones) o netjoin (término más genérico) que consiste en la sincronización de la información del estado de la red en cada lado. Cada nodo informa al otro de los canales y usuarios existentes en la parte de la red que representa así como los usuarios presentes en cada canal, la configuración de cada uno de estos últimos, etc. Este proceso no está exento de problemas y en muchos casos, especialmente en redes medianamente grandes, se dan conflictos entre las dos partes de la red: usuarios duplicados, canales con el mismo nombre y diferentes configuraciones, operadores, etc. Estas desincronizaciones pueden resolverse con diferentes criterios en función del IRCd que estemos utilizando, generalmente atendiendo a fechas (prioridad al más antiguo o nuevo) y jerarquía de la red (prioridad a lo que diga el hub). Existe la posibilidad de proporcionar a algunos nodos de la red privilegios especiales para hacer prevalecer sus órdenes sobre las del resto, por lo general asignadas a nodos de servicios que veremos con más detenimiento posteriormente.

Una vez establecida la conexión estando el IRCd en pleno funcionamiento la mecánica básica consiste en recibir los comandos provenientes de los usuarios y servidores con los que está directamente conectado y procesarlos o propagarlos a su destino final en función de su objetivo, que puede ser el propio servidor, otro servidor, un grupo de servidores especificado por una máscara, un usuario local, un usuario remoto o un canal. De este modo se mantiene la comunicación entre usuarios conectados en diferentes servidores de la red aunque tampoco este mecanismo de propagación está libre de problemas puesto que al no ser la comunicación instantánea, a causa de los diferentes retardos que pudieran existir entre los diferentes nodos de la red es posible que cuando el mensaje llegue a su destino el usuario haya cambiado de nombre, por ejemplo. Este problema está parcialmente subsanado en algunas implementaciones mediante la aplicación de alguna de las mejoras del protocolo original que veremos más adelante.

Servicios del IRC

Con el tiempo las administraciones de las redes de IRC se dieron cuenta de que la funcionalidad original provista por el protocolo IRC era algo limitada. Por ejemplo, el primer usuario en entrar en un canal es designado automáticamente operador de dicho canal y para mantener este privilegio ha de permanecer conectado a la red y dentro del canal en cuestión o bien designar otros operadores que puedan restaurar su estado de operador más adelante. Por otra parte, el nick (alias) de un usuario puede ser establecido siempre y cuando sea válido y esté libre, de modo que un usuario puede encontrarse al conectarse a la red que su nick habitual está opcupado por otro usuario que puede además intentar suplantarle.

Algunos de estos problemas podían ser inicialmente resueltos por los operadores del IRC (IRCops), usuarios con unos privilegios especiales definidos en la configuración del servidor que les permiten hacer cosas como expulsar a un usuario de la red o conceder privilegios de operador en un canal a cualquier usuario sin la necesidad de tener dicho estatus en el canal con anterioridad. No obstante a medida que las redes crecieron esto se tornó claramente ineficiente.

La primera solución a este problema fue la creación de bots (robots del IRC), programas que conectaban como cliente a la red de IRC y, con privilegios de operador y una interfaz en forma de línea de comandos mediante mensajes privados, podían automatizar algunas de estas tareas, por ejemplo permitir el registro de apodos y canales por contraseña y encargarse de autenticar a los usuarios para posteriormente restituirles los privilegios o forzarlos a cambiarse de apodo en caso de no poder demostrar ser los dueños legítimos del mismo.

No obstante esta solución no es del todo eficiente puesto que la implementación en modo cliente hace difícil que el programa robot disponga de toda la información necesaria y generalmente la calidad del enlace con la red es insuficiente, vemos que por ejemplo si queremos que el bot monitorice la actividad de todos los canales debería de estar dentro de todos ellos (algunos IRCd tienen un límite duro en cuanto al máximo de canales en los que puede estar un usuario simultáneamente, en otros casos esto es configurable), lo cual no parece muy adecuado.

La solución a esto son los nodos de servicios. Un nodo de servicios es un tipo especial de IRCd que por lo general no acepta conexiones de clientes ni servidores y únicamente puede ser conectado a un hub. De cara al resto de la red se comporta como uno más, haciendo ver al resto de la red que tiene conectados a él una serie de clientes que no son tales conocidos como pseudoclientes. Estos pseudoclientes actúan a modo de interfaz con los usuarios permitiendo la clásica interacción en forma de línea de comandos, pero el receptor último de los comandos enviados es el propio nodo de servicios que ahora aprovecha todas las facilidades derivadas de su condición de servidor. Los nodos de servicios por lo general disponen además de comandos especiales restringidos al protocolo servidor-servidor permitiéndoles acciones como el renombrado de usuarios, desconexión de otros servidores, etc. Habitualmente algunos de estos comandos requieren una autorización especial como se ha mencionado anteriormente, que permite al resto de nodos de la red identificar al nodo de servicios como tal.

Las funciones más habituales de los nodos de servicios se refieren al registro de usuarios para preservar el uso de su nick, registro de canales, mensajería entre usuarios (una especie de buzón personal para recibir mensajes cuando un usuario no está conectado) y servicios de apoyo a la administración de la red. Otros paquetes de servicios poseen además funcionalidades estadísticas, permitiendo generar informes de uso de la red tales como gráficas representando la fluctuación del número de usuarios y canales en activo a lo largo del tiempo, así como servicios de valor añadido para los usuarios como enlaces con webservices desde un bot de la red de IRC. Otra de las funciones habitualmente llevadas a cabo por los nodos de control es la de prevención de ataques, analizando las conexiones entrantes para intentar decidir si se tratan de conexiones a través de proxies anónimos o similares, (uno de los ataques más típicos en redes de IRC son los ataques de clones).

No obstante este modelo de red presenta una debilidad importante, el problema de la centralización. Al estar los servicios localizados en un nodo (el nodo de servicios), una caída de dicho nodo o un netsplit dejaría al menos una parte de la red fuera del alcance del nodo de control, con lo que se puede decir que la red tiene en el nodo de servicios su punto débil. Ante un netsplit usuarios malintencionados podrían aprovecharse de la ausencia de los servicios de red para suplantar a otro usuario o tomar el control de un canal ajeno. Existe una solución a este problema basada en el control distribuido.

Control distribuido de la red de IRC

Para solucionar el problema de la centralización mencionado y de paso ofrecer a la larga algunos servicios de valor añadido a sus usuarios, la extinta red española ESNET ideó un nuevo mecanismo de gestión de la red de IRC. El nuevo sistema consistía en que cada uno de los nodos de la red dispusiera de su propia copia local de una base de datos distribuida (BDD), similar a la base de datos de los servicios de red pero limitada a la información esencial para el funcionamiento básico de la red.

Inicialmente se empezó almacenando la información de los usuarios, apodo y contraseña. De este modo los usuarios podían autenticarse directamente con el nodo al que se conectaban sin la intervención de un nodo de servicios y con independencia de que la red estuviese en netsplit. Así se evitaba el problema de que un usuario pudiese suplantar a otro durante un netsplit o mientras los servicios de red se encontrasen fuera de servicio. Pronto se fueron encontrando otros usos para la base de datos distribuida, que se organizaba en una serie de tablas con la estructura más simple posible, dos campos, clave y valor (cadenas ambos). Naturalmente este proceso tampoco se libra de problemas de sincronización y fue necesario desarrollar un protocolo conocido como protocolo DB para asegurar que durante la operación normal de la red y en los netburst la información de la base de datos distribuida se mantuviese consistente entre los diferentes nodos.

Aunque en un principio la información de la base de datos era manipulada directamente por los administradores de la red ESNET, pronto se vio este sistema como un complemento para el modelo tradicional del nodo central de control. El nodo de control podía actuar de la manera habitual atendiendo las peticiones de registro y configuración de los usuarios para posteriormente registrar los cambios relevantes en la base de datos distribuida haciendo uso de sus privilegios especiales. Algunas de sus antiguas funciones como la autenticación de usuarios ya no eran necesarias puesto que cada nodo local se encargaría de realizarlas, de este modo los servicios de red aún eran necesarios para dar usuarios de alta o realizar modificaciones pero los servicios mínimos de la red se mantenían en caso de haber problemas. El protocolo DB evolucionó para convertirse en DBH, y se sucedieron varias versiones del mismo.

Otras mejoras reseñables

Aparte de la incorporación de la base de datos distribuida en el IRCd de ESNET, las diferentes variantes del IRCd original han ido incorporando diferentes mejoras al protocolo original, entre las cuales destacamos:

1. Compresión de enlaces: Compresión del tráfico entre servidores para lograr una mayor velocidad de transmisión sacrificando tiempo de CPU (empleado en la compresión y descompresión de la información).
2. Enlaces seguros: Empleo de técnicas como SSL para proteger la comunicación entre servidores y/o con los clientes de filtraciones indeseadas. Lamentablemente, ésta opción parece no ser muy eficaz en cuanto a seguridad.
3. Nuevos modos de canal y usuario: En suma a los modos provistos en el IRC estándar algunos IRCds definen nuevos modos de usuario y canal para ofrecer una mayor funcionalidad a los usuarios: restricción de mensajes privados, de colores enviados a los canales, control de ataques, etc. Conviene encontrar un compromiso entre funcionalidad y eficiencia puesto que algunas posibilidades que pueden resultar divertidas en realidad tienen escasa utilidad real y se traducen en una bajada de rendimiento del IRCd, si bien en función del tamaño de la red nos podemos utilizar un IRCd más o menos cargado de características adicionales.
4. Hosts virtuales: El IRC original permite que un usuario pueda conocer la dirección IP de sus interlocutores y esto se ha traducido durante años en un problema de seguridad para los participantes de la red de IRC dado que en cualquier momento a raíz de una disputa generada en la red uno podía ser el objetivo de ataques de denegación de servicio y similares con el objetivo de desconectar al usuario en cuestión de la red por la fuerza o simplemente para fastidiar. La mayoría de IRCds modernos utilizados en las principales redes de IRC permiten al usuario definir un modo por el cual su dirección IP es sustituida por un nombre de host virtual generalmente resultado de la codificación de su host real de forma que sólo los administradores de la red puedan revertir el proceso. Algunos IRCds permiten además la definición de hosts virtuales personalizados que los usuarios pueden definir a placer como un servicio añadido.
5. Tokenización del protocolo: El protocolo IRC inicial utiliza como identificadores de comando cadenas generalmente autodescriptivas como PRIVMSG o NOTICE que sin embargo resultan ser ineficientes llegando en algunos casos a ocupar más que el propio mensaje a transmitir. Con el fin de minimizar el tráfico y mejorar así la eficiencia del sistema algunos protocolos mejorados permiten además el uso de identificadores (tokens) equivalentes con la mínima longitud posible.
6. Uso de numéricos: Para evitar el problema anteriormente mencionado ocasionado por los retardos cuando un usuario cambia de nick mientras un mensaje para él está en camino y situaciones similares, algunos IRCd asignan a servidores y clientes un identificador único (numérico) oculto al usuario y persistente durante el tiempo que se prolongue la conexión que será utilizado internamente para direccionarlos con independencia del apodo del usuario o nombre del servidor en un momento dado. Adicionalmente los numéricos permiten ahorrar caracteres puesto que por lo general suelen tener una longitud de 2 o 3 caracteres frente a los 32 que puede llegar a tener un apodo.
7. Nuevos comandos: Comandos que aportan funcionalidad adicional como SETNAME o permiten realizar tareas con mayor eficiencia como WATCH (notificación automática de entrada y salida de usuarios en oposición al polling con ISON).

Instalación y configuración del IRCd

En la mayoría de los casos, un IRCd será instalado en un servidor con el fin de federarse con alguna red de IRC ya existente. En estos casos la administración de la red en cuestión proveerá al futuro administrador del servidor con el software a instalar y la configuración a utilizar para la correcta interconexión del nuevo nodo con el resto de la red. Esta operación con frecuencia requerirá también especificar una autorización de conexión para el nuevo nodo en alguno de los hubs de la red.

En el caso de que nos propongamos iniciar una nueva red o montar un servidor de IRC independiente deberemos hacernos primero con algún software IRCd y posteriormente configurarlo por nuestra cuenta. Como se ha comentado con anterioridad la mayoría de IRCd's en el mercado son derivados del original de Jarkko Oikarinen y habitualmente están liberados bajo la GPL. Generalmente funcionan bajo entornos Unix y compatibles, como Linux o FreeBSD, aunque existen algunos IRCds con versión para Windows (e incluso algunos exclusivos para este entorno, no obstante no muy populares) y otros sistemas operativos. La mayoría de estos IRCds, al menos los principales y más conocidos, han sido desarrollados en el seno de alguna red de IRC que tomó una versión anterior y llegado un punto decidió hacer un fork para realizar cambios sustanciales en el protocolo para adaptarlo a sus necesidades. Destacamos el Bahamut de DALnet, el ircU de Undernet, el Hybrid de EFnet, el IRCd original desarrollado por IRCnet y el UnrealIRCd, un IRCd que si bien su desarrollo no está asociado a ninguna red de importancia es muy popular en redes de tamaño medio por la gran cantidad de características que posee en forma de modos de canal y usuario, comandos, etc. También existen IRCds comerciales que sin embargo no han tenido gran calado debido a su escasa calidad en comparación con los anteriormente mencionados, en esta categoría habría que destacar Conference Room.

Una vez elegido y descargado el IRCd a utilizar, en muchos casos tendremos que seguir el procedimiento habitual de compilación e instalación de los entornos *nix y, en cualquier caso, una vez instalado el IRCd deberemos configurarlo. Cada IRCd viene acompañado de una documentación que explica el contenido del fichero de configuración y aunque existen diferencias entre las distintas implementaciones por lo general la información básica que se ha de proporcionar es el nombre del servidor y del administrador, las IPs y puertos de escucha, las clases de conexión, las autorizaciones de conexión para servidores entrantes y las direcciones de los servidores a los que nos hemos de conectar como Leaf. Opcionalmente se pueden definir nodos y usuarios privilegiados (IRCops), exclusiones, etc. Tradicionalmente los ficheros de configuración de los IRCds se organizaban en líneas identificadas por una letra indicando el tipo de opción a definir, seguida por los distintos valores separados por dos puntos según el formato de cada línea. De ahí la denominación de G-lines (exclusiones), O-lines (IRCops), etc. para algunos elementos en el IRC. No obstante muchos IRCd modernos han evolucionado persentando ficheros de configuración en formatos más amigables basados en Bison o XML. Algunos incluso admiten ciertas configuraciones globales de la red a través de una tabla a tal efecto en la base de datos distribuida, en caso de disponer de ella.

Una manera usual de correr un servidor de IRC cuando no se dispone de una máquina es contratar una cuenta de Shell con algún ISP. Conviene fijarse en las condiciones puesto que muchos prohíben explícitamente el tráfico IRC. Otros ofrecen paquetes específicamente destinados a tal uso. Un factor importante a tener en cuenta es el número de usuarios locales que podemos atender simultáneamente, aunque esto no sólo dependerá de las limitaciones impuestas en la máquina sino de la calidad del enlace.

Véase también

En inglés: IRCd Facts for Kids