Un IRCd , abreviatura de Internet Relay Chat daemon , es un software de servidor que implementa el protocolo IRC , lo que permite a las personas hablar entre sí a través de Internet (intercambiando mensajes de texto en tiempo real). [1] [2] Es distinto de un bot de IRC que se conecta de forma saliente a un canal de IRC.
El servidor escucha conexiones de clientes IRC [3] en un conjunto de puertos TCP . [4] Cuando el servidor es parte de una red IRC, también mantiene una o más conexiones establecidas con otros servidores/demonios. [5]
El término ircd originalmente se refería a una única pieza de software, [6] pero eventualmente se convirtió en una referencia genérica para cualquier implementación de un demonio IRC. [7] [8] Sin embargo, la versión original todavía se distribuye con el mismo nombre, [9] y este artículo analiza ambos usos.
El IRCd original se conocía como 'ircd' y fue creado por Jarkko Oikarinen (WiZ en IRC) en 1988. [10] [11] Recibió ayuda de varias otras personas, como Markku Savela (msa en IRC), quien ayudó con el lanzamiento de 2.2+msa, etc.
En sus primeras revisiones, IRC no tenía muchas de las características que hoy se dan por sentadas, como canales con nombre y operadores de canal . Los canales estaban numerados (canal 4 y canal 57, por ejemplo) y el tema del canal describía el tipo de conversación que se desarrollaba en el canal. Un vestigio de esto es que unirse al canal 0 hace que un cliente abandone todos los canales en los que se encuentra actualmente: "CANAL 0" es el comando original para abandonar el canal actual.
El primer cambio importante en IRC, en la versión 2.5, fue agregar canales con nombre : "+channels". Los "+channels" fueron reemplazados por "#channels" en la versión 2.7, los canales numéricos fueron eliminados por completo y se implementaron prohibiciones de canales (modo +b).
Alrededor de la versión 2.7, hubo una pequeña pero notable disputa [ aclaración necesaria ] , que condujo a ircu, la bifurcación Undernet de ircd.
irc2.8 agregó "&channels" (aquellos que existen solo en el servidor actual, en lugar de en toda la red) y "!channels" (aquellos que teóricamente están a salvo de sufrir las muchas formas en que un usuario podría explotar un canal al " montar un netsplit "), y es la versión base de la cual se derivan casi todas las implementaciones actuales.
Alrededor de la versión 2.8 apareció el concepto de retraso de canal y nick, un sistema diseñado para ayudar a frenar prácticas abusivas como las adquisiciones y el split riding. Esto no fue aceptado por la mayoría de los IRC modernos (EFnet, DALnet, Undernet, etc.) y, por lo tanto, la versión 2.8 se dividió en una serie de daemons diferentes utilizando una teoría opuesta conocida como TS, o marca de tiempo, que almacenaba una marca de tiempo única con cada canal o apodo en la red para decidir cuál era el "correcto" que se debía mantener.
El sellado de tiempo en sí mismo ha sido revisado varias veces para corregir diversos problemas en su diseño. Las últimas versiones de dichos protocolos son:
Si bien los protocolos cliente-servidor son al menos funcionalmente similares, los protocolos servidor-servidor difieren ampliamente (los protocolos de servidor TS5, P10 y ND/CD son incompatibles), lo que hace muy difícil "vincular" dos implementaciones separadas del servidor IRC. Existen algunos servidores "puente" que permiten vincular, por ejemplo, servidores 2.10 con servidores TS5, pero estos suelen ir acompañados de restricciones sobre qué partes de cada protocolo se pueden utilizar y no se utilizan ampliamente.
Los lanzamientos importantes basados en 2.8 incluyeron:
El código base original continuó desarrollándose principalmente para su uso en la red IRCnet . Se introdujeron nuevos protocolos de servidor a servidor en la versión 2.10, lanzada en 1998, y en la 2.11, lanzada por primera vez en 2004, y vigente a partir de 2007. [actualizar]Este demonio es utilizado por IRCnet y se puede encontrar en http://www.irc.org/ftp/irc/server/ El ircd original es software libre , licenciado bajo la Licencia Pública General de GNU . Esta línea de desarrollo produjo las 4 RFC de IRC lanzadas después de la RFC 1459, que documentan exclusivamente este protocolo de servidor.
2.8.21+CS e IRCd híbrido continúan utilizándose en EFnet , siendo ircd-ratbox (una rama de ircd-hybrid) a partir de 2004 [actualizar]el más popular.
Más recientemente, se escribieron varios daemons de irc desde cero, como ithildin, [12] InspIRCd, [13] csircd (también escrito por Chris Behrens), ConferenceRoom, [14] Microsoft Exchange Chat Service, WeIRCd, [15] o IRCPlus/IRCXPro. [16]
Estos intentos han tenido un éxito desigual y han suscitado grandes dosis de escepticismo por parte de la comunidad de desarrollo de IRC existente. Con cada nuevo IRCd, se utiliza una versión ligeramente diferente del protocolo IRC, [17] [18] y muchos clientes y bots de IRC se ven obligados a comprometer características o variar su implementación en función del servidor al que están conectados. [19] Estas diferencias se suelen implementar con el fin de mejorar la usabilidad, la seguridad, la separación de poderes o la facilidad de integración con los servicios . Posiblemente una de las diferencias más comunes y visibles sea la inclusión o exclusión del estado de operador de canal semioperativo (que no es un requisito de las RFC).
Los números de puerto asignados oficialmente son 194 ("irc"), 529 ("irc-serv") y 994 ("ircs"). [20] Sin embargo, estos puertos están en el rango privilegiado (0-1024), lo que en un sistema tipo Unix significa que el demonio históricamente tendría que tener privilegios de superusuario para poder abrirlos. Por varias razones de seguridad esto solía ser indeseable.
Los puertos comunes para un proceso IRCd son 6665 a 6669, siendo 6667 el valor predeterminado histórico. [21] Estos puertos pueden ser abiertos por un proceso que no sea superusuario y se volvieron ampliamente utilizados.
Para ejecutar un servidor IRC de gran tamaño, que tenga más de unos pocos miles de usuarios simultáneos, es necesario mantener abiertas durante largos períodos una gran cantidad de conexiones TCP . Muy pocos servidores IRC tienen varios subprocesos , ya que casi todas las acciones necesitan acceder (al menos leer y posiblemente modificar) el estado global.
El resultado es que las mejores plataformas para ircds son aquellas que ofrecen mecanismos eficientes para manejar grandes cantidades de conexiones en un único hilo. Linux ofrece esta capacidad en forma de epoll , en series de kernel posteriores a 2.4.x. FreeBSD (desde 4.1) y OpenBSD (desde 2.9) ofrecen kqueue . Solaris ha tenido /dev/poll desde la versión 7, y desde la versión 10 en adelante tiene IOCP (I/O Completion Ports). Windows ha soportado IOCP desde Windows NT 3.5. La diferencia que hacen estas nuevas interfaces puede ser dramática. Los desarrolladores de IRCU han mencionado aumentos en la capacidad práctica por servidor de 10.000 usuarios a 20.000 usuarios. [ cita requerida ]
Algunos IRCd admiten Transport Layer Security (TLS), pero para aquellos que no lo hacen, aún es posible utilizar SSL a través de Stunnel . El puerto no oficial, pero más utilizado para conexiones IRCd TLS es 6697. Más recientemente, como una mejora de la seguridad y la usabilidad, varios autores de clientes y servidores han comenzado a redactar un estándar conocido como el estándar STARTTLS [22] que permite que las conexiones TLS y de texto sin formato coexistan en el mismo puerto TCP.
Los daemons de IRC admiten IPv4 y algunos también admiten IPv6 . En general, la diferencia entre las conexiones IPv6 e IPv4 a IRC es puramente académica y el servicio funciona de la misma manera a través de cualquiera de los dos protocolos.
Las redes IRC de gran tamaño constan de varios servidores con fines de escalabilidad horizontal . Existen varias extensiones del protocolo IRC para estos fines. [23]
IRCX (Internet Relay Chat eXtensions) es una extensión del protocolo IRC desarrollado por Microsoft
El protocolo P10 es una extensión del protocolo Internet Relay Chat para comunicaciones de servidor a servidor desarrollado por el Undernet Coder Committee para su uso en el software de servidor ircu. Es similar en su propósito a los protocolos IRCX y EFnet TS5/TS6 e implementa el marcado de tiempo de canal y nick para manejar colisiones de nick y división de canal de red, respectivamente. Otros IRCd que utilizan esta extensión de protocolo incluyen beware ircd. [23] [24] [25]
El protocolo TS6 es una extensión del protocolo Internet Relay Chat para comunicaciones de servidor a servidor desarrollado inicialmente por los desarrolladores de ircd-ratbox. Se ha extendido mediante varios programas de IRC y tiene la característica de que las implementaciones adecuadas de TS6 pueden vincularse entre sí mediante la negociación de características, incluso si las características son dispares.
El término "bloquear" un servidor, un canal o un apodo se refiere a la práctica de bloquear dicho canal o apodo en el servidor o red o dicho servidor en la red. Una posible explicación de cómo surgió este término es que lleva el nombre del operador llamado Jupiter, que obtuvo el control del apodo NickServ en EFnet . [26] [ cita requerida ] EFnet no ofrece servicios como NickServ; Jupiter obtuvo el control del apodo ya que él (entre otros operadores) no creía que los apodos debieran ser propiedad de un propietario. Hoy en día, los operadores de EFnet bloquean apodos que se usan como servicios en otras redes.
Un apodo o jupe de servidor aprovecha el hecho de que ciertos identificadores son únicos; al usar un identificador, uno adquiere un bloqueo exclusivo que impide que otros usuarios lo utilicen.
Los jupes sancionados oficialmente también pueden utilizar servicios u opciones de configuración del servidor para hacer cumplir el jupe, como cuando se realiza un jupe a un servidor comprometido para evitar que dañe la red.
En la práctica, los operadores de IRC ahora utilizan configuraciones de jupe para hacer que los canales o los apodos no estén disponibles administrativamente. [27] Un jupe de canal se refiere a una prohibición específica de un servidor de un canal, lo que significa que no se puede ingresar a un canal específico cuando se está conectado a un servidor determinado, pero otros servidores pueden permitir que un usuario se una al canal. Esta es una forma de prohibir el acceso a canales problemáticos.
Una línea O (frecuentemente también escrita como O:line [ cita requerida ] ; en los IRCd que admiten operadores locales, las líneas O de estos se llaman o:lines con una O minúscula [ cita requerida ] ), abreviada de Operator Line y derivada del archivo de configuración basado en líneas del IRCd original, es una línea de código en un archivo de configuración del demonio de IRC que determina qué usuarios pueden convertirse en operadores de IRC y qué permisos obtienen al hacerlo. El nombre proviene del prefijo utilizado para la línea en el IRCd original, una O mayúscula. La línea O especifica el nombre de usuario, la contraseña, los indicadores del operador y las restricciones de la máscara de host para un operador en particular. Un servidor puede tener muchas líneas O según las necesidades administrativas del servidor y la red. [28]
Los indicadores de operador se utilizan para describir los permisos que se le otorgan a un operador. Si bien algunos operadores de IRC pueden estar a cargo del enrutamiento de la red, otros pueden estar a cargo del abuso de la red, lo que hace que su necesidad de ciertos permisos sea diferente. [4] Los indicadores de operador disponibles varían ampliamente según el demonio de IRC que se esté utilizando. En general, los demonios de IRC con más funciones tienden a tener más indicadores de operador, y los demonios de IRC más tradicionales tienen menos.
También se puede configurar una línea O para que solo los usuarios de una determinada máscara de host o dirección IP puedan obtener el estado de operador de IRC mediante esa línea O. El uso de máscaras de host y direcciones IP en la línea O requiere que la dirección IP permanezca igual, pero brinda seguridad adicional.
Cuando un usuario es bloqueado (abreviatura de kill line ), se le prohíbe el acceso a un servidor determinado, ya sea por un tiempo determinado o de forma permanente. Una vez bloqueado, no se le permite volver a ingresar a ese servidor. Esto se registra como una línea en el archivo de configuración del demonio IRC del servidor con el prefijo "K", de ahí "K-line".
Algunos daemons de IRC, incluido ircd-hybrid y sus descendientes, pueden configurarse para propagar líneas K a algunos o todos los demás servidores de una red. En esa configuración, las líneas K son efectivamente prohibiciones globales similares a las líneas G.
Si bien el motivo preciso de la desconexión varía de un caso a otro, los motivos más habituales involucran algún aspecto del cliente o del usuario contra el que se emite.
Hay una serie de otras "líneas" de red relacionadas con la línea K. Los daemons de IRC modernos también permitirán a los operadores de IRC configurar estas líneas durante el funcionamiento normal, cuando no se necesita acceder rutinariamente al archivo de configuración del servidor.
Una G-line o línea de eliminación global (también escrita G:line ) es una prohibición de red global aplicada a un usuario; el término proviene de Undernet pero en DALnet se usaba un concepto similar conocido como AKill . [ cita requerida ]
Las líneas G a veces se almacenan en el archivo de configuración del IRCd, aunque algunas redes, que manejan líneas K a través de los servicios IRC , prefieren tenerlas almacenadas en los archivos de configuración de sus servicios. Siempre que una persona con línea G intente conectarse a la red IRC, los servicios o el demonio IRC desconectarán automáticamente al cliente, a menudo mostrando un mensaje que explica el motivo de la prohibición.
Las líneas G son una variante de las líneas K, que funcionan de forma muy similar, excepto que las líneas K solo desconectan a los clientes de un servidor de la red. Las líneas G se aplican normalmente a un usuario que ha recibido una línea K en un servidor pero continúa abusando de la red conectándose a través de un servidor diferente. Las líneas G suelen considerarse una medida extrema, que solo se utiliza en casos de abuso repetido cuando se han hecho muchos intentos de razonar con el usuario infractor. Por lo tanto, especialmente en redes más grandes, a menudo solo se permite que los operadores de IRC globales de alto rango las establezcan, mientras que las líneas K, que en su mayoría se consideran un asunto local, se dejan en manos de los operadores del servidor individual de la red.
Las líneas G también funcionan de forma ligeramente diferente a las líneas K. Las líneas G suelen configurarse como *@IPaddress o *@host, siendo la primera la mejor opción. Si se utiliza la opción *@host, el servidor debe realizar una búsqueda DNS inversa del usuario y luego comparar el host devuelto con los hosts de la lista de líneas G. Esto genera demoras y, si el DNS no devuelve resultados correctos, el usuario bloqueado puede seguir accediendo a la red.
Una línea Z o línea zap (también escrita Z:line ) es similar a una línea K, pero se aplica al rango de direcciones IP de un cliente y se considera que se utiliza en casos extremos. Debido a que una línea Z no tiene que verificar los nombres de usuario (identd) o los nombres de host resueltos , se puede aplicar a un usuario antes de que envíe cualquier dato al conectarse. Por lo tanto, una línea Z es más eficiente y utiliza menos recursos que una línea K o una línea G cuando se prohíbe el acceso a una gran cantidad de usuarios.
En algunos demonios IRC como ircd-hybrid, esto se llama línea D ( línea de denegación) o línea X.
Las líneas Z a veces se almacenan en el archivo de configuración del IRCd, aunque algunas redes, que manejan líneas a través de los servicios IRC, prefieren tenerlas almacenadas en los archivos de configuración de sus servicios. Siempre que una persona con línea Z intente conectarse a la red IRC, los servicios o el demonio IRC desconectarán automáticamente al cliente, a menudo mostrando un mensaje que explica el motivo de la prohibición.
Las líneas Z son una variante de las líneas K, que funcionan de forma muy similar. La mayoría de las líneas Z se "otorgan" a personas que abusan de la red en su conjunto (en redes más pequeñas, se otorgan con mayor frecuencia por incidentes aislados).
Las líneas Z también funcionan de forma ligeramente diferente a las líneas K. Las líneas Z se configuran normalmente como *@IP o *@host, siendo la primera la mejor opción. Las líneas Z no esperan una respuesta de identificación del usuario que se conecta, sino que cierran inmediatamente el socket una vez que se compara la IP del usuario con la lista de líneas Z y se encuentra una coincidencia. Si se utiliza la opción *@host, el servidor debe realizar una búsqueda DNS inversa en el usuario y luego comparar el host devuelto con los hosts de la lista de líneas Z. Esto puede resultar en demoras o, si el DNS no devuelve correctamente, los usuarios baneados aún podrían ingresar a la red. En realidad, la opción *@host va completamente en contra de las intenciones de usar una línea Z y, por lo tanto, algunos programas IRCd no permitirán nada que no sea *@IP, con comodines (?,*) o longitudes de prefijo CIDR ( por ejemplo, /8) permitidos en la sección IP para bloquear subredes enteras. Otra diferencia con las líneas K (que afectan solo a los clientes de IRC) es que si una IP está baneada, nada, ni siquiera otros servidores, puede conectarse desde esta IP (o rango de IP, dependiendo de la máscara de baneo).
Una ventaja de usar líneas Z en lugar de líneas K y líneas G, desde la perspectiva de un servidor o administrador de red, es que una línea Z utiliza menos ancho de banda que una línea K, principalmente porque no espera una respuesta de identificación o una búsqueda de DNS .
Una desventaja de usar Z-line en lugar de K-line o G-line es que resulta más difícil prohibir ISPs completos y direcciones IP muy dinámicas, algo común en algunas conexiones de acceso telefónico y DSL . Por ejemplo, si un administrador de red desea prohibir todo el ISP example.com (con rangos de direcciones IP hipotéticos de 68.0.0.0 – 68.255.255.255 y 37.0.0.0 – 38.255.255.255), una G-line podría usar *@*example.com, mientras que una Z-line requeriría *@37.*.*.*, *@38.*.*.* y *@68.*.*.* para lograr lo mismo.
Las líneas Z también pueden ser globales, en cuyo caso se denominan líneas GZ . Las líneas GZ funcionan de la misma manera que las líneas Z, excepto que se propagan a todos los servidores de la red. Algunos daemons de IRC también pueden configurarse para compartir líneas Z con otros servidores.
En algunos IRCds, como UnrealIRCd, una línea Q prohíbe un apodo, o cualquier apodo que coincida con un patrón dado. Esto se usa más a menudo para prohibir el uso de apodos de servicios (como "X" o NickServ ) o prohibir el uso de apodos de operadores de IRC por parte de no operadores. Algunos demonios de IRC pueden desconectar a los usuarios cuando se aplica inicialmente la línea Q, mientras que otros forzarán un cambio de apodo, o no harán nada hasta que el usuario cubierto por la línea Q se vuelva a conectar. Otros IRCds, como ircd-hybrid, usan el comando "RESV" ("reservar") en su lugar, con la letra de estadísticas que permanece como Q. El comando "RESV" también puede prohibir el uso de un canal.
{{cite journal}}: Requiere citar revista |journal=( ayuda ){{cite journal}}: Requiere citar revista |journal=( ayuda ){{cite journal}}: Requiere citar revista |journal=( ayuda ){{cite journal}}: Requiere citar revista |journal=( ayuda ){{cite journal}}: Requiere citar revista |journal=( ayuda )