Невидимые сети и скрытые серверы: выявление истинного IP/сетевого идентификатора I2P-узлов

Введение:

I2P является распределенной невидимой сетью, использующей модель смешанной сети, и в определенной мере она похожа на Tor, но специализирующаяся на предоставлении внутренних служб вместо обеспечения доступа в "большой интернет".
Название I2P произошло от сокращения "Проект Невидимый Интернет" ("Invisible Internet Project"), хотя в этой длинной форме он редко употребляется . Подразумевается, что он действует как оверлейная сеть поверх сети Интернет для большей анонимности и безопасности.

Основной целью этого проекта является обеспечение безопасности I2P eepSite узлов (веб-серверов скрытых в сетях I2P) путем нахождения слабых мест в реализации этих систем на более высоких уровнях приложения, которые могут привести к их реальным IP или раскрытию личности администратора. Мы также хотели бы найти уязвимости, которые могут привести к значительному снижению анонимности, и компенсировать их. Раскрытие этих недостатков позволит администраторам сервисов I2P eepSite избежать этих ловушек, когда они реализуют свои веб-приложения I2P. Вторичной целью было дать возможность идентифицировать определенные группы людей, в поиске которых правоохранительные органы могли бы быть заинтересованы, в частности это педофилы. Эти цели несколько противоречивы, так как правоохранительные органы могли бы использовать эти сведения, чтобы преследовать группы по другим причинам, а педофилы - чтобы помочь скрыть себя, однако ни одна из этих целей не являются желаемой, но все же с вопросами конфиденциальности иногда нужно принимать плохое ради хорошего. I2P была выбрана в качестве платформы, т. к. в отличии от Tor, I2P исследована меньше, однако многие из подобных идей и технологий должны быть применимы к обеим системам, так как они предлагают аналогичные функциональные возможности, когда речь идет о скрытых сервисах, основанных на HTTP. Другая особенность, которая делает эти исследования более примечательными, в том, что в прошлом большая часть работы была нацелена на обнаружение пользователей, а не поставщиков услуг в невидимой сети.

Хотя существует много работ на тему атак на анонимизирующие сети, большинство из них кажутся понятны только посвященным. Вот немного предыдущих статей, исследующих эту тему, которые могут быть полезны для изучения:

Определение местонахождения скрытых серверов[1].

Атаки, основанные на недостаточной производительности маршрутизации против анонимных систем[2].

Работа "Определение местонахождения скрытых серверов" не может быть непосредственно применима, так как I2P предположительно идет по пути самостоятельной синхронизации времени во избежание проблемы сдвига часов[3]. Более близкий к I2P анализ можно найти на сайте проекта: "Модель угроз I2P[4]", а руководства по созданию более анонимных сервисов -- на сайте "Ugha's I2P Wiki[5]". Страница модели угроз указывает на много других ресурсов и работ по возможным направлениям атак. Больше исходной информации, которая будет использована на протяжении испытаний, перечислено в разделе о подходе.

Сведения по I2P

Так как академическое сообщество более осведомлено о сети Tor, чем о I2P, возможно будет полезным сравнить две эти системы и немного осветить основы, касающиеся работы I2P. И Tor и I2P используют многослойную криптографию, поэтому промежуточные участники не могут дешифровать содержимое соединений сверх того, что им нужно знать для передачи соединения дальше к следующей точке цепи. Вместо концентрации на анонимном доступе в Интернет, главная идея I2P - предоставить анонимное обеспечение сервисов (подобно концепции скрытых сервисов в Tor). Эта сеть обеспечивает внешний доступ в Интернет посредством того, что можно назвать "внешними прокси", вместе с доступом различных внутренних служб сети в сети Tor или Freenet, однако это не является целью основного замысла.

Каждый I2p-узел в общем является маршрутизатором (и вы можете использовать эти термины до некоторой степени как взаимозаменяемые, когда дело касается I2P) поэтому нет четкой разницы между сервером и обычным клиентом, в отличии от сети Tor. Некоторые I2P-узлы принимают на себя больше ответственности, чем другие, например floodfill-маршрутизаторы, которые участвуют в NetDB для обработки маршрутизации. В отличии от Tor, в I2P не используются централизованные сервера-указатели для соединения узлов, вместо этого используется DHT (Distributed Hash Table - Распределенная таблица хэшей), основанная на Kademlia[6] - это уже упоминавшаяся NetDB. Эта распределенная система помогает убрать точку отказа и сопротивляться попыткам блокировки подобно тому, что случилось с Tor, когда Китай заблокировал доступ к его основным серверам-указателям 25-го сентября 2009 года[7]. То, что I2P полагается на систему точка-точка для распределения маршрутизации, открывает больше средств для атак типа "Sybil"[8], а так же для шпионских узлов, однако были предприняты шаги для смягчения ситуации, которые описаны в документации к I2P[9].

Вместо обращения к другим маршрутизаторам или службам по их IP, I2P использует криптографические идентификаторы для определения как маршрутизаторов так и конечных служб. Например, внутренний идентификатор для "www.i2p2.i2p", главного веб-сайта проекта, выглядит так:

-KR6qyfPWXoN~F3UzzYSMIsaRy4udcRkHu2Dx9syXSz

UQXQdi2Af1TV2UMH3PpPuNu-GwrqihwmLSkPFg4fv4y

QQY3E10VeQVuI67dn5vlan3NGMsjqxoXTSHHt7C3nX3

szXK90JSoO~tRMDl1xyqtKm94-RpIyNcLXofd0H6b02

683CQIjb-7JiCpDD0zharm6SU54rhdisIUVXpi1xYgg

2pKVpssL~KCp7RAGzpt2rSgz~RHFsecqGBeFwJdiko-

6CYW~tcBcigM8ea57LK7JjCFVhOoYTqgk95AG04-hfe

hnmBtuAFHWklFyFh88x6mS9sbVPvi-am4La0G0jvUJw

9a3wQ67jMr6KWQ~w~bFe~FDqoZqVXl8t88qHPIvXelv

Ww2Y8EMSF5PJhWw~AZfoWOA5VQVYvcmGzZIEKtFGE7b

gQf3rFtJ2FAtig9XXBsoLisHbJgeVb29Ew5E7bkwxvE

e9NYkIqvrKvUAt1i55we0Nkt6xlEdhBqg6xXOyIAAAA

Это представление адреса назначения в кодировке base64. Очевидно, что заставлять пользователя вводить это кусок данных размером в 516 байт будет не так дружественно, к тому же это не приемлемо в некоторых протоколах (например в HTTP). I2P обеспечивает некоторые обходные пути для именования идентификаторов, один из которых - имена в формате base32, во многом подобный соглашению именования доменов .onion в сетях Tor. Основной 516-байтный идентификатор декодируется(с некоторой заменой символов) в некое исходное значение, которое хэшируется с помощью алгоритма SHA256, затем этот хэш переводится в кодировку base32 и в конец добавляется ".b32.i2p"[10]. Результаты этой операции для идентификатора, указанного выше, будут выглядеть так:

rjxwbsw4zjhv4zsplma6jmf5nr24e4ymvvbycd3swgiinbvg7oga.b32.i2p

С этой формой гораздо удобнее работать. Для большинства пользователей eepSite более распространенное решение именования - это использование локальной адресной книги I2P, которая связывает простое имя типа "www.i2p2.i2p" с его более длинным base64-идентификатором. Не существует официальных служб типа DNS для осуществления поиска, т. к. это будет точкой сбоя, которого проект I2P хочет избежать. Каждый I2P-узел имеет свой собственный набор текстовых файлов, которые содержат соответствия имен, в большей степени похожий на способ, которым интернет привык пользоваться до того, как был изобретен DNS - это файлы HOSTS, которые переводили имена в IP-адреса. Однако внутри I2P сети есть службы именования по подписке, с которыми можно синхронизироваться, если пользователь того пожелает, однако это означает, что пользователь на некотором уровне доверяет этим службам, чтобы они не отнимали эти соответствия имен.

Идентификатор маршрутизатора - это не тоже самое, что идентификатор службы, поэтому даже если кажется, что служба запущена на определенном маршрутизаторе, эти два идентификатора не могут быть так просто связаны между собой. В I2P так же применяются некоторые техники, помогающие снижать эффективность атак, направленных на сопоставление трафика. В то время, как Tor-сеть использует один меняющийся путь для связи, I2P использует концепцию "входящих" и "исходящих" туннелей, поэтому ответы и запросы не обязательно используют одинаковые пути для обмена информацией. I2P так же использует вариант Onion ("луковой") маршрутизации, упомянутой как Garlic ("чесночная") маршрутизация[11], в которой более чем одно сообщение упаковано в "дольку". Это перемешивание информации с использованием чесночной маршрутизации может привести к замешательству атакующих, пытающихся сопоставить размеры и промежутки времени передачи, а если "дольки" составлены из пакетов от приложений, терпимых к высоким задержкам (например электронная почта) и приложений, которым нужны низкие задержки (например web-трафик), сопоставление может оказаться даже более трудным. Другие сравнения межу I2P, Tor и другими анонимными сетями можно найти на сайте проекта I2P в статье "I2P в сравнении с другими анонимными сетями"[12].

Внутри сети I2P можно поддерживать много разных служб (IRC, BitTorrent, eDonkey, Email), а разработчики I2P обеспечили API для создания новых приложений, которые используют сеть I2P. Как отмечают разработчики проекта, множество стандартных интернет-приложений не разрабатывались с оглядкой на анонимность, поэтому при адаптации этих приложений для использования поверх I2P-сети необходимо проявлять осторожность. Существует много приложений, которые можно исследовать на предмет утечек данных, однако эта работа будет сконцентрирована на eepSite - web-сайтах внутри I2P-сети. В установке I2P по-умолчанию приняты некоторые меры на уровне приложения, для того, чтобы помочь отфильтровать разоблачающую информацию, однако провайдеры служб допускают ошибки, которые могут привести к тому слишком много информации будет раскрыто.

Обзор подхода

Наш главный подход - это посмотреть на уровень приложения и увидеть, какие детали узлы и eepSite'ы отдают о себе. Это уже было проделано в прошлом против скрытых клиентов с достаточным успехом:

Metasploit Decloaking Engine[13]

Проект EFF по идентификации веб-клиентов[14][3]

Поскольку мы нацелены на идентификацию серверов, а не клиентов, точные направления атаки будут отличаться, однако будет и их перекрытие. Много I2P служб содержатся на узлах/маршрутизаторах, которые так же действуют как клиентский узел владельца, поэтому атаки, направленные на клиента для их раскрытия, тоже могут быть плодотворными. Люди постоянно допускают ошибки при настройке веб-северов и приложений, что приводит к тому, что слишком много информации может утечь к атакующему, информации, способной упростить поиск работающей уязвимости. Этот тип информационной утечки регулярно упоминается в Top 10 OWSAP(Open Web App Security Project или Открытый проект безопасности веб-приложений)[15] в той или иной форме. Один из наших лозунгов гласит: "Определенные уязвимости временны, грубые ошибки при настройке - постоянны". Некоторые техники, применявшиеся нами для выявления идентификационной информации о узле eepSite'а, включают:

1. Захват заголовков серверов, использующихся на ипсайтах внутри I2P и на IP-адресах, о которых известно, что они участвуют в скрытой сети, для уменьшения анонимного множества исследуемых серверов.

2. Поиск по whois и обратной DNS-записи для определения информации, касающейся IP-адресов узлов I2P.

3. Использование стека TCP/IP для определения "отпечатков" операционных систем.

4. Проверка I2P-имен виртуальных узлов на их общедоступных IP.

5. Сравнение часов на удаленном I2P-сайте и на общедоступном IP-адресе подозреваемого узла с часами в нашей системе. Мы делали это с помощью заголовка HTTP "Date:".

6. Использование атак с включением команд в запрос к серверу.

7. Ошибки в реализации web-службы для деанонимизации администрации или пользователей. (Это оказалось гораздо сложнее, чем мы сначала думали).

Благодаря природе I2P-сети, в нее было введено несколько сложностей. Эти технические сложности привели к полной неудаче или выявлению неоднозначных результатов у многих стандартных приложений проверки безопасности. Вот несколько примеров этих проблем:

Первое.
Обмен данными с eepSite'ами обычно осуществляется через HTTP-прокси. Это более мудро с точки зрения ограничения соединения, чем использование SOCKS-прокси, и намного более ограниченно, чем иметь прямое TCP/IP-соединение с целью. К тому же, HTTP-прокси, идущий в I2P по умолчанию не поддерживает команду "CONNECT". Не смотря на то, что это указано в документации, впервые мы столкнулись с этим, пытаясь запустить сканирование с помощью Nmap, используя утилиту proxychains и увидев следующее сообщение(после применения Wireshark для диагностики, почему наши попытки заканчиваются неудачей):

Предупреждение: не-HTTP протокол

Запрос использует неверный протокол.

I2P HTTP-прокси поддерживает ТОЛЬКО HTTP запросы. Другие протоколы, такие как HTTPS и FTP не допускаются.

Не смотря на то что это сложная проблема, мы смогли обойти проблему, написав несколько собственных скриптов на python для выполнения требуемых задач. zzz[16] указал нам, что SOCKS и команда "CONNECT" должны работать, если мы настроим тоннели для них, но сначала мы не смогли заставить их функционировать. После длительных консультаций с zzz (и отсылки логов) выяснилось, что есть небольшая уловка для установки соединения с ипсайтом (eepSite) через туннель SOCKS-прокси. Мы должны были удостовериться, что DNS запросы отправлялись через SOCKS-туннель; в противном случае DNS-система пыталась бы искать имя хоста, оканчивающееся на .i2p в публичном интернете, где такой домен верхнего уровня не зарегистрирован. В Firefox это можно настроить, добавив в about:config строку:

network.proxy.socks_remote_dns = true

Однако это решает проблему только для Firefox. Эта проблема может вызвать трудности при настройке других приложений для использования клиентского SOCKS-туннеля в качестве прокси.

Второе.
Возможно из-за первого, многие из средств индексации, с которыми мы до сих пор экспериментировали давали ложные результаты или зависали при индексации ипсайтов. Для компенсации особенностей ипсайтов мы написали специальные скрипты, также мы вручную проверяли результаты индексации. Многие из страниц размещенных в I2P используют ПО для форума, доски изображений или блога, это ПО передает параметры через секцию пути файла в URL. Это может привести к тому, что не будет возвращена ошибка 404 даже при запросе несуществующего файла. Когда средство индексации сообщает о том, что найден устаревший или уязвимый файл, его приходится проверять вручную.

Третье.
Фильтрация клиентских запросов несколько усложняет атаку администратора ипсайта (eepSite), используя ошибки в web-службе, иначе случайные XSS-атаки попадают в логи[17]. Если администратор все же был поражен с помощью XSS, вполне возможно, что они в то же время будут пользоваться и I2P, что в таком случае приведет к тому, что возвращаемая информация будет проходить через внешний прокси, а не напрямую с их IP-адресов. При использовании HTTP-туннеля, I2P автоматически меняет строку агента web-браузера на "User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.6)", а для внутренних I2P-сайтов на "MYOB/6.66 (AN/ON)". Такое поведение снижает к нулю попадание XSS-атак в логи ипсайта, а также надежду получить информацию обратно, когда администратор проверяет логи с помощью HTML-отчета. Множество HTTP-заголовков фильтруются или нормализуются I2P, это такие заголовки как: Accept, Accept-Charset, Accept-Encoding, Accept-Language, Accept-Ranges, Referer[18], Via и From[19]. Добавьте также тот факт, что администратор, осознающий необходимость безопасности, может использовать NoScript, TorButton (который обеспечивает больший анонимизирующий функционал , чем просто смена прокси-серверов) или другие дополнения, улучшающие анонимность, отчего атаки направленные на клиентскую часть могут оказаться более трудоемкими. Хотя на тему идентификации и уникальности клиента, мы провели быструю проверку, используя Panopticlick. Когда мы попытались использовать нормальную установку Firefox, Panopticlick сообщил, что мы "уникальны среди 1258250 протестированных до настоящего момента". Однако когда мы воспользовались Tor Browser Bundle[20] и настроили его для использования с нашим локальным I2P-прокси, Panopticlick сообщил, что "один из 15343 браузеров имеет такой же "отпечаток" как и у вас", что гораздо лучше. По существу, для пользователей I2P рекомендуется использовать не их браузеры по умолчанию, а использовать вместо этого специально выделенные браузеры.

Наш опыт в тестировании веб-приложений внутри I2P ярко показал, что более важно понимать принципы их работы, чем просто использовать против них случайные инструменты и "надеяться на лучшее". Nathan Hamiel и Marcin Wielgoszewsk подготовили отличный доклад на Defcon 18 по вопросам написания собственных инструментов для оценки безопасности веб-приложений[21]. К сожалению, мы не могли ничего найти об их работах до того, как мы сделали большую часть наших инструментов. Если кому интересно, они опубликовали свои примеры кода[22].

Следующими важными проблемами были юридические по природе в противоположность техническим. Во время индексации нам было необходимо быть осторожными, чтобы не загрузить на наши системы какой нибудь незаконный материал. В I2P содержится значительное количество детской порнографии, а законы США достаточно суровы в этом отношении, даже если файлы были получены во время легальных исследований. Поэтому в основном мы индексировали текст, который в виде данных EXIF в картинках, содержащихся на ипсайтах, к сожалению, может иметь значение в выявлении личности. Другая проблема состояла в том, что некоторые техники, которые мы проверяли, могли быть неприемлемыми при применении против ресурсов, которые нам не принадлежат, поэтому мы настроили свой собственный ипсайт, для выполнения многих проверок. Для частых веб-уязвимостей, которые могут повлечь за собой разоблачение личности, мы проводили проверки на учебном пакете Mutillidae[23], который реализует Top 10 уязвимостей по версии OWASP. Хоть Mutillidae не слишком реалистичен с той точки зрения, что он ПРЕДНАЗНАЧЕН для взлома, он по крайней мере действует как доказательство концепции того, что если подобные уязвимости найдутся на I2P-приложении, обращенном во вне, они могут привести к получению идентификационной информации.

Оценка

Сбор данных о eepSites

Первоочередной задачей, с которой нам требовалось справиться, являлся способ проверки, какие I2P сайты работают в данный момент и отвечают на запросы. I2P, как и многие другие P2P системы, содержит массу "пены". Эта "пена" усложняет своевременное определение доступности сайтов.

Одним из решений, позволяющих получить информацию о доступных сайтах, может быть сканирование популярных I2P порталов, таких как forum.i2p или ugha.i2p, на предмет наличия адресов, оканчивающихся на .i2p, а затем сканировать далее рекурсивно. Однако такой путь может быть достаточно долгим, многие ссылки ведут на "мёртвые" ресурсы (видимо немало людей запускают сайт только для развлечения, а затем забывают про него) и мы можем пропустить сайты, которые активны, но на которые ссылаются не очень часто.

Другая возможность - это анализировать файл host.txt, который I2P использует для именования соответствия криптографических идентификаторов и проверяет доступность каждого i2p-ресурса. SusiDNS позволяет пользователю подписываться на сервисы сопоставления имен узлов. Сервисы адресных книг, на которые мы были подписаны:

http://www.i2p2.i2p/hosts.txt

http://i2host.i2p/cgi-bin/i2hostetag

http://stats.i2p/cgi-bin/newhosts.txt

http://tino.i2p/hosts.txt

Это дало нам 1538 имен узлов в нашей адресной книге на приблизительно 13:00 EST 10/27/2010.

Окончательным решением было использовать комбинацию обоих методов. Был написан скрипт на Python, который просто проверял код статуса, возвращаемого ипсайтом, когда запрашивался его корневой документ, а заодно делал захват заголовка типа сервера, который сообщал web-демон ипсайта. Хотя сообщаемая информация может быть модифицирована системным администратором, чтобы не содержать дополнительную информацию о платформе или даже возвращать неверную информацию, не все администраторы обеспокоены этим. Этот скрипт может быть использован напрямую через локальный i2p-прокси, или может быть связан с другим перехватывающим прокси для дополнительной функциональности. В общем, перехватывающие прокси предназначены для запуска на локальной системе и позволяют пользователю изменять запросы перед их отсылкой на сервер, а многие из них предлагают дополнительный функционал, например слежение за изменениями или сканирование на предмет частых ошибок в настройке. Мы выбрали ZAP (Zed Attack Proxy[24]) в качестве прокси-перехватчика, а так же использовали его для необходимых действий с сайтами. ZAP является ответвлением проекта Paros Proxy и кажется прекрасно работает на подобных задачах.

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

C:\Windows\SysWOW64\config\systemprofile\AppData\Roaming\I2P\hosts.txt

Выбор количества потоков несколько произволен. Мы не хотели загрузить локальные прокси слишком большим количеством запросов, однако выполнение проверок статуса и захват заголовков по одному было бы слишком медленно. Мы получили разумные результаты с количеством потоков в пределах от 10 до 25. При тестировании были получены следующие цифры: при 100 параллельных потоков найдено 104 активных eepSites за 798.585 секунд, а при 10 потоках 112 через 5934.425 секунды. Имейте в виду, что эти результаты не абсолютно предсказуемы, поскольку внешние факторы, возможно, вызвали различия в скорости, и числе eepSites, но кажется, что локальный I2P-прокси может работать во много потоков, не переставая обрабатывать большое количество сетевых соединений. Таким образом, мы получили более быстрое сканирование с использованием большего количества потоков.

Для экономии места мы не будем вставлять исходный код наших сценариев для исследования, но наши примеры на Python доступны на веб-сайте автора или по запросу [25]. Ниже -- краткий обзор о функции каждого сценария:

I2PMassGrabber-headers.py

Проверяет состояние каждого I2P хоста из файла host.txt на предмет доступности, а затем генерирует вывод в формате CSV и HTML в формате: имя хоста, статус, и заголовок сервера. Входной файл и прокси-серверы должны быть изменены на основе пользовательских настроек. Этот сценарий также собирает отпечатки веб-страниц, которые могут быть рассмотрены в дальнейшем.

real-IP-banner.py

Собирает HTTP заголовки с публичных IP, таким образом мы можем сравнивать, сортировать и фильтровать их позже.

dump-and-sort-i2p-router-ips.py

Код для разбора NetDB, использовавшийся для получения списка IP из нашего локального NetDB-кэша. Регулярное выражение необходимо доработать, т. к. несколько неверных IP попали в результирующий список. Генерирует или добавляет данные в файл all-sorted-uniq.txt, поэтому этот скрипт может быть запущен с помощью планировщика для сборки IP-адресов I2P-узлов за какое-то время.

time-stamp-server.py

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

virtual-server-test.py

Скрипт проверки виртуальных узлов I2P. Этот скрипт использует большой CSV-файл для проверки определенных имен узлов I2P на заданном публичном IP-адресе для того, чтобы узнать, не возвращаются ли разные страницы. Он так же сохраняет "отпечатки" этих страниц в директории с временными метками.

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

Настроив python-сценарий для сбора заголовков на использование ZAP в качестве его прокси, а затем направив ZAP на локальный I2P-HTTP прокси, мы были в состоянии выполнять как сбор заголовков, так и загрузку URL-информации в ZAP, которая потом могла быть использована для дальнейшего сканирования. Вывод сценария направлялся в два файла с именами в виде временной метки, один в HTML для непосредственного просмотра в браузере, а второй - в CSV для подачи на вход в другие приложения. Вот пример CSV-файла:

"bitcoin4cash.i2p","200","Apache"

"shpargalko.i2p","200","Apache/2.2.15 (Win32) PHP/5.3.2"

"darrob.i2p","200",""

"ufm.i2p","200","Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.12 with Suhosin-Patch"

CSV - это удобный в работе формат, т.к. он может быть легко импортирован в другие программы, особенно Microsoft Excel и Access. Данные, полученные с помощью ZAP, будут немного освещены в последующих разделах. Самая большая выгода для атакующего при использовании перехватывающего прокси - нахождение возможных веб-приложений для эксплуатации [их уязвимостей] с помощью таких возможностей ZAP, как скрытое наблюдение, простой перебор[доступных] файлов\директорий, сканирование [портов]. Администратор eepSite'а должен осознавать, что просто потому, что тот или иной файл или каталог не афишируется, не означает, что он не может быть найден атакующим.

Одновременно со сканированием сайтов с помощью ZAP и сбором заголовков eepSite'ов с помощью python-скрипта, мы попытались запустить Wireshark[26] и сохранить сетевой трафик на диск. Не смотря на то, что данные, отправляемые по сети зашифрованы, просто знание того, кто общается с нами через I2P может быть изобличающим. Мы можем отфильтровать трафик для узлов, о которых мы знаем, что они соединены с нами в I2P-сети, основываясь на известных номерах портов, которые мы используем. Эти порты не фиксированы, но мы можем найти их, перейдя в локальную консоль [управления]:

http://127.0.0.1:7657/config.jsp

и записав порты, которые сейчас заданы. Т.к. наш I2P-узел использовал одновременно UDP и TCP порт 12668, мы задали фильтр захвата как "port 12668" для того, чтобы убрать посторонние данные. Во время испытаний со сниффером, мы столкнулись с ошибкой, которая привела к падению Wireshark. Для смягчения этой проблемы, мы использовали более простой инструмент, который идет в составе Wireshark, который называется dumpcap, только для того, чтобы записать пакеты в файл без их отображения и разбора. Делалось это так:

dumpcap -i \Device\NPF_{E97777A0-5863-4741-AA42-FD3E02B2BD4C} -s 0 -f "port 12668" -w g:\dumpcap.pcap -a duration:3600

Эта команда имеет следующие параметры:

-i указывает dumpcap какой сетевой интерфейс использовать (если вы не уверены, какой из ваших локальных интерфейсов использовать, см. опции локальных интерфейсов, используя ключ -D)

-s для задания размера захвата, т.о. мы захватываем весь пакет

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

-w указывает расположение файла в формате pcap для вывода

-a говорит dumpcap остановить захват при определенных обстоятельствах (в данном случае через час после начала[захвата])

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