Компания
1 155,29
рейтинг
9 августа 2014 в 20:19

Разработка → Атаки шейпинга в сетях low latency или почему Tor не спасает от спецслужб



Тайминг-атаки являются известным слабым местом сети Tor и неоднократно обсуждались, в том числе на Хабре, где можно найти порядка 10 статей, так или иначе затрагивающих эту тему. Зачем нужна еще одна? Существует достаточно распространенное заблуждение, что подобные атаки всегда требуют статистического анализа и достаточно сложны в реализации. Ранее опубликованные статьи относятся именно к такому классу атак. Мы рассмотрим вполне реалистичный сценарий, в котором достаточно единственного запроса для деанонимизации пользователя сети.

Поскольку вопрос возможности деанонимизации пользователей Tor в очередной раз активно обсуждается в рунете, я публикую «печатную» версию фрагмента своей презентации с PHDays 2014. Приведенная ниже атака не специфична для Tor и может быть использована против любых low latency средств сокрытия источника трафика – VPN, цепочки прокси и даже их комбинации.

Мы рассмотрим сценарий, для реализации которого в Tor требуется соблюдение двух условий:
  1. Иметь возможность вмешиваться в трафик между exit node и узлом назначения. Это можно сделать, имея доступ к конечному серверу, exit node или любой точке прохождения трафика между ними. То есть фактически это условие может выполнить любой желающий, организовав собственные exit node в достаточном количестве.
  2. Иметь пассивный доступ к трафику между клиентом сети и entry node.

Причем здесь спецслужбы? Оборудование СОРМ, установленное у любого российского провайдера, как правило полностью пассивно, и умеет обнаруживать, протоколировать и интерпретировать (например, восстанавливать переписку в мессенджерах) трафик, обладающий заданными характеристиками. Отследить присутствие этого оборудования «со стороны» практически невозможно, так как оно не генерирует никакого собственного трафика и никак не влияет на прослушиваемый.

Наличие у атакующего доступа к оборудованию СОРМ вполне удовлетворяет второму из условий атаки. А значит у спецслужб, имеющих доступ к оборудованию и способных организовать некое количество exit node в Tor, есть все, что требуется, включая желание заниматься этим вопросом.

Принцип атаки

Со стороны exit node в трафик вносятся предопределенные изменения, не меняющие передаваемые данные, но затрагивающие «форму» трафика – меняются размеры проходящих пакетов и задержки между ними. Временные характеристики в low latency сетях меняются не значительно, этот факт обычно используется в timing-атаках. Размеры пакетов меняются достаточно прогнозируемым образом, как это будет продемонстрировано. Это значит, что переразбив трафик на пакеты определенной последовательности размеров с определенной последовательностью задержек можно со стороны exit node промаркировать трафик таким образом, что на стороне entry node эта маркировка может быть обнаружена, таким образом может быть сопоставлено соединение или запрос к серверу с пользователем Tor.

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

Насколько сложно это реализуется и как выглядит на практике?

Я реализовал атаку путем перенаправления трафика exit node в прокси-сервер, в который были внесены небольшие правки для организации шейпинга трафика по заранее определенному шаблону.

Как выглядит «обычный» трафик в Tor? Это фрагмент трафика от entry node к клиенту связанный с передачей результатов HTTP-запроса без внесения в трафик каких-либо маркировок:



Идет TLS-трафик, внутри которого содержатся блобы (пакеты) информации, преимущественно размером 3648 октетов. Размер блоба определяется числом попавших в него ячеек трафика tor, которые имеют фиксированный размер. На уровене TCP блобы разбиваются на IP-пакеты размером преимущественно 1414 октетов, что связано с Path MTU. TCP-пакет может содержать как фрагмент одного блоба, так и конец одного блоба и начало следующего. Однако, встречаются и блобы размером 560 октетов и TCP-пакеты меньшего размера. Разбиение исходных данных на блобы и разбиение блобов по TCP-пакетам зависит от разных параметров — таймингов серверов, размеров буфера, которыми он передает данные, задержкам сети. При повторном запросе рисунок может быть немного другой. Однако статистически один и тот же запрос к одному и тому же серверу будет иметь достаточно четкую картину. Поскольку при загрузке одной и той же web-страницы происходит достаточно большое количество запросов с передачей, как правило, одних и тех же запросов и ответов, то есть типичных объемов информации с типичными задержками, то сопоставлением данных можно попытаться обнаружить к какому именно ресурсу обращается пользователь, особенно если он посещает его регулярно. На этом основаны классические тайминг-атаки.

Но мы идем другим путем. Вместо пассивного измерения тайминга, в исходный трафик со стороны exit node вносим шейпинговую маркировку (maRk). Чистый нешифрованный трафик, пущенный мимо Tor, теперь выглядит следующим образом:



Как происходит маркировка? Передаем маленькие пакеты двух разных размеров. Различие в размерах в несколько сот байт в данном случае ни на что не влияет, но позволяет визуально различить два разных типа пакетов в серии. Задержки между двумя типами пакетов 60 и 110 миллисекунд, они подобраны так, чтобы показать наиболее интересную картинку на выходе.

Когда тот же трафик проходит через Tor, между entry node и пользователем он выглядит следующим образом:



Что мы теперь видим. Все блобы в TLS теперь имеют размер 560 октетов (а значит мы умеем управлять размером, 3648 или 560 октетов за счет отправки больших или маленьких порций трафика). Кстати, в этом месте наблюдается проблема амплификации трафика — минимальный пакет данных увеличивается более чем в 10 раз. Каждый отправленный нами пакет приходит отдельным блобом в TLS. При этом IP-пакет размером 1414 октетов содержит два полных блоба и начало третьего, пакет 389 октетов — конец третьего блоба и пакет в 619 октетов — отдельный четвертый блоб. То есть 4 IP-пакета исходного трафика приходят в 3 IP-пакетах в трафике Tor. Хорошо это или плохо? Плохо, так как мы потеряли часть информации о таймингах.

Что случилось и почему такая странная последовательность: это вызвано особенностями работы TCP-стека, а именно совместной работой алгоритма Нагла и TCP delayed acknowledgements. Однако между группами пакетов и между пакетами в группе интервал остается неизменным, то есть как минимум половину информации по таймингам мы получаем. Чтобы «побороть» ожидание и группировку в алгоритме Нагла, можно отправить количество трафика такое, чтобы передаваемые блобы превысили размер MTU (но недостаточное для формирования «большого» блоба в 3648 байт).

Если сравнить третью картинку с первой, то понятно, что в трафик вносится достаточно четкая и легко детектируемая аномалия, которая позволяет следящему оборудованию «сработать» при ее обнаружении. Причем в случае СОРМ детектируемость этой аномалии достаточна для доказательной базы.

Данная атака может применяться к практически любому шифрованному или нешифрованному соединению, как по направлению от сервера к клиенту, так и в обратном.

Какие есть ограничения?

«Нелинейное» поведение трафика из-за алгоритма Нагла может приводить к потере части информации о таймингах, однако, эту потерю можно обнаружить на принимающей стороне и компенсировать избыточностью передаваемой информации. Для того, чтобы трафик можно было шейпить, он должен быть достаточным. Казалось бы, сложно промаркировать таким образом, например, ssh-соединение с запущенным bash’ем и периодически выдаваемыми командами, так как в нем не передается достаточно данных, чтобы сформировать пакеты с нужными maRk-сигнатурами.

На самом деле, промаркировать можно даже соединение, в котором данные совсем не передавались. Дело в том, что даже после того, как клиентское приложение инициировало закрытие TCP-соединения, данные, отправленные через Tor в сторону клиента, будут продолжать доставляться. Это дает возможность после получения FIN+ACK в соединении со стороны клиента отправить в его сторону промаркированную порцию случайных данных. Эти данные никогда не будут считаны клиентским приложением, но они все равно дойдут до клиента и таким образом раскроют его. То есть атака может быть проведена полностью скрытно от клиента и объем информации, которым можно промаркировать соединение, более чем достаточен. Аналогичный способ можно применить и в большинстве VPN, но, к счастью, он не сработает с прокси и другими прикладными шлюзами.

Есть ли надежное решение?

Атаку может быть сложнее провести при активной работе клиента, так как необходимо детектировать пакеты, относящиеся к одной цепочке, посторонний трафик зашумляет сигнатуру. Можно так же взять на себя роль relay в сети Tor, что затруднит обнаружение маркированного трафика. Есть несколько способов дополнительно усложнить атаку: комбинация Tor, VPN и цепочки прокси затрудняет угадывание финальной формы трафика и частично устраняет атаку через полузакрытое соединение. Можно усложнить обнаружение испортив известные сигнатуры нестандартными параметрами TCP-стека. Но надежного способа полностью устранить подобные угрозы в рамках Tor или распространенных VPN-сетей нет. Атаки шейпинга, как разновидность тайминг-атак находятся за пределами их профиля защиты.

Единственное надежное решение – использовать внутри шифрованного соединения виртуальный линк, в котором идет постоянный поток ячеек фиксированной длины с фиксированной пропускной способностью. Так работают, например, сети ATM (Asynchronous Transfer Mode). Причем шифрование должно проводиться без сжатия данных, то есть потребляемая полоса трафика должна быть неизменной. Такие технологии не могут пока широко использоваться для повседневной работы, так как слишком высоки дополнительные расходы на канал, который активно используется даже в момент простоя.
Автор: @z3apa3a

Комментарии (77)

  • +3
    Недавно пробегала инфа что есть дешёвый и не требующий больших ресурсов вроде СОРМ способ определения пользователя Тор, но потом всё как-то заглохло (вроде бы запретили выступление на конфе) — никто не знает подробностей?
    • +4
      Насколько я знаю, подтвержденной информации нет, но разработчики tor предполагают, что речь идет об атаке через relay-early cells, CVE-2014-5117, т.к признаки этой атаки были обнаружены «вживую».
  • +7
    Мне казалось, что размер пакетов в сети Tor фиксированный, чтобы подобные атаки не проходили. Об этом есть информация в Tor FAQ.

    Была ли данная атака опробована против скрытых сервисов и их пользователей?

    Планируется ли применение атаки на практике?

    Допустим, пользователь посещает атакующий сайт через lynx, запущенный на неподконтрольном спецслужбам сервере, доступ к серверу осуществляется через SSH. Полная цепочка: пользователь — тор — SSH — неподконтрольный сервер — mail.ru. Можно ли будет пользователя вычислить в данном случае?
    • +1
      Как видно выше — рамеры фиксированные, но есть как минимум два разных размера блобов, 3648 и 560.

      Специально против скрытых сервисов не пробовал, но не вижу причин, почему она не могла бы быть проведена, можно «модулировать» данные запроса от клиента к серверу.

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

      С lynx ситуация интересная. Теоретически, отследить может быть возможным. lynx «выкинет» из трафика часть данных (теги, служебную информацию), но в целом, он передаст данные дальше в ssh-соединение. Но здесь могут иметь значение детали, например верстка HTML на таблицах может задерживать их отображение, в данном случае это критично. + через любой прикладной шлюз, включая и такой не пройдет невидимая атака, надо модулировать реальные данные.
      • 0
        P.S. вот так понятней: в один блоб TLS может попадать разное количество ячеек tor, атакующий за счет шейпинга может этим управлять.
        • 0
          Я думаю, можно устранить данную атаку, если внести изменения в тор. Например, не позволять цепочке менять скорость передачи данных: если в какой-то момент данные шли медленно, то некоторое время после не давать скорости увеличиваться. Ну и какие-нибудь поправки на начало передачи, котгда возможны скачки. Скорость передачи данных в нормальных условиях несильно скачает. А вот если сайт пытается провести атаку, то все его данные будут идти медленно и принимающая сторона не сможет заметить аномалии.
          • +1
            В действительности скорость передачи данных очень сильно скачет. Например, в HTTP через одно соединение проходит несколько запросов, между которыми могут быть паузы порядка десятков секунд. А в мессенджерах, терминальных сессиях и т.п. трафик вообще рандомно ходит в любом направлении.
            • 0
              Тогда зайдем с другой стороны — будем цепляться не за минимальную скорость, а за максимальную. То есть, если в какой-то момент данные передавались быстро, то ближайшие несколько секунд скорость не должна резко снижаться. Если данных от сайта недостаточно, чтобы набрать нужную скорость, то дополнять цепочку случайным шумом, который отбрасывается уже на стороне клиента.

              Но даже тут сайт может выкрутиться и помечать соединения путем наращивания скорости по определенному правилу (например, первую секунду 1 кб/с, потом 10 секунд 10 кб/с, потом 20 секунд 15 кб/с, так можно создать довольно много комбинаций). Поэтому окончательное решение — это то, чего в торе делать точно не захотят, а именно постоянный шумовой трафик с определенной скоростью или на одной из небольшого набора скоростей. Как мне известно, так делают в I2P. Сработает ли Ваша атака против I2P? Если подключаться к тору через I2P, будет ли возможна атака?
              • 0
                Вариант с сохранением фиксированной полосы канала работает, он как раз был в конце статьи описан. Но надо понимать, что любое затухание/набор скорости — это уже бит информации.

                А вот со стороны сайта делать какие-то действия бесполезно — атакующий все равно может эти данные перешейпировать по-своему.

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

                Конечно, при таких условиях атака гораздо менее практична, т.к. такие темплейты гораздо сложней распознать в массовом трафике, чем последовательность пакетов определенного размера от известных entry node, чтобы «взвести» оборудование и начать анализировать трафик именно этой сессии.
                • 0
                  Правильное решение не в сохранении фиксированной ширины, а в поддержании случайности (непредсказуемости) характеристик потока данных.
                  • 0
                    Не может быть полной случайности и непредсказуемости данных на неслучайном потоке данных. Если сервер передает большой кусок данных — принимающая сторона должна получить большой кусок данных ровно в то же самое время. Если вы хотите этот кусок сокрыть — придется постоянно передавать большие куски данных.
                    • 0
                      Если сервер передает большой кусок данных — принимающая сторона должна получить большой кусок данных ровно в то же самое время. Если вы хотите этот кусок сокрыть — придется постоянно передавать большие куски данных.
                      Да, разумеется. Например, качать-раздавать торренты и релеить трафик других нод.
                      • 0
                        Тогда все-таки правильней поддерживать именно полосу фиксированной ширины, т.к. тогда в принципе нет характеристик, которые контролируются со стороны атакующего, следовательно ничего нельзя получить даже при длительном наблюдении. Если смешивать полезные данные со случайными, то это не спасает от статистического анализа, т.к. при статистическом анализе «случайные» данные становятся закономерными и отделимыми от полезной нагрузки, «белый шум» превращается в прямую. Передаваемый раз в секунду пакетик из 1 байта не видим в зашумленном трафике, но очень хорошо виден при статистическом анализе.
                        • 0
                          Подождите, я ничего и не говорил о смешивании =) Я имею в виду именно полосу искусственно регулируемой, хоть и динамической ширины. Т.е. её ширина и прочие характеристики никак не должны коррелировать с характеристиками управляемого трафика. Т.е., это не (random + данные) и не (random + данные) = const, это (данные + что-то) = random.
                • 0
                  Строго говоря, есть небесполезные действия со стороны сайта: отправка рандомных пакетов на хост получателя. Их отбросит выходная нода тора, но маскировка цже получится.
                  • 0
                    Не очень понял, что имеется ввиду. Любые пакеты отправленные вне TCP-соединения будут отброшены и ни на что не повлияют, любые пакеты отправленые внутри TCP-соединения точно так же будут «перешейпированы» атакующим и использованы для передачи маркировки.
  • +2
    Эффективность атаки должна ослабевать при увеличении количества добровольцев, устанавливающих выходные ноды Tor.
    • +2
      Да, но к сожалению, только в том случае, если у атакующей стороны нет возможности получить контроль над сервером или контролировать трафик где-то ближе к серверу.
  • +2
    По-идее, решаемо на уровне выходных TOR нод — принудительный коллапс пакетов. Впрочем, это может увеличить задержки.
    • +2
      Затрудняет, но все-такие не решает: атакующему придется использовать более явные бёрсты трафика и более длительные тайминги между ними, т.е. «передавать данные» между двумя своими точками на меньшей скорости с большей амплитудой.
      • +2
        ну, кстати, да. можно же, например, страницы сайта (несколько подгружаемых JSок) отдавать с разной задержкой разному клиенту в отдельных соединениях…
        • +1
          Да-да. Много вариантов, можно и свой баннер на конкретный сайт за деньги повесить, и шейпить отдачу баннера. От рекламных денег никто ж не отказывается.

          А еще год назад на одной из выставок (не помню — или Zero Nights или PHD) показывали активное оборудование СОРМ, которое встает в разрыв между абонентской сетью и интернетом и умеет шейпить трафик. Exit node под контролем такого оборудования — это готовое условие для атаки. И не факт что в других странах уже не так.

          • +2
            насколько знаю, у нас, пока, тьфу-тьфу, СОРМ стоит только пассивный. причем часто в ДЦ по «ошибке техника» очередной свич может оказаться туда не подцепленный, абы какой траффик таки шел и хватит.
  • 0
    А кто получатель этого ID? Не очень понимаю, где двуглавый орел сидит на карте сети.
    • +2
      В случае двуглавого орла получатель ID это оборудование СОРМ, в случае других орлов — его аналоги. Т.е. если спецслужбы захотят знать, кто посещает, например, сайты определенной тематики, им достаточно промаркировать часть трафика от этих сайтов вблизи этих сайтов (если они на подконтрольной территории) или на exit node'ах и на оборудовании отслеживать получателей маркировки. Там где маркировка вошла и не вышла — там и конечный получатель.
      • +1
        Все, понял. Это для трафика от сайтов к пользователю. Спасибо!
      • 0
        «Там где маркировка вошла и не вышла — там и конечный получатель.»
        Так может нужно всю полученную информацию отправлять куда-нибудь?
        Тогда, выйдет, что маркировка и вошла и вышла — и вроде как конечный получатель вовсе и не конечный получатель. Путаю?
        • 0
          На уровне протокола не очень эффективное сокрытие, т.к. «подозреваемые» все равно есть и выбрать из них того, кто реально запрашивал трафик относительно просто. А в случае именно с tor получатель обнаруживается и без этого условия, т.к. получает трафик от известного списка entry node.
          А если делать такой финт «по собственной инициативе» и подставлять кого-то другого — так проще воспользоваться соседским WiFi.
          • +1
            А в случае именно с tor получатель обнаруживается и без этого условия, т.к. получает трафик от известного списка entry node.
            Одна из причин ставить VPN, тор-мост, ssh или даже просто прокси перед тором. Искать среди всех пользователей, открыто подключающихся к тору, проще, чем среди всех, кто пользуется чем-то из вышеперечисленного.
            • +1
              Да, любое сочетание технологий затрудняет поиск конечного получателя трафика и на практике скорее всего этого достаточно.
  • –3
    Обнаружить tor-сайт очень просто. надо дать атаку HTTP/HTTPS в 5-6 гбит/с.
    Таргет датацентр сам Вас найдет и сообщит о том, что его атаковали из Вашей сети, дальше это уже вопрос техники и связей обнаружить конкретного пациента.
    • +3
      И как датацентр определит, что атака идет с вашей сети?
      У тора все соединения идут через 3 узла, а эти узлы скорее всего не будут иметь к вам никакого отношения.
      • –1
        По цепочке.
    • 0
      Не совсем понял в части про «сам Вас найдет и сообщит о том, что его атаковали из Вашей сети», ведь в случае со скрытыми сайтами адрес пользователя тоже скрыт. Таргет датацентру будет казаться, что его атакуют Guard-ноды, которые использует скрытый сайт. А в целом идея хорошая, если проводящая сторона имеет своего человека в каждом возможном датацентре.

      Я думаю, эту атаку можно предотвратить, если разнести сам целевой сайт и скрытый сервис тора по разным датацентрам. Сервер, на котором находится сам сайт, через тор подключается к серверу со скрытым сервисом, а там расположен обратный прокси с функцией распознавания DDOS. Если силовики вычисляют сервер, на котором располагается скрытый сервис, они всё равно не видят, где был целевой сайт. А можно исхитриться и использовать заложенные в сам Tor средства для борьбы с DDOS'ом скрытых сервисов.
  • 0
    ipfw pipe 10 config delay $(($RANDOM%100))ms bw $(($RANDOM%10000))Kbit/s
    с частотой 10 раз в секунду должно помочь
    • +1
      Нет, к сожалению не поможет, это то же самое что datacompboy предлагает выше. К тому же, с точки зрения реализации, это классическая атака slow read, она приведет к увеличению потребления ресурсов на entry node.
      • 0
        datacompboy предлагает делать это на выходной ноде.
        Я же предлагаю делать это на клиенте.
        Хотя, да, против целенаправленного подбора параметров под конкретного клиента не подействует.
      • 0
        Есть другой вариант. Использовать вышеприведенное + 100% загрузка сетевого канала в обе стороны.
        Боюсь, в данном шуме никакие timing атаки не помогут.
        • 0
          Тогда в ход пойдет математика, которая уже умеет извлекать полезный сигнал из-под шумов.
          • 0
            Так в том-то и дело, что именно шума то нет. Есть перегруженный канал взаимопохожих данных, с перегрузками, случайными задержками и т.д.
            Невозможно будет вычленить воздействующий сигнал, так как его объем пусть будет 0.1% от ширины канала и его флуктуации нельзя будет вычислить.
            Да, если бы вражеский «сигнал» давили какой-то частотной помехой, даже белым шумом, математика бы помогла, но здесь — сомневаюсь.
            • 0
              Поможет, еще как. Чем уже спектр полезного сигнала, тем проще его выделять на фоне помех. Конечно, выделить тикание часов на фоне взлетающего самолета будет проблематично, но математика сдвигает шансы в нашу сторону. Для примера возьмем ту же мобильную связь — задавить до полного исчезновения сервиса крайне трудно, даже глушилки и те справляются лишь только с 10-15 метров.
              • 0
                А вы сможете выделить тиканье конкретных часов среди тиканья десятки тысяч похожих?
                • 0
                  Если у нас есть возможность задать спектр тикания, а эта возможность у нас есть, то задача сильно упрощается.
  • 0
    Аналогичный способ можно применить и в большинстве VPN, но, к счастью, он не сработает с прокси и другими прикладными шлюзами.
    Объясните, пожалуйста, почему эта атака не работает с прокси. Что будет, если перед тором поставить прокси?

    Нет ли возможности выставить фиксированный размер UDP-пакета в VPN? Казалось бы, это должно решить проблему.
    • +2
      Атака в целом работает с прокси, не работает только передача маркировки через полузакрытое соединение, когда маркировку можно передать скрытно от клиентского приложения, не затрагивая передачу реальных данных. Именно потому, что прикладной шлюз одновременно является и клиентом и сервером. Клиент не считает«скрытых» данных — соответственно и не передаст их в сервеную часть и дальше следующему клиенту.

      С UDP все даже легче, т.к. в нем Нагла нет. Т.е. потеря возможности управлять размером пакетов с лихвой компенсируется очень прогнозируемыми таймингами.
  • +1
    Работа вне конкурса habrahabr.ru/post/230923/?
    • +2
      имхо, автор слишком долго был на белой стороне (3proxy,security.nnov.ru), чтобы перейти на темную сторону :)
    • +2
      На конкурс не примут, оборудование СОРМ контролируется ФСБ а не МВД :)
      • 0
        ну это уже совсем пустяки — раз есть решение задачи через ФСБ, то МВД должно выставить конкурс на получение доступа из-вне к оборудованию СОРМ :)
  • +5
    3ара3а работает на мейлру? Оу, куда катится этот мир?..
  • 0
    Т.е. проблема актуальна, когда пытаешься получать ресурсы из интернета? Т.е., если мы открываем внутренние ресурсы или сайты i2p или пользуемся mesh-сетью типа cjdns, то становится неактуально или просто усложняется?
    • 0
      Смотря что для вас актуально — сама возможность атаки или практическая реализация на конкретном оборудовании. На внутренних ресурсах и корпоративных сетях построенных на арендуемых каналах нет оборудования СОРМ.

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

  • –2
    Вы тут все такие умные и интересные, только вы не учитываете одну очень важную штуку — СОРМ не может вмешиваться в трафик так, как он стоит не в разрыв сети, а тупо на него зеркалируеться весь трафик.
    • +2
      Для этой атаки как раз и требуется пассивный СОРМ, в статье описаны условия.
  • –1
    > Иметь пассивный доступ к трафику между клиентом сети и entry node.
    Гм, разве ещё остались на свете идиоты, которые не держат entry node на собственном компе или хотя бы в своей домашней сети?
    • 0
      Никто и не даст поднять на вашем компе entry node, т.к. entry node в tor — ограниченный список (относительно) доверенных узлов.
      Вы поднимаете у себя клиента tor и идете на entry node, который, как правило, находится в другой стране. Трафик можно слушать везде, по пути от вас (клиента) до entry node и пассивный доступ к этому трафику имеет и оборудование СОРМ у вашего провайдера и соответствующее оборудование в той стране, где располагается entry node. Т.е. возможность слушать этот трафик имеет даже и не одна спецслужба, а несколько.
      • –1
        А почему ВПН не помогает от этой пассивной прослушки?
        • +3
          VPN точно так же передает «форму» трафика и тайминги, это особенность большинства сетей low latency. Если я отправляю маленький пакетик раз в секунду — будет приходить минимальный возможный пакет раз в секунду. Если я отправляю большой бёрст трафика — будет приходить большой бёрст трафика.
      • 0
        Сколь мне известно, любая запущенная нода в этой сети является и entry node, и relay node, и, при соответствующей настройке, exit node. «Ограниченный список относительно доверенных узлов» — это те, которые нужны для bootstrap. Эта штука централизована, да.
        Ну, ещё в TOR централизована система bridges, ну и ещё кой-чего, но это уже отдельная песня не из этой оперы.
        • 0
          Не любая, для этого надо получить соответствующий consensus flag «Guard». Т.е. при желании сделать это возможно (поэтому и «относительно»), но просто так поднять у себя на домашнем компе tor и объявить себя entry node не получится.
  • +1
    Вы упомянули «имея доступ к конечному серверу» в п.1.
    То есть, например, если оборудование СОРМ будет стоять как на серверах вконтакте, так и у провайдеров, задача «найти, кто это пишет через tor» переходит в практическую плоскость?

    Как вариант обхода, мне кажется, можно запустить torrent через tor на небольшой скорости, 1-10кб/с.
    Вот вам и энтропия.
    • 0
      Пока здесь ничего не ясно. Но в зависимости от того, какое именно оборудование и где заставят устанавливать соц. сети — вполне возможно.
  • 0
    Атакующий должен иметь возможность изменять форму трафика, который exit node отдает middleman node, а так же читать трафик между entry node и пользователем. Я правильно понял?
    Извините за простые вопросы.
    • 0
      Не совсем, атакующий должен иметь возможность изменять форму нешифрованного трафика между точкой назначения и exit node и читать трафик между entry node и пользователем.

      Ваш вариант атаки тоже возможен, но менее интересен практически.
  • 0
    А если кэширующий прокси внутри tor?
    Какой-нибудь .onion, выходим на который, вводим адрес нужного сайта — он его кэширует, а мы уже смотрим из прокси.
    Т.е. exit-нода в этом случае поможет раскрыть только прокси, но не реального пользователя.
    • +1
      Можно, да. Например выкачать страницу вместе с графикой и отдать ее целиком — но это будет уже не low latency.
      • +1
        Ну, что поделать…
        Максимально секурные системы не могут быть при этом и максимально удобными.
  • 0
    Т.е. если я правильно понял Большой Брат таки следит за нами (сюрприз, сюрприз) и если вдруг кому-то надо сделать черное-черное дело то это все лежит в плоскости беготни по open WiFi и/или использования симки купленной на чужое имя.
    О возможности постить котиков в сеть анонимно сидя у себя дома следует забыть.
    С другой стороны то, что каждый IP пакет пока не надо подписывать закрытым ключом хранящимся на чипе вшитом в голову тоже радует.
  • 0
    То есть я захожу на mail.ru, и атакующий должен пометить трафик от mail.ru ко мне. Здесь все просто, местонахождение mail.ru хорошо известно. Дальше надо искать метки на оборудовании СОРМ всех провайдеров России, не так ли? Ведь мой домашний айпи скрыт тором / впном и mail.ru его не видит. Какова вероятность того, что атакующий найдет нужного провайдера раньше, чем я прочитаю с mail.ru все что мне надо и закрою браузер? Какова вероятность того же самого события в случае, если я не в России?
    • 0
      Оборудование СОРМ не обслуживается провайдерами, провайдеры не имеют к нему доступа, оно обслуживается ФСБ.
      Искать не надо, оборудование включено постоянно, достаточно чтобы прохождение такой метки генерировало отслеживаемое событие, точно так же, как его генерирует обращение к определенным ресурсам или ключевые фразы.

      Вероятность, что такие приемы в ближайшее время будут использовать наши спецслужбы как раз не высока, т.к. ими контролируется очень небольшой сегмент сети. Зато очень высока вероятность того, что этот прием уже использует АНБ, у него все необходимое есть. АНБ это может делать даже в том случае, если пользователь из России через тор обращается к ресурсу из России, достаточно чтобы вами и точкой входа и между точкой выхода и сервером были наблюдаемые сети.
  • 0
    Спасибо за пояснение. Я не знал что СОРМ можно программировать на события. Теперь все ясно. Трафик на mail.ru помечается меткой, а когда помеченный трафик проходит через моего провайдера, СОРМ срабатывает на событие, посылает сообщение куда надо и сдает меня с потрохами. Даже если нас будет таких миллион, подобрать миллион разных комбинаций размера пакета и задержки по идее можно. Садимся в машину с тонированными стеклами и забрызганным грязью номерным знаком, паркуемся в людном месте, где мы не привлечем внимания, и ищем вайфай, к которому можно подключиться, в том числе и взломав его. Подключаемся с помощью роутера с прошвкой openwrt, и перед подключением генерим на роутере случайный мак wifi-интерфейса. Кстати, если у меня браузер открыт в VNC-сессии на амазоне, что будет в этом случае с метками? Помеченный трафик придет на амазон, где СОРМа нет, а дальше по протоколу VNC, завернутому в VPN или/и тор, уже пойдут новые, непомеченные пакеты, правильно? Могут ли меня как-то вычислить в этом случае?
    • 0
      VNC — да, вполне можно пометить. Например, внедрить в страницу баннер, который будет «мигать» в определенной последовательности. При просмотре страницы мигание баннера будет генерировать весьма характерный трафик в VNC.
      • 0
        И конечно же отключение флэша (в VNC он у меня и так всегда выключен, только мешает) не поможет — баннер может быть анимированной гифкой или HTML5. Про lynx в ssh-сессии вы уже ответили выше. А как насчет lynx в VNC-сессии?
        • 0
          А для VNC разве нельзя просто фиксированный фреймрейт задать?
          • 0
            Не знаю таких тонкостей о VNC. Если можно задать фреймрейт — то да, это хорошая защита. Но все равно остаются «но»: могут быть тайминг атаки путем нагрузки процессора через внедрение джаваскрипта в страницу, нагрузка процессора может влиять на реальные интервалы между фреймами. Могут быть ошибки реализации, например неудачный выбор паддинга.
      • 0
        Если использовать удалённый сервер за VPN, как прокси, то страница с баннером и всеми скриптами загрузится один раз и будет мигать на клиентском компьютере, не создавая нагрузки на сеть.
        • 0
          Вопрос был про VNC. Трафик VNC передается не между сервером и клиентом, а между клиентом и терминалом. Передаются при этом изменения областей экрана. Поэтому мигания баннера приводят к всплескам трафика.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка