Методы и средства защиты компьютерной информации (стр. 7 )

Таблица 1.2 Строковые типы данных протокола OSCAR.

Условное название	Размер	Комментарии
string	data	В TLV строка наследует размер от размера TLV
string08	u08 + data	Один байт, а за ним цепочка байтов данных
string16	u16 + data	Два байта, а за ними цепочка байтов данных

Тип данных TLV – широко распространенные структуры в протоколе OSCAR, используемые для представления динамически вводимых данных (см. табл. 1.3). Синтаксические анализаторы (также называемые парсерами) должны всегда игнорировать незнакомые тэги, чтобы не вызвать ошибку в устаревших клиентах после добавления в протокол новых элементов. Возможные значения тэгов определяются тем, где именно в протоколе находится TVL, эти возможные значения принадлежат классу TVL. Вообще говоря, термины «тип» и «тэг» часто используются как синонимы, но в данном документе под словом «тэг» подразумевается целочисленное значение, связанное с TVL, а под словом «тип» - тип данных, соответствующий этому значению.

Таблица 1.3. Тип данных TVL

Название	Тип	Комментарии
tag	u16	Численные значения определены в классе TLV для группы TLV
len	u16	Длина переменной в байтах
value	blob	Данные внутри структуры TVL длины len; чаще для представления используется другой тип данных — см. описание класса TLV

TLV обычно используются в массивах структур TVL, позволяя легко расширять протокол. Использование только одной TLV без массива не приносит большой выгоды, т. к. это позволяет описать только один элемент. Есть два общих метода добавления массива TLV к типам данных и SNACs. Также существует дополнительный метод добавления массива TLV к SNACs. Наиболее часто встречающийся – tlvBlock, который представляет из себя число TLV типа u16, за которым следуют сами TLV (см. табл. 1.4). Менее распространенный – tlvBlock, который вместо числа TLV представляет собой суммарный размер всех TLV. Третий (возможный только в SNACs) – tlvRestBlock, который сообщает, что все последующие байты в SNAC – TLV.

Таблица 1.4. tlvBlock

Название	Размер	Комментарии
tlvBlock	u16 + data	Два байта, содержащие информацию о количестве элементов, за ними – элементы
tlvLBlock	u16 + data	Два байта, содержащие информацию о суммарном размере элементов, за ними – элементы

Несколько углубимся в то, как реализована передача данных в протоколе OSCAR. Вся информация, которой обмениваются клиент и сервер, упаковывается в, так называемые, FLAP-пакеты. Каждый из них имеет обязательные поля: Command Start, Channel ID, Sequence Number, Data Length и mand Start имеет длину один байт – это заголовок пакета. Channel ID – идентификатор канала, который обозначает разные виды каналов, к которым может относиться пакет, будь то канал соединения или канал данных и т. д. Чаще всего это именно канал данных. Длина этого поля также один байт. Sequence Number – это анахронизм, оставшийся от UDP, когда порядковый номер пакета с каждым следующим посланным пакетом увеличивался на единицу для обеспечения целостности передаваемых данных, что сегодня делает TCP. Data Length – длина поля данных. Data – это просто передаваемые данные, длина произвольная, но ограниченная двумя байтами.

Обычно процесс работы с ICQ начинается с подключения к серверу login. через порт 5190. Сервер принимает UIN и пароль, передавая FLAP-пакет со значением Data, равным единице.

В ICQ используется формат записи данных TLV. TLV является аббревиатурой от Type, Length, Value. В TLV упаковываются почти все данные, включая сами сообщения, однако напрямую эти пакеты используются редко. Обычно они упакованы в еще один вид пакетов – SNAC. SNAC-пакеты используются исключительно в канале данных. Внутри этого пакета есть следующие поля: FamilyId (тип Word) – идентификатор типа данных, SubtypeId (Word) – идентификатор подтипа, Flags[0] и Flags[1] (byte) – служебные флаги, RequestId (dword) – идентификатор запроса и SNAC Data (произвольная длина) – сами данные.

Следовательно, SNAC-пакет записывается в поле Data FLAP-пакета, а TLV-пакет – в поле Data SNAC-пакета.

Структура данных, передаваемых по протоколу OSCAR, не является примитивной. Более глубокое описание этой структуры гораздо сложнее: каждой возможной комбинации FamilyID и SubTypeID для SNAC-пакетов соответствуют разнообразные вложенные TLV-пакеты, которые могут быть разными даже для одинаковых SNAC`ов.

Все данные, которые были получены в ходе экспериментов, в том числе: основные идеи использования различных типов данных в протоколе OSCAR, распределение UIN, структура возникающих ошибок, доскональное описание FLAP и SNAC уровней, а также описание наиболее значимых групп SNAC не были включены в данное пособие, чтобы избежать излишней информативности этих подробностей, т. к. они не являются определяющими в дальнейшем направлении работы.

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

Однако, обобщая данные, полученные в результате эксперимента, приходим к выводу, что общая схема пакета, используемого протоколом такова (см. табл. 1.5.):

Таблица 1.5. Общая схема пакета протокола OSCAR

FLAP Header	Array TLV	SNAC Header	Array TLV
`*`	Тип FLAP	Sequence Number	Length DATA	TLV (--,--)	Группа SNAC	Тип SNAC	Flags	RequestId	TLV (--,--)
1 байт	1 байт	2 байта	2 байта	∑(2+2+{leni})	2 байта	2 байта	2 байта	4 байта	∑(2+2+{leni})

В указанной схеме, достаточно много TLV полей, имеющих нерегулярную структуру и отличающихся непостоянными смещениями относительно заголовков. Размер включённой в пакет «полезной нагрузки», смысловых данных, напрямую зависит от значения поля Length: Size = ({Lenth}+4) байта. Помещённые за полем Length данные располагаются в строгом порядке следования, однако их размеры нельзя определить заранее. Для осуществления гибкой (эффективной) фильтрации сообщений данного протокола с указанием известных смещений необходимо уметь считывать значение поля Length, а также значения полей Length всех используемых структур TLV пакета. Таким образом, в общем случае, для всех полей, кроме полей FLAP заголовка, мы не можем получить конкретное значение смещения от начала прикладных данных.

1.2.2.2 Структура и фильтрация BitTorrent.

BitTorrent – система совместной передачи файлов на основе пиринговой сети, разработанная в 2001 году Брэмом Коэном. Доля интернет-трафика, приходящаяся на BitTorrent, крупнейшая среди долей прочих протоколов общемирового трафика. Система функционирует за счёт совокупной работы нескольких протоколов, главным из которых является одноимённый протокол BitTorrent (bittorrent protocol). Принцип работы BitTorrent таков: нагрузка на распространителя файла уменьшается благодаря тому, что клиенты начинают обмениваться данными сразу же, даже если файл не докачен ими до конца.

Основными преимуществами использования данной сети являются:

·  надёжность и работоспособность за счёт равных ролей участников в функционировании сети;

·  высокие скорости передачи данных, особенно по сравнению с традиционными сетями;

·  отсутствие централизованной системы распространения файлов, поисковых серверов;

·  простота и удобство использования для пользователей.

Однако использование сети BitTorrent кроет за собой и ряд существенных недостатков:

·  значительный рост входящего/исходящего трафика, существенное увеличение расходов клиентов, имеющих мегабайтную тарификацию;

·  высокая нагрузка трафика BitTorrent на каналы связи Интернет-провайдеров (BitTorrent буквально занимает соединение и замедляет скорость работы прочих приложений);

·  риск правовой ответственности за создание и использование: т. к. передаваемые в пиринговых сетях файлы зачастую являются охраняемыми объектами авторских и/или смежных прав.

В торрент-среде распространена своя специфическая терминология:

·  Раздача (англ. seeding) — процесс распространения файла по протоколу BitTorrent.

·  Пир (англ. peer — соучастник) — клиент, участвующий в раздаче. Иногда пирами называют только скачивающих участников.

·  Сид, иногда сидер (англ. seeder — сеятель) — пир, имеющий все сегменты распространяемого файла, то есть либо начальный распространитель файла, либо уже скачавший весь файл.

·  Личер (англ. leech — пиявка) — пир, не имеющий пока всех сегментов, то есть продолжающий скачивание. Термин часто употребляется и в негативном смысле, который он имеет в других файлообменных сетях: пользователь, который отдает гораздо меньше, чем скачивает.

·  Рой (англ. swarm) — совокупность всех пиров, участвующих в раздаче.

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