Comments 77
Недавно пробегала инфа что есть дешёвый и не требующий больших ресурсов вроде СОРМ способ определения пользователя Тор, но потом всё как-то заглохло (вроде бы запретили выступление на конфе) — никто не знает подробностей?
Мне казалось, что размер пакетов в сети Tor фиксированный, чтобы подобные атаки не проходили. Об этом есть информация в Tor FAQ.
Была ли данная атака опробована против скрытых сервисов и их пользователей?
Планируется ли применение атаки на практике?
Допустим, пользователь посещает атакующий сайт через lynx, запущенный на неподконтрольном спецслужбам сервере, доступ к серверу осуществляется через SSH. Полная цепочка: пользователь — тор — SSH — неподконтрольный сервер — mail.ru. Можно ли будет пользователя вычислить в данном случае?
Была ли данная атака опробована против скрытых сервисов и их пользователей?
Планируется ли применение атаки на практике?
Допустим, пользователь посещает атакующий сайт через lynx, запущенный на неподконтрольном спецслужбам сервере, доступ к серверу осуществляется через SSH. Полная цепочка: пользователь — тор — SSH — неподконтрольный сервер — mail.ru. Можно ли будет пользователя вычислить в данном случае?
Как видно выше — рамеры фиксированные, но есть как минимум два разных размера блобов, 3648 и 560.
Специально против скрытых сервисов не пробовал, но не вижу причин, почему она не могла бы быть проведена, можно «модулировать» данные запроса от клиента к серверу.
Подозреваю, что на практике эта атака уже может использоваться, но, возможно, это просто моя паранойя. Отследить атаку очень сложно, особенно если не используются слишком заметные шаблоны. Если немного сдвинуть тайминги, то полученная картинка будет гораздо менее заметна на глаз, хотя будет нисколько не хуже определяться алгоритмически.
С lynx ситуация интересная. Теоретически, отследить может быть возможным. lynx «выкинет» из трафика часть данных (теги, служебную информацию), но в целом, он передаст данные дальше в ssh-соединение. Но здесь могут иметь значение детали, например верстка HTML на таблицах может задерживать их отображение, в данном случае это критично. + через любой прикладной шлюз, включая и такой не пройдет невидимая атака, надо модулировать реальные данные.
Специально против скрытых сервисов не пробовал, но не вижу причин, почему она не могла бы быть проведена, можно «модулировать» данные запроса от клиента к серверу.
Подозреваю, что на практике эта атака уже может использоваться, но, возможно, это просто моя паранойя. Отследить атаку очень сложно, особенно если не используются слишком заметные шаблоны. Если немного сдвинуть тайминги, то полученная картинка будет гораздо менее заметна на глаз, хотя будет нисколько не хуже определяться алгоритмически.
С lynx ситуация интересная. Теоретически, отследить может быть возможным. lynx «выкинет» из трафика часть данных (теги, служебную информацию), но в целом, он передаст данные дальше в ssh-соединение. Но здесь могут иметь значение детали, например верстка HTML на таблицах может задерживать их отображение, в данном случае это критично. + через любой прикладной шлюз, включая и такой не пройдет невидимая атака, надо модулировать реальные данные.
P.S. вот так понятней: в один блоб TLS может попадать разное количество ячеек tor, атакующий за счет шейпинга может этим управлять.
Я думаю, можно устранить данную атаку, если внести изменения в тор. Например, не позволять цепочке менять скорость передачи данных: если в какой-то момент данные шли медленно, то некоторое время после не давать скорости увеличиваться. Ну и какие-нибудь поправки на начало передачи, котгда возможны скачки. Скорость передачи данных в нормальных условиях несильно скачает. А вот если сайт пытается провести атаку, то все его данные будут идти медленно и принимающая сторона не сможет заметить аномалии.
В действительности скорость передачи данных очень сильно скачет. Например, в HTTP через одно соединение проходит несколько запросов, между которыми могут быть паузы порядка десятков секунд. А в мессенджерах, терминальных сессиях и т.п. трафик вообще рандомно ходит в любом направлении.
Тогда зайдем с другой стороны — будем цепляться не за минимальную скорость, а за максимальную. То есть, если в какой-то момент данные передавались быстро, то ближайшие несколько секунд скорость не должна резко снижаться. Если данных от сайта недостаточно, чтобы набрать нужную скорость, то дополнять цепочку случайным шумом, который отбрасывается уже на стороне клиента.
Но даже тут сайт может выкрутиться и помечать соединения путем наращивания скорости по определенному правилу (например, первую секунду 1 кб/с, потом 10 секунд 10 кб/с, потом 20 секунд 15 кб/с, так можно создать довольно много комбинаций). Поэтому окончательное решение — это то, чего в торе делать точно не захотят, а именно постоянный шумовой трафик с определенной скоростью или на одной из небольшого набора скоростей. Как мне известно, так делают в I2P. Сработает ли Ваша атака против I2P? Если подключаться к тору через I2P, будет ли возможна атака?
Но даже тут сайт может выкрутиться и помечать соединения путем наращивания скорости по определенному правилу (например, первую секунду 1 кб/с, потом 10 секунд 10 кб/с, потом 20 секунд 15 кб/с, так можно создать довольно много комбинаций). Поэтому окончательное решение — это то, чего в торе делать точно не захотят, а именно постоянный шумовой трафик с определенной скоростью или на одной из небольшого набора скоростей. Как мне известно, так делают в I2P. Сработает ли Ваша атака против I2P? Если подключаться к тору через I2P, будет ли возможна атака?
Вариант с сохранением фиксированной полосы канала работает, он как раз был в конце статьи описан. Но надо понимать, что любое затухание/набор скорости — это уже бит информации.
А вот со стороны сайта делать какие-то действия бесполезно — атакующий все равно может эти данные перешейпировать по-своему.
В I2P я не смотрел, т.е. атака частично компенсирована, но опять же — если у нас есть, например, 4 различимые скорости и мы можем, скажем, раз в минуту между ними переключаться — значит можно передавать 2 бита в минуту, надо только найти способ скрытно сохранять канал достаточно долго и пихать туда трафик так, чтобы со стороны клиентского приложения это не вызывало подозрений. Это возможно в большинстве прикладных протоколов.
Конечно, при таких условиях атака гораздо менее практична, т.к. такие темплейты гораздо сложней распознать в массовом трафике, чем последовательность пакетов определенного размера от известных entry node, чтобы «взвести» оборудование и начать анализировать трафик именно этой сессии.
А вот со стороны сайта делать какие-то действия бесполезно — атакующий все равно может эти данные перешейпировать по-своему.
В I2P я не смотрел, т.е. атака частично компенсирована, но опять же — если у нас есть, например, 4 различимые скорости и мы можем, скажем, раз в минуту между ними переключаться — значит можно передавать 2 бита в минуту, надо только найти способ скрытно сохранять канал достаточно долго и пихать туда трафик так, чтобы со стороны клиентского приложения это не вызывало подозрений. Это возможно в большинстве прикладных протоколов.
Конечно, при таких условиях атака гораздо менее практична, т.к. такие темплейты гораздо сложней распознать в массовом трафике, чем последовательность пакетов определенного размера от известных entry node, чтобы «взвести» оборудование и начать анализировать трафик именно этой сессии.
Правильное решение не в сохранении фиксированной ширины, а в поддержании случайности (непредсказуемости) характеристик потока данных.
Не может быть полной случайности и непредсказуемости данных на неслучайном потоке данных. Если сервер передает большой кусок данных — принимающая сторона должна получить большой кусок данных ровно в то же самое время. Если вы хотите этот кусок сокрыть — придется постоянно передавать большие куски данных.
Если сервер передает большой кусок данных — принимающая сторона должна получить большой кусок данных ровно в то же самое время. Если вы хотите этот кусок сокрыть — придется постоянно передавать большие куски данных.Да, разумеется. Например, качать-раздавать торренты и релеить трафик других нод.
Тогда все-таки правильней поддерживать именно полосу фиксированной ширины, т.к. тогда в принципе нет характеристик, которые контролируются со стороны атакующего, следовательно ничего нельзя получить даже при длительном наблюдении. Если смешивать полезные данные со случайными, то это не спасает от статистического анализа, т.к. при статистическом анализе «случайные» данные становятся закономерными и отделимыми от полезной нагрузки, «белый шум» превращается в прямую. Передаваемый раз в секунду пакетик из 1 байта не видим в зашумленном трафике, но очень хорошо виден при статистическом анализе.
Подождите, я ничего и не говорил о смешивании =) Я имею в виду именно полосу искусственно регулируемой, хоть и динамической ширины. Т.е. её ширина и прочие характеристики никак не должны коррелировать с характеристиками управляемого трафика. Т.е., это не (random + данные) и не (random + данные) = const, это (данные + что-то) = random.
Строго говоря, есть небесполезные действия со стороны сайта: отправка рандомных пакетов на хост получателя. Их отбросит выходная нода тора, но маскировка цже получится.
Эффективность атаки должна ослабевать при увеличении количества добровольцев, устанавливающих выходные ноды Tor.
По-идее, решаемо на уровне выходных TOR нод — принудительный коллапс пакетов. Впрочем, это может увеличить задержки.
Затрудняет, но все-такие не решает: атакующему придется использовать более явные бёрсты трафика и более длительные тайминги между ними, т.е. «передавать данные» между двумя своими точками на меньшей скорости с большей амплитудой.
ну, кстати, да. можно же, например, страницы сайта (несколько подгружаемых JSок) отдавать с разной задержкой разному клиенту в отдельных соединениях…
Да-да. Много вариантов, можно и свой баннер на конкретный сайт за деньги повесить, и шейпить отдачу баннера. От рекламных денег никто ж не отказывается.
А еще год назад на одной из выставок (не помню — или Zero Nights или PHD) показывали активное оборудование СОРМ, которое встает в разрыв между абонентской сетью и интернетом и умеет шейпить трафик. Exit node под контролем такого оборудования — это готовое условие для атаки. И не факт что в других странах уже не так.
А еще год назад на одной из выставок (не помню — или Zero Nights или PHD) показывали активное оборудование СОРМ, которое встает в разрыв между абонентской сетью и интернетом и умеет шейпить трафик. Exit node под контролем такого оборудования — это готовое условие для атаки. И не факт что в других странах уже не так.
А кто получатель этого ID? Не очень понимаю, где двуглавый орел сидит на карте сети.
В случае двуглавого орла получатель ID это оборудование СОРМ, в случае других орлов — его аналоги. Т.е. если спецслужбы захотят знать, кто посещает, например, сайты определенной тематики, им достаточно промаркировать часть трафика от этих сайтов вблизи этих сайтов (если они на подконтрольной территории) или на exit node'ах и на оборудовании отслеживать получателей маркировки. Там где маркировка вошла и не вышла — там и конечный получатель.
Все, понял. Это для трафика от сайтов к пользователю. Спасибо!
«Там где маркировка вошла и не вышла — там и конечный получатель.»
Так может нужно всю полученную информацию отправлять куда-нибудь?
Тогда, выйдет, что маркировка и вошла и вышла — и вроде как конечный получатель вовсе и не конечный получатель. Путаю?
Так может нужно всю полученную информацию отправлять куда-нибудь?
Тогда, выйдет, что маркировка и вошла и вышла — и вроде как конечный получатель вовсе и не конечный получатель. Путаю?
На уровне протокола не очень эффективное сокрытие, т.к. «подозреваемые» все равно есть и выбрать из них того, кто реально запрашивал трафик относительно просто. А в случае именно с tor получатель обнаруживается и без этого условия, т.к. получает трафик от известного списка entry node.
А если делать такой финт «по собственной инициативе» и подставлять кого-то другого — так проще воспользоваться соседским WiFi.
А если делать такой финт «по собственной инициативе» и подставлять кого-то другого — так проще воспользоваться соседским WiFi.
А в случае именно с tor получатель обнаруживается и без этого условия, т.к. получает трафик от известного списка entry node.Одна из причин ставить VPN, тор-мост, ssh или даже просто прокси перед тором. Искать среди всех пользователей, открыто подключающихся к тору, проще, чем среди всех, кто пользуется чем-то из вышеперечисленного.
Обнаружить tor-сайт очень просто. надо дать атаку HTTP/HTTPS в 5-6 гбит/с.
Таргет датацентр сам Вас найдет и сообщит о том, что его атаковали из Вашей сети, дальше это уже вопрос техники и связей обнаружить конкретного пациента.
Таргет датацентр сам Вас найдет и сообщит о том, что его атаковали из Вашей сети, дальше это уже вопрос техники и связей обнаружить конкретного пациента.
И как датацентр определит, что атака идет с вашей сети?
У тора все соединения идут через 3 узла, а эти узлы скорее всего не будут иметь к вам никакого отношения.
У тора все соединения идут через 3 узла, а эти узлы скорее всего не будут иметь к вам никакого отношения.
Не совсем понял в части про «сам Вас найдет и сообщит о том, что его атаковали из Вашей сети», ведь в случае со скрытыми сайтами адрес пользователя тоже скрыт. Таргет датацентру будет казаться, что его атакуют Guard-ноды, которые использует скрытый сайт. А в целом идея хорошая, если проводящая сторона имеет своего человека в каждом возможном датацентре.
Я думаю, эту атаку можно предотвратить, если разнести сам целевой сайт и скрытый сервис тора по разным датацентрам. Сервер, на котором находится сам сайт, через тор подключается к серверу со скрытым сервисом, а там расположен обратный прокси с функцией распознавания DDOS. Если силовики вычисляют сервер, на котором располагается скрытый сервис, они всё равно не видят, где был целевой сайт. А можно исхитриться и использовать заложенные в сам Tor средства для борьбы с DDOS'ом скрытых сервисов.
Я думаю, эту атаку можно предотвратить, если разнести сам целевой сайт и скрытый сервис тора по разным датацентрам. Сервер, на котором находится сам сайт, через тор подключается к серверу со скрытым сервисом, а там расположен обратный прокси с функцией распознавания DDOS. Если силовики вычисляют сервер, на котором располагается скрытый сервис, они всё равно не видят, где был целевой сайт. А можно исхитриться и использовать заложенные в сам Tor средства для борьбы с DDOS'ом скрытых сервисов.
UFO just landed and posted this here
Нет, к сожалению не поможет, это то же самое что datacompboy предлагает выше. К тому же, с точки зрения реализации, это классическая атака slow read, она приведет к увеличению потребления ресурсов на entry node.
UFO just landed and posted this here
UFO just landed and posted this here
Тогда в ход пойдет математика, которая уже умеет извлекать полезный сигнал из-под шумов.
UFO just landed and posted this here
Поможет, еще как. Чем уже спектр полезного сигнала, тем проще его выделять на фоне помех. Конечно, выделить тикание часов на фоне взлетающего самолета будет проблематично, но математика сдвигает шансы в нашу сторону. Для примера возьмем ту же мобильную связь — задавить до полного исчезновения сервиса крайне трудно, даже глушилки и те справляются лишь только с 10-15 метров.
Аналогичный способ можно применить и в большинстве VPN, но, к счастью, он не сработает с прокси и другими прикладными шлюзами.Объясните, пожалуйста, почему эта атака не работает с прокси. Что будет, если перед тором поставить прокси?
Нет ли возможности выставить фиксированный размер UDP-пакета в VPN? Казалось бы, это должно решить проблему.
Атака в целом работает с прокси, не работает только передача маркировки через полузакрытое соединение, когда маркировку можно передать скрытно от клиентского приложения, не затрагивая передачу реальных данных. Именно потому, что прикладной шлюз одновременно является и клиентом и сервером. Клиент не считает«скрытых» данных — соответственно и не передаст их в сервеную часть и дальше следующему клиенту.
С UDP все даже легче, т.к. в нем Нагла нет. Т.е. потеря возможности управлять размером пакетов с лихвой компенсируется очень прогнозируемыми таймингами.
С UDP все даже легче, т.к. в нем Нагла нет. Т.е. потеря возможности управлять размером пакетов с лихвой компенсируется очень прогнозируемыми таймингами.
Работа вне конкурса habrahabr.ru/post/230923/?
3ара3а работает на мейлру? Оу, куда катится этот мир?..
Т.е. проблема актуальна, когда пытаешься получать ресурсы из интернета? Т.е., если мы открываем внутренние ресурсы или сайты i2p или пользуемся mesh-сетью типа cjdns, то становится неактуально или просто усложняется?
Смотря что для вас актуально — сама возможность атаки или практическая реализация на конкретном оборудовании. На внутренних ресурсах и корпоративных сетях построенных на арендуемых каналах нет оборудования СОРМ.
В принципе проблема актуальна везде, где трафик проходит через две точки, в одной из которых возможна его маркировка а в другой прослушивание и где такая возможность что-то дает атакующему. Про i2p и практичность атак чуть выше говорили — пока есть хоть какая-то возможность менять форму выходного сигнала — есть и возможность его маркировать, но на практике реализовать гораздо сложнее.
В принципе проблема актуальна везде, где трафик проходит через две точки, в одной из которых возможна его маркировка а в другой прослушивание и где такая возможность что-то дает атакующему. Про i2p и практичность атак чуть выше говорили — пока есть хоть какая-то возможность менять форму выходного сигнала — есть и возможность его маркировать, но на практике реализовать гораздо сложнее.
Вы тут все такие умные и интересные, только вы не учитываете одну очень важную штуку — СОРМ не может вмешиваться в трафик так, как он стоит не в разрыв сети, а тупо на него зеркалируеться весь трафик.
UFO just landed and posted this here
Никто и не даст поднять на вашем компе entry node, т.к. entry node в tor — ограниченный список (относительно) доверенных узлов.
Вы поднимаете у себя клиента tor и идете на entry node, который, как правило, находится в другой стране. Трафик можно слушать везде, по пути от вас (клиента) до entry node и пассивный доступ к этому трафику имеет и оборудование СОРМ у вашего провайдера и соответствующее оборудование в той стране, где располагается entry node. Т.е. возможность слушать этот трафик имеет даже и не одна спецслужба, а несколько.
Вы поднимаете у себя клиента tor и идете на entry node, который, как правило, находится в другой стране. Трафик можно слушать везде, по пути от вас (клиента) до entry node и пассивный доступ к этому трафику имеет и оборудование СОРМ у вашего провайдера и соответствующее оборудование в той стране, где располагается entry node. Т.е. возможность слушать этот трафик имеет даже и не одна спецслужба, а несколько.
Вы упомянули «имея доступ к конечному серверу» в п.1.
То есть, например, если оборудование СОРМ будет стоять как на серверах вконтакте, так и у провайдеров, задача «найти, кто это пишет через tor» переходит в практическую плоскость?
Как вариант обхода, мне кажется, можно запустить torrent через tor на небольшой скорости, 1-10кб/с.
Вот вам и энтропия.
То есть, например, если оборудование СОРМ будет стоять как на серверах вконтакте, так и у провайдеров, задача «найти, кто это пишет через tor» переходит в практическую плоскость?
Как вариант обхода, мне кажется, можно запустить torrent через tor на небольшой скорости, 1-10кб/с.
Вот вам и энтропия.
Пока здесь ничего не ясно. Но в зависимости от того, какое именно оборудование и где заставят устанавливать соц. сети — вполне возможно.
Атакующий должен иметь возможность изменять форму трафика, который exit node отдает middleman node, а так же читать трафик между entry node и пользователем. Я правильно понял?
Извините за простые вопросы.
Извините за простые вопросы.
А если кэширующий прокси внутри tor?
Какой-нибудь .onion, выходим на который, вводим адрес нужного сайта — он его кэширует, а мы уже смотрим из прокси.
Т.е. exit-нода в этом случае поможет раскрыть только прокси, но не реального пользователя.
Какой-нибудь .onion, выходим на который, вводим адрес нужного сайта — он его кэширует, а мы уже смотрим из прокси.
Т.е. exit-нода в этом случае поможет раскрыть только прокси, но не реального пользователя.
Т.е. если я правильно понял Большой Брат таки следит за нами (сюрприз, сюрприз) и если вдруг кому-то надо сделать черное-черное дело то это все лежит в плоскости беготни по open WiFi и/или использования симки купленной на чужое имя.
О возможности постить котиков в сеть анонимно сидя у себя дома следует забыть.
С другой стороны то, что каждый IP пакет пока не надо подписывать закрытым ключом хранящимся на чипе вшитом в голову тоже радует.
О возможности постить котиков в сеть анонимно сидя у себя дома следует забыть.
С другой стороны то, что каждый IP пакет пока не надо подписывать закрытым ключом хранящимся на чипе вшитом в голову тоже радует.
То есть я захожу на mail.ru, и атакующий должен пометить трафик от mail.ru ко мне. Здесь все просто, местонахождение mail.ru хорошо известно. Дальше надо искать метки на оборудовании СОРМ всех провайдеров России, не так ли? Ведь мой домашний айпи скрыт тором / впном и mail.ru его не видит. Какова вероятность того, что атакующий найдет нужного провайдера раньше, чем я прочитаю с mail.ru все что мне надо и закрою браузер? Какова вероятность того же самого события в случае, если я не в России?
Оборудование СОРМ не обслуживается провайдерами, провайдеры не имеют к нему доступа, оно обслуживается ФСБ.
Искать не надо, оборудование включено постоянно, достаточно чтобы прохождение такой метки генерировало отслеживаемое событие, точно так же, как его генерирует обращение к определенным ресурсам или ключевые фразы.
Вероятность, что такие приемы в ближайшее время будут использовать наши спецслужбы как раз не высока, т.к. ими контролируется очень небольшой сегмент сети. Зато очень высока вероятность того, что этот прием уже использует АНБ, у него все необходимое есть. АНБ это может делать даже в том случае, если пользователь из России через тор обращается к ресурсу из России, достаточно чтобы вами и точкой входа и между точкой выхода и сервером были наблюдаемые сети.
Искать не надо, оборудование включено постоянно, достаточно чтобы прохождение такой метки генерировало отслеживаемое событие, точно так же, как его генерирует обращение к определенным ресурсам или ключевые фразы.
Вероятность, что такие приемы в ближайшее время будут использовать наши спецслужбы как раз не высока, т.к. ими контролируется очень небольшой сегмент сети. Зато очень высока вероятность того, что этот прием уже использует АНБ, у него все необходимое есть. АНБ это может делать даже в том случае, если пользователь из России через тор обращается к ресурсу из России, достаточно чтобы вами и точкой входа и между точкой выхода и сервером были наблюдаемые сети.
Спасибо за пояснение. Я не знал что СОРМ можно программировать на события. Теперь все ясно. Трафик на mail.ru помечается меткой, а когда помеченный трафик проходит через моего провайдера, СОРМ срабатывает на событие, посылает сообщение куда надо и сдает меня с потрохами. Даже если нас будет таких миллион, подобрать миллион разных комбинаций размера пакета и задержки по идее можно. Садимся в машину с тонированными стеклами и забрызганным грязью номерным знаком, паркуемся в людном месте, где мы не привлечем внимания, и ищем вайфай, к которому можно подключиться, в том числе и взломав его. Подключаемся с помощью роутера с прошвкой openwrt, и перед подключением генерим на роутере случайный мак wifi-интерфейса. Кстати, если у меня браузер открыт в VNC-сессии на амазоне, что будет в этом случае с метками? Помеченный трафик придет на амазон, где СОРМа нет, а дальше по протоколу VNC, завернутому в VPN или/и тор, уже пойдут новые, непомеченные пакеты, правильно? Могут ли меня как-то вычислить в этом случае?
VNC — да, вполне можно пометить. Например, внедрить в страницу баннер, который будет «мигать» в определенной последовательности. При просмотре страницы мигание баннера будет генерировать весьма характерный трафик в VNC.
И конечно же отключение флэша (в VNC он у меня и так всегда выключен, только мешает) не поможет — баннер может быть анимированной гифкой или HTML5. Про lynx в ssh-сессии вы уже ответили выше. А как насчет lynx в VNC-сессии?
А для VNC разве нельзя просто фиксированный фреймрейт задать?
Не знаю таких тонкостей о VNC. Если можно задать фреймрейт — то да, это хорошая защита. Но все равно остаются «но»: могут быть тайминг атаки путем нагрузки процессора через внедрение джаваскрипта в страницу, нагрузка процессора может влиять на реальные интервалы между фреймами. Могут быть ошибки реализации, например неудачный выбор паддинга.
Если использовать удалённый сервер за VPN, как прокси, то страница с баннером и всеми скриптами загрузится один раз и будет мигать на клиентском компьютере, не создавая нагрузки на сеть.
Вопрос был про VNC. Трафик VNC передается не между сервером и клиентом, а между клиентом и терминалом. Передаются при этом изменения областей экрана. Поэтому мигания баннера приводят к всплескам трафика.
Sign up to leave a comment.
Атаки шейпинга в сетях low latency или почему Tor не спасает от спецслужб