История сети I2P берет свое начало в 2003 году, в связи с чем обросла слухами, домыслами и статьями об уязвимостях, часть из которых уже неактуальна. Перед началом основного повествования обозначим решенные проблемы, упоминание которых вы можете встретить до сих пор. Пусть они вас не смущают.
Распространенные заблуждения
Байка номер один: I2P плохо масштабируется и при большом приросте узлов сеть будет парализована, т.к. справочные узлы - флудфилы - не справятся с потоком информации. Дескать I2P работает только пока не популярна, а стоит общей нагрузке вырасти - сеть ляжет.
На самом деле количество флудфилов растет вместе с сетью, а для обращения к определенному скрытому сервису все флудфилы вовсе не требуются. Каждый скрытый сервис публикует свой полный адрес (называемый лизсетом) на двух флудфилах, ближайших по DHT. В свою очередь координаты DHT меняются каждые сутки практически случайным образом.
При получении публикуемого лизсета, каждый из двух флудфилов дублирует информацию трем другим флудфилам, являющимся наиболее близкими в логическом смысле. Итого лизсет публикуется не менее, чем на четырех практически случайных роутерах, к которым и происходит обращение при поиске адреса конкретного сайта или другого скрытого ресурса. Короче говоря: сеть является распределенной и ресурсы для обработки лизсетов растут вместе с общим количеством узлов. Со времен зарождения байки о плохой масштабируемости I2P, сеть многократно выросла и до сих пор остается функциональной без каких-либо намеков на перегрузку флудфилов. Также стоит добавить, что осуществляется переход на новое шифрование, призванное снизить нагрузку на флудфилы.
Байка номер два: роутер, на котором располагается конкретный скрытый сервис, можно определить по ключу шифрования роутера в лизсете скрытого ресурса. Модель строится на том, что луковичное шифрование, используемое в туннелях, не является достаточным, и в первую очередь к сообщению применяется сквозное шифрование ключом роутера, который должен расшифровать сообщение и передать его локальной конечной точке.
Подразумевается, что ключи у скрытых сервисов уникальные, а у роутера - один единственный и, имея идентификатор этого ключа, можно отслеживать другие туннели пользователя. На самом деле эта угроза была ликвидирована на ранних стадиях разработки I2P. Современный лизсет содержит ключ шифрования, никак не связанный с роутером. Для каждого скрытого сервиса используется уникальный ключ, поэтому сопоставление ключей от лизсетов различных скрытых сервисов одного администратора не дает почвы для предположений, что они находятся на одном роутере.
Байка номер три: туннели I2P можно перехватить. Под перехватом подразумевается не дешифровка трафика, а выявление хозяина туннеля. Для атаки требуется максимально возможное количество роутеров с хорошим аптаймом для постоянного их участия в транзитных туннелях. Суть атаки заключается в ожидании момента, когда туннель жертвы будет в большей части (или целиком) состоять из злонамеренных роутеров. Транзитные узлы ничего не знают об общем количестве роутеров в цепочке, однако длина туннелей по умолчанию составляет три хопа. Если допустить, что три роутера подконтрольных злоумышленнику сообщаются между собой в рамках одного туннеля, он может с большой вероятностью предположить, что конечное звено известной цепочки является хозяином туннеля.
В случае перехвата исходящего туннеля пользователя, злоумышленник может узнать куда пользователь обращается, если по нереальному везению в этот момент ему будет известен лизсет, содержащий в себе данные входного туннеля скрытого ресурса, которые совпадут с теми, куда прямо сейчас передается информация. На самом деле эта атака практически не осуществима в настоящий момент, когда количество узлов в сети составляет многие десятки тысяч. При каком бы то ни было перехвате туннеля нельзя с полной уверенностью сказать, что узел, предполагаемый, как владелец туннеля, не является всего лишь еще одним транзитным роутером. Также подобная атака не может называться нацеленной, а скорее случайной, непредсказуемой и очень затратной. Шанс хоть какого-то успешного исполнения всегда остается ничтожно малым.
Ресид
Самым простым способом борьбы с I2P является блокировка ресид-серверов, к одному из которых происходит обращение за начальным рисунком сети при первом запуске роутера. Ресид представляет из себя архив с некоторым количеством файлов routerInfo, по сути - пакет с информацией о случайных роутерах, через которые строятся первые пользовательские туннели и начинается автоматическое расширение локальной базы сети. Все ресид-серверы держат энтузиасты, а сами адреса ресидов имеются в общем доступе. Обращение к ним происходит по доменным именам и на известные IP-адреса, поэтому собрать всё в список и централизованно заблокировать - задача не из сложных. Однако, затруднить первый запуск вовсе не означает заблокировать работу сети I2P! На случай блокировки поддерживается использование прокси при обращении к ресиду, что с легкостью позволяет обойти ограничения локального провайдера. Помимо этого любой роутер может быть запущен с уже имеющейся базой сети, например, взятой с другого I2P-роутера. Новым шагом в борьбе с возможной блокировкой является использование дополнительных зашифрованных каналов связи. В настоящее время таким инструментом является Yggdrasil Network, который служит не только для обращения к ресиду, но и для полноценного использования сети I2P. Для стороннего наблюдателя активность Yggdrasil сравнима с подключением через VPN. На момент выхода статьи работа I2P через Yggdrsail и прокси реализованы только в i2pd, что является дополнительным аргументом против морально устаревшего роутера на Java.
Второй сценарий манипуляций с ресидом - попытка перехвата архива с роутерами по пути до пользователя, чтобы повредить, или подменить. От этого защищает протокол HTTPS, а также криптографическая подпись. Сертификаты держателей ресид-серверов, т.е. их криптографические удостоверения, распространяются в комплекте с I2P-роутером. После получения стартового пакета роутер проверяет его подпись. Если подпись соответствует сертификату, можно быть уверенным, что ресид не был подменен.
Держатели ресидеров - обычные пользователи, энтузиасты. Они не проходят какую-либо проверку и чаще всего остаются инкогнито. Актуальность ресид-серверов регулярно проверяется сообществом и, в случае нарушения работоспособности, в ближайшем релизе I2P-роутера сервер убирается из списка.
Атака Сивиллы и Затмение
Атака Сивиллы (Sybil) и атака Затмение (Eclipse) имеют схожую реализацию. Их смысл заключается в наводнении сети узлами, подконтрольными злоумышленнику, которые будут работать ради одной цели: держать пользователя в песочнице. Изолирующие роутеры не сообщают информацию об обычных узлах, чтобы пользователь не вышел из блокады. Это позволяет мониторить список ресурсов, которые атакуемый пользователь размещает на своем роутере, а также список тех, которые он посещает. Чтобы получить информацию о входных туннелях скрытого ресурса, необходимо получить его лизсет от ближайшего флудфила, равно также как опубликовать лизсет своего ресурса, чтобы его могли найти.
В случае успешной атаки, все туннели пользователя состоят из узлов, подконтрольных злоумышленнику, также как и доступные флудфилы. Основное отличие атаки Сивиллы от Затмения заключается в том, что модель Сивиллы не направлена на заранее известного пользователя, а Затмение наоборот подразумевает изоляцию изначально известной цели. В любом случае названные модели атак подразумевают использование модифицированных I2P-роутеров и высокую грамотность атакующего. Отойдя от обобщенной теории, разберем возможность осуществления этих угроз.
Атаку Затмение на практике можно считать не реализуемой. Это связано с системой ресидов, которые защищены от перехвата. В случае, когда роутер производит первый старт со скопированной базой сети, т.е. по сути дела со стартовым пакетом не от общеизвестного ресида, а от другого I2P-роутера, будем полагать, что источник априори надежный. Логично заключим, что стартовый пакет из недоверенного источника использовать неследует. Если допустить, что злоумышленник выступит в роли энтузиаста и разместит общеизвестный ресид-сервер, надо особо отметить, что в I2P-роутере используется несколько независимых ресидеров, один из которых выбирается случайным образом. Это делает вероятность таргетированной атаки крайне малой из-за чего теряется смысл попытки ее осуществления.
Атака Сивиллы, нацеленная на мониторинг сети в общем, кажется более подходящей для только что описанной модели со злонамеренным ресидом. Но при подробном рассмотрении окажется, что профит фальшивого ресида не окупит средства, затраченные на его организацию. Во-первых, необходимо иметь большие мощности, чтобы ввести в сеть максимально возможное количество подконтрольных узлов. Во-вторвых, нужно разработать программное обеспечение, которое будет гибко объединять в одну базу данных информацию, собираемую с подконтрольных узлов. В-третьих, атака, направленная на анализ, подразумевает большую длительность, которой не получится, т.к. злонамеренный ресид будет скоро выявлен сообществом. Самый очевидный признак такой атаки - не увеличивающееся, или слишком малое количество известных роутеров, которое отображается в веб-консоли. В параноидальном случае следует удалить всю локальную базу роутера, которая хранится в папке netDb и перезапустить роутер, что спровоцирует новое обращение к случайному ресиду. Если у вас достаточно оснований полагать, что какой-то ресид скомпрометирован, обязательно сообщите об этом сообществу разработчиков. На момент выхода статьи не было зарегистрировано ни одной попытки подобной атаки.
Java router destination attack
Последняя модель атаки весьма сложная, но критически опасная в случае успешного исполнения. Проблема обнародована ведущим разработчиком I2Pd и в роутере на C++ отсутствует, однако в Java-роутере долгое время не исправляется. Модель позволяет определить факт нахождения двух и более конечных точек на одном роутере, т.е. фактически определить, что несколько анонимных сущностей физически расположены на одном компьютере. Возможность атаки заключается в том, что все лизсеты в Java-роутере хранятся в одном месте.
В рамках атаки осуществляется полноценное обращение к некоторой конечной точке (в англоязычной терминологии - destination), которая отвечает и сохраняет лизсет атакующего. Затем происходит обращение к другой конечной точке, однако лизсет для ответа не сообщается, и ответа по логике быть не должно. Если ответ приходит, атакующий с уверенностью заключает, что ответившая конечная точка, которой не был отправлен лизсет для ответа, находится на том же роутере, где и первый ресурс, которому был дан лизсет.
В I2Pd проблема решена просто и изящно: для каждой конечной точки создается отдельное хранилище лизсетов, к которому не могут обратиться другие скрытые сервисы, расположенные на роутере.
При детальном рассмотрении часто упоминаемых угроз оказалось, что уязвимостей в I2P гораздо меньше, чем об этом любят говорить псевдо-эксперты. Поддерживайте свободные проекты, сообщайте о багах и недочетах. Свободное ПО - это когда без финансирования и чаще всего без рекламы, но на совесть. Не забывайте, что СМС при регистрации - это не норма!
Материал составлен по тексту и иллюстрациям из видео. Оригинальная статья размещена в блоге дата-центра ITSOFT.
Комментариев нет:
Отправить комментарий