обнаружение P2P-трафика
С появлением в конце 1999 года Napster'a, P2P приложения быстро обрели популярность в интернет-сообществе. Вместе с тем возросло потребление трафика такими приложениями и появилась необходимость в обнаружении пользователей P2P-сетей в пределах сетевого трафика компании. В этой статье автор предлагает новый способ обнаружения пользователей P2P, основанный на анализе поведения трафика, позволяющий определить даже тип используемого P2P-приложения.
В настоящее время есть два основных способа идентификации пользователей P2P: наличие открытых портов и анализ трафика. Далее следует их краткий обзор.
анализ открытых портов
Проверка на наличие открытых портов - самый простой и распространенный из способов обнаружения использования P2P-приложений. Он основывается на том, что большинство P2P-приложений работают на заданных по умолчанию портах. Например:
- Limewire - 6346/6347 TCP/UDP;
- Morpheus - 6346/6347 TCP/UDP;
- BearShare - 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-приложения. И все, что для этого нужно, это логи сетевого трафика.
Что подразумевается под анализом 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-портов для взаимодействия с внешними хостами. В терминах сетевого уровня этот шаблон может быть сформулирован следующим образом: за период времени Х, с одного IP-адреса и фиксированного UDP-порта отправляются пакеты на Y различных IP с фиксированным или случайным портом. Опыт показывает, что при X равном 5,Yy равен 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-пакетов. /* Не совсем понятно, как Skype попал в эту веселую компанию, но раз уж автор провел исследования относительно этого софта, почему бы и не опубликовать, вдруг кому понадобится :) – прим. ред. */
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-приложений.
Йеминг Гонг, перевод Владимир Куксенок.
В настоящее время есть два основных способа идентификации пользователей P2P: наличие открытых портов и анализ трафика. Далее следует их краткий обзор.
анализ открытых портов
Проверка на наличие открытых портов - самый простой и распространенный из способов обнаружения использования P2P-приложений. Он основывается на том, что большинство P2P-приложений работают на заданных по умолчанию портах. Например:
- Limewire - 6346/6347 TCP/UDP;
- Morpheus - 6346/6347 TCP/UDP;
- BearShare - 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-приложения. И все, что для этого нужно, это логи сетевого трафика.
Что подразумевается под анализом 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-портов для взаимодействия с внешними хостами. В терминах сетевого уровня этот шаблон может быть сформулирован следующим образом: за период времени Х, с одного IP-адреса и фиксированного UDP-порта отправляются пакеты на Y различных IP с фиксированным или случайным портом. Опыт показывает, что при X равном 5,Yy равен 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-пакетов. /* Не совсем понятно, как Skype попал в эту веселую компанию, но раз уж автор провел исследования относительно этого софта, почему бы и не опубликовать, вдруг кому понадобится :) – прим. ред. */
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-приложений.
Йеминг Гонг, перевод Владимир Куксенок.
Сетевые решения. Статья была опубликована в номере 09 за 2005 год в рубрике sysadmin
