Обнаружение P2P трафика
ОГЛАВЛЕНИЕ
С появлением в конце 1999 года Napster'a, P2P приложения быстро обрели популярность в интернет сообществе. Вместе с тем возросло потребление трафика такими приложениями и появилась необходимость в обнаружении пользователей P2P сетей в пределах сетевого трафика компании. В этой статье автор предлагает новый способ обнаружения P2P пользователей, основанный на анализе поведения трафика, позволяющий определить даже тип используемого P2P приложения.
Limewire 6346/6347 TCP/UDP
Morpheus 6346/6347 TCP/UDP
BearShare default 6346 TCP/UDP
Edonkey 4662/TCP
EMule 4662/TCP 4672/UDP
Bittorrent 6881-6889 TCP/UDP
WinMx 6699/TCP 6257/UDP
Для обнаружения P2P пользователей данным способом, нужно анализировать сетевой трафик на наличие соединений, использующих эти порты. Если соответствие обнаружено, это может быть индикатором P2P активности. Анализ открытых портов – практически единственный метод, доступный сетевым администраторам, ни имеющих специального ПО или аппаратных средств (таких как системы обнаружения вторжений) для мониторинга трафика.
Описанный способ очень прост в реализации, но его недостатки очевидны. Большинство P2P приложений позволяют изменять номера портов по умолчанию на любые. Кроме этого, многие современные приложения предпочитают использовать случайные номера портов. Также существует тенденция использования номеров портов известных приложений, таких как 80 порт. Все эти факты снижают эффективность данного способа.
Суть этого способа в мониторинге трафика, проходящего через сеть, на предмет обнаружения определенных сигнатур, специфичных для P2P приложений, в полезной нагрузке пакетов. Многие современные коммерческие и свободно распространяемые решения для обнаружения P2P трафика основаны на этом методе. В их число входят L7-filter, Cisco's PDML, Juniper's netscreen-IDP, Alteon Application Switches, сигнатуры основных приложений Microsoft и NetScout. Каждое из этих приложений с помощью регулярных выражений анализирует данные, проходящие через прикладной уровень, пытаясь определить факт использования P2P приложения.
Так как в описанном методе производится анализ полезной нагрузки пакетов, любые уловки, такие как использование случайных портов, не имеют смысла. Данный метод обычно более точен и правдоподобен, однако и у него есть недостатки. Вот то, что нужно помнить, применяя метод анализа трафика:
P2P приложения постоянно развиваются и соответственно изменяются их сигнатуры. Чтобы анализ трафика был эффективен, требуется постоянное обновление базы сигнатур. С появлением программ для обнаружения P2P трафика, разработчики P2P приложений все чаще и чаще шифруют трафик, например, используя SSL, что сильно затрудняет анализ протокола.
Поиск по сигнатуре требует анализа всего сетевого трафика, что может создать проблемы в работе крупных сетей. Такое ПО может создавать слишком большие нагрузки на сетевое оборудование или даже быть причиной ошибок в работе сети. Кроме того, поиск по сигнатуре на прикладном сетевом уровне очень ресурсоемкий. Чем больше пропускная способность сети, тем большую цену придется заплатить за проверку трафика. Если ваша организация не может позволить себе специальное оборудовании или программное обеспечение для анализа трафика, является ли проверка открытых портов единственной альтернативой? К счастью, ответ – нет. Метод, основанный на шаблонах поведения трафика, является и функциональным и рентабельным.
Ахиллесова пята Napster’a – полная зависимость от центрального сервера. Если сервер прекратит работу – сеть разрушится. Это хорошо иллюстрируется действиями звукозаписывающих компаний, вынудивших Napster прекратить свою работу.
Случай с Napster’ом показал уязвимость централизованной структуры и сильно повлиял на дальнейшее развитие P2P приложений. По причинам законности, безопасности, масштабируемости, анонимности и др. все больше и больше современных P2P приложений работают в полностью или частично децентрализованной сетевой структуре или двигаются в этом направлении. Основные P2P сети и протоколы, такие как Edonkey2k, FastTrack, Gnutella, Gnutella2, Overnet, Kad, все использует данную концепцию.
Здесь нужно пояснить, Bittorrent не является универсальной P2P сетью, хотя это популярное P2P приложение. В то время как сетевая структура Bittorrent частично децентрализована, он все еще нуждается в ведомых серверах и методы, описанные в этой статье, не могут использоваться для идентификации пользователей этой программы.
Децентрализация означает сетевую структуру без центральных индексных серверов. Это основное направление эволюции P2P. Сегодня существует много сетей, имеющих полностью или частично децентрализованную структуру. Некоторым P2P приложениям, таким как EMule и Edonkey, поддерживающим полностью децентрализованные протоколы типа Kademlia, вообще не нужны никакие сервера. Но на данный момент самая популярная сетевая модель - частично децентрализованная, являющаяся гибридом децентрализованных сетей.
В частично децентрализованной сети все еще присутствуют центральные сервера, но они явно не конкретизированы и не статичны. Вместо этого, некоторые пользователи, обладающие значительными ресурсами (скорость процессора, дисковое пространство, высокоскоростная связь и процессорное время) автоматически принимают на себя функции центрального сервера. Каждый из них обслуживает группу обычных пользователей. Они связаны друг с другом и формируют основу частично децентрализованной сети. По мере появления в сети новых пользователей и ухода старых, компьютеры, исполняющие роль центральных серверов, меняются.
Чтобы подключиться к сети, пользователь должен найти способ подключиться к одному из действующих серверов. Список таких серверов может поставляться с программой или находиться на специальном сайте. Подключившись к сети, P2P приложение, кроме выполнения стандартной работы по загрузке файлов, должно взаимодействовать с P2P сетью, загружать информацию на сервер, проверять статус сервера, получать текущий список доступных серверов, сравнивать их характеристики и переключаться на наилучший, искать файлы, проверять статус компьютеров, на которых этих файлы находятся, сохранять список серверов для дальнейшего использования и т.д. Короче говоря, кроме стандартного трафика загрузки файлов, пользователю нужно отправлять большое количество управляющих пакетов на различные хосты, чтобы своевременно реагировать на изменяющуюся структуру сети. Это первый ключевой элемент метода идентификации P2P пользователей на основе поведения трафика: для взаимодействия с децентрализованной сетью пользователям периодически необходимо отсылать много управляющих пакетов.
Почему UDP? Это простой, эффективный и низкозатратный протокол. Он не гарантирует доставку пакета, не требует установки и поддержки соединения. Все эти возможности делают UDP пригодным для быстрой доставки данных большому количеству получателей. Это все что нужно P2P приложениям. Внимательно изучив различные P2P программы, вы увидите, что для большинства современных приложений характерно определенное сетевое поведение. После запуска они начинают прослушивать один или несколько UDP портов и на протяжении всей работы активно взаимодействуют с внешними адресами через эти порты. Это второй ключевой элемент метода идентификации P2P пользователей на основе поведения трафика: для отправки управляющих пакетов пользователи используют один или несколько UDP портов.
Теперь давайте рассмотрим, как можно идентифицировать популярное P2P приложение Edonkey2000.
11:24:19.650034 IP x.10810 > y.34.233.22.8613: UDP, length: 25
11:24:19.666047 IP x.2587 > y.138.230.251.4246: UDP, length: 6
11:24:19.666091 IP x.10810 > y.127.115.17.4197: UDP, length: 25
11:24:19.681433 IP x.10810 > y.76.27.4.4175: UDP, length: 25
11:24:19.681473 IP x.2587 > y.28.31.240.4865: UDP, length: 6
11:24:19.696907 IP x.2587 > y.162.178.102.4265: UDP, length: 6
......
11:24:20.946921 IP x.2587 > y.250.47.34.4665: UDP, length: 6
11:24:20.962509 IP x.2587 > y.152.93.254.4665: UDP, length: 6
11:24:20.978275 IP x.2587 > y.28.31.241.5065: UDP, length: 6
11:24:20.993871 IP x.2587 > y.135.32.97.580: UDP, length: 6
11:24:21.009621 IP x.2587 > y.149.102.1.4246: UDP, length: 6
11:24:29.681224 IP x.10810 > y.32.97.189.5312: UDP, length: 4
11:24:29.696903 IP x.10810 > y.10.34.181.7638: UDP, length: 4
11:24:29.716503 IP x.10810 > y.26.234.251.12632: UDP, length: 4
......
11:26:20.291874 IP x.10810 > y.19.149.0.21438: UDP, length: 19
Как мы видим, весь трафик исходит из двух UDP портов: 2587 и 10810 (эти порты были выбраны Edonkey случайным образом и на другом хосте могут отличаться). Целевые адреса разнообразны. Фактически, Edonkey использует один порт для запроса статуса серверов Edonkey, а другой для создания соединений, поисковых запросов и другой работы.
За период времени x, с одного IP и фиксированного UDP порта отправляются пакеты на y различных IP с фиксированным или случайным портом.
Опыт показывает, что при x равном 5, y равен 3, и на основе этого можно сделать выводы о наличии P2P трафика. Для получения более точного или грубого результата администраторы могут изменять значения x и y.
На практике мы можем сохранять логи сетевой активности соответствующих устройств и использовать базу данных и несложный скрипт для их обработки. Каждую минуту можно проверять, если какой-либо хост с фиксированного порта отправляет некоторое количество UDP пакетов на различные IP адреса, скорее всего это P2P хост.
Автор этой статьи провел тестирование в одном из крупнейших китайских интернет провайдеров. Логи сетевых соединений экспортировались как Netflow-данные и сохранялись в БД MySQL. С помощью небольшого скрипта, обрабатывающего данные, многие хосты были идентифицированы как P2P хосты, и что самое интересное, были обнаружены новые, широко не распространенные, P2P приложения.
Значимость этого шаблона очевидна: такой подход не требует никакой информации о прикладном уровне, и в то же время весьма эффективен. Данный метод не зависит от базы сигнатур, поэтому с его помощью можно обнаруживать известные и неизвестные на данный момент P2P приложения. Вместе с тем для анализа информации сетевого уровня не требуется практически никакого дополнительно программного или аппаратного обеспечения, а нагрузка на существующее оборудование незначительна.
Более тщательно анализируя UDP трафик различных P2P приложений можно обнаружить интересные закономерности. Выше было упомянуто, что P2P приложению с децентрализованной структурой необходимо периодически отправлять большое количество командных пакетов разного типа. Пакеты одного типа часто имеют одинаковый размер. Поэтому, анализируя UDP пакеты, даже при отсутствии информации прикладного уровня, можно точно определить, какое P2P приложение используется.
У большинства P2P приложений не документированы все детали реализации, некоторые поставляются с закрытыми исходными кодами, поэтому структура UDP пакетов большинства UDP приложений может быть нам точно не известна. Автор этой статьи выбрал семь популярных децентрализованных P2P приложений и провел такие наблюдения. Результаты подтвердили гипотезу о том, что все эти приложения для взаимодействия с внешним миром используют пакеты фиксированной длинны.
Результаты этих простых тестов весьма интересны. Мы может использовать этот метод для идентификации P2P приложения, используемого пользователем. Однако, данная технология все еще находится на начальном этапе развития и многое еще предстоит сделать. Для точного результата требуется подробное изучение каждого приложения.
Кроме того, существуют также и другие методы, которые можно применять и комбинировать с техниками, описанными в этой статье, для более эффективного обнаружения P2P пользователей и идентификации P2P приложений. Некоторые P2P приложения подключаются к фиксированным внешним IP адресам для выполнения ряда функций, таких как проверка на наличие обновлений, аутентификация, загрузка рекламы и др. Например, Kazaa во время работы подключается к ssa.Kazaa.com, desktop.Kazaa.com и некоторым другим сайтам. Skype при каждом запуске создает TCP соединение с ui.skype.com.
Также присутствуют другие характеристики, по которым можно производить анализ поведения трафика, например тип переданных данных. Продолжительность соединения также может использоваться для обнаружения P2P трафика, но это добавит дополнительный уровень сложности.
Стандартные методы
В настоящее время есть два основных способа идентификации пользователей P2P: наличие открытых портов и анализ трафика. Далее следует их краткий обзор.Анализ открытых портов
Проверка на наличие открытых портов самый простой и распространенный из способов обнаружения использования P2P приложений. Он основывается на том, что большинство P2P приложений работают на заданных по умолчанию портах. Например:Limewire 6346/6347 TCP/UDP
Morpheus 6346/6347 TCP/UDP
BearShare default 6346 TCP/UDP
Edonkey 4662/TCP
EMule 4662/TCP 4672/UDP
Bittorrent 6881-6889 TCP/UDP
WinMx 6699/TCP 6257/UDP
Для обнаружения P2P пользователей данным способом, нужно анализировать сетевой трафик на наличие соединений, использующих эти порты. Если соответствие обнаружено, это может быть индикатором P2P активности. Анализ открытых портов – практически единственный метод, доступный сетевым администраторам, ни имеющих специального ПО или аппаратных средств (таких как системы обнаружения вторжений) для мониторинга трафика.
Описанный способ очень прост в реализации, но его недостатки очевидны. Большинство P2P приложений позволяют изменять номера портов по умолчанию на любые. Кроме этого, многие современные приложения предпочитают использовать случайные номера портов. Также существует тенденция использования номеров портов известных приложений, таких как 80 порт. Все эти факты снижают эффективность данного способа.
Анализ трафика
Кроме проверки на наличие открытых портов у администраторов есть еще один метод обнаружения использования P2P приложений - анализ трафика протоколов прикладного уровня.Суть этого способа в мониторинге трафика, проходящего через сеть, на предмет обнаружения определенных сигнатур, специфичных для P2P приложений, в полезной нагрузке пакетов. Многие современные коммерческие и свободно распространяемые решения для обнаружения P2P трафика основаны на этом методе. В их число входят L7-filter, Cisco's PDML, Juniper's netscreen-IDP, Alteon Application Switches, сигнатуры основных приложений Microsoft и NetScout. Каждое из этих приложений с помощью регулярных выражений анализирует данные, проходящие через прикладной уровень, пытаясь определить факт использования P2P приложения.
Так как в описанном методе производится анализ полезной нагрузки пакетов, любые уловки, такие как использование случайных портов, не имеют смысла. Данный метод обычно более точен и правдоподобен, однако и у него есть недостатки. Вот то, что нужно помнить, применяя метод анализа трафика:
P2P приложения постоянно развиваются и соответственно изменяются их сигнатуры. Чтобы анализ трафика был эффективен, требуется постоянное обновление базы сигнатур. С появлением программ для обнаружения P2P трафика, разработчики P2P приложений все чаще и чаще шифруют трафик, например, используя SSL, что сильно затрудняет анализ протокола.
Поиск по сигнатуре требует анализа всего сетевого трафика, что может создать проблемы в работе крупных сетей. Такое ПО может создавать слишком большие нагрузки на сетевое оборудование или даже быть причиной ошибок в работе сети. Кроме того, поиск по сигнатуре на прикладном сетевом уровне очень ресурсоемкий. Чем больше пропускная способность сети, тем большую цену придется заплатить за проверку трафика. Если ваша организация не может позволить себе специальное оборудовании или программное обеспечение для анализа трафика, является ли проверка открытых портов единственной альтернативой? К счастью, ответ – нет. Метод, основанный на шаблонах поведения трафика, является и функциональным и рентабельным.
Поведение трафика
Информация о сетевом трафике может быть легко получена из различных сетевых устройств без серьезного воздействия на производительность и доступность системы. В маленьких и средних сетях администраторы могут использовать логи сетевого оборудования. В больших сетях можно использовать функцию Netflow на маршрутизаторе для сохранения логов сетевого трафика.
Несмотря на то, что полученные данные несколько “сыроваты”, в них все же есть полезная информация, которую можно проверить на соответствие определенным шаблонам. Хорошие результаты может принести анализ UDP сеансов.
Обнаружение P2P пользователей
Автор этой статьи обнаружил уникальные моменты в поведении трафика, характерные для P2P приложений. Данный факт может использоваться для обнаружения хостов, на которых работают P2P приложения. И все, что для этого нужно, это логи сетевого трафика. Что подразумевается под анализом UDP сеансов и как это может нам помочь? Перед тем как ответить на этот вопрос, давайте рассмотри популярное P2P приложение Napster.Централизованные, нецентрализованные и смешанные P2P сети
Napster, разработанный Шоном Фенингом, впервые появился в мае 1999 и представлял собой первое поколение P2P сетей. Сетевая структура Napster’а была централизована, что означает, что ее составными частями были два элемента: центральные индексные сервера и пользовательские компьютеры. Центральные сервера принадлежали Napster’у и использовались для обслуживания пользователей. Когда пользователь хотел загрузить музыкальный файл, он посылал запрос на центральный индексный сервер, который в соответствии с запросом производил поиск в своей базе данных и отсылал ответ, содержащий список других пользователей, имеющих желаемые музыкальные файлы. Затем, для загрузки файла, пользователь мог создать прямое соединения с пользователями из полученного списка.Ахиллесова пята Napster’a – полная зависимость от центрального сервера. Если сервер прекратит работу – сеть разрушится. Это хорошо иллюстрируется действиями звукозаписывающих компаний, вынудивших Napster прекратить свою работу.
Случай с Napster’ом показал уязвимость централизованной структуры и сильно повлиял на дальнейшее развитие P2P приложений. По причинам законности, безопасности, масштабируемости, анонимности и др. все больше и больше современных P2P приложений работают в полностью или частично децентрализованной сетевой структуре или двигаются в этом направлении. Основные P2P сети и протоколы, такие как Edonkey2k, FastTrack, Gnutella, Gnutella2, Overnet, Kad, все использует данную концепцию.
Здесь нужно пояснить, Bittorrent не является универсальной P2P сетью, хотя это популярное P2P приложение. В то время как сетевая структура Bittorrent частично децентрализована, он все еще нуждается в ведомых серверах и методы, описанные в этой статье, не могут использоваться для идентификации пользователей этой программы.
Децентрализация означает сетевую структуру без центральных индексных серверов. Это основное направление эволюции P2P. Сегодня существует много сетей, имеющих полностью или частично децентрализованную структуру. Некоторым P2P приложениям, таким как EMule и Edonkey, поддерживающим полностью децентрализованные протоколы типа Kademlia, вообще не нужны никакие сервера. Но на данный момент самая популярная сетевая модель - частично децентрализованная, являющаяся гибридом децентрализованных сетей.
В частично децентрализованной сети все еще присутствуют центральные сервера, но они явно не конкретизированы и не статичны. Вместо этого, некоторые пользователи, обладающие значительными ресурсами (скорость процессора, дисковое пространство, высокоскоростная связь и процессорное время) автоматически принимают на себя функции центрального сервера. Каждый из них обслуживает группу обычных пользователей. Они связаны друг с другом и формируют основу частично децентрализованной сети. По мере появления в сети новых пользователей и ухода старых, компьютеры, исполняющие роль центральных серверов, меняются.
Чтобы подключиться к сети, пользователь должен найти способ подключиться к одному из действующих серверов. Список таких серверов может поставляться с программой или находиться на специальном сайте. Подключившись к сети, P2P приложение, кроме выполнения стандартной работы по загрузке файлов, должно взаимодействовать с P2P сетью, загружать информацию на сервер, проверять статус сервера, получать текущий список доступных серверов, сравнивать их характеристики и переключаться на наилучший, искать файлы, проверять статус компьютеров, на которых этих файлы находятся, сохранять список серверов для дальнейшего использования и т.д. Короче говоря, кроме стандартного трафика загрузки файлов, пользователю нужно отправлять большое количество управляющих пакетов на различные хосты, чтобы своевременно реагировать на изменяющуюся структуру сети. Это первый ключевой элемент метода идентификации P2P пользователей на основе поведения трафика: для взаимодействия с децентрализованной сетью пользователям периодически необходимо отсылать много управляющих пакетов.
Шаблоны UDP соединения
Большинство современных P2P приложений, использующих децентрализованную структуру, имеют встроенный модуль, выполняющий всю работу по взаимодействию с сервером. В качестве протокола взаимодействия часто используется UDP.Почему UDP? Это простой, эффективный и низкозатратный протокол. Он не гарантирует доставку пакета, не требует установки и поддержки соединения. Все эти возможности делают UDP пригодным для быстрой доставки данных большому количеству получателей. Это все что нужно P2P приложениям. Внимательно изучив различные P2P программы, вы увидите, что для большинства современных приложений характерно определенное сетевое поведение. После запуска они начинают прослушивать один или несколько UDP портов и на протяжении всей работы активно взаимодействуют с внешними адресами через эти порты. Это второй ключевой элемент метода идентификации P2P пользователей на основе поведения трафика: для отправки управляющих пакетов пользователи используют один или несколько UDP портов.
Теперь давайте рассмотрим, как можно идентифицировать популярное P2P приложение Edonkey2000.
Пример UDP трафика Edonkey2000
Ниже показаны выборочные части логов исходящего UDP трафика Edonkey. Фактически, за две минуты мы получили 390 записей. В данном примере адрес отправителя заменен на x, а первая часть адреса получателя на y.11:24:19.650034 IP x.10810 > y.34.233.22.8613: UDP, length: 25
11:24:19.666047 IP x.2587 > y.138.230.251.4246: UDP, length: 6
11:24:19.666091 IP x.10810 > y.127.115.17.4197: UDP, length: 25
11:24:19.681433 IP x.10810 > y.76.27.4.4175: UDP, length: 25
11:24:19.681473 IP x.2587 > y.28.31.240.4865: UDP, length: 6
11:24:19.696907 IP x.2587 > y.162.178.102.4265: UDP, length: 6
......
11:24:20.946921 IP x.2587 > y.250.47.34.4665: UDP, length: 6
11:24:20.962509 IP x.2587 > y.152.93.254.4665: UDP, length: 6
11:24:20.978275 IP x.2587 > y.28.31.241.5065: UDP, length: 6
11:24:20.993871 IP x.2587 > y.135.32.97.580: UDP, length: 6
11:24:21.009621 IP x.2587 > y.149.102.1.4246: UDP, length: 6
11:24:29.681224 IP x.10810 > y.32.97.189.5312: UDP, length: 4
11:24:29.696903 IP x.10810 > y.10.34.181.7638: UDP, length: 4
11:24:29.716503 IP x.10810 > y.26.234.251.12632: UDP, length: 4
......
11:26:20.291874 IP x.10810 > y.19.149.0.21438: UDP, length: 19
Как мы видим, весь трафик исходит из двух UDP портов: 2587 и 10810 (эти порты были выбраны Edonkey случайным образом и на другом хосте могут отличаться). Целевые адреса разнообразны. Фактически, Edonkey использует один порт для запроса статуса серверов Edonkey, а другой для создания соединений, поисковых запросов и другой работы.
Поиск по шаблону
Анализ работы других децентрализованных P2P приложений, таких как BearShare, Skpye, Kazaa, EMule, Limewire, Shareaza, Xolox, MLDonkey, Gnucleus, Sancho и Morpheus показал аналогичные результаты. Все эти приложения действуют одинаково: они используют один или несколько UDP портов для взаимодействия с внешними хостами. В терминах сетевого уровня этот шаблон может быть сформулирован следующим образом:За период времени x, с одного IP и фиксированного UDP порта отправляются пакеты на y различных IP с фиксированным или случайным портом.
Опыт показывает, что при x равном 5, y равен 3, и на основе этого можно сделать выводы о наличии P2P трафика. Для получения более точного или грубого результата администраторы могут изменять значения x и y.
На практике мы можем сохранять логи сетевой активности соответствующих устройств и использовать базу данных и несложный скрипт для их обработки. Каждую минуту можно проверять, если какой-либо хост с фиксированного порта отправляет некоторое количество UDP пакетов на различные IP адреса, скорее всего это P2P хост.
Автор этой статьи провел тестирование в одном из крупнейших китайских интернет провайдеров. Логи сетевых соединений экспортировались как Netflow-данные и сохранялись в БД MySQL. С помощью небольшого скрипта, обрабатывающего данные, многие хосты были идентифицированы как P2P хосты, и что самое интересное, были обнаружены новые, широко не распространенные, P2P приложения.
Ложные срабатывания
Описанный способ кажется неплохим для обнаружения трафика, но что насчет ложных срабатываний? К счастью, такое поведение трафика редко встречается среди других сетевых приложений. Исключением являются игровые сервера и DNS сервера. Эти типы серверов также генерируют трафик, отсылая большое количество UDP пакетов на различные IP адреса. Но администраторы легко могут определить, является ли хост одним из вышеперечисленных серверов, так как в этом случае он не будет отсылать никаких пакетов с портов отличных от своего функционального порта, что в свою очередь не характерно для P2P приложений.Значимость этого шаблона очевидна: такой подход не требует никакой информации о прикладном уровне, и в то же время весьма эффективен. Данный метод не зависит от базы сигнатур, поэтому с его помощью можно обнаруживать известные и неизвестные на данный момент P2P приложения. Вместе с тем для анализа информации сетевого уровня не требуется практически никакого дополнительно программного или аппаратного обеспечения, а нагрузка на существующее оборудование незначительна.
Минусы такого подхода
В описанном методе есть два минуса. Он может быть использован только для обнаружения P2P приложений, реализующих децентрализованную сетевую структуру (хотя большинство P2P приложений децентрализованы). Второй недостаток – если P2P приложение для взаимодействия с сетью использует протокол TCP, а не UDP, наши попытки его идентифицировать потерпят неудачу.
Идентификация P2P приложений
До этого момента мы пытались обнаружить P2P пользователей на основании логов сетевых соединений. Теперь продвинемся на шаг дальше, попробовав точно идентифицировать используемое хостом P2P приложение, не имея доступа к информации прикладного уровня.Более тщательно анализируя UDP трафик различных P2P приложений можно обнаружить интересные закономерности. Выше было упомянуто, что P2P приложению с децентрализованной структурой необходимо периодически отправлять большое количество командных пакетов разного типа. Пакеты одного типа часто имеют одинаковый размер. Поэтому, анализируя UDP пакеты, даже при отсутствии информации прикладного уровня, можно точно определить, какое P2P приложение используется.
У большинства P2P приложений не документированы все детали реализации, некоторые поставляются с закрытыми исходными кодами, поэтому структура UDP пакетов большинства UDP приложений может быть нам точно не известна. Автор этой статьи выбрал семь популярных децентрализованных P2P приложений и провел такие наблюдения. Результаты подтвердили гипотезу о том, что все эти приложения для взаимодействия с внешним миром используют пакеты фиксированной длинны.
Edonkey2000
Edonkey2000 использует большое количество 6 байтовых UDP пакетов для запроса ‘server status request’. Этот тип пакетов можно наблюдать в основном во время запуска Edonkey. В дополнение, пакеты, содержащие запрос поиска, почти всегда имеют размер 25 байт.BearShare
Во время запуска BearShare отсылает 28 байтовые UDP пакеты на несколько целевых адресов. Каждый раз, когда BearShare начинает загрузку файла, происходит отправка большого количества 23 байтовых UDP пакетов хостам-владельцам файла.Limewire
При старте Limewire отправляет много UDP пакетов, размером в 23 и 35 байт. В начале операции загрузки файла этот P2P клиент отсылает большое количество 23 байтовых UDP пакетов.Skype
При запуске Skype отправляет много 18 байтовых UDP пакетов.Kazaa
С началом работы Kazaa отправляет 12 байтовые UDP пакеты на различные хосты.EMule
Когда вы запустите EMule и начнете соединение с сервером, данное приложение оправит большое количество 6 байтовых UDP пакетов с запросами ‘server status request’ и ‘get server info’. Если вы захотите подключиться к сети Kad, Emule в процессе соединения будет отправлять UDP пакеты, размером 27 и 35 байт.Shareaza
На протяжении всей работы Shareaza периодически отправляет 19 байтовые UDP пакеты.Результаты этих простых тестов весьма интересны. Мы может использовать этот метод для идентификации P2P приложения, используемого пользователем. Однако, данная технология все еще находится на начальном этапе развития и многое еще предстоит сделать. Для точного результата требуется подробное изучение каждого приложения.
Кроме того, существуют также и другие методы, которые можно применять и комбинировать с техниками, описанными в этой статье, для более эффективного обнаружения P2P пользователей и идентификации P2P приложений. Некоторые P2P приложения подключаются к фиксированным внешним IP адресам для выполнения ряда функций, таких как проверка на наличие обновлений, аутентификация, загрузка рекламы и др. Например, Kazaa во время работы подключается к ssa.Kazaa.com, desktop.Kazaa.com и некоторым другим сайтам. Skype при каждом запуске создает TCP соединение с ui.skype.com.
Также присутствуют другие характеристики, по которым можно производить анализ поведения трафика, например тип переданных данных. Продолжительность соединения также может использоваться для обнаружения P2P трафика, но это добавит дополнительный уровень сложности.
Заключение
Универсального решения для обнаружения работающего P2P приложения не существует. На сегодняшний день самые распространенные методы, проверка открытых портов и анализ трафика, не являются лучшими. Разрабатывайте собственные методы, и, может быть, некоторые из них значительно поднимут планку в эффективности обнаружения P2P трафика и идентификации P2P приложений.Йеминг Гонг, перевод Владимир Куксенок