Протокол интернет-чата IRC: история и принципы работы

Введение

Протокол для чата и обмена сообщениями в реальном времени

IRC (Internet Relay Chat) – это текстовая система обмена мгновенными сообщениями. IRC разработан для группового общения в дискуссионных форумах, называемых каналами, но также поддерживает общение один на один посредством личных сообщений, а также чат и передачу данных, включая обмен файлами. Internet Relay Chat реализован как протокол прикладного уровня для обеспечения текстовой коммуникации. Процесс чата функционирует по клиент-серверной сетевой модели. Пользователи подключаются к IRC-серверу, который может быть частью более крупной IRC-сети, используя клиент – это может быть веб-приложение, автономная программа или компонент, встроенный в более крупное приложение. Примеры программ для подключения включают Mibbit, IRCCloud, KiwiIRC и mIRC. Использование IRC неуклонно снижается с 2003 года, потеряв 60% своих пользователей.

История

IRC был создан Яркко Ойкариненом в августе 1988 года для замены программы под названием MUT (MultiUser Talk) на BBS под названием OuluBox в Университете Оулу в Финляндии, где он работал в Департаменте науки об обработке информации. Яркко намеревался расширить программное обеспечение BBS, которым он управлял, чтобы обеспечить новости в стиле Usenet, дискуссии в реальном времени и другие функции, подобные BBS. Первой реализованной частью была чат-функция, которую он создал, используя фрагменты кода, написанные его друзьями Йирки Куоппалой и Юккой Пихлом. Первая сеть IRC работала на единственном сервере с именем tolsun.oulu.fi. Ойкаринен вдохновлялся системой чата, известной как Bitnet Relay, которая функционировала в сети BITNET. Йирки Куоппала убедил Ойкаринена обратиться к Университету Оулу с просьбой открыть исходный код IRC, чтобы его можно было запускать и за пределами Оулу, и после того, как код был опубликован, Йирки Куоппала немедленно установил еще один сервер. Это была первая «сеть IRC». Когда число пользователей Ойкаринена росло, он привлек друзей из Хельсинкского и Тампереского университетов к запуску серверов IRC, и вскоре за ними последовали и другие университеты. В это время Ойкаринен понял, что остальные функции BBS, вероятно, не поместятся в его программу. «В ней была строка для произвольных серверов, поэтому люди подключали серверы и вызывали конфликты ников». «Свободная сеть Эриды» (EFnet) сделала машину Эриды первым сервером, подвергнутым Q-линии (Q – от quarantine) в IRC. Как снова отметил Умпус, подобная практика уже применялась во время войны в Персидском заливе. Журналы чатов этих и других событий хранятся в архиве ibiblio.

Техническая информация

IRC — это открытый протокол, использующий TCP. Пользователи получают доступ к сетям IRC, подключая клиент к серверу. Существует множество клиентских реализаций, таких как mIRC, HexChat и irssi, а также серверных реализаций, например, оригинальный IRCd. Большинство IRC-серверов не требуют от пользователей регистрации учетной записи, но никнейм необходим перед подключением. Изначально IRC был протоколом обычного текста. Однако де-факто стандартом всегда было использование порта 6667/TCP и соседних портов (например, портов TCP 6660–6669, 7000), чтобы избежать необходимости запуска программного обеспечения IRCd с правами root. В протоколе указывалось, что символы должны быть 8-битными, но не определялась кодировка символов, используемая в тексте. Это может вызывать проблемы при общении между пользователями, использующими разные клиенты и/или платформы. Все используемые сегодня протоколы IRC от клиента к серверу происходят от протокола, реализованного в версии irc2.4.0 сервера IRC2, и описаны в RFC 1459. После публикации RFC 1459 новые функции в реализации irc2.10 привели к публикации нескольких пересмотренных документов по протоколу (RFC 2810, RFC 2811, RFC 2812 и RFC 2813); однако эти изменения протокола не получили широкого распространения среди других реализаций. Несмотря на публикацию множества спецификаций протокола IRC, официальной спецификации не существует, поскольку протокол остается динамичным. Практически ни один клиент и очень мало серверов строго не опираются на вышеупомянутые RFC как на справочные материалы. Microsoft разработала расширение для IRC в 1998 году посредством проприетарного IRCX. Позже компания прекратила распространение программного обеспечения, поддерживающего IRCX, и вместо этого начала разрабатывать проприетарный MSNP. Стандартная структура сети IRC-серверов — это дерево. Сообщения маршрутизируются только по необходимым ветвям дерева, но состояние сети отправляется на каждый сервер, и обычно существует высокая степень взаимного доверия между серверами. Однако эта архитектура имеет ряд проблем. Некорректно работающий или злонамеренный сервер может нанести серьезный ущерб сети, а любые изменения в структуре, будь то преднамеренные или вызванные условиями в базовой сети, требуют разделения и повторного объединения сети. Это приводит к большому объему сетевого трафика и ложным сообщениям о входе/выходе пользователей, а также к временной потере связи для пользователей на разделяемых серверах. Добавление сервера в большую сеть означает значительную фоновую нагрузку на пропускную способность сети и большую нагрузку на память сервера. Однако после установления каждое сообщение для нескольких получателей доставляется аналогично многоадресной рассылке (multicast), то есть каждое сообщение проходит по сетевому каналу ровно один раз. Это преимущество по сравнению с протоколами, не поддерживающими многоадресную рассылку, такими как Простой протокол передачи почты (SMTP) или Расширяемый протокол обмена сообщениями и присутствия (XMPP). IRC-демон может использоваться в локальной сети (LAN). Таким образом, IRC можно использовать для облегчения общения между людьми в локальной сети (внутреннее общение).

IRC is an open protocol that uses TCP Users access IRC networks by connecting a client to a server. There are many client implementations, such as mIRC, HexChat and irssi, and server implementations, e. g. the original IRCd. Most IRC servers do not require users to register an account but a nickname is required before being connected. IRC was originally a plain text protocol However, the de facto standard has always been to run IRC on 6667/TCP and nearby port numbers (for example TCP ports 6660–6669, 7000) to avoid having to run the IRCd software with root privileges. The protocol specified that characters were 8 bit but did not specify the character encoding the text was supposed to use. This can cause problems when users using different clients and/or different platforms want to converse. All client to server IRC protocols in use today are descended from the protocol implemented in the irc2.4.0 version of the IRC2 server, and documented in RFC 1459. Since RFC 1459 was published, the new features in the irc2.10 implementation led to the publication of several revised protocol documents (RFC 2810, RFC 2811, RFC 2812 and RFC 2813); however, these protocol changes have not been widely adopted among other implementations. Although many specifications on the IRC protocol have been published, there is no official specification, as the protocol remains dynamic. Virtually no clients and very few servers rely strictly on the above RFCs as a reference. Microsoft made an extension for IRC in 1998 via the proprietary IRCX. They later stopped distributing software supporting IRCX, instead developing the proprietary MSNP. The standard structure of a network of IRC servers is a tree. Messages are routed along only necessary branches of the tree but network state is sent to every server and there is generally a high degree of implicit trust between servers. However, this architecture has a number of problems. A misbehaving or malicious server can cause major damage to the network and any changes in structure, whether intentional or a result of conditions on the underlying network, require a net split and net join. This results in a lot of network traffic and spurious quit/join messages to users and temporary loss of communication to users on the splitting servers. Adding a server to a large network means a large background bandwidth load on the network and a large memory load on the server. Once established, however, each message to multiple recipients is delivered in a fashion similar to multicast, meaning each message travels a network link exactly once. This is a strength in comparison to non multicasting protocols such as Simple Mail Transfer Protocol (SMTP) or Extensible Messaging and Presence Protocol (XMPP). An IRC daemon can be used on a local area network (LAN). IRC can thus be used to facilitate communication between people within the local area network (internal communication).

Команды и ответы

IRC имеет линейную структуру. Клиенты отправляют однострочные сообщения на сервер, получают ответы на эти сообщения и копии некоторых сообщений, отправленных другими клиентами. В большинстве клиентов пользователи могут вводить команды, добавляя к ним символ "/". В зависимости от команды, она может быть обработана полностью клиентом или (обычно, если клиент не распознает команду) передана непосредственно на сервер, возможно, с некоторыми изменениями. Из-за особенностей протокола, автоматизированные системы не всегда могут надежно сопоставить отправленную команду с её ответом и вынуждены прибегать к предположениям.

Канал

Основным средством связи с группой пользователей в установленной IRC-сессии является канал. Каналы в сети можно отобразить с помощью IRC-команды LIST, которая перечисляет все в данный момент доступные каналы, не имеющие режимов +s или +p, в данной конкретной сети. Пользователи могут присоединиться к каналу, используя команду JOIN, которая в большинстве клиентов доступна как /join #имяканала. Сообщения, отправленные в присоединенные каналы, затем передаются всем остальным пользователям. Другие, менее распространенные типы каналов включают каналы с префиксом "+" – так называемые «модельные» каналы без операторов – и каналы с префиксом "!", представляющие собой каналы с временными метками в сетях, которые обычно не поддерживают временные метки.

Операторы IRC

Есть также пользователи, которые обладают повышенными правами на своем локальном сервере или во всей сети; они называются операторами IRC, иногда сокращенно IRCops или Opers (не путать с операторами каналов). Поскольку реализация IRCd различается, привилегии оператора IRC также варьируются в зависимости от конкретного IRCd. RFC 1459 IRC-серверы, службы и другие клиенты, включая ботов, могут использовать его для идентификации конкретной IRC-сессии. Формат маски хоста – nick!user@host. Маска хоста похожа на, но не следует путать с адресом электронной почты. Часть "nick" – это никнейм, выбранный пользователем, который может быть изменен во время соединения. Часть "user" – это имя пользователя, сообщаемое протоколом ident на стороне клиента. Если ident недоступен на клиенте, используется имя пользователя, указанное при подключении, с добавлением символа тильды в начале. Часть "host" – это имя хоста, с которого подключается клиент. Если сервер не может разрешить IP-адрес клиента в действительное имя хоста, вместо имени хоста используется сам IP-адрес. В связи с проблемами конфиденциальности, связанными с раскрытием IP-адреса или имени хоста клиента, некоторые IRC-демоны также предоставляют функции защиты конфиденциальности, такие как режим "+x" в InspIRCd или UnrealIRCd. Это хеширует IP-адрес клиента или маскирует часть имени хоста, делая его невидимым для пользователей, кроме IRCops. Пользователи также могут запросить "виртуальный хост" (или "vhost"), который будет отображаться в маске хоста для обеспечения дополнительной анонимности. Некоторые IRC-сети, такие как Libera Chat или Freenode, используют их как "маскировки", чтобы указать, что пользователь связан с группой или проектом.

Вызовы

Проблемами в изначальной разработке IRC были большой объем совместно используемых данных, ограничивающий масштабируемость, отсутствие уникальных идентификаторов пользователей, вызывающее коллизии никнеймов, недостаточная защита от сетевых разделений посредством циклической маршрутизации, компромисс между масштабируемостью и информацией о присутствии пользователей в реальном времени, уязвимости протокола, позволяющие злоупотребления, непрозрачная и неоптимизированная передача сообщений, а также отсутствие шифрования. Некоторые из этих проблем были решены в современном IRC.

Атаки

Поскольку соединения IRC могут быть незашифрованными и обычно поддерживаются в течение длительного времени, они представляют собой привлекательную цель для злоумышленников, осуществляющих DoS/DDoS-атаки, и хакеров. В связи с этим необходима продуманная политика безопасности, чтобы предотвратить атаки на IRC-сеть, такие как война за захват контроля. IRC-сети могут также блокировать пользователей или серверы с помощью K-линий или G-линий, оказывающих негативное воздействие. Некоторые IRC-серверы поддерживают SSL/TLS-соединения для повышения безопасности. Это помогает предотвратить использование программ-снифферов для перехвата паролей пользователей IRC, однако эта мера имеет ограниченную эффективность из-за открытого характера IRC-каналов. SSL-соединения требуют поддержки как на стороне клиента, так и на стороне сервера (что может потребовать от пользователя установки SSL-бинарных файлов и специальных патчей или модулей для IRC-клиента на свой компьютер). Некоторые сети также используют SSL для соединений между серверами и предоставляют специальный флаг канала (например, +S), который разрешает доступ только пользователям, подключенным по SSL, при этом запрещая идентификацию операторов в открытом виде, чтобы в полной мере использовать преимущества SSL. IRC служил ранней платформой для разработки многих видов интернет-атак, таких как использование поддельных сообщений ICMP о недоступности для разрыва TCP-соединений IRC (так называемый "нукинг") с целью раздражения пользователей или облегчения захвата контроля.

Предотвращение злоупотреблений

Одним из самых спорных технических вопросов, связанных с реализациями IRC, который сохраняется и по сей день, является вопрос о преимуществах протоколов "задержки ника/канала" (Nick/Channel Delay) по сравнению с протоколами "временных меток" (Timestamp). Оба метода предназначены для решения проблемы атак типа "отказ в обслуживании", но используют совершенно разные подходы. Проблема с исходным протоколом IRC заключалась в том, что при разделении и повторном объединении двух серверов, обе стороны сети просто объединяли свои каналы. Если пользователь мог присоединиться к "разделенному" серверу, где канал, существовавший на другой стороне сети, был пуст, и получить статус оператора, он становился оператором "объединенного" канала после завершения разделения сети. Если пользователь выбирал ник, который уже существовал на другой стороне сети, сервер отключал обоих пользователей при повторном подключении ("коллизия ников"). Это часто использовалось для "массового отключения" всех пользователей на канале, что приводило к созданию каналов без операторов, где не было никого, кто мог бы пресекать злоупотребления. Помимо создания проблем внутри IRC, это побуждало людей проводить DoS-атаки на серверы IRC, чтобы вызвать разделение сети, которое они затем использовали в своих целях. Стратегии задержки ника (ND) и задержки канала (CD) направлены на предотвращение злоупотреблений путем задержки повторных подключений и смены ников. После того, как пользователь отключается и ник становится доступным, или канал перестает существовать, потому что все его пользователи покинули его (что часто происходит во время разделения сети), сервер не позволяет никому использовать этот ник или присоединиться к этому каналу, пока не пройдет определенный период времени (задержка). Идея заключается в том, что даже если происходит разделение сети, злоумышленнику это бесполезно, поскольку он не может захватить ник или получить статус оператора на канале, и, следовательно, не может произойти коллизия ника или "слияние" канала. В некоторой степени это создает неудобства для легитимных пользователей, которым может потребоваться временно использовать другое имя после повторного подключения (добавление подчеркивания – распространенный способ решения проблемы). Протокол временных меток является альтернативой задержкам ника/канала, который разрешает коллизии, используя приоритет на основе временных меток. Каждому нику и каналу в сети присваивается временная метка – дата и время его создания. Когда происходит разделение сети, два пользователя с каждой стороны могут использовать один и тот же ник или канал, но когда две стороны объединяются, выживает только один. В случае с никами, более новый пользователь, согласно его временной метке (TS), отключается; при коллизии каналов участники (пользователи на канале) объединяются, но операторы канала с "проигравшей" стороны разделения теряют свой статус оператора. TS – гораздо более сложный протокол, чем ND/CD, как с точки зрения проектирования, так и реализации. Несмотря на несколько пересмотров, некоторые реализации все еще сталкиваются с проблемами "рассинхронизации" (когда два сервера в одной сети не согласны с текущим состоянием сети) и допускают слишком большую гибкость в отношении того, что было разрешено "проигравшей" стороной. Например, в исходных протоколах TS не было защиты от пользователей, устанавливающих баны или другие режимы в проигрывающем канале, которые затем объединялись при воссоединении разделения, даже если пользователи, установившие эти режимы, потеряли свой статус оператора канала. Некоторые современные IRC-серверы на основе TS также включают в себя некоторую форму ND и/или CD в дополнение к временным меткам, чтобы еще больше ограничить злоупотребления. Большинство сетей сегодня используют подход на основе временных меток. Разногласия между временными метками и ND/CD привели к тому, что несколько серверов отделились от EFnet и сформировали IRCnet. После разделения EFnet перешел на протокол TS, а IRCnet использовал ND/CD. В последних версиях ircd IRCnet, а также в ircd, использующих протокол TS6 (включая Charybdis), ND был расширен/заменен механизмом под названием SAVE. Этот механизм присваивает каждому клиенту UID при подключении к серверу IRC. Этот идентификатор начинается с числа, которое запрещено в никах (хотя некоторые ircd, а именно IRCnet и InspIRCd, позволяют клиентам переключаться на свой собственный UID в качестве ника). Если два клиента с одинаковым ником подключаются с разных сторон разделения сети ("коллизия ников"), первый сервер, обнаруживший эту коллизию, заставит обоих клиентов изменить свой ник на свой UID, тем самым спасая обоих клиентов от отключения. В IRCnet ник также будет заблокирован на некоторое время (ND), чтобы предотвратить повторную коллизию, если оба клиента попытаются вернуться к исходному нику.

One of the most contentious technical issues surrounding IRC implementations, which survives to this day, is the merit of "Nick/Channel Delay" vs. "Timestamp" protocols. Both methods exist to solve the problem of denial of service attacks, but take very different approaches. The problem with the original IRC protocol as implemented was that when two servers split and rejoined, the two sides of the network would simply merge their channels. If a user could join on a "split" server, where a channel that existed on the other side of the network was empty, and gain operator status, they would become a channel operator of the "combined" channel after the netsplit ended; if a user took a nickname that existed on the other side of the network, the server would kill both users when rejoining (a "nick collision"). This was often abused to "mass kill" all users on a channel, thus creating "opless" channels where no operators were present to deal with abuse. Apart from causing problems within IRC, this encouraged people to conduct denial of service attacks against IRC servers in order to cause netsplits, which they would then abuse. The nick delay (ND) and channel delay (CD) strategies aim to prevent abuse by delaying reconnections and renames. After a user signs off and the nickname becomes available, or a channel ceases to exist because all its users parted (as often happens during a netsplit), the server will not allow any user to use that nickname or join that channel, until a certain period of time (the delay) has passed. The idea behind this is that even if a netsplit occurs, it is useless to an abuser because they cannot take the nickname or gain operator status on a channel, and thus no collision of a nickname or "merging" of a channel can occur. To some extent, this inconveniences legitimate users, who might be forced to briefly use a different name after rejoining (appending an underscore is popular). The timestamp protocol is an alternative to nick/channel delays which resolves collisions using timestamped priority. Every nickname and channel on the network is assigned a timestampthe date and time when it was created. When a netsplit occurs, two users on each side are free to use the same nickname or channel, but when the two sides are joined, only one can survive. In the case of nicknames, the newer user, according to their TS, is killed; when a channel collides, the members (users on the channel) are merged, but the channel operators on the "losing" side of the split lose their channel operator status. TS is a much more complicated protocol than ND/CD, both in design and implementation, and despite having gone through several revisions, some implementations still have problems with "desyncs" (where two servers on the same network disagree about the current state of the network), and allowing too much leniency in what was allowed by the "losing" side. Under the original TS protocols, for example, there was no protection against users setting bans or other modes in the losing channel that would then be merged when the split rejoined, even though the users who had set those modes lost their channel operator status. Some modern TS based IRC servers have also incorporated some form of ND and/or CD in addition to timestamping in an attempt to further curb abuse. Most networks today use the timestamping approach. The timestamp versus ND/CD disagreements caused several servers to split away from EFnet and form the newer IRCnet. After the split, EFnet moved to a TS protocol, while IRCnet used ND/CD. In recent versions of the IRCnet ircd, as well as ircds using the TS6 protocol (including Charybdis), ND has been extended/replaced by a mechanism called SAVE. This mechanism assigns every client a UID upon connecting to an IRC server. This ID starts with a number, which is forbidden in nicks (although some ircds, namely IRCnet and InspIRCd, allow clients to switch to their own UID as the nickname). If two clients with the same nickname join from different sides of a netsplit ("nick collision"), the first server to see this collision will force both clients to change their nick to their UID, thus saving both clients from being disconnected. On IRCnet, the nickname will also be locked for some time (ND) to prevent both clients from changing back to the original nickname, thus colliding again.

Боты

Типичное применение ботов в IRC — предоставление IRC-сервисов или конкретных функций в канале, например, для проведения чат-игр или уведомления о внешних событиях. Однако некоторые IRC-боты используются для осуществления злонамеренных атак, таких как отказ в обслуживании, рассылка спама или эксплуатация уязвимостей.

Вышибальщик .

Программа, работающая как демон на сервере и функционирующая как постоянный прокси, известна как BNC или баунсер. Её задача – поддерживать соединение с IRC-сервером, выступая в качестве ретранслятора между сервером и клиентом, или просто как прокси-сервер. Если клиент теряет сетевое соединение, баунсер может оставаться подключенным и архивировать весь трафик для последующей передачи, позволяя пользователю возобновить IRC-сессию без прерывания соединения с сервером. Кроме того, для получения эффекта, аналогичного баунсеру, IRC-клиент (обычно текстовый, например Irssi) можно запустить на постоянно включенном сервере, к которому пользователь подключается через SSH. Это также позволяет устройствам, имеющим только функциональность SSH, но не установленным IRC-клиентом, подключаться к IRC и совместно использовать IRC-сессии. Чтобы IRC-клиент не завершал работу при закрытии SSH-соединения, его можно запустить внутри терминального мультиплексора, такого как GNU Screen или tmux, что позволяет ему постоянно оставаться подключенным к IRC-сети и записывать переписку в интересующих пользователя каналах или поддерживать присутствие канала в сети. По аналогии с этой настройкой, в 2004 году был запущен IRC-клиент клиент-серверной архитектуры под названием Smuxi.

Поисковые системы

Существует множество поисковых систем, помогающих пользователям найти нужную информацию в IRC. Обычно поисковая система состоит из двух частей: "бэкенда" (или "паука/сканера") и "фронтенда" – собственно "поисковой системы". Бэкенд (паук/веб-сканер) – это основная часть поисковой системы, отвечающая за обход IRC-серверов для индексации передаваемой по ним информации. Индексируемая информация обычно состоит исключительно из текста каналов (текста, публично отображаемого в открытых каналах). Для хранения данных обычно используется реляционная база данных, такая как MySQL или Oracle. Фронтенд "поисковой системы" представляет собой пользовательский интерфейс для работы с базой данных, предоставляющий пользователям возможность поиска по индексированным данным и получения необходимой информации. Эти фронтенды могут быть разработаны на различных языках программирования. Большинство поисковых систем используют собственный паук – единое приложение, отвечающее за обход IRC и индексацию данных, однако существуют и "пользовательские" индексаторы. Последние полагаются на пользователей, устанавливающих "расширение" в свой IRC-клиент; это расширение отправляет информацию о каналах, в которых находится пользователь, в базу данных. Многие пользователи создают собственные, упрощенные поисковые системы, используя функции логирования, встроенные во многие IRC-клиенты. Такие поисковые системы обычно реализуются в виде ботов и предназначены для работы с конкретным каналом или группой связанных каналов.

Кодирование символов

В IRC до сих пор отсутствует единый общепринятый стандарт для передачи символов, выходящих за пределы 7-битного репертуара ASCII. IRC-серверы обычно передают сообщения от клиента к другому клиенту в виде байтовых последовательностей, без какой-либо интерпретации или перекодирования символов. Протокол IRC (в отличие, например, от MIME или HTTP) не имеет механизмов для объявления и согласования вариантов кодирования символов. Это возлагает на клиент ответственность за выбор подходящего кодека символов. На практике каналы IRC в значительной степени использовали те же кодировки символов, которые также использовались операционными системами (в частности, производными Unix) в соответствующих языковых сообществах:
7-битная эра: В первые дни IRC, особенно среди пользователей скандинавских и финских языков, национальные варианты ISO 646 были доминирующими кодировками символов. Они кодируют не-ASCII символы, такие как Ä Ö Å ä ö å, в кодовых позициях 0x5B 0x5C 0x5D 0x7B 0x7C 0x7D (US ASCII: [ \ ] { | }). Именно поэтому эти коды всегда разрешены в никнеймах. Согласно RFC 1459, { | } в никнеймах следует рассматривать как строчные эквиваленты [ \ ] соответственно. Технически IRC не предоставляет собственных механизмов передачи файлов; обмен файлами реализуется IRC-клиентами, как правило, с использованием протокола Direct Client to Client (DCC), в котором передача файлов осуществляется посредством обмена личными сообщениями между клиентами. Подавляющее большинство IRC-клиентов поддерживают передачу файлов DCC, поэтому обмен файлами считается неотъемлемой частью IRC. Однако широкое использование этого протокола иногда также приводит к спаму DCC. Команды DCC также использовались для эксплуатации уязвимых клиентов, заставляя их выполнять такие действия, как отключение от сервера или выход из клиента.