Введение
Протокол для передачи файлов и прямого чата в Internet Relay Chat
Direct Client to Client (DCC) (первоначально Direct Client Connection) – это подпротокол, связанный с IRC, позволяющий пользователям напрямую соединяться друг с другом, используя IRC-сервер для установления соединения с целью обмена файлами или проведения чата без ретрансляции через сервер. После установления соединения типичный сеанс DCC функционирует независимо от IRC-сервера. Изначально разработанный для использования с ircII, он теперь поддерживается многими IRC-клиентами. Некоторые одноранговые клиенты на серверах протокола Napster также обладают возможностью отправки и получения файлов через DCC, включая TekNap, SunshineUN и Lopster. Существует вариант протокола DCC под названием SDCC (Secure Direct Client to Client), также известный как DCC SCHAT, который поддерживает зашифрованные соединения. Официальной спецификации RFC для использования DCC не существует. Соединения DCC могут быть инициированы двумя способами: наиболее распространенный способ – использование CTCP для начала сеанса DCC. CTCP отправляется от одного пользователя через сеть IRC другому пользователю. Альтернативный способ инициирования сеанса DCC – прямое подключение клиента к DCC-серверу. В этом случае трафик не проходит через сеть IRC (сторонам не требуется подключение к IRC-сети для установления соединения DCC).
The most common way is to use CTCP to initiate a DCC session. The CTCP is sent from one user, over the IRC network, to another user. Another way to initiate a DCC session is for the client to connect directly to the DCC server. Using this method, no traffic will go across the IRC network (the parties involved do not need to be connected to an IRC network in order to initiate the DCC connection).
История
ircII был первым IRC-клиентом, реализовавшим протоколы CTCP и DCC. Протокол CTCP был разработан Майклом Сандрофом в 1990 году для версии ircII 2.1. Протокол DCC был разработан Троем Ролло в 1991 году для версии 2.1.2, однако изначально не планировался для портирования на другие IRC-клиенты.
DCC CHAT
Служба CHAT позволяет пользователям общаться друг с другом через DCC-соединение. Трафик передается напрямую между пользователями, а не через сеть IRC. По сравнению с обычной отправкой сообщений, это снижает нагрузку на сеть IRC, позволяет отправлять большие объемы текста за один раз из-за отсутствия защиты от флуда и повышает безопасность связи, поскольку сообщение не проходит через серверы IRC (однако сообщение остается в виде обычного текста). DCC CHAT обычно инициируется с помощью CTCP-рукопожатия. Пользователь, желающий установить соединение, отправляет целевому пользователю следующий CTCP-запрос: DCC CHAT <IP-адрес> <порт>, где <IP-адрес> и <порт> – это IP-адрес и номер порта отправителя, представленные в виде целых чисел. <порт> равен 6667 для стандартного DCC CHAT. Получатель может затем подключиться к указанному порту и IP-адресу. После установления соединения протокол DCC CHAT очень прост: пользователи обмениваются сообщениями, завершающимися символами CRLF. Сообщения, начинающиеся с ASCII 001 (управляющий символ A, представленный ниже символом ^A) и слова ACTION, и заканчивающиеся другим символом ^A, интерпретируются как эмоции: [^A]ACTION машет на прощание[^A].
Доска DCC
Это расширение для DCC CHAT, позволяющее отправлять простые команды рисования, а также текстовые строки. DCC Whiteboard инициируется обменом данными, аналогичным DCC CHAT, но с заменой протокола на: DCC CHAT wboard. После установления соединения, два клиента обмениваются сообщениями, завершающимися символами CRLF. Сообщения, начинающиеся (и опционально заканчивающиеся) символом ASCII, интерпретируются как специальные команды; команда представляет собой эмоцию, а остальные вызывают отрисовку линий на поверхности доски пользователя или позволяют двум клиентам согласовать набор функций.
DCC CHAT wboard
Once the connection is established, the two clients exchange CRLF terminated messages. Messages that begin (and optionally end) with ASCII are interpreted as special commands; the command represents an emote, while others cause lines to be drawn on the user's whiteboard surface, or allow the two clients to negotiate a set of features.
DCC SEND
Служба SEND позволяет пользователям отправлять файлы друг другу. Изначальная спецификация протокола обмена данными не позволяла получателю узнать общий размер файла и возобновить передачу. Это вынудило клиентов внедрять собственные расширения протокола обмена, многие из которых получили широкую поддержку. Изначальный протокол обмена состоял в том, что отправитель отправлял получателю следующий CTCP-сообщение: DCC SEND Как и в случае с DCC CHAT, и – это IP-адрес и порт, на котором отправитель будет ожидать входящее соединение. Некоторые клиенты заключают имена файлов, содержащие пробелы, в двойные кавычки. Обычно в качестве последнего аргумента добавляется размер файла: DCC SEND На этом этапе изначальная спецификация предписывала получателю либо подключиться к указанному адресу и порту и ждать данных, либо игнорировать запрос, но для клиентов, поддерживающих расширение DCC RESUME, была предусмотрена третья альтернатива – запросить у отправителя пропуск части файла, отправив ответ CTCP: DCC RESUME Если отправляющий клиент поддерживает DCC RESUME, он ответит DCC ACCEPT, и получатель сможет подключиться к указанному адресу и порту и прослушивать данные для добавления к уже существующему файлу. Данные отправляются клиенту блоками, каждый из которых клиент должен подтвердить, отправив общее количество полученных байтов в виде 32-битного целого числа в сетевом порядке байтов. Это замедляет соединения и избыточно, поскольку используется TCP. Расширение send ahead частично решает эту проблему, не дожидаясь подтверждений, но поскольку получателю все равно приходится отправлять их за каждый полученный блок, если отправитель их ожидает, проблема не решается полностью. Другое расширение, TDCC, или turbo DCC, отменяет подтверждения, но требует слегка модифицированного протокола обмена и не имеет широкой поддержки. В более ранних версиях TDCC слово SEND в протоколе обмена заменялось на TSEND; более поздние версии используют слово SEND, но добавляют после протокола обмена, что делает эту версию TSEND совместимой с другими клиентами (при условии, что они могут анализировать модифицированный протокол обмена).
As with DCC CHAT, and are the IP address and port where the sending machine will be listening for an incoming connection. Some clients enclose filenames with spaces in double quotes. It is common practice to add the file size as a last argument: DCC SEND
At this point, the original specification had the receiver either connect to the given address and port and wait for data, or ignore the request, but for clients supporting the DCC RESUME extension, a third alternative is to ask the sender to skip part of the file by sending the CTCP reply: DCC RESUME
If the sending client supports DCC RESUME, it will reply with, DCC ACCEPT , and the receiver can connect to the given address and port and listen for data to append to an already existing file. Data is sent to the client in blocks, each of which the client must acknowledge by sending the total number of bytes received in the form of a 32 bit network byte order integer. This slows down connections and is redundant because of TCP. The send ahead extension relieves this problem somewhat by not waiting for the acknowledgements, but since the receiver still has to send them for every block it receives, in case the sender expects them, it is not solved completely. Another extension, TDCC, or turbo DCC, removes the acknowledgements, but requires a slightly modified handshake and is not widely supported. Older versions of TDCC replaced the word SEND in the handshake with TSEND; later versions use the word SEND but append a after the handshake, making this version of TSEND compatible with other clients (as long as they can parse the modified handshake).
Эксплойт DCC SEND
"DCC send exploit" может относиться к двум уязвимостям: варианту ошибки переполнения буфера в mIRC, возникающей из-за имен файлов длиной более 14 символов, и ошибке проверки входных данных в некоторых маршрутизаторах производства Netgear, D-Link и Linksys, активируемой использованием определенного порта. В частности, уязвимость маршрутизатора может быть вызвана появлением фразы "" с последующими как минимум 6 символами без пробелов или переносов строк в любом месте TCP-потока на порту 6667, а не только при фактическом запросе DCC SEND. В 2000-х годах было возможно объединить несколько уязвимостей в одну строку, которая, будучи размещенной в публичном канале, могла привести к отключению множества пользователей (либо из-за сбоя IRC-клиентов, сбоя маршрутизаторов, либо из-за срабатывания излишне строгих настроек по умолчанию в антивирусном программном обеспечении).
DCC XMIT
XMIT-сервис – это модифицированная версия DCC SEND, позволяющая возобновлять передачу файлов и сокращать избыточный трафик от ACK-пакетов. XMIT не имеет широкой поддержки. Процедура установления соединения XMIT несколько отличается от процедуры установления соединения SEND. Отправитель отправляет CTCP-сообщение, предлагающее файл получателю: DCC XMIT [[[ ]]]. Квадратные скобки здесь обозначают необязательные части. Это протокол, используемый для передачи; в настоящее время определен только он. В отличие от стандартного DCC SEND, адрес может быть указан в дополнительных формах стандартной точечной нотации для IPv4, либо в шестнадцатеричной или смешанной нотации для IPv6. Чтобы оставить один из начальных параметров пустым, но указать последующий, более ранний параметр можно задать как . Если получатель не поддерживает используемый протокол, он отправит ответ CTCP следующего формата: ERRMSG DCC CHAT недоступен. CHAT используется здесь для обеспечения совместимости с сообщениями об ошибках, отправляемыми расширенным DCC CHAT. Если получатель отклоняет передачу, он отправляет следующий ответ CTCP: ERRMSG DCC CHAT отклонено. Другие ошибки сообщаются аналогичным образом. Если получатель готов и способен принять файл, он подключается к указанному адресу и порту. Дальнейшие действия зависят от используемого протокола. В случае протокола, XMIT-сервер, получив соединение, отправляет 32-битное значение времени t в сетевом порядке байтов, представляющее время модификации файла. Предположительно, основываясь на времени модификации локального файла, клиент затем отправляет еще одно 32-битное значение в сетевом порядке байтов – смещение, к которому сервер должен перейти при отправке файла. Это значение должно быть установлено в ноль, если требуется передать весь файл, или в размер локального файла, если клиент хочет возобновить предыдущую загрузку. Хотя XMIT быстрее, чем SEND, он имеет то же ограничение: невозможно определить размер файла, если он не указан в CTCP-переговорах или не известен заранее. Кроме того, из-за 32-битного смещения невозможно возобновить передачу файла размером более двух гигабайт.
Square brackets here enclose optional parts. is the protocol to use for the transfer; only is defined presently. Unlike standard DCC SEND, can be in the additional forms of standard dotted notation for IPv4, or either hexadecimal or mixed notation for IPv6. To leave an early parameter empty, but still supply a later one, the earlier one can be specified as If the receiver does not implement the protocol used, it will send back a CTCP reply of the format: ERRMSG DCC CHAT unavailable. CHAT is used here to maintain compatibility with the error messages sent by the extended DCC CHAT. If the receiver declines the transfer, it sends the following CTCP reply: ERRMSG DCC CHAT declined. Other errors are reported in the same fashion. If the receiver is willing and capable of receiving the file, it will connect to the given address and port. What happens then depends on the protocol used. In the case of the protocol, the XMIT server will, upon receiving a connection, send a 32 bit time t in network byte order, representing the file's modification time. Presumably based on the modification time of the local file, the client will then send another network byte order long, an offset which the server should seek to when sending the file. This should be set to zero if the whole file is wanted, or the size of the local file if the client wishes to resume a previous download. While faster than SEND, XMIT carries one of the same limitations in that it is impossible to tell how big the file is, unless its size is specified in the CTCP negotiation or known beforehand. Furthermore, it is not possible to resume a file past the two gigabyte mark due to the 32 bit offset.
Пассивный DCC
В обычном соединении DCC инициатор выступает в роли сервера, а целевое устройство – в роли клиента. Из-за повсеместного использования брандмауэров и снижения сквозной прозрачности из-за NAT инициатор может оказаться не в состоянии выступать в роли сервера. Были разработаны различные способы инициировать выполнение роли сервера на целевом устройстве:
Сервер DCC
Это расширение стандартных DCC SEND и CHAT было представлено IRC-клиентом mIRC. DCC Server имеет частичную поддержку, но не является стандартным для всех клиентов (см. Сравнение IRC-клиентов). Он позволяет инициировать DCC-соединение по IP-адресу, без использования IRC-сервера. Это достигается за счет того, что принимающий клиент выступает в роли сервера (отсюда и название), прослушивая (обычно на порту 59) запрос на установку соединения от отправителя. Для CHAT инициатор отправляет 1000, а получатель отвечает 1000, после чего обмен данными продолжается по стандартному протоколу DCC CHAT. Для SEND инициатор отправляет 1200, а получатель отвечает 1210, где – смещение в файле, с которого начинается передача. Далее передача данных происходит как обычный DCC SEND. DCC Server также поддерживает файловые серверы в стиле mIRC и DCC GET.
РДКЦ
DCC Server не предоставляет способа указать используемый порт, поэтому его необходимо согласовывать вручную, что не всегда возможно, так как одна из сторон может быть не пользователем. RDCC — это механизм установления соединения для DCC Server, который, помимо порта, предоставляет IP-адрес сервера, который клиент может не найти иным способом из-за маскировки хоста. Он не получил широкого распространения. Инициатор запрашивает порт, на котором ожидает цель, отправляя CTCP-запрос RDCC , где обозначает чат, обозначает отправку, а обозначает файловый сервер. Цель может ответить CTCP-сообщением RDCC 0 , где и имеют те же значения, что и для обычных DCC SEND и CHAT. После этого инициатор подключается к и , и происходит рукопожатие DCC Server.
DCC RSEND
Это альтернатива DCC REVERSE в клиенте KVIrc. Отправитель предлагает файл, отправляя CTCP-сообщение: DCC RSEND. Получатель может принять предложение, ответив CTCP-сообщением DCC RECV, после чего отправитель подключается к получателю и отправляет файл, как при обычной DCC SEND.
Файловые серверы (FSERV)
DCC fserve, или файловый сервер, позволяет пользователю просматривать, читать и скачивать файлы, расположенные на DCC-сервере. Обычно это реализуется посредством DCC CHAT-сессии (предоставляющей пользователю командную строку) или специальных команд CTCP для запроса файла. Файлы передаются через DCC SEND или DCC XMIT. Существует множество реализаций DCC-файловых серверов, среди которых команда FSERV в популярном клиенте mIRC.