• Уважаемые продавцы ознакомтесь с новыми правилами по размещению банеров /threads/kak-projti-proverku-i-poluchit-status-prodavca.10963/

Как работает DNS в Tor и почему попытки его улучшить сделают только хуже

Джедай

Юзер
Подтвержденный
Сообщения
160
Реакции
216
А разве биржи и обменники не https? Как там возможна такая подмена?
 

username1234

Помощник Администратора
Команда форума
Сообщения
844
Реакции
1.707
Сделки
4
А разве биржи и обменники не https? Как там возможна такая подмена?
да, клиент запросил пополнение баланса, сервак ответил куар кодом, данные летят через узел, налету этим узлом подменяются и клиент видит куар код, только адрес там уже другой. Это обыкновенный MITM. по +- такому принципу банковские трояны работают. ток там функцию злого посредника выполняет висящий в памяти процесс.
 

torinmyheart

Software engineer, security expert
Проверенный сервис
Подтвержденный
Сообщения
80
Реакции
262
В dnscrypt-proxy есть такая функия под названием force_tcp включив ее все соеденения принудительно пойдут через TCP и при этом включить вот этот параметр и при этом нужно указать где proxy socks://127.0.0.1:9050 это опция будет перенаправлять на Тор Что скажете на это?
По поводу защиты DNS есть информация в этой статье и в продолжении, приглашаю ознакомиться. Это касается целесообразности и влияния на анонимность.

А разве такое возможно? Криптовалютный платеж же подписывается закрытым ключом и если изменить в нем адрес получателя, то подпись станет недействительна? Если это не так, то почему это тогда не исправили? Это же просто огромная будет дыра
Нет, такой сценарий невозможен, вы всё правильно говорите. Направлять крипто-кошелёк в Tor безопасно (при условии, что у вас надёжный кошелёк).
А разве биржи и обменники не https? Как там возможна такая подмена?
Опять же, вы правы. В случае успешной MITM-атаки можно подменить сам адрес на сайте, чтобы жертва своими руками отправила монеты злоумышленнику.
Наличие HTTPS ещё не означает полную безопасность, а иногда и HTTP до сих пор встречается) Об этом вторая статья, приглашаю.

Продолжение: Атаки на соединения в Tor: как работает HTTPS и как не сделать его бесполезным
Onion: rutordeep | rutordark | rutorbest | rutorclub | rutorsite
Клирнет: rutor.wtf | rutor.nl | rutor.live | rutor.market | rutor.love | rutor.biz
 

OHNи

Пассажир
Заблокирован
Сообщения
97
Реакции
121
Читал на одном дыхание.
 

Nahema5

Продвинутый юзер
Сообщения
282
Реакции
102
Эксклюзивно для Rutor
Что такое DNS знаешь? Точно? Я всё же оставлю это здесь это наглядное пояснение.
Очень упрощённо:
torproject.org116.202.120.166 (IP - точный адрес сервера в интернете)
gnu.org209.51.188.116
eff.org173.239.79.196
Это и есть DNS, элементарно. Такая таблица распределна по специальным серверам по всему миру, они называются DNS-сервера. Если вы пользуетесь обычным браузером, то DNS-сервер вам выбирает провайдер, либо вы сами, если заданы собственные настройки DNS.
На самом деле из этой схемы исключён целый слой - NS-сервера (иногда CDN). Этот слой имеет чисто техническую роль и совершенно не важен для понимания темы, поэтому я виртуально перекладываю функции NS на DNS и получаю красивое упрощённое объяснение.
  • § 1 Как работает DNS в Tor, кто выбирает DNS-сервер?
  • § 1 Когда DNS-сервер может вас деанонимизировать?
  • § 1 Почему защита DNS в Tor сделает только хуже (и даже DNS over HTTPS [DoH] не поможет)?
  • § 1 Почему успешно пройденный тест на утечку DNS не означает отсутствие утечек.
  • § 2 Как узлы Tor могут атаковать вас, используя DNS и как от этого защититься?
  • § 2 Как узлы Tor могут атаковать SSH и SFTP -соединения, в которых DNS вовсе не задействуется?

1. Прежде чем защищаться от атак, убедитесь, что вы используете Tor правильно!
Начинаем с фундаментального - утечка DNS. Но речь пойдёт не только о банальной утечке из браузера.

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

Деанонимизация по утечке DNS (с позиции государства):
  1. Установить примерное время, когда объект слежки появился (зашёл) на тот или иной сайт. В этом поможет логирование активности, тот же онлайн на форумах или в мессенджерах.
  2. Выяснить кто в это же время получал данные о соответствующих доменах с подконтрольных нам DNS-серверов.
Думаете, это не сработает, потому что диапазон времени может быть широким, а запросов в этот период может быть несколько? Ещё как сработает, потому что эту операцию можно повторять снова и снова, каждый раз накладывая полученные данные друг на друга, пока круг поиска не сузится до одного или нескольких человек.

Как найти утечку в браузере?
https://www.dnsleaktest.com
Если по результату вы не видите в таблице чего-то близкого к вашей стране или даже городу, значит утечки DNS в браузере, скорее всего, нет. Для надёжности несколько раз обновите цепочку и повторите тест, результаты должны отличаться.
Этот способ проверяет только браузер, но ведь DNS может "утекать" не только из браузера. Если вы так подумали, то вы правы. Но об этом чуть ниже.

Как устранить утечку в браузере?
Утечка DNS - это не болезнь, а симптом чего-то более серьёзного, поэтому прежде всего нужно выяснить первопричину. Утечка DNS в большинстве случаев говорит о том, что вы присрали Tor туда, где он быть не должен. Например, пустили обычный браузер через Tor по socks5. В этом случае может возникнуть и утечка обычных запросов, отпечатков браузера и железа, что уже намного опаснее, поэтому утечка DNS - это не единственная и не главная ваша проблема. Чтобы её исправить, нужно избавиться от хреновых решений и использовать полноценный Tor-браузер, а ещё лучше Whonix.

Если вы не видите утечку, это ещё не значит, что её нет
Задумывались о том, что, например, XMPP-клиент может допускать утечку, даже когда он настроен на прокси в Tor? Или любая другая программа, которая направляется в Tor через свою настройку socks-прокси? Аналогия про симптом здесь тоже работает. Программы могут допускать утечку и обычных запросов, а это уже совсем плохо. Выявить такую утечку слишком сложно. Анализ кода или анализ исходящего трафика не подходит, это всё долго, неэффективно, и придётся повторять после каждого обновления.
Причина проблемы в том, что любая программа свои внутренние настройки рассматривает как рекомендации. Она может строго им следовать, а может от них отступать, всё зависит от того, что разработчики понаписывали в коде. И чтобы надёжно решить проблему, нужно вынести перенаправление трафика за пределы программы. Туда, где она не сможет на это повлиять. Отбросив плохие практики (роутер в Tor, сомнительные скрипты с гитхаба), оставляю два пути решения:
  • Простой. torsocks . Если написать это перед командой запуска программы, она автоматически отправится в tor и не сможет из него случайно выбраться. Эта утилита есть в репозитории apt, утечку DNS она не допускает. Но такой способ нельзя считать очень надёжным, при определённых обстоятельствах он может подвести. Подойдёт только для простых (лучше даже разовых) задач, где высокий уровень надёжности не является критично важным.
  • Надёжный. Whonix. Это лучший вариант, запускать программы нужно внутри Workstation. Утечек он точно не допустит, к тому же имеет высокую защиту от человеческого фактора и случайных сбоев.


2. Какого хера Tor сам выбирает для меня DNS?

Как это работает:

В названии раздела уже дан ответ. Да, всё решает Tor. Точнее, выходная нода выбирает DNS по своему предпочтению. Новая цепочка - новая нода - новый DNS-сервер.

Как TorProject контролирует выбор DNS-серверов на выходных узлах Tor
А никак он его не контролирует. Выходные ноды не согласуют выбор DNS-сервера ни с вами, ни с TorProject, у которого нет никакого прямого влияния на этот процесс.
Для примера. Году так в 2018 TorProject обратили внимание, что из всех DNS-запросов в Tor на один только Google уходит 24%. Это централизация, которая всегда вредит конфиденциальности. Взялись TorProject за инструкции, публикации и документации, чтобы донести проблему до операторов выходных нод. Но кто-то что-то недопонял и в 2019 году вместо Google выросла доля Cloudflare, да так, что Google+Cloudflare стал занимать 31%.
Сейчас положительные успехи уже есть, но вы можете представить как тяжело они даются.
Продвигать DoT/DoH TorProject пока не собирается, потому что DNS-серверов с такой функцией мало и переход на них даст централизацию, от которой сейчас пытаются избавляться.
В результате DNS-запросы передаются в открытом виде и выходные ноды Tor имеют техническую возможность подменять данные и направлять вас по ложному IP.

Если вы хотите запретить Tor'у самодеятельность и прикрутить к нему свой собственный DoH, не спешите. Этим вы сделаете только хуже.

Что делать, если очень чешутся руки и хочется прикрутить DoH к Tor или Whonix
Подумать.
Технически это возможно. Сам Tor не позволяет настроить выбор DNS-сервера. Ни в браузере, ни в демоне (демон - служебная программа в linux) сделать это стандартными методами не получится. Этот факт уже должен наталкивать на мысль, что с идеей что-то не так.

В теории:
В Tor существуют опции CacheDNS и UseDNSCache (которые, кстати, сам Tor не рекомендует включать). Можно встроить в tor компонент, который будет выполнять DNS-запросы отдельно, а результат подсовывать в виде кэша.
На практике:
  • Ваше поведение в Tor будет нетипичным, оно отличит вас от большинства других пользователей, станет вашим личным маркером, что очень плохо для анонимности.
  • Выходная нода при желании всё равно может забить хер на полученый IP и перенаправить на какой-то другой.
  • От подмены IP на DNS-сервере вы никак не защищены.
  • Вы лишаетесь диверсификации DNS-среверов (новая цепочка - новый сервер) и вместо этого используете один единственный.
Поэтому единолично менять устройство DNS в Tor - это плохая идея.

Если вы используете браузер Firefox на Whonix, не включайте в нём DoH.


Всё, что здесь написано про DoH, актуально только в Tor! В обычном браузере, который общается с интернетом напрямую, наоборот следует включить DoH, в этом случае он будет полезен.


Так как же сделать DNS-запросы в Tor безопасными?

Для начала перестать пытаться сделать их опасными. Надеюсь, с этим разобрались.

Я кое-что пропустил в предыдущем разделе. Почему разработчики Tor рекомендуют не использовать опции типа UseDNSCache?
Опции помечены как "deprecated", а в документации сказано: This options ... can harm your anonymity (Эти опции .. могут навретить вашей анонимности)
Что плохого в кэшировании DNS?
  • По-умолчанию эта функция отключена, к тому же не рекомендована к использованию, значит среди пользователей Tor она встречается крайне редко. Такая опция даже без собственных доработок может стать отличным маркером. Не самым ярким, но всё же вашим личным маркером.
  • Кэш запросов не сбрасывается при обновлении цепочки. Отсюда две проблемы:
    • Если выходная нода попробует провернуть атаку с подменой DNS (которую подробно разберём позже), фейковый IP "прилипнет" к вашей системе и обновление цепочки не сбросит его. Это будет способствовать успешной атаке на вас. Так называемый, "липкий MITM".
    • Другая атака связана с выдачей уникального IPv6 каждому посетителю сайта, благодаря чему можно связывать между собой разные цепочки Tor, инициированные одним и тем же пользователем. Однако, возможность применения этой атаки ограничена, потому кнопка "New identity" (Новая личность) чистит любой кэш, а простая смена цепочки не чистит ничего, поэтому может оставить и другие следы. Но всё же, в определённых условиях эта атака может сработать, эта проблема указана разработчиками Tor и её тоже нужно принять во внимание.
Ещё не тотальный деанон, но уже нарушение конфиденциальности и неприятное "пособничество" злоумышленнику на выходной ноде.

Изначально кэш DNS сделали для повышения производительности, но вреда от этой функции сейчас больше, чем пользы.
В разлычных статьях иногда встречаются заготовленные конфигурации torrc, в которых эта опция включена. Если вы не копировали в свою систему что попало и не пытались улучшить Tor (опять), то всё должно быть нормально.
Но всё равно проверим, хотя бы из любопытства.

Каких опций быть не должно: CacheDNS, CacheIPv4DNS, CacheIPv6DNS, UseDNSCache, UseIPv4Cache, UseIPv6Cache
Команда для проверки (выполнять лучше от вашего стандартного пользователя, а не root):
Bash:
sudo egrep -inR --color 'DNSCache|CacheDNS|CacheIPv.DNS|UseIPv.Cache' /etc/tor/tor* /etc/torrc.d/ /usr/local/etc/torrc.d/ ~/.torrc*
Можно запустить как на host-os, так и на Whonix Gateway.
Команда должна выдать пустой результат (No such file or directory можно игнорировать). Если совпадения были найдены, их нужно удалить из файлов. Удалять нужно не всю строку, а только те слова, что перечислены выше. Вот так (зелёное оставить, красное удалить):
SocksPort 9051 CacheDNS UseDNSCache

Tor-Browser проверять нет необходимости, его вряд ли кто-то настраивает через конфиги, поскольку его конфиги перезаписываются при перезапусках и обновлениях, произвольные модификации там не приживаются.
PATH_TO_TOR_BROWSER_DIR - путь к папке с браузером Tor.
Bash:
sudo egrep -inR --color 'DNSCache|CacheDNS|CacheIPv.DNS|UseIPv.Cache' PATH_TO_TOR_BROWSER_DIR/Browser/TorBrowser/Data/

Использование Firefox на Whonix лучше максимально сократить. Для создания новой личности в Firefox на Whonix нужно полностью очистить браузер, закрыть его, перезапустить Tor кнопкой Restart Tor на Gateway и только после этого открыть браузер снова.

Нам врёт документация Tor.
В некоторых мануалах в интернете вы можете обнаружить такую строчку:
CacheIPv4DNS - Tells the client to remember IPv4 DNS answers we receive from exit nodes via this connection. (On by default.)
Опасная для конфиденциальности опция по-умолчанию включёна???
Это действительно было написано в документации, но это не правда. Разработчики Tor
выключили эту настройку ещё в начале 2015 года, но забыли отредактировать мануал. Спустя аж 4 года вспомнили и исправили ошибку, о чём свидетельствует этот коммит: https://gitlab.torproject.org/dgoulet/tor/-/commit/b979415e8bf4c33e6d540c780edeeb40bce5e512. Но на многих сайтах до сих пор лежит старая версия мануала с ошибкой. Знайте, что в реальности все эти опции Off by default.


Хорошо, вы убедились в том, что DNS работает правильно и не вредит вашей анонимности.
Но ведь он по-прежнему никак не защищён.
Да и хрен с ним!

Если бы защита DNS внутри Tor была возможна, то она была бы бесполезна. Дело в том, что DNS следует рассматривать как вспомогательную технологию. Он лишь помогает быстро найти нужный сервер. А за соответствие домена и сервера отвечают совсем другие механизмы, на которые и нужно обратить внимание.

Кстати. По итогу статьи получается, что наибольший вред анонимности приносят не особенности Tor, а наши собственные неправильные действия. Забегая вперёд скажу, что и у следующей статьи итог будет примерно такой же. Забавно, не находите?

И вот только теперь, когда мы не вредим сами себе, можно добавить для этого злоумышленника. Обратимся к классике. Негодяй Bob поднял выходную ноду Tor и предпринимает попытки атаковать Alice, чтобы завладеть её данными, деньгами, а может и самой Alice. Рассмотрим ситуацию с обеих позиций, чтобы понять как распознать возможную атаку и увернуться от неё.

Но это в следующей статье. Продолжение: Атаки на соединения в Tor: как работает HTTPS и как не сделать его бесполезным
Onion: rutordeep | rutordark | rutorbest | rutorclub | rutorsite
Клирнет: rutor.wtf | rutor.nl | rutor.live | rutor.market | rutor.love | rutor.biz
Доктор, у меня с 5го числа обнаружено очень - очень, странное поведение узлов соеденения, образно выражаясь, другие кроме {us},{de} словно перестали сущевствовать, ставил их в исключённые, либо неконктит либо игнорит как будто их это не касается, меняю apk, устройства, источники apk но, воз и ныне тут.
Пора баул или финальную сцену репетировать?
Сообщение обновлено:

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

torinmyheart

Software engineer, security expert
Проверенный сервис
Подтвержденный
Сообщения
80
Реакции
262
Доктор, у меня с 5го числа обнаружено очень - очень, странное поведение узлов соеденения, образно выражаясь, другие кроме {us},{de} словно перестали сущевствовать, ставил их в исключённые, либо неконктит либо игнорит как будто их это не касается, меняю apk, устройства, источники apk но, воз и ныне тут.
Пора баул или финальную сцену репетировать?
Вопрос не понял, но попробую ответить)
Если в вашей стране блокируют тор или цензурируют интернет, вы можете сталкиваться с подобными проблемами. Вот тут я писал о том, как применять мосты:
http://rutordeepkpafpudl22pbbhzm4ll...s-mostami-perestal-rabotat.40413/#post-394532
Дополню: прежде чем ставить новые мосты obfs, можете пингануть их IP. Это сэкономит время, но не избавит от необходимости смотерть в логи.

Можно и так сказать. Это понятие широкое. Тайминг-атакой можно назвать любую атаку, которая опирается на время. В реальных условиях в торе применить "классическую" тайминг-атаку очень сложно. Утечка DNS упрощает этот процесс, открывает новые векторы атак. В этом контексте можно подумать и над другими вариантами деанонимизации, например, выдача DNS-сервером уникальных IPv6. А разбор тайминг-атак заслуживает отдельной большой статьи.
 

Nahema5

Продвинутый юзер
Сообщения
282
Реакции
102
Вопрос не понял, но попробую ответить)
Если в вашей стране блокируют тор или цензурируют интернет, вы можете сталкиваться с подобными проблемами. Вот тут я писал о том, как применять мосты:
http://rutordeepkpafpudl22pbbhzm4ll...s-mostami-perestal-rabotat.40413/#post-394532
Дополню: прежде чем ставить новые мосты obfs, можете пингануть их IP. Это сэкономит время, но не избавит от необходимости смотерть в логи.


Можно и так сказать. Это понятие широкое. Тайминг-атакой можно назвать любую атаку, которая опирается на время. В реальных условиях в торе применить "классическую" тайминг-атаку очень сложно. Утечка DNS упрощает этот процесс, открывает новые векторы атак. В этом контексте можно подумать и над другими вариантами деанонимизации, например, выдача DNS-сервером уникальных IPv6. А разбор тайминг-атак заслуживает отдельной большой статьи.
По поводу первой части ответа попробую внести ясность ввиду тяжелейшей болезни, цитирование своего сообщения, позже как нибудь развернул, если заинтересует то, чего вроде бы как быть не может но, оно есть:
Тёмные дела произошли с Bromite, без объективных причин, пропали данные автозаполнения:Search1::Shock1::Slow1:
Очень странные дела...
Особенно если учесть что, сладкая парочка узлов, два друга... и подпруга, которые не дают мне забыть кто виноват во всех нововведениях в наш трудовой быт, а именно пиндосы и фрицы, по сей день неустанно, сменяя друг друга, и лишь в порядке исключения, иногда и совсем не на долго, уступают место кому-то ещё. И фоне этих голых фактов, никакая теория и даже академического уровня квалифицированность в принципах работы маршрутизации сети тор и её анонимности, не может быть убедительно от слова и большими буквами - СОВСЕМ)))
Никогда не подозревал что, мысль свалить с этой планеты, не будет казаться слишком абсурдной)))
И хоть и откладываю решение этой проблемы, да блин, это именно проблема, всё равно понимаю что, засухариться как Борну, это будет бессмысленно, не столько дело в технологической сингулярности, которая не за горами, сколько в уже существующих технологиях. Проявлять столь пристальное и длительное внимание, к кому бы то ни было, чтобы потом забыть, эти кроссы не будут, у них явно другой имидж, а как бы не развивались события, вечного зыринга точно ожидать не стоит, рано или поздно, даже страны обратно помирятся, если конечно хватит ума, не за бросать друг друга, ни сегодня завтра, ракетами (кстати этот сценарий тоже, мне уже не кажется таким фантастичным, уровня какого нибудь голливудского посапокалипсиса, а вполне себе обыденной вероятностью типа, 11 сентября, августа 2008, зелёных человеков или движухой на Украине...
Короче, с добрым утром :Mail11:
С писательским олимпом разобрался, пойду в поле посмотрю, чего там можно украсить)))
Это разумеется не полная картина но, вроде понятная...
 
Сверху Снизу