|
Страница 2 из 3
Обнаружение 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, наши попытки его идентифицировать потерпят неудачу. |