El protocolo cliente a cliente ( CTCP ) es un tipo especial de comunicación entre clientes de Internet Relay Chat (IRC).
CTCP es un protocolo común implementado por la mayoría de los principales clientes de IRC en uso en la actualidad. [ cita requerida ] CTCP extiende el protocolo IRC original al permitir que los usuarios consulten a otros clientes o canales, esto hace que todos los clientes en el canal respondan el CTCP, para obtener información específica. Además, CTCP se puede utilizar para codificar mensajes que el protocolo IRC sin procesar no permitiría enviar a través del enlace, como mensajes que contienen nuevas líneas o el valor de byte 0 (NULL). CTCP no establece una conexión directa entre clientes; sin embargo, se usa comúnmente para negociar conexiones DCC .
CTCP permite a los usuarios consultar a un cliente remoto sobre la versión del cliente que están usando (vía CTCP VERSION
), o la hora (vía CTCP TIME
), entre otras cosas. También se usa para implementar el comando / me (vía CTCP ACTION
).
Historia
ircII fue el primer cliente de IRC en implementar los protocolos CTCP y DCC. [1] El protocolo CTCP fue implementado por Michael Sandrof en 1990 para la versión 2.1 de ircII, [2] mientras que el protocolo DCC fue implementado por Troy Rollo en 1991 para la versión 2.1.2. [3]
Estructura
Un mensaje CTCP se implementa como un PRIVMSG
o NOTICE
donde el primer y último carácter del mensaje son el valor ASCII 0x01. Además, se escapan los caracteres que no estarían permitidos en el protocolo IRC. Dado que a NOTICE
como estándar no debería generar una respuesta, los mensajes CTCP se envían como PRIVMSG
y la respuesta se implementa con a en NOTICE
lugar de a PRIVMSG
.
Una consulta CTCP se inicia en la mayoría de los clientes de la siguiente manera:
CTCP
Donde VERSION
. Ej. ), Y
Comandos CTCP comunes
Los comandos y respuestas de CTCP son específicos del cliente; como tal, dependiendo del cliente de IRC, es posible que algunos de los siguientes comandos CTCP no activen una respuesta o tengan un formato diferente al que se muestra aquí.
VERSIÓN
Una CTCP VERSION
petición devolverá el nombre y la versión del cliente de IRC el objetivo está utilizando, y en algunos casos la información técnica, tales como el sistema operativo , la velocidad del reloj , la CPU del fabricante y la arquitectura de CPU / conjunto de instrucciones .
Una respuesta de muestra para una CTCP VERSION
solicitud a un objetivo que usa el cliente HexChat (una bifurcación de XChat) es:
VERSIÓN HexChat 2.9.1 [x86] / Windows 8 [1.46GHz]
HORA
Una CTCP TIME
solicitud devolverá la hora local de la computadora de destino. Dependiendo del cliente de IRC, la respuesta puede consistir en la fecha , la hora (ya sea en formato de 12 horas o en formato de 24 horas ), el año (por ejemplo, 2012) y, a veces, la zona horaria (por ejemplo, EST ).
Una respuesta de muestra para una CTCP TIME
solicitud a un objetivo que usa el cliente ChatZilla es:
HORA Viernes 23 de noviembre de 2012 19:26:42 EST
SILBIDO
Una CTCP PING
solicitud determinará la tasa de ping que existe directamente entre dos clientes (es decir, descontando el servidor). El CTCP PING
comando funciona enviando un argumento entero (a menudo) (una marca de tiempo ) a un cliente de destino, el cliente de destino responde proporcionando exactamente el mismo parámetro numérico. Se calcula la diferencia entre la marca de tiempo original y la marca de tiempo actual, y el resultado se muestra al usuario que inició el CTCP PING . La mayoría de las veces, se utiliza una marca de tiempo que utiliza milisegundos debido a que la mayoría de los usuarios con conexiones a Internet de banda ancha tienen un ping de menos de 1 segundo.
Una CTCP PING
solicitud de muestra para apuntar a
CTCP PING 23152511
Del mismo modo, la salida de muestra generada a partir de la diferencia (ver arriba) es:
Respuesta de ping de: 0.53 segundo (s)
CHAT DCC
El servicio CHAT permite a los usuarios charlar entre ellos a través de una conexión DCC. El tráfico irá directamente entre los usuarios y no a través de la red IRC. En comparación con el envío de mensajes normalmente, esto reduce la carga de la red de IRC, permite el envío de grandes cantidades de texto a la vez, debido a la falta de control de inundaciones, y hace que la comunicación sea más segura al no exponer el mensaje a los servidores de IRC (sin embargo, el el mensaje todavía está en texto plano ).
El CHAT DCC normalmente se inicia mediante un protocolo de enlace CTCP . El usuario que desea establecer la conexión envía el siguiente CTCP al destino, donde ip y puerto son la dirección IP y el número de puerto del remitente, y se expresan como números enteros. El protocolo es chat para DCC CHAT estándar. La parte receptora puede conectarse al puerto y la dirección IP dados.DCC CHAT protocol ip port
Una vez que se establece una conexión, el protocolo utilizado para DCC CHAT es muy simple: los usuarios intercambian mensajes terminados en CRLF . Los mensajes que comienzan con un ASCII 001 (control-A, representado a continuación por [^ A] ) y la palabra ACCIÓN , y son terminados por otro ASCII 001 , se interpretan como emotes: [^A]ACTION waves goodbye[^A]
.
Pizarra DCC
Se trata de una extensión de DCC CHAT, que permite enviar comandos de dibujo sencillos, así como líneas de texto. DCC Whiteboard se inicia con un protocolo de enlace similar al DCC CHAT, con el protocolo chat reemplazado por wboard : .DCC CHAT wboard ip port
Una vez que se establece la conexión, los dos clientes intercambian mensajes terminados con CRLF . Mensajes que comienzan (y opcionalmente terminan) con ASCII 001 se interpretan como comandos especiales; El comando ACCIÓN representa un emote, mientras que otros hacen que se dibujen líneas en la superficie de la pizarra del usuario o permiten que los dos clientes negocien un conjunto de características.
ENVIAR DCC
El servicio SEND permite a los usuarios enviarse archivos entre sí. La especificación original para el protocolo de enlace no permitía al receptor conocer el tamaño total del archivo ni reanudar una transferencia. Esto ha hecho que los clientes introduzcan sus propias extensiones al apretón de manos, muchas de las cuales cuentan con un amplio apoyo.
El apretón de manos original consistió en el envío de la siguiente CTCP al receptor remitente: .DCC SEND filename ip port
Al igual que con DCC CHAT, ip y puerto son la dirección IP y el puerto donde la máquina emisora estará escuchando una conexión entrante. Algunos clientes encierran los nombres de archivo con espacios entre comillas dobles. Es una práctica común añadir el tamaño del archivo como último argumento: .DCC SEND filename ip port file size
En este punto, la especificación original hacía que el receptor se conectara a la dirección y el puerto dados y esperara los datos, o ignorara la solicitud, pero para los clientes que admiten la extensión DCC RESUME, una tercera alternativa es pedirle al remitente que omita parte del mensaje. archivo mediante el envío de la respuesta CTCP: .DCC RESUME filename port position
Si el cliente de envío admite DCC RESUME, responderá con, y el receptor puede conectarse a la dirección y el puerto dados y escuchar los datos para agregarlos a un archivo ya existente.DCC ACCEPT filename port position
Los datos se envían al cliente en bloques, cada uno de los cuales el cliente debe reconocer enviando el número total de bytes recibidos en forma de un entero de orden de bytes de red de 32 bits . Esto ralentiza las conexiones y es redundante debido a TCP . La extensión de envío anticipado alivia un poco este problema al no esperar los reconocimientos, pero dado que el receptor aún tiene que enviarlos por cada bloque que recibe, en caso de que el remitente los espere, no se resuelve por completo.
Otra extensión, TDCC o turbo DCC, elimina los reconocimientos, pero requiere un protocolo de enlace ligeramente modificado y no es ampliamente compatible. Las versiones anteriores de TDCC reemplazaron la palabra SEND en el apretón de manos por TSEND; las versiones posteriores usan la palabra ENVIAR, pero agregan un T después del protocolo de enlace, haciendo que esta versión de TSEND sea compatible con otros clientes (siempre que puedan analizar el protocolo de enlace modificado).
Explotación DCC SEND
El exploit de envío DCC puede referirse a dos errores, un error de desbordamiento de búfer variante en mIRC desencadenado por nombres de archivo de más de 14 caracteres [4] y un error de validación de entrada en algunos enrutadores fabricados por Netgear , D-Link y Linksys , desencadenado por el uso de Puerto 0 . [5] [6] El exploit del enrutador, en particular, puede activarse cuando la frase ' DCC SEND 'seguido de al menos 6 caracteres sin espacios o líneas nuevas aparece en cualquier lugar de una secuencia TCP en el puerto 6667, no solo cuando se ha realizado una solicitud DCC SEND real.
DCC XMIT
El servicio XMIT es una versión modificada de DCC SEND que permite reanudar archivos y reduce el tráfico inútil de los largos de ACK. XMIT no es ampliamente compatible.
El apretón de manos XMIT difiere algo del apretón de manos SEND. El remitente envía un CTCP ofreciendo un archivo al receptor:DCC XMIT protocol ip port[ name[ size[ MIME-type]]]
Aquí, los corchetes encierran piezas opcionales. protocolo es el protocolo que se utilizará para la transferencia; solo claro se define actualmente. A diferencia de DCC SEND estándar, ip puede estar en las formas adicionales de notación estándar con puntos para IPv4, o en notación hexadecimal o mixta para IPv6. Para dejar un parámetro inicial vacío, pero aún proporcionar uno posterior, el anterior se puede especificar como - . Si el receptor no implementa el protocolo utilizado, se enviará de vuelta una respuesta CTCP del formato: .ERRMSG DCC CHAT protocol unavailable
CHAT se utiliza aquí para mantener la compatibilidad con los mensajes de error enviados por el DCC CHAT ampliado. Si el receptor rechaza la transferencia, envía la siguiente respuesta CTCP: .ERRMSG DCC CHAT protocol declined
Otros errores se informan de la misma manera. Si el receptor está dispuesto y es capaz de recibir el archivo, se conectará a la dirección y al puerto indicados. Lo que sucede entonces depende del protocolo utilizado.
En el caso de la clara protocolo, el servidor XMIT será, al recibir una conexión, enviar una de 32 bits time t
en el orden de bytes de red , lo que representa el tiempo de modificación del archivo. Presumiblemente, basándose en la hora de modificación del archivo local, el cliente enviará otro orden de bytes de red long
, un desplazamiento que el servidor debe buscar al enviar el archivo. Esto debe establecerse en cero si se desea el archivo completo, o el tamaño del archivo local si el cliente desea reanudar una descarga anterior.
Si bien es más rápido que SEND, XMIT tiene una de las mismas limitaciones en el sentido de que es imposible saber qué tan grande es el archivo, a menos que su tamaño se especifique en la negociación CTCP o se conozca de antemano. Además, no es posible reanudar un archivo más allá de la marca de dos gigabytes debido al desplazamiento de 32 bits.
DCC pasivo
En una conexión DCC normal, el iniciador actúa como servidor y el objetivo es el cliente . Debido al firewall generalizado y la reducción de la transparencia de un extremo a otro debido a NAT , es posible que el iniciador no pueda actuar como servidor. Se han ideado varias formas de pedirle al objetivo que actúe como servidor:
Servidor DCC
Esta extensión a DCC SEND y CHAT normales fue introducida por el cliente IRC mIRC . DCC Server tiene un soporte moderado, pero no es estándar en todos los clientes (consulte Comparación de clientes de Internet Relay Chat ).
Permite el inicio de una conexión DCC por dirección IP, sin necesidad de un servidor IRC. Esto se logra cuando el cliente receptor actúa como un servidor (de ahí el nombre) escuchando (generalmente en el puerto 59) para un apretón de manos del remitente.
Para un CHAT, el iniciador envía . A continuación, el objetivo responde con, y el resto procede de acuerdo con el protocolo DCC CHAT estándar.1000 initiator nick
1000 target nick
Para un ENVIAR, el iniciador envía . El objetivo responde con,, donde la posición de reanudación es el desplazamiento en el archivo desde el que comenzar. Desde aquí, la transferencia procede como un ENVÍO DCC normal.1200 initiator nick filesize filename
1210 target nick resume position
DCC Server también admite servidores de archivos de estilo mIRC y DCC GET.
RDCC
DCC Server no proporciona ninguna forma de especificar el puerto que se utilizará, por lo que esto debe negociarse manualmente, lo que no siempre es posible, ya que uno de los lados puede no ser humano. RDCC es un mecanismo de protocolo de enlace para DCC Server, que además del puerto también proporciona la dirección IP del servidor, que es posible que el cliente no pueda encontrar de otra manera debido al enmascaramiento del host. No tiene un amplio apoyo.
El iniciador solicita el puerto en el que está escuchando el objetivo enviando la consulta CTCP , donde la función es RDCC function comment
c para charlar, s para enviar, o f para servidor de archivos.
El objetivo puede entonces responder CTCP con ,, donde ip y puerto tienen los mismos significados que para DCC SEND y CHAT normales. Después de esto, el iniciador se conecta a la ip y al puerto , y sigue un protocolo de enlace del servidor DCC.RDCC 0 ip port
DCC REVERSA
A diferencia del servidor DCC, donde el protocolo de enlace se maneja a través de una conexión IP directa, DCC REVERSE tiene un protocolo de enlace CTCP normal, similar al que utiliza DCC SEND. Esto no está ampliamente implementado. El emisor ofrece un archivo al receptor enviando el mensaje CTCP: . La clave es una cadena de caracteres ASCII de entre 1 y 50 caracteres en el rango de 33 a 126 y actúa como un identificador para la transferencia.DCC REVERSE filename filesize key
Si el receptor acepta, envía la respuesta CTCP, DCC REVERSE key start ip port
Aquí, start es la posición en el archivo desde la cual comenzar a enviar, ip es la dirección IP del receptor en notación estándar con puntos para IPv4 , o notación hexadecimal para IPv6 . El remitente luego se conecta a la dirección IP y al puerto indicado por el receptor, y sigue un DCC SEND normal. Tanto el emisor como el receptor pueden cancelar el apretón de manos mediante el envío de la respuesta CTCP, .DCC REJECT REVERSE key
DCC RSEND
Esta es la alternativa del cliente KVIrc a DCC REVERSE. El emisor ofrece un archivo mediante el envío de la CTCP: . El receptor puede entonces aceptar mediante CTCP respondiendo con, y el remitente se conecta al receptor y envía como durante un ENVÍO DCC normal.DCC RSEND filename filesize
DCC RECV filename ip port start
DCC inverso / cortafuegos
Este mecanismo DCC pasivo es compatible con al menos mIRC , Visual IRC , XChat , KVIrc, DMDirc , Klient , Konversation y PhibianIRC . El emisor ofrece un archivo enviando el mensaje CTCP, . ip es la dirección IP del remitente en orden de bytes de red, expresada como un solo entero (como en DCC estándar). Se envía el número 0 en lugar de un puerto válido, lo que indica que se trata de una solicitud DCC inversa. token es un número entero único; si TSEND está siendo utilizado (por un cliente que lo apoya), la carta DCC SEND filename ip 0 filesize token
Se agrega una T al token, lo que le permite al receptor saber que no necesita enviar reconocimientos.
El receptor puede aceptar el archivo mediante la apertura de un socket de escucha y responde con el mensaje CTCP, . Es idéntico al mensaje DCC inverso original, excepto que la dirección IP y el puerto identifican el enchufe donde está escuchando el receptor. token es el mismo que en la solicitud original, lo que le permite al remitente saber qué solicitud está siendo aceptada. (Debido a que este mensaje sigue el mismo formato que una solicitud de envío de DCC normal, algunos servidores que filtran las solicitudes de DCC pueden requerir que el remitente agregue el receptor a su lista de "permitidos de DCC").DCC SEND filename ip port filesize token
El remitente luego se conecta al conector del receptor, envía el contenido del archivo y espera a que el receptor cierre el conector cuando el archivo está terminado.
Cuando se utiliza la extensión RESUME del protocolo SEND, la secuencia de comandos se convierte en (con >> indicando un mensaje saliente en el lado de inicio, y << respuesta de su par):
>> DCC SEND filename ip 0 filesize token
<< DCC RESUME filename 0 position token
>> DCC ACCEPT filename 0 position token
<< DCC SEND filename peer-ip port filesize token
Después de lo cual el protocolo procede normalmente (es decir, el remitente se conecta a la toma del receptor).
Servidores de archivos (FSERV)
Un fserve DCC , o servidor de archivos, permite al usuario navegar, leer y descargar archivos ubicados en un servidor DCC.
Normalmente, esto se implementa con una sesión DCC CHAT (que presenta al usuario un símbolo del sistema) o comandos CTCP especiales para solicitar un archivo. Los archivos se envían a través de DCC SEND o DCC XMIT. Hay muchas implementaciones de servidores de archivos DCC, entre ellas el comando FSERV en el popular cliente mIRC .
Ver también
- Chat de retransmisión por Internet (IRC)
- Cliente de IRC
- Comparación de los clientes de Internet Relay Chat
- DCC (cliente directo a cliente)
Referencias
- ^ Piccard, Paul; Brian Baskin; George Spillman; Marcus Sachs (1 de mayo de 2005). "Redes IRC y Seguridad". Protección de aplicaciones de mensajería instantánea y P2P para empresas (1ª ed.). Syngress. pag. 386. ISBN 1-59749-017-2.
Los autores del paquete de software ircII fueron pioneros en la transferencia de archivos a través de IRC.
- ^ Vea los archivos 'NOTAS' y 'source / ctcp.c' incluidos con ircii-2.1.4e.tar.gz [ enlace muerto permanente ]
- ^ Consulte los archivos 'ACTUALIZACIONES' y 'fuente / dcc.c' incluidos con ircii-2.1.4e.tar.gz [ enlace muerto permanente ]
- ^ "Información de explotación de SecurityFocus" .
- ^ " Vulnerabilidad ' DCC Send' en enrutadores Netgear" .
- ^ " Vulnerabilidad ' DCC Send' en enrutadores Linksys" .
enlaces externos
- Detalles de CTCP