ICQ, WHOIS и Finger

ICQ — система обмена сообщениями

Протокол ICQ обеспечивает обмен сообщениями в режимах клиент-сервер и клиент-клиент. Идея данного протокола принадлежит израильтянам Яру Голдфингеру (Yair Goldfinger), Арику Ванди (Arik Vandi), Сефи Визигеру (Sefi Visiger) и Амнону Амиру (Amnon Amir). Именно эти люди создали в 1996 году компанию Mirabilis для предоставления клиентам нового вида обмена сообщениями. Протокол ICQ конкурировал с несколькими другими схожими решениями и победил.

Данный протокол позволяет пользователям Интернет легко находить друг друга и столь же легко общаться. Вспомним, что для общения через электронную почту нужно знать почтовый адрес партнера. В ICQ предусмотрена возможность обмена сообщениями более чем с одним партнером (каждому из участников на экране выделяется индивидуальное окно). Для транспортировки данных могут использоваться протоколы UDP (версии 1-5) или TCP (версии выше 6). Те, кто работал с UNIX, возможно, пользовались системами обмена сообщениями TALK или PHONE. Эти системы похожи на ICQ, но они предполагают знание LOG-имен партнеров.

Через четыре месяца после основания фирмы Mirabilis появилась первая версия реализации ICQ ("I seek you"). В июле 1998 года по инициативе America Online приемником Mirabilis Ltd. стала компания ICQ Inc. (см. также www.mirabilis.com или www.megasecurity.org).

Каждый пользователь ICQ имеет cписок людей, с которыми он/она хочет общаться. Этот список может увеличиваться. Для каждого пользователя из контактного списка отображается его статус.

Протокол ICQ позволяет передавать не только сообщения, но и файлы. К сожалению, существует несколько модификаций стандарта. Кроме того, следует учитывать тот факт, что протокол ICQ не является публичным (права на него принадлежат компании Mirabilis). показана общая схема взаимодействия пользователей с сервером и друг с другом.

Первоначально пользователи устанавливают соединение с ICQ -сервером. После авторизации и выбора партнера пользователи могут установить соединение непосредственно между собой, минуя сервер (например, клиенты, отмеченные цифрами 1 и 3). Пользователи могут быть подключенными к серверу (режим on-line) и отключенными (2, 6, 9 и 11; режим off-line). На показан формат пакета ICQv4.

На показан формат кадра версии ICQ 5.

Первые два байта характеризуют версию протокола. Далее после четырех нулевых октетов следует уникальный идентификатор клиента UIN. После идентификатора сессии следует код команды. В данном конкретном случае код команды для разрыва соединения — 0xC2EE (обратный порядок байтов). Поля ID-сессии и порядковые номера (SEQ_NUM1,SEQ_NUM2) служат для целей безопасности.

Контакт с партнером устанавливается через TCP-соединение. Все остальные коммуникации осуществляются с использованием UDP-дейтограмм, посылаемых ICQ -серверу. Получение всех UDP-дейтограмм должны подтверждаться получателем. Если в течение 10 секунд не пришло подтверждение, происходит повторная передача. После 6 неудачных повторных передач посылается сообщение B_MESSAGE_ACK. Процедура повторяется 2 раза. Если отклика не получено, ICQ клиент считается отключенным.

Прежде чем коммуникация между пользователями станет возможной, клиент должен зарегистрироваться в сервере. В процессе авторизации клиент посылает серверу данные о себе, включая свой IP-адрес, TCP-порт, зарезервированный для ICQ, пароль пользователя и контактный список. С этого момента клиент считает себя подключенным, и будет посылать регулярно серверу сообщения ‘keep alive’ (еще жив). Эти сообщения выполняют две функции: позволяют клиенту быть уверенным в том, что он имеет доступ к серверу, а серверу — знать, что клиент все еще подключен. По умолчанию клиент будет подключен к серверу через UDP-порт 4000. Такие функции, как отправка сообщений пользователям offline, получение информации о пользователе, поиск пользователей в глобальном каталоге ICQ и изменение пароля, осуществляются путем посылки UDP-дейтограмм ICQ -серверу. Все эти пакеты следуют простому шаблону, включая UIN отправителя, специальный код, определяющий функцию, которую должен осуществить сервер, и опционные параметры.

Когда пользователь посылает сообщение /URL/ и т.д. другому пользователю, который подключен к серверу, клиент ICQ установит TCP-соединение непосредственно с этим пользователем, и пошлет сообщение, используя формат, сходный с используемым при отправке UDP пакетов. После того, как сообщение послано, TCP-соединение не прерывается, а сохраняется открытым и используется для последующего обмена сообщениями. Соединение закрывается, когда любой из пользователей разрывает ICQ -соединение.

Все текстовые строки начинаются с двухбайтового поля длины, указывающего число байт в строке. Любые строки в данном протоколе завершаются кодом 00. При чтении пакетов может применяться любая информация для определения длины строки, но при отправке следует использовать как поле длины, так и завершающие два нулевых байта. Все строки работают в кодировке MS Windows, т.e. символьном наборе ISO Latin-1, а текстовые строки завершаются CR/LF. (Не все строки могут содержать разрывы строк.)

Поле VERSION присутствует во всех ICQ -пакетах и идентифицирует пакет как ICQ -сообщение. Поле SEQ_NUM содержит порядковый номер пакета. Все пакеты должны иметь уникальный порядковый номер (если это только не повторная передача). Это делается для того, чтобы исключить путаницу, если UDP-пакет потерян или задублирован. Заметим, что сервер и клиент имеют разную нумерацию, так что SEQ_NUM = 3 пакета, посланного сервером, отличается от SEQ_NUM = 3 пакета, посланного клиентом. Заметим также, что сервер начинает нумерацию с 00 00, а клиент — с 01 00.

Коммуникации между двумя клиентами с использованием TCP (режим узел-узел)

Когда пользователь хочет послать сообщение, URL и т.д., другому пользователю, он проверяет, установлено ли уже с ним соединение. Если установлено, тогда будет использоваться это соединение. Если нет, пользователь проверяет IP-адрес и порт удаленного пользователя (информация посылается сервером, когда удаленный пользователь авторизован) и осуществляет соединение с этим адресом. Обычно номера портов лежат в диапазоне 1200-1300 (десятичные). Когда новое соединение установлено, должно быть послано сообщение CHANNEL_INIT. С этого момента всякий раз, когда пользователь хочет послать сообщение, отсылается CHANNEL_MESSAGE. Получение всех посланных сообщений должно быть подтверждено адресатом, используя CHANNEL_ACK.

TCP-обмен идентичен коммуникации с привлечением UDP. Каждый пакет должен содержать длину пакета (не включая счетчик длины). Код длины занимает два октета. Большинство сообщений содержат UIN отправителя.

Действующая версия протокола имеет уязвимости. Аутентификация осуществляется без использования шифрования и т.д., — понятно, что по мере совершенствования протокола эти уязвимости будут устранены.

WHOIS-сервис

WHOIS обеспечивает каталожную службу для пользователей сети (см. RFC-0954, .3912). Эта служба заключается в поиске доменных имен и IP-адресов по имени машины и наоборот. WHOIS может поставлять информацию о сетях, о структуре доменов и т.д. Существует несколько региональных баз данных whois (ARIN, APNIC, IANA, RIPE, LACNIC, RIPN и др.). В действительности имена при регистрации доменов и при выдаче IP-адресов автоматически вводятся в базу данных. Каждая запись в базе имеет уникальный идентификатор (handle), имя, тип записи и ряд других полей в зависимости от типа записи. База данных поддерживается в каждой сети независимо и взаимодействие между ними не всегда существует.

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

Сейчас создан новый протокол WHOIS++, в котором учтены прежние недостатки.

В общем случае обращение к серверу WHOIS может иметь вид

whois [-aAbdgiIlmQrR6] [-c country-code | -h host] [-p port] name ...,

где буквы в квадратных скобках являются обозначениями возможных опций.

Утилита whois просматривает рекорды баз данных нескольких NIC (Network Information Centers).

Допустимы следующие опции:

-a использовать базу данных ARIN (American Registry for Internet Numbers). Она содержит записи о сетях, которые не попали в базы данных APNIC и RIPE.

-A использовать базу данных APNIC (Asia/Pacific Network Information Center). Она содержит записи о сетях Восточной Азии, Австралии, Новой Зеландии и островов Тихого океана.

-b использовать базу данных Network Abuse Clearinghouse. Она содержит адреса, куда следует обращаться в случае атаки. Адреса упорядочены по именам доменов.

-c country-code Это эквивалентно использованию опции -h с аргументом "country-code.whois-servers.net".

-d использовать базу данных министерства обороны США. Она содержит записи для субдоменов .MIL.

-g использовать базу данных федерального правительства США, которая содержит записи для субдоменов .GOV.

-h host Используется данная машина вместо варианта по умолчанию. Может называться имя или IP-адрес машины.

По умолчанию утилита whois формирует имя сервера whois, применяя сервер домена верхнего уровня (TLD — top-level domain), переданного в качестве аргумента, добавив ".whois-servers.net".

В случае, когда специфицирован IP-адрес, сервер whois будет использовать по умолчанию ARIN (American Registry for Internet Numbers). Если запрос к ARIN ссылается на APNIC, LACNIC или RIPE, этот сервер будет также запрошен (предполагается, что опция -Q отсутствует).

-I Использовать базу данных whois.networksolutions.com (Network Solutions Registry for Internet Numbers). Она содержит записи и контактную информацию для большинства доменов .COM, .NET, .ORG и .EDU.

-I Использовать базу данных IANA (Internet Assigned Numbers Authority). Она содержит записи о сетях доменов верхнего уровня.

-I Использовать базу данных LACNIC (Latin American and Caribbean IP address Regional Registry). Она содержит записи для сетей Латинской Америки и Карибского бассейна.

-m Использовать базу данных RADB (Route Arbiter Database). Она содержит информацию о маршрутной политике для большого числа сетевых операторов.

-p port Соединиться с сервером whois через port. Если эта опция не специфицирована, будет использован номер порта 43.

-Q Выполнить быстрый поиск. Это означает, что утилита whois не будет пытаться найти имя на официальном сервере whois. Эта опция не работает, если применяется в комбинации с любыми другими опциями.

-r Использовать базу данных RIPE (R’eseaux IP Europeens). Она содержит номера сетей и контактную информацию по Европе.

-R Использовать базу данных RIPN (Russia Network Information Center). Она содержит номера сетей и контактную информацию для субдомена .RU. В настоящее время эта опция исключена, и рекомендуется применять опцию -c с аргументом "RU".

-6 Использовать базу данных IPv6 Resource Center (6bone). Она содержит имена сетей и IPv6 адреса.

Примеры

Большинство типов данных, таких, как доменные имена и IP адреса, могут применяться в качестве аргументов для утилиты whois с любыми опциями.

Чтобы получить контактную информацию об администраторе, работающем в российском TLD домене "RU", следует использовать опцию –c, как это показано в ниже приведенном примере, где CONTACT-ID заменяется реальным контактным идентификатором.

whois -c RU CONTACT-ID

Следующий пример демонстрирует то, как можно получить данные об IPv6-адресе или имени машины, задействуя опцию -6, которая направляет запрос в 6bone.

whois -6 IPv6-IP-Address

Следует учитывать, что длина отклика в случае запроса WHOIS в несколько раз больше длительности запроса, и это может дать возможность для атак типа отказа обслуживания (DoS). Такая особенность является причиной того, что некоторые whois -серверы не откликаются, если запросы поступают слишком часто. По этой причине можно рекомендовать создавать свою базу данных для часто запрашиваемых имен и адресов.

Ниже представлен результат обращения к серверу WHOIS (RIPE) для IP-адреса 80.18.87.243, откуда была произведена успешная атака нашей рабочей станции в 2005 году.

% This is the Ripe-Mirror Whois server.
% Note: this output has been filtered.
% Information related to '80.18.87.240 - 80.18.87.255'
inetnum: 80.18.87.240 - 80.18.87.255
netname: TESESPA
descr: TESESPA
country: IT
admin-c: AB4030-RIPE
tech-c: AB4031-RIPE
status: ASSIGNED PA
mnt-by: INTERB-MNT
source: RIPE # Filtered

person: ANDREA BONALDO
address: TESE
address: VIA SEST. CASTELLO 2737
address: 30100 VENEZIA
address: Italy
phone: +39412728388
nic-hdl: AB4030-RIPE
source: RIPE # Filtered

person: ANDREA BONALDO
address: TESE
address: VIA SEST. CASTELLO 2737
address: 30100 VENEZIA
address: Italy
phone: +39412728388
nic-hdl: AB4031-RIPE
source: RIPE # Filtered

% Information related to '80.18.0.0/15AS3269'

route: 80.18.0.0/15
descr: INTERBUSINESS
origin: AS3269
remarks: ************************************************
remarks: * Pay attention *
remarks: * Any communication sent to email different *
remarks: * from the following will be ignored! *
remarks: * Any abuse reports, please send them to *
remarks: * abuse@business.telecomitalia.it *
remarks: ************************************************
mnt-by: INTERB-MNT
source: RIPE # Filtered

Из этих данных видно, что атака была произведена из Италии (Венеция). Претензии можно послать по адресу abuse@business.telecomitalia.it. Следует заметить, что форматы данных для разных серверов отличаются.

Протокол Finger

Finger является простым протоколом (RFC-1288), который служит для получения информации о пользователях узлов Internet. Протокол использует TCP-порт 79. Команда Finger может дать вам данные о списке пользователей, которые работают в данный момент на интересующей вас ЭВМ, о конкретном пользователе (дата последнего сеанса входа в систему и т.д.), о списке загруженных задач, о типах интерфейсов (например, терминалов). Данный протокол обеспечивает интерфейс для удаленной информационной программы пользователя ( RUIP — Remote USer Information Program).

Протокол Finger базируется на TCP. Локальная ЭВМ осуществляет TCP-соединение с удаленным узлом через указанный порт. После этого становится доступной программа RUIP, и пользователь может посылать ей свои запросы. Каждый запрос представляет собой строку текста. RUIP, получив запрос, анализирует его и присылает ответ, после чего соединение закрывается.

Любые пересылаемые данные должны иметь формат ASCII, не иметь контроля по четности, и каждая строка должна завершаться последовательностью CRLF (ASCII 13, за которым следует ASCII 10).

Программа RUIP должна воспринимать любые запросы Finger. Такие запросы могут иметь следующий формат:

{Q1} ::= [{W}|{W}{S}{U}]{C}
{Q2} ::= [{W}{S}][{U}]{H}{C}
где {U} ::= имя_пользователя
{H} ::= @hostname | @hostname{H}
{W} ::= /W
{S} ::= | {S}
{C} ::= {H}

является рекурсивным, по этой причине не существует каких-либо ограничений на число лексем типа @hostname в запросе. В примере спецификации {Q2} число лексем @hostname не может превышать двух.

Следует иметь в виду, что в случае запросов " finger user@host" программа RUIP в действительности получит "user".

Запрос {Q2} требует переадресации запроса другой программе RUIP. Программа RUIP может либо осуществить эту процедуру, либо отказать в переадресации. В случае выполнения запроса она должна это подтвердить, сообщая, что:

ЭВМ <H1> открывает соединение Finger <F1-2> с RUIP на ЭВМ <H2>.
<H1> выдает <H2> RUIP запрос <Q1-2> типа {Q2} (например, FOO@HOST1@HOST2).

При этом следует извлечь информацию о том, что:

ЭВМ <H2> является самой правой ЭВМ в запросе <Q1-2> (например, HOST2)
Запрос <Q2-3> является остатком запроса <Q1-2> 
 после удаления правой части "@hostname" 
  (например, FOO@HOST1)

Таким образом:

<H2> RUIP должна открыть соединение <F2-3> с <H3>, используя <Q2-s>.
<H2> RUIP должна прислать любую информацию, посланную от <F2-3>
к <H1> через <F1-2> .
<H2> RUIP должна закрыть <F1-2> в нормальных обстоятельствах толь-
ко когда <H3> RUIP закрывает <F2-3> .

По большей части, вывод RUIP не следует каким-либо жестким регламентациям, так как он предназначен для чтения людьми, а не программами. Главное требование — информативность может ограничиваться только соображениями безопасности.

Запрос {C} требует выдачи списка всех работающих пользователей. RUIP должна либо ответить, либо активно отказаться. Если она отвечает, то она должна выдать, по крайней мере, полные имена пользователей. Системный администратор может включить в выдачу и другую полезную информацию, такую, как:

Запрос {U}{C} является требованием присылки информации о статусе определенного пользователя {U}. Если вы не хотите выдавать такую информацию, тогда следует заблокировать работу Finger.

Ответ должен включать в себя полное имя пользователя. Если пользователь активно работает в сети, то присылаемые данные должны включать, по крайней мере, тот же объем информации, что и при запросе {C}.

Так как это запрос информации об отдельном пользователе, администратор может добавить определенную информации об этом человеке, например:

Информационный файл пользователя может содержать короткое сообщение, которое оставляет пользователь для передачи по запросу Finger. (Оно иногда называется "plan"-файлом). Это легко реализуется путем поиска программой в корневом каталоге (или в специально выделенном каталоге) пользователя файла с заданным именем. Системному администратору должно быть разрешено включать и выключать эту опцию.

При запросе Finger существует возможность запуска определенной программы пользователя. Если такая опция предусмотрена, системному администратору должно быть позволено запрещать эту процедуру. Данная опция, создавая определенные угрозы, практически беспредельно расширяет возможности Finger.

Так как данные, выдаваемые протоколом Finger, крайне полезны для хакеров, настоятельно рекомендуется блокировать работу этого протокола.

К вымирающему виду услуг можно отнести и протокол рассылки новостей NNTP. Этот протокол по своей природе почти не отличим от SMTP и содержит элементы подписных листов LISTSERV.