Мультихоуминг в I2P — защита от тайминг-атаки и дополнительная гарантия аптайма
Размещение веб-ресурса в скрытой сети подразумевает нежелание обнаружения физического местонахождения сервера. Когда профессионалы ставят своей целью раскрыть личность владельца той или иной площадки, в ход идет всё: от социальной инженерии до анализа метаданных изображений, размещенных на сайте и тому подобное. В рамках этой статьи нас интересует тайминг-атака, основанная на сопоставлении различных событий во времени и их логическая состыковка. Например, подозреваемый N вошел в дом, после чего через пять минут его предполагаемая виртуальная личность появилась в чате. В более реальных случаях время появления подозреваемого в сети может намекать на его часовой пояс. Подобных приемов наблюдательности не перечесть.
Опыт со сгоревшим дата-центром OVH показал, что от тайминг-атаки не защищены даже пользователи топовых ЦОД. Резкий уход в оффлайн нескольких сервисов в момент пожара отлично демонстрирует сужение круга подозреваемых — нужно искать среди клиентов пострадавшего дата-центра.
В I2P существует прием, именуемый мультихоумингом. Термин «мультихоуминг» происходит он английских слов «multi» и «home» — на русский язык можно перевести, как «одновременное размещение веб-ресурса на нескольких хостах». Ниже рассмотрим суть этого явления.
Изложенный материал может быть полезен широкому кругу администраторов, студентов и любопытствующих, и никоим образом не имеет своей целью призвать читателя к противоправным действиям!
Ищи-свищи
Маршрутизация I2P описана в статье про флудфилы. Вкратце, суть сводится к следующему: внутрисетевой адрес привязывается к криптографическим ключам, которые локально хранятся на сервере.
Простая реализация мультихоуминга не требует шаманских навыков, так как представляет из себя банальную развертку двух одинаковых веб-серверов, которые при одинаковых ключах имеют один и тот же I2P-адрес. В таком случае нельзя фактически предсказать на какой из двух серверов попадет пользователь. Да он, собственно, и сам не узнает.
Дабы схема была осмыслена, все сервера должны располагаться в разных местах (различные дата-центы, юрисдикции и даже континенты). Кстати говоря, серверов может быть не два, а хоть сотня. Если произойдет нацеленная атака, либо случайное ЧП с одним из серверов, ничего страшного не случится — пользователи будут получать лизсет от сервера, который по-прежнему находится в сети и никто не сможет сделать вывод о том, что в отключенном сервере или дата-центре хостился ваш скрытый веб-ресурс. В случае со статичными сайтами это готовая реализация, а для ресурсов с бэкэндом (базой данных и прочим) — все выведенные в I2P веб-серверы должны ссылаться на основной сервер, то есть выступать в роли прокси.
Здесь становится очевидно слабое место, от которого так пытались избавиться, — основной сервер. В некоторых конфигурациях возможно вообразить полное зеркалирование между двумя автономными серверами, однако в сложных и высоконагруженных проектах, использующих куки и различные базы данных, всё упирается хотя бы в один сервер, существующий в единственном экземпляре, потеря которого неизбежно скажется на работоспособности веб-ресурса (если ошибаюсь — развернуто опишите конфигурацию в комментариях). Очевидно, что критически важный сервер должен располагаться в самом надежном месте.
I2P не славится скоростью передачи информации, поэтому связь проксирующих серверов с основным в большинстве случаев целесообразно организовать через быстрое защищенное соединение вроде VPN или Yggdrasil. Если подходить с умом, надо стараться планировать архитектуру в стиле неуловимого Джо, чтобы скомпрометированный сервер-пустышка не мог служить подсказкой о размещении основного сервера… Оставим этот ребус на откуп читателю.
Практическая реализация
На этот раз много букв о сложной конфигурации не получится, потому что всё предельно просто. На всех серверах-клонах создается обычный серверный туннель с использованием одинаковых ключей. Надо отметить, что одинаковыми должны быть не имена, указанные в конфиге, а именно файлы. Для этого необходимо скопировать ключ на каждый сервер, размещая его в рабочей директории i2pd. Как правило, это /var/lib/i2pd/, но точный путь можно всегда посмотреть в веб-консоли (параметр «Data path»). Тонкости проксирования сайтов выходят за рамки этой статьи, но тема легко гуглится и в банальных случаях выливается в несколько строк конфигурационного файла веб-сервера.
Если заинтересовались безопасным хостингом ресурсов в I2P, имеет смысл размещать на арендуемых серверах не основной ключ, который всецело отвечает за внутрисетевой адрес, а временный, кража которого не выльется в фатальную потерю. Подробнее об этом читайте в отдельном материале.
Оригинальная статья опубликована в блоге дата-центра ITSOFT.
