- PVSM.RU - https://www.pvsm.ru -
Размещение веб-ресурса в скрытой сети подразумевает нежелание обнаружения физического местонахождения сервера. Когда профессионалы ставят своей целью раскрыть личность владельца той или иной площадки, в ход идет всё: от социальной инженерии до анализа метаданных изображений, размещенных на сайте и тому подобное. В рамках этой статьи нас интересует тайминг-атака, основанная на сопоставлении различных событий во времени и их логическая состыковка. Например, подозреваемый N вошел в дом, после чего через пять минут его предполагаемая виртуальная личность появилась в чате. В более реальных случаях время появления подозреваемого в сети может намекать на его часовой пояс. Подобных приемов наблюдательности не перечесть.
Опыт со сгоревшим дата-центром OVH [1] показал, что от тайминг-атаки не защищены даже пользователи топовых ЦОД. Резкий уход в оффлайн нескольких сервисов в момент пожара отлично демонстрирует сужение круга подозреваемых - нужно искать среди клиентов пострадавшего дата-центра.
В I2P существует прием, именуемый мультихоумингом. Термин "мультихоуминг" происходит он английских слов "multi" и "home" - на русский язык можно перевести, как "одновременное размещение веб-ресурса на нескольких хостах". Ниже рассмотрим суть этого явления.
Изложенный материал может быть полезен широкому кругу администраторов, студентов и любопытствующих, и никоим образом не имеет своей целью призвать читателя к противоправным действиям!
Маршрутизация I2P описана в статье [2] про флудфилы. Вкратце, суть сводится к следующему: внутрисетевой адрес привязывается к криптографическим ключам, которые локально хранятся на сервере.
Простая реализация мультихоуминга не требует шаманских навыков, так как представляет из себя банальную развертку двух одинаковых веб-серверов, которые при одинаковых ключах имеют один и тот же I2P-адрес. В таком случае нельзя фактически предсказать на какой из двух серверов попадет пользователь. Да он, собственно, и сам не узнает.
Дабы схема была осмыслена, все сервера должны располагаться в разных местах (различные дата-центы, юрисдикции и даже континенты). Кстати говоря, серверов может быть не два, а хоть сотня. Если произойдет нацеленная атака, либо случайное ЧП с одним из серверов, ничего страшного не случится - пользователи будут получать лизсет от сервера, который по-прежнему находится в сети и никто не сможет сделать вывод о том, что в отключенном сервере или дата-центре хостился ваш скрытый веб-ресурс. В случае со статичными сайтами это готовая реализация, а для ресурсов с бэкэндом (базой данных и прочим) - все выведенные в I2P веб-серверы должны ссылаться на основной сервер, то есть выступать в роли прокси.
Здесь становится очевидно слабое место, от которого так пытались избавиться, - основной сервер. В некоторых конфигурациях возможно вообразить полное зеркалирование между двумя автономными серверами, однако в сложных и высоконагруженных проектах, использующих куки и различные базы данных, всё упирается хотя бы в один сервер, существующий в единственном экземпляре, потеря которого неизбежно скажется на работоспособности веб-ресурса (если ошибаюсь - развернуто опишите конфигурацию в комментариях). Очевидно, что критически важный сервер должен располагаться в самом надежном месте.
I2P не славится скоростью передачи информации, поэтому связь проксирующих серверов с основным в большинстве случаев целесообразно организовать через быстрое защищенное соединение вроде VPN или Yggdrasil [3]. Если подходить с умом, надо стараться планировать архитектуру в стиле неуловимого Джо, чтобы скомпрометированный сервер-пустышка не мог служить подсказкой о размещении основного сервера... Оставим этот ребус на откуп читателю.
На этот раз много букв о сложной конфигурации не получится, потому что всё предельно просто. На всех серверах-клонах создается обычный серверный туннель [4] с использованием одинаковых ключей. Надо отметить, что одинаковыми должны быть не имена, указанные в конфиге, а именно файлы. Для этого необходимо скопировать ключ на каждый сервер, размещая его в рабочей директории i2pd. Как правило, это /var/lib/i2pd/
, но точный путь можно всегда посмотреть в веб-консоли [5] (параметр "Data path"). Тонкости проксирования сайтов выходят за рамки этой статьи, но тема легко гуглится [6] и в банальных случаях выливается в несколько строк конфигурационного файла веб-сервера.
Если заинтересовались безопасным
Оригинальная статья опубликована в блоге дата-центра ITSOFT.
Автор: acetone
Источник [9]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/informatsionnaya-bezopasnost/366867
Ссылки в тексте:
[1] сгоревшим дата-центром OVH: https://habr.com/ru/news/t/546264/
[2] статье: https://habr.com/ru/post/563958/
[3] Yggdrasil: https://habr.com/ru/post/547250/
[4] серверный туннель: https://i2pd.readthedocs.io/en/latest/user-guide/tunnels/#i2p-tunnel-configuration
[5] веб-консоли: http://127.0.0.1:7070/
[6] гуглится: https://duckduckgo.com/?q=%D0%9F%D1%80%D0%BE%D0%BA%D1%81%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5+%D1%81%D0%B0%D0%B9%D1%82%D0%B0+nginx+proxy_pass&t=ffab&ia=web
[7] хостингом: https://www.reg.ru/?rlink=reflink-717
[8] материале: https://habr.com/ru/post/557690/
[9] Источник: https://habr.com/ru/post/571720/?utm_source=habrahabr&utm_medium=rss&utm_campaign=571720
Нажмите здесь для печати.