Основные уязвимые стороны P2P

 

Реализация и использование распределенных систем имеют не только плюсы, но и минусы, связанные с особенностями обеспечения безопасности. Получить контроль над столь разветвленной и большой структурой, какой является сеть P2P, или использовать пробелы в реализации протоколов для собственных нужд — желанная цель для хакеров. К тому же защитить распределенную структуру сложнее, чем централизованный сервер.

Столь огромное количество ресурсов, которое имеется в сетях P2P, тяжело шифровать/дешифровать, поэтому большая часть информации об IP-адресах и ресурсах участников хранится и пересылается в незашифрованном виде, что делает ее доступной для перехвата. При перехвате злоумышленник не только получает собственно информацию, но также узнает и об узлах, на которых она хранится, что тоже опасно.

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

Серьезная проблема — распространение “червей” и подделка ID ресурсов с целью их фальсификации. Например, в клиенте Kazaa используется хеш-функция UUHash, которая позволяет быстро находить ID для больших файлов даже на слабых компьютерах, но при этом остается возможность для подделки файлов и записи испорченного файла, имеющего тот же ID.

Чтобы справиться с описанной проблемой, клиенты должны пользоваться надежными хеш-функциями (“деревьями” хеш-функций, если файл копируется по частям), такими, как SHA-1, Whirlpool, Tiger, и только для решения малоответственных задач — контрольными суммами CRC. Для уменьшения объемов пересылаемых данных и облегчения их шифрования можно применить компрессию. Для защиты от вирусов нужно иметь возможность хранить идентифицирующую метаинформацию о “червях”, как это, в частности, сделано в сети Gnutella2.

Другая проблема — возможность подделки ID серверов и узлов. При отсутствии механизма проверки подлинности пересылаемых служебных сообщений, например с помощью сертификатов, существует возможность фальсификации сервера или узла (многих узлов). Так как узлы обмениваются информацией, подделка некоторых из них приведет к компрометации всей сети или ее части. Закрытое ПО клиентов и серверов не является решением проблемы, так как есть возможность для реинжиниринга протоколов и программ (reverse engineering).

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

Часть клиентов только копируют чужие файлы, но не предлагают ничего для копирования другим (leechers).

В московских домовых сетях на нескольких активистов, делающих доступными более 100 Гбайт информации, приходится около сотни, выкладывающих менее 1 Гбайт. Для борьбы с этим используются разные методы. В eMule применен метод кредитов: скопировал файл — кредит уменьшился, позволил скопировать свой файл — кредит увеличился (xMule — кредитная система с поощрением распространения редких файлов). В сети eDonkey стимулируется размножение источников, в Bittorrent реализована схема “сколько блоков файла получил, столько отдал” и т. п.[1]

 

Некоторые пиринговые сети

DirectConnect

пиринговый сеть torrent одноранговый

Direct Connect — это частично централизованная файлообменная (P2P) сеть, в основе работы которой лежит особый протокол, разработанный фирмой NeoModus.

NeoModus была основана Джонатаном Хессом (Jonathan Hess) в ноябре 1990 года как компания, зарабатывавшая на adware-программе «Direct Connect». Первым сторонним клиентом стал «DClite», который никогда полностью не поддерживал протокол. Новая версия Direct Connect уже требовала простой ключ шифрования для инициализации подключения, этим он надеялся блокировать сторонние клиенты. Ключ был взломан и автор DClite выпустил новую версию своей программы, совместимой с новым программным обеспечением от NeoModus. Вскоре, код DClite был переписан, и программа была переименована в Open Direct Connect. Кроме всего прочего, ее пользовательский интерфейс стал многодокументным (MDI), и появилась возможность использовать плагины для файлообменных протоколов (как в MLDonkey). У Open Direct Connect также не было полной поддержки протокола, но появился под Java. Немногим позже, начали появляться и другие клиенты: DCTC (Direct Connect Text Client), DC++ и др.

Сеть работает следующим образом. Клиенты подключаются к одному или нескольким серверам, так называемым хабам для поиска файлов, которые обычно не связаны между собой (некоторые типы хабов можно частично или полностью связать в сеть, используя специализированные скрипты или программу Hub-Link) и служат для поиска файлов и источников для их скачивания. В качестве хаба чаще всего используются PtokaX, Verlihub, YnHub, Aquila, DB Hub, RusHub. Для связи с другими хабами используются т.н. dchub-ссылки:

dchub://[ имя пользователя ]@[ IP или Домен хаба ]:[ порт хаба ]/[путь к файлу]/[имя файла]

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

Данный вид ссылки на файл может применяться, когда невозможно использовать magnet-ссылку так как содержимое файла может измениться либо файл еще не создан.

Отличия от других P2P-систем:

1. Обусловленные структурой сети

· Развитый многопользовательский чат

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

· Присутствие привилегированных пользователей — операторов, обладающих расширенным набором возможностей управления хабом, в частности, следящих за соблюдением пользователями правил чата и файлообмена

2. Зависящие от клиента

· Возможность скачивать целые директории

· Результаты поиска не только по названиям файлов, но и по директориям

· Ограничения на минимальное количество расшаренного материала (по объёму)

· Поддержка скриптов с потенциально безграничными возможностями как на клиентской стороне, так и на стороне хаба (верно не для всяких хабов и клиентов)

Авторы клиента DC++ разработали для решения специфичных проблем принципиально новый протокол, называнный Advanced Direct Connect (ADC), цель которого — повышение надежности, эффективности и безопасности файлообменной сети. 2 декабря 2007 года вышла окончательная версия протокола ADC 1.0. Протокол продолжает развиваться и дополняться. [3]

 

Bit Torrent

 

BitTorrent (букв. англ. «битовый поток») — пиринговый (P2P) сетевой протокол для кооперативного обмена файлами через Интернет.

Файлы передаются частями, каждый torrent-клиент, получая (скачивая) эти части, в то же время отдаёт (закачивает) их другим клиентам, что снижает нагрузку и зависимость от каждого клиента-источника и обеспечивает избыточность данных. Протокол был создан Брэмом Коэном, написавшим первый torrent-клиент «BitTorrent» на языке Python 4 апреля 2001 года. Запуск первой версии состоялся 2 июля 2001 года.

Для каждой раздачи создаётся файл метаданных с расширением.torrent, который содержит следующую информацию:

- URL трекера;

- Общую информацию о файлах (имя, длину и пр.) в данной раздаче;

- Контрольные суммы (точнее, хеш-суммы SHA1) сегментов раздаваемых файлов;

- Passkey пользователя, если он зарегистрирован на данном трекере. Длина ключа устанавливается трекером.

Необязательно:

- Хеш-суммы файлов целиком;

- Альтернативные источники, работающие не по протоколу BitTorrent. Наиболее распространена поддержка так называемых web–сидов (протокол HTTP), но допустимыми также являются ftp, ed2k, magnet URI.

Файл метаданных является словарем в bencode формате. Файлы метаданных могут распространяться через любые каналы связи: они (или ссылки на них) могут выкладываться на веб-серверах, размещаться на домашних страницах пользователей сети, рассылаться по электронной почте, публиковаться в блогах или новостных лентах RSS. Также есть возможность получить info часть публичного файла метаданных напрямую от других участников раздачи благодаря расширению протокола "Extension for Peers to Send Metadata Files". Это позволяет обойтись публикацией только магнет-ссылки. Получив каким-либо образом файл с метаданными, клиент может начинать скачивание.

Перед началом скачивания клиент подсоединяется к трекеру по адресу, указанному в торрент-файле, сообщает ему свой адрес и хеш-сумму торрент-файла, на что в ответ клиент получает адреса других клиентов, скачивающих или раздающих этот же файл. Далее клиент периодически информирует трекер о ходе процесса и получает обновлённый список адресов. Этот процесс называется объявлением (англ. announce).

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

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

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

Когда скачивание почти завершено, клиент входит в особый режим, называемый end game. В этом режиме он запрашивает все оставшиеся сегменты у всех подключенных пиров, что позволяет избежать замедления или полного «зависания» почти завершенной закачки из-за нескольких медленных клиентов.

Спецификация протокола не определяет, когда именно клиент должен войти в режим end game, однако существует набор общепринятых практик. Некоторые клиенты входят в этот режим, когда не осталось незапрошенных блоков, другие — пока количество оставшихся блоков меньше количества передающихся и не больше 20. Существует негласное мнение, что лучше поддерживать количество ожидаемых блоков низким (1 или 2) для минимизации избыточности, и что при случайном запрашивании меньший шанс получить дубликаты одного и того же блока.

Недостатки и ограничения

· Недоступность раздачи – если нет раздающих пользователей (сидов);

· Отсутствие анонимности:

- пользователи незащищенных систем и клиентов с известными уязвимостями могут быть подвергнуты атаке.

- возможно узнать адреса пользователей, обменивающихся контрафактным контентом и подать на них в суд.

· Проблема личеров – клиентов, которые раздают гораздо меньше, чем скачивают. Это ведет к падению производительности.

· Проблема читеров – пользователей, модифицирующих информацию о количестве скачанных\переданных данных.

Персонализация – протокол не поддерживает ников, чата, просмотра списка файлов пользователя. [3]

 

Заключение

 

Современные пиринговые сети претерпели сложную эволюцию и стали во многих отношениях совершенными программными продуктами. Они гарантируют надежную и высокоскоростную передачу больших объемов данных. Они имеют распределённую структуру, и не могут быть уничтожены при повреждении нескольких узлов.

Технологии, опробованные в пиринговых сетях, применяются сейчас во многих программах из других областей:

- для скоростного распространения дистрибутивов опенсорсных программ (с открытым кодом);

- для распределённых сетей передачи данных таких как Skype и Joost.

Однако системы обмена данными часто используются в противоправной сфере: нарушаются закон об авторских правах, цензура и т.д. Можно сказать следующее: разработчики пиринговых сетей отлично понимали, для чего те будут использоваться, и позаботились об удобстве их использования, анонимности клиентов и неуязвимости системы в целом. Программы и системы обмена данными часто относят к «серой» зоне интернета — зоне, в которой нарушается законодательство, но доказать виновность причастных к нарушению лиц или сложно, или невозможно.

Программы и сети обмена данными находятся где-то на «окраине» интернета. Они не пользуются поддержкой крупных компаний, иногда им вообще никто не содействует; их создатели, как правило, хакеры, которым не по душе интернет-стандарты. Программы обмена данными не любят производители брандмауэров, маршрутизаторов и подобного оборудования, а также интернет-провайдеры (ISP) — «хакерские» сети отбирают у них значительную часть драгоценных ресурсов. Поэтому провайдеры пытаются всячески вытеснить и запретить системы обмена данными или ограничить их деятельность. Однако в ответ на это создатели систем обмена данными снова начинают искать противодействия, и часто добиваются отличных результатов.

Реализация и использование распределенных систем имеют не только плюсы, но и минусы, связанные с особенностями обеспечения безопасности. Получить контроль над столь разветвленной и большой структурой, какой является сеть P2P, или использовать пробелы в реализации протоколов для собственных нужд — желанная цель для хакеров. К тому же защитить распределенную структуру сложнее, чем централизованный сервер.

Столь огромное количество ресурсов, которое имеется в сетях P2P, тяжело шифровать/дешифровать, поэтому большая часть информации об IP-адресах и ресурсах участников хранится и пересылается в незашифрованном виде, что делает ее доступной для перехвата. При перехвате злоумышленник не только получает собственно информацию, но также узнает и об узлах, на которых она хранится, что тоже опасно.

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

Серьезная проблема — распространение “червей” и подделка ID ресурсов с целью их фальсификации. Например, в клиенте Kazaa используется хеш-функция UUHash, которая позволяет быстро находить ID для больших файлов даже на слабых компьютерах, но при этом остается возможность для подделки файлов и записи испорченного файла, имеющего тот же ID.

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

Также ведется работа по созданию проектов, объединяющих сети и протоколы (например, JXTA – разработчик Билл Джой). [3]

 

Список литературы

 

1. Ю. Н. Гуркин, Ю. А. Семенов. «Файлообменные сети P2P: основные принципы, протоколы, безопасность» // «Сети и Системы связи», №11 2006

06/02/2011 17:23 http://www.ccc.ru/magazine/depot/06_11/read.html?0302.htm

2. А. Грызунова Napster: история болезни InterNet magazine, number 22 06/02/2011 15:30 http://www.gagin.ru/internet/22/7.html

3. Современные компьютерные сети Реферат 06/02/2011 15:49 http://5ballov.qip.ru/referats/preview/106448

4. 28/01/2011 16:56 http://ru.wikipedia.org/wiki/Peer-to-peer

5. http://style-hitech.ru/peer-to-peer_i_tjekhnologii_fajloobmjena

28/01/2011 15:51