Tor dns как работает
Как использовать Tor в качестве DNS-сервера (посылать DNS-запросы через Tor)
Ниже приведены следующие варианты прозрачного проксирования (торификации) DNS-трафика:
Tor как системный DNS-сервер:
перезапустите Tor и пропишите в системных настройках подключения к интернет «DNS сервер: 127.0.0.1». Чтобы это работало в системах Linux или *BSD, Tor должен запускаться от root'а (возможен сброс привелегий до умолчального пользователя tor после запуска).Для работы нужно указать DNSPort (смотрите ниже).
Tor как DNS-сервер для конкретной программы, поддерживающей собственные настройки DNS:
Примером такой программы является uTorrent. Добавьте в файл настроек torrc строки перезапустите Tor и пропишите в настройках программы «DNS сервер: 127.0.0.1, порт 5300».Принудительное использование Tor как DNS-сервера для конкретных пользователей или программ:
а затем средствами firewall'а или другой программы "заверните" запросы к DNS от нужных пользователей или программ на адрес 127.0.0.1:5300. Разделение по пользователям доступно только в системах Linux и *BSD, а разделение по программам (учтите, что оно не является надёжным) — только в Windows.Примечание: в последних двух вариантах вместо порта 5300 можно использовать любой другой незанятый порт (число) в промежутке от 1025 до 65535.
Как удлинить цепочку Tor с помощью программы polipo (использовать с Tor программы без поддержки socks-прокси)
Внимание. При смене цепочек для polipo по сигналу NewNym от vidalia через Tor, polipo удерживает соединение, что Tor воспринимает как долговременную цепочку и не меняет исходящий узел. Это возможно некритично при данном сценарии использования, но послужило одной из причин отказа от polipo в проекте Tor. Надо это учитывать, в случае если вы захотите приспособить polipo для чего-то другого.
-
Качаем старую сборку Tor Browser c Polipo из архива Tor Project, например:
-
Распаковываем архив, находим там подкаталог old_tb/App и копируем из него в tb/App файлы:
– для Linux polipo
- Создаем каталог tb/Data/Polipo и копируем в него конфигурационный файл old_tb/Data/Polipo/polipo.conf
- Дописываем в файл tb/Data/Vidalia/vidalia.conf в разделе [General] строки:
- В файле tb/Data/Tor/torrc заменяем строку (если есть)
где proxy_host: proxy_port – адрес внешнего прокси. После добавления прокси Tor Browser надо перезапустить. Отследить подключение к этому прокси можно в окне цепочек Vidalia или в IP-анализаторах типа ipligence. А чем может быть плоха предложенная мною схема для мобильных подлкючений использовать чистый файл /var/lib/tor/state?
Вроде бы ничего не меняется как если бы входил в сеть с только что установленным tor?
И такой еще вопрос. Со слов некоторых научных работников, мне известно, что ФСБ последнее время поднимало очень много tor-нод. С какой целью, правда, они затруднились ответить.
Возникает вопрос, как проконтролировать, чтобы входные узлы не имели российских ip-адресов, т.к. в этом случае велика вероятность, что входные узлы уже контролируются ФСБ.
И второе. Могут ли сервера, находящиеся в России, иметь ip-адрес, выделенный другому государству? Понятное дело, что в случае тайного сговора между ФСБ и АНБ (или на более высоком уровне) – могут, и это невозможно отследить, а вот помимо воли американских структур, распределяющий ip-адреса по регионам (не помню как этот институт у них там называется) – могут? Или подменять ip, но так, чтобы обратный трафик тоже до них доходил?
P. S. Конечно, можно предположить, что российские спецслужбы имеют сервера Tor и за границей, как вариант. Если бы были хорошие мысли по поводу их вычисления, тоже неплохо было бы их услышать. Только, имхо, в этом последнем случае они вообще становятся "неуловимыми", и спасти ситуацию могут лишь только толпы добровольцев, запускающих в частном порядке сервера Tor.
Которых почему-то в России не наблюдается.
В последние версии стали включать Tor GeoIP-db, чтобы примерно учитывать географическое положение узлов при построении цепочки.
>Конечно, можно предположить, что российские спецслужбы имеют сервера Tor и за границей, как вариант.Это элементарно вопрос денег. Поднять tor-сервер можно на платном виртуальном хостинге, коих тысячи по всему миру.
>ФСБ последнее время поднимало очень много tor-нод. С какой целью, правда, они затруднились ответить.Допустим это не слухи. Прозревается заговор.
Допустим точка "пользовательский провайдер — вход в сеть Tor" всегда прослушивается (тут даже guard-узел малополезен), количество экситов в сети мало и большинство из них принадлежит трёхбуквенным агентствам. Тогда снимая трафик в двух точках ("ISP-пользователя") – ("подконтрольный Exit"), можно делать атаку пересечения и смотреть, куда пошёл пользователь. Чем больше подконтрольных экситов, тем выше вероятность собрать данные о пользователе.
Кстати, ФСБ (или кому-там) необязательно запускать свои Tor-узлы в Росии (или где-там) — для проведения атак корреляции достаточно прослушивать трафик поступающий и исходящий с этого узла со стороны провайдера, через которого работает этот узел. МОжно ещё поковырять трафик на магистральных узлах — это работа для систем эшелоноподобного типа.
Ответ на ваш вопрос добавлен в другой список раздела вопросов-кандидатов в FAQ, в пункте об атаках подтверждения и пересечения. Гость, вы задали хороший темп работ и дали много поводов для конструктивных размышлений в попытках ответить на все ваши вопросы!
На поверхности могли бы лежать 2 цели: получение информации о IP, пользующихся Tor, или, что вероятнее, изучение трафика на выходе из эксит-нод, и забота о скорости работы сети, если они сами ею пользуются.
Возникает вопрос, как проконтролировать, чтобы входные узлы не имели российских ip-адресов, т.к. в этом случае велика вероятность, что входные узлы уже контролируются ФСБ.
Есть excludenodes-опция, но она полумера (в статистике могут внезапно появиться новые IP-дреса из РФ, которые вы ещё не перечислили в списке). Есть подобные опции, которые фильтруют по стране, но они тоже не до конца надёжны, т.к. трудно всегда и однозначно сказать кому принадлежит адрес (в общем случае). Т.е. всё это полумеры.
Могут ли сервера, находящиеся в России, иметь ip-адрес, выделенный другому государству?
Да, могут. Я скажу даже большее: есть такие IP-адреса, которые не ассоциированы ни с каким государством, и не числятся ни в каких базах данных. Некоторые умельцы в некоторых странах могут себе их установить и работать на них до поры до времени.
Или подменять ip, но так, чтобы обратный трафик тоже до них доходил?
Если вы выбрали их сервер в цепочке, то через него идёт и прямой и обратный трафик, если же не выбрали, то никакой не идёт. Выбирает всегда сам клиент Tor'а.
Конечно, можно предположить, что российские спецслужбы имеют сервера Tor и за границей, как вариант. Если бы были хорошие мысли по поводу их вычисления, тоже неплохо было бы их услышать. Только, имхо, в этом последнем случае они вообще становятся "неуловимыми"
Да у нас любой громодянин может поднять свой Tor-сервер в банановой республике, чем здесь спецслужбы-то выделены? :)
спасти ситуацию могут лишь только толпы добровольцев, запускающих в частном порядке сервера Tor.
Да, и об этом уже сто раз писали.
Общее число подключенных к интернету юзеров в РФ мало по сравнению с другими странами – с этим всё и связано."Я щас взорвусь как тыща тонн тротила
Во мне заряд нетворческого зла
Меня сегодня муза посетила. " (В. Высоцкий)
Прошу прощения за оффтоп
Общее число подключенных к интернету юзеров в РФ мало по сравнению с другими странами – с этим всё и связано.
А ещё меньше широкополосных безлимитных тарифов в замкадье. . и нет такой жёсткой системы прессинга псевдоасоциальных элементов (терриристов/экстремистов/нацистов/ксенофобов/антисемитов/педофилов/некрофилов, кем бы они ни были) как в европах и америках :-D
При таком сценарии атаки пересечения будут давать на выходе IP-адрес Tor-сервера и не будет возможности подтверждения — исходит ли трафик от этого сервера непосредственно как от клиента сети Tor или это трафик, пропущенный от других пользователей.Не всё так просто. Если у противника есть внешний способ контролировать присутствие пользователя (например, онлайн в джаббере), то разрыв нужной цепочки между Tor-нодами всё проявит (наблюдаемо выкинет пользователя из джаббера). То, что при этом ещё какие-то соединения у каких-то юзеров порастут – дело уже третье. Т.е. вам бы как-то надо понятнее прояснить этот момент, без неоднозначностей чтоб было.
В первом варианте если противнику принадлежит и , то по корреляциям он упирается в , но не зная длину цепочки не может сказать, от кого она исходит. А если противнику принадлежит и , то он не только установит корреляцию, но и определит наличие и точное название в цепочке, следовательно зная её длину, он может предположить, что инициатор .
И не важно, будет он при этом рвать цепочки или получит корреляции активно, похоже, что запуск сервера даёт относительно немного примуществ.
Зато во втором варианте определить не сможет.
Вопрос в FAQ под вопросом? :)
Ну если запуск сервера не ухудшает анонимность, то можно сказать что "полезно", т.к. при каких-то атаках и впрямь улучшает защиту (есть какой-то псевдопокрывающий трафик от других юзеров Tor-сети).В первом варианте если противнику принадлежит и , то по корреляциям он упирается в , но не зная длину цепочки не может сказать, от кого она исходит.
Неправильно. На сервисе виден IP эксита, На есть корреляция в этой цепоче с и определяется, что цепочка пошла из , но не на , а на , значит в этой цепочке работает в режиме и эта цепочка не порождена другими пользователями.
Что имели ввиду разработчики, когда говорили, что запуск сервера повышает анонимность — неясно. По крайней мере от атак пересечения это также не защищает. Может они имели ввиду только запуск экситов?
Может быть существуют другие предположения о том, какие точки съёма трафика контролирует противник, при которых анонимность будет всё же повышаться. > как вариант в настройках конкретной программы, если она это позволяетЕсли нужно, чтобы перенаправлялись только DNS-запросы каких-то конкретных программ
Становится непонятно: если вариант с «конкретной программой» уже рассмотрен, то зачем её снова повторно рассматривают ниже. Дело-то в том, что есть принудительное заворачивание (программа об этом сама не знает) и конвенциональное (программа имеет настройки для этого). Короче, описывать все эти детали, следя за понятностью для тех, кто вообще не в теме, желания нет, потому лучше убрать ту оговорку. Более того, я не видел ни одной программы, которой можно указать DNS-сервер в настройках, т.е. отличный от системного.
Кто конкретно понимается под DNS-резволингом, мне тоже не до конца ясно. Где-то в районе /comment53198 это косвенно упоминалось, вроде как имеются блокирующие и неблокирующие резолверы, у firefox свой резолвер и т.д. Резолвер — это DNS-клиент? И, опять же, если какая-то программа имеет свой резолвер, то что это значит? Может быть, просто есть много отдельных программ — DNS-клиентов/резолверов, и разные программы просто используют разные резолверы? man dig тот же. Т.е. если программа шлёт DNS-запрос, с точки зрения ОС от кого шлётся запрос? Если она использует какой-то внешний неконвенциональный DNS-клиент, то и программа, чей трафик надо будет завернуть на 127.0.0.1:5300, получается, будет другой (нужно заворачивать трафик от резолвера, а не от целевых программ, его использующих).
Есть сомнения в правильности терминологии. Является ли Tor на соответствующем порту DNS-сервером? Фактически он не резолвит, а просто перенаправляет DNS-запросы на exit-ноды, а раз так, значит, с точки зрения exit-нод Tor является DNS-клиентом?.
Добохозяйки могут не понять, что вместо PORT надо указать число из промежутка 1025-65535, а рассказывать, как устроена ОС в рамках FAQ — долго, муторно и совсем не к месту, не хочется писать все эти пояснения и предостережения, превращая один абзац в статью. Имхо, лучше указать конкретное число и сделать оговорку.
Тут, к минимум, три замечания:
- DNSPort 53 — это избыточно, т.к. значение по умолчанию. Т.е. опция включается сама, если DNSListenAddress включено. Я привык для себя писать кое-что избыточно, но делать так во всех инструкциях — значит, неправомерно усложнять их.
- 53 — привелегированный порт (по крайней мере, в юниксах). Т.е. сторонний пользователь не запустит ничего на портах, кажется, 0-1024. Если запускается от рута и потом присходит дроп привелегий, то, думаю, тоже всё ОК, но если тупо запустить Tor-клиент от кого попало, никто ему 53ий порт не даст заюзать.
- Кто-нибудь это вообще тестировал, особенно на виндах?
2б 3. На винде работает, пробовал и без прав. Про никсы добавлю в примечание. Для нормальной работы Tor надо DNS, поэтому когда ставишь DNS как Tor, то при нерабочем Tor (через него dns), Tor не может подключиться. Как сделать так, чтобы для подключения к сети не нужны были dns?
Сейчас в Tor есть три порта для разруливания клиентского трафика — SOCKSPort, TransPort, DNSPort, которые могут повторяться в конфиге множество раз и к каждому из которых может применяться определённый набор опций по изоляции протоколов. Всё это может быть разрулено файрволлом по потребностям, главное усложнёнными настройками не нарушить безопасность.
Если у пользователя есть понимание этих возможностей, то DNS — это частный случай "продвинутых настроек". Если понимания нет, то может случиться так, что он неправильно поймёт зачем это нужно. Например, услышит про проблему "утечки DNS", DNS порт прокинет правильно, а с SOCKS или TransPort'ом сделает что-нибудь не так и будет думать, что защитился от всех утечек трафика. К примеру "анонимно" заторит какую-нибудь программу, в которой только DNS будут завёрнуты в Tor, а TCP-трафик пойдёт в сеть напрямую.
Что если вам хочется ходить в сеть без надуманных ограничений, но не хочется каждый раз в браузере подменять прокси? Что если вы хотите заходить и на запрещенные сайты, и на обычные, и чтобы при этом скорость, с которой открываются обычные сайты, не страдала? Что если вам интересно знать что творится в удалённых частях глобальной сети?
Исходя из этих соображений нам нужно чтобы:
- Обычные сайты открывались как обычно
- Запрещенные сайты открывались через Tor без настроек
- Все сайты в зоне .onion тоже открываются без настроек
С одной стороны, требования противоречивые. А другой стороны, чего не сделаешь ради удобства!
Можно было бы вспомнить различные способы и средства для обхода DPI, но если не хочется ни о чем таком думать, а скорей даже хочется настроить и забыть, то аналогов Tor для решения поставленной задачи в части простого доступа к заблокированным сайтам нет.
Вы не получите полной анонимности следуя только этим инструкциям. Анонимность без мер OPSEC невозможна. Инструкция подразумевают лишь обход ограничений.
Что нам нужно?
Для начала нам нужен или роутер, или сервер, работающий в качестве прозрачного моста, пропускающего через себя весь трафик. Это может быть и существующий сервер, это может быть и коробочка с Raspberry Pi. Могут подойти и обычные компактные роутеры с Linux, если на них в принципе можно поставить необходимые пакеты.
Если подходящий роутер у вас уже есть, то настраивать отдельно мост не нужно и можно сразу перейти к настройке Tor.
Если же установка Tor на ваш роутер представляет проблему, то вам понадобится любой компьютер с двумя сетевыми интерфейсами и Debian Linux на борту. Его вы в конечном счёте подключите в разрыв сети между роутером, который смотрит во внешний мир, и вашей локальной сетью.
Настроим мост
Настройка моста в Debian проблемы не представляет. Вам понадобится программа brctl , которая есть в пакете bridge-utils :
Постоянная конфигурация для моста задаётся в /etc/network/interfaces . Если вы делаете мост из интерфейсов eth0 и eth1 , то конфигурация будет выглядеть так:
Вам нужно выбрать какую-то одну конфигурацию для моста: с динамическим IP или статическим.
Обратите внимание что на этом этапе не обязательно включать сервер в разрыв сети. Можно обойтись и одним подключенным интерфейсом.
Попросим систему применить новые настройки:
Теперь можно проверить существование моста командой brctl show :
Посмотреть выданный IP адрес, и проверить вообще факт выдачи какого-то IP по DHCP или статически, можно командой ip :
Если с IP адресами всё в порядке, то уже можно попробовать включить сервер в разрыв сети.
В конце концов все устройства в вашей сети, будучи включены через сервер, должны иметь полный доступ к глобальной сети будто никакого сервера между ними и внешним роутером нет. То же касается работы DHCP и прочего. Всё это стоит проверить до перехода к настройке Tor.
Если что-то работает не так же, как раньше, или вообще не работает, стоит сначала решить проблемы, лишь потом переходить к настройке собственно Tor.
Настроим демон Tor
Установка Tor выполняется обычно. Установим также базу данных привязки к странам:
В конец файла конфигурации /etc/tor/torrc нужно дописать директивы для включения функции прокси-сервера:
Перезапустим Tor и проверим что DNS в нашей конфигурации работает на каком-нибудь известном сайте:
Последняя команда должна вывести IP из подсети 10.0.0.0/8 .
При перезапуске Tor по делу ругается на использование публичного IP для TransPort и DNSPort , которые в самом деле могут быть доступны посторонним. Исправим это недоразумение, разрешив только соединения из локальной сети (в моём случае это 192.168.1.0/24 ):
Последние два правила можно пропустить если у вас для цепочки INPUT по умолчанию стоит правило DROP .
Настроим доступ для всей локальной сети
Чтобы все устройства в сети смогли зайти на сайты в Tor нам нужно переадресовать все запросы к выделенной сети 10.0.0.0/8 на порт встроенного прокси-сервера Tor:
Два правила для цепочек PREROUTING и OUTPUT мы добавляем чтобы схем работала не только с устройств в сети, но и с самого сервера. Если не требуется чтобы эта схема работала с самого сервера, то добавления правила в цепочку OUTPUT можно пропустить.
Переадресация DNS запросов к зоне .onion
Эту проблему можно было бы решить либо заменой DNS сервера на свой в DHCP ответах клиентам, либо, если у вас в сети не принято использовать локальный DNS сервер, перехватом всего DNS трафика. Во втором случае не нужно будет ровным счетом ничего настраивать, но все ваши клиенты, и вы в том числе, потеряете возможность делать произвольные запросы к произвольным серверам. Это очевидное неудобство.
Мы же будем переадресовать лишь DNS запросы, упоминающие домен .onion , на порт встроенного DNS сервера, оставляя все остальные запросы в покое:
Магическая строка 056f6e696f6e00 связана с особенностями передачи точки в DNS запросах: она передаётся в виде длины следующей после неё строки. Потому в начале нашей магической строки стоит 0x05 для пяти символов в слове onion . В конце строки стоит нулевой байт 0x00 потому что корневой домен (точка) имеет нулевую длину.
Такой подход позволяет ваши пользователям (и вам самим) пользоваться какими им удобно DNS серверами, а также запрашивать информацию у любых DNS серверов без посредников. Вместе с тем никакие запросы в зоне .onion не будут попадать в открытый интернет.
Теперь попробуйте достучаться до какого-нибудь популярного сайта в сети Tor с любого устройства в локальной сети. Например, так:
Отладка и решение возможных проблем
Если хочется убедиться что никакие DNS запросы к .onion не идут дальше сервера, то их отсутствие можно проверить так:
В норме эта команда, выполненная на сервере, должна показать полное отсутствие пакетов - то есть не выводить ничего, чтобы вы не делали.
Если Firefox не видит .onion
Если вам это мешает, а перспектива случайной деанонимизации вас не волнует (ведь мы уже не пускаем DNS запросы к .onion в открытый интернет), отключить эту настройку можно в about:config по ключу network.dns.blockDotOnion .
Мобильный Safari и .onion
Провайдер подменяет IP в DNS
Некоторые провайдеры из экономических соображений, вместо блокировки сайтов по IP или через DPI, лишь подменяют IP для DNS запросов по списку запрещенных сайтов.
Простейшим решением этой проблемы будет переход на сервера Google Public DNS. Если это не помогает, а значит ваш провайдер перенаправляет вообще весь DNS трафик на свой сервер, то можно перейти на использование Tor DNS, в свою очередь переадресовав весь трафик на него:
В моей сети используются IP из 10.0.0.0/8
Нет проблем! Во всех директивах выше используйте какую-то другую подсеть из предназначенных для этого, исключая зарезервированные. Серьезно, обратите внимание на резервированные.
Кроме того, не обязательно использовать сразу весь диапазон - можно ограничиться и подсетью. Например, подойдет 10.192.0.0/10 .
Обход блокировок через Tor
Для выхода на заблокированные сайты через Tor прежде всего нужно убедиться что вы не меняете шило на мыло, используя выходные узлы подверженные тем же ограниченияем что и вы в силу географического нахождения. Это можно сделать указав в torrc выходные узлы в каких странах нельзя использовать.
К счастью, и благодаря особенностям работы сети, ответственные ведомства сейчас рекомендуют (?) или использовать DPI, или блокировать сразу по IP. Это работает нам на руку потому что нам не нужно в реальном времени следить за тем, какое доменное имя какого заблокированного сайта резолвится сейчас в какой IP - за нас это уже сделано создателями реестра. Понятно что иногда вы можете всё-таки наткнуться на блокировку если, например, сайт поменял IP, а в реестре его ещё нет.
Если мы работаем только с IP адресами заблокированных сайтов, то для переадресации через Tor запросов к множеству IP лучше использовать программу ipset из одноименного пакета. Создадим таблицу в которой будут храниться все адреса:
Теперь мы можем добавить переадресацию для всех IP из списка на порт прокси-сервера Tor:
Проверим переадресацию
Проверим что наша схема с переадресацией в принципе работает. Для этого добавим в черный список IP сайта для проверки настройки Tor.
Если это не так, то проверьте ещё раз что вы задали все правила для iptables . Это можно сделать такой командой:
Всего у вас должно быть шесть правил в двух цепочках PREROUTING и OUTPUT .
Открываем заблокированные сайты через Tor
Получить список заблокированных адресов можно через API, любезно предоставленное проектом РосКомСвобода. Получим текущий список IP адресов и добавим их в таблицу для разблокировки, предварительно очистив ранее добавленные IP адреса:
Эта операция занимает существенное время, потому ждём спокойно. При этом сам список много памяти не займет - 30 тысяч IP адресов занимают лишь порядка 500 кб.
Проверяем доступность на первом попавшемся запрещенном сайте из списка. Например, на LinkedIn.
Обновляем реестр
Реестр не стоит на месте и список заблокированных сайтов пополняется. Потому вам нужно время от времени выгружать актуальный список IP и добавлять его в ipset . Лучше всего это делать не выгружая весь список целиком каждый раз, а выкачивая только изменения, например, отсюда c GitHub.
Возможно удалять и добавлять только изменившиеся в списке IP, для чего вам может пригодится git whatchanged .
Если вам подходит скрипт выше, то ему самое место в /etc/cron.daily/blacklist-update . Не забудьте дать этому файлу права на выполнение.
Сохраняем настройки
Естественно вы захотите сохранить где-то все настройки iptables чтобы не вводить их заново при каждой перезагрузке. Если вы этого уже не делаете как-то ещё, то вам поможет пакет.
При первой установке будет предложено сохранить все текущие правила. Если вы их измените и захотите чтобы после перезагрузки изменения остались, то вам необходимо сохранить их повторно:
К сожалению, такого же удобного пакета для ipset пока нет, но эта проблема решается скриптом /etc/network/if-pre-up.d/ipset :
Обязательно нужно дать и этому скрипту права на выполнение:
При следующей перезагрузке этот скрипт выполнится и восстановит список заблокированных IP.
Если забыть о серверах.
Окей, скажите вы, ну а что если я хочу получить все тот же удобный доступ к .onion , но без серверов - локально, на одном компьютере?
Нет проблем! В этом случае все даже проще. Хватить добавить эти три строчки в torrc :
Затем эти два правила для iptables :
И можно проверять. Доступ к заблокированным сайтам настраивается по инструкции выше.
Ложка дёгтя
Несмотря на простоту и удобство этот подход наследует часть недостатков сети Tor.
Можно было бы понадеяться что администраторы таких узлов не будут следить за вами из соображений их собственного крепкого ночного сна, но.
Если вы заходите на какой-то сайт по незащещённому соединению, через Tor ли напрямую, нужно всегда иметь ввиду что ваши логины и пароли в принципе могут оказаться в папке с литерами на столке у человека в погонах.
Вот и все!
Параллельно с написанием данной статьи, 30 июля 2017 был опубликован документ, фактически запрещающий использование на территории России анонимайзеров и VPN-технологий, позволяющих обходить запрет на доступ к сайтам и информационным ресурсам, когда такой доступ ограничен в соответствии с законодательством Российской Федерации. К таковым, несомненно, относится и описываемая ниже технология. Владельцам VPN сервисов предлагается ограничить доступ к запрещенным сайтам. Кроме того операторы поисковых систем обязаны прекратить выдачу ссылок на сайты и информационные ресурсы, когда такой доступ ограничен в соответствии с законодательством Российской Федерации. Почти все нормы начинают действовать с 1 ноября 2017 года.
Думается, что ни у кого не возникает сомнений по поводу широкой распространенности действительно неприемлемого интернет-контента, способного оказать значительные негативные влияния на общество в целом и каждую отдельную личность в частности. Но, кроме того, несомненно, огромный интерес вызывает и степень соприкосновения последствий применения положений нового закона и статьи 23 Конституции РФ. А в сочетании с прочтением таких произведений, как "Мы" и "1984", дискуссия на эту тему может поддерживать свет в окнах долго за полночь. Авторы статьи сохраняют нейтральный статус в обсуждении данных проблем и не берутся оценивать моральные и философские аспекты использования Tor, равно как и причины использования подобных технологий. Статья старается осветить лишь техническую сторону обеспечения анонимности в сети.
Часть 1. Настройка Tor.
Даже удивительно, как просто организовать анонимный "серфинг" в сети Интернет с помощью Tor. Идем на официальный сайт и загружаем Tor Browser для Windows. Запускаем и пользуемся! На этом можно было и закончить статью, но легких путей мы не ищем, да и гораздо больший интерес представляет потенциальная возможность направления трафика приложений, отличных от браузеров, через сеть Tor, например сетевого сканера. А для этого нам необходимо будет установить "чистый" Tor без дополнительных компонентов. Называется он Expert Bundle. На момент написания настоящей статьи актуальная версия для Windows – 0.3.0.9. Скачанный архив распакуем для удобства в C:\tor-win32-0.3.0.9\. Далее запускаем tor.exe находясь в каталоге C:\tor-win32-0.3.0.9\Tor. Видим в логе строчки:
Как видите, Tor работает "из коробки". "Коробку" эту можно сравнить с автоматической, поскольку мы работаем с параметрами по умолчанию. Но мы можем перейти и на "ручное" управление. Для этого заглянем в рабочую директорию, наблюдаем две папки:
- Tor (здесь лежат библиотеки программы и сам исполняемый файл tor.exe)
- Data\Tor (здесь видим файлы geoip и geoip6 – база данных блоков IP-адресов с привязкой к географическому положению каждого блока; для версий IPv4 и IPv6 соответственно)
Существующий набор опций Tor достаточно обширен и рассмотреть их все не является целью данной статьи. Полный список и синтаксис команд (на английском языке) можно найти на сайте разработчиков.
Важный нюанс! Выходные сервера в Tor постоянно меняются случайным образом. Это означает, что ресурс, который мы посещаем, может в каждый момент времени видеть нас под разными IP-адресами из разных стран. Кроме параметра ExcludeExitNodes, устанавливающего запрет на использование выходных нод, у нас есть возможность прямо указывать, какой сервер (нод) должен быть выходным. IP-адрес в этом случае будет постоянным:
ExitNodes
StrictExitNodes 1
Где ExitNodes указывает определённый сервер в качестве выходного узла, а StrictExitNodes 1 – указание в случае недоступности выбранного сервера не пытаться подключиться к другому, а выводить ошибку.
Найти список выходных узлов можно по ссылке.
В качестве параметра, можем указать отпечаток узла:
Допускается записывать несколько узлов через запятую или, например, указав ExitNodes – получим только Российские сервера в качестве выходных. Притворимся русским хакером – в наши дни это тренд, не сбавляющий оборотов. Только не забудьте в параметре ExcludeExitNodes убрать значение , иначе возникнет конфликт.
После сохранения конфигурационного файла создадим ярлык для запуска Tor. Для того чтобы включить использование нашего конфигурационного файла запускать Tor необходимо с ключом -f, далее указав путь к файлу настроек. Пример для нашего варианта:
C:\tor-win32-0.3.0.9\Tor\tor.exe -f C:\tor-win32-0.3.0.9\Data\Tor\torrc
Запускаем ярлык. В папке C:\tor-win32-0.3.0.9\ должна появиться папка var, в которой помимо рабочих файлов Tor появится лог-файл notice.log. Все, что Tor выводит в консоль, будет писаться в этот файл для последующего анализа. В файле notice.log видим строчки:
Часть 2. Серфинг.
Нам остается настроить браузер для работы. Для этого в Firefox в меню настроек параметров соединения указываем в качестве прокси-сервера для доступа в интернет SOCKS5 сервер с адресом 127.0.0.1:9050.
Для настройки браузеров IE и Chrome нужно зайти в Свойства браузера [Подключения -> Настройка сети -> Дополнительно]. Аналогично укажем настройки SOCKS-сервера 127.0.0.1:9050
Во-первых, сервис сразу определил тот факт, что мы пользуемся сетью Tor. Поскольку база "выходных нод" является открытой, сделать это нетрудно. Кроме того, видна разница во временных зонах браузера и IP-адреса, а значит, нетрудно догадаться, что наш настоящий часовой пояс соответствует времени браузера. Данная проблема исправляется просто – сменой часового пояса или времени в операционной системе.
Во-вторых, сервис 2ip обнаружил утечку DNS. Она возникает, когда приложение отправляет DNS-запросы, используя DNS-серверы провайдера. Браузеры резолвят DNS-имена в обход Tor. Проверить наличие этой утечки можно здесь. При использовании SOCKS5 прокси в Firefox, такая утечка происходит. Чтобы от этого избавиться, нужно изменить настройку, определяющую, где будут выполняться DNS-запросы при использовании SOCKS5 [в адресной строке набираем about:config, находим логическую опцию network.proxy.socks_remote_dns, двойным кликом меняем значение на true], теперь при использовании SOCKS-прокси, DNS-запросы будут тоже ходить через SOCKS. Проверяем. Утечки DNS больше нет – мы перешли на использование публичных DNS-серверов.
Следующая проблема – утечка IP через Flash. При этом в нашем случае проблема была характерна для браузера Chrome. Не помогло включение в настройках контента Chrome опции "Блокировать Flash на сайтах". После чего был удален Adobe Flash Player, паранойя нарастала и был удален еще и Adobe Air. Зачем он только был установлен? Но проблему это не решило и упорно происходила утечка через Flash. Решить проблему с Chrome так и не удалось, было решено вывести этот браузер из испытаний. К тому же сервисы Google известны наиболее "прокачанной" системой сбора информации о пользователе, поэтому их использование противоречит принципам анонимности. Не зря разработчики Tor выбрали базой для разработки Tor Browser именно Firefox.
Последняя проблема, которую нам удалось обнаружить – утечка через WebRTC – протокол передачи потоковых данных между браузерами или другими, поддерживающими его приложениями, по технологии точка-точка. Работа ряда сервисов, таких как чат Gmail и Facebook, браузерного варианта Skype и многих других основана на этой технологии и без WebRTC эти службы не будут доступны в полном объёме. Сервис для проверки этой уязвимости (и не только) – WebRTC Leak Test. В нашем случае был виден локальный IP-адрес за NAT, а также белый IP-адрес маршрутизатора. Большой брат наблюдает. Для исправления проблемы в браузере Firefox введите about:config, найдите параметр media.peerconnection.enabled и установите значение FALSE.
Фух! Теперь кажется все. Хочется взять свои слова о простоте анонимного серфинга обратно. Вряд ли теперь мы сможем сказать, что это было просто! Стоит сказать о том, что Tor Browser избавлен изначально от описанных утечек анонимности и использование его для серфинга является более предпочтительным. Но ручная настройка позволила увидеть, какое количество проблем может возникать при попытке получить анонимность в сети. При этом, после пройденного пути, говорить о сто процентной анонимности при серфинге в сети вообще практически невозможно. Конечно, степень анонимности зависит не только от технической подготовки клиентской части, но и от возможностей ресурсов, на которые мы обращаемся. В любом случае необходимо внимательно относиться к технической стороне вопроса анонимности и пользоваться сервисами для проверки возможных утечек.
Направление трафика других приложений через цепочки серверов Tor мы рассмотрим в следующих статьях.
В случае, если у вас есть дополнительная информация о возможных утечках, не описанных в данной статье, пишите нам на адрес Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра. с пометкой "блог". Мы открыты для общения!
Реверс малвари
Сводная группа ученых из шведского Королевского технологического института, университета в Карлстаде и Принстонского университета представила новый метод атак, который получил имя DefecTor и способен помочь в деле деанонимизации пользователей Tor.
Исследователи пишут, что для реализации такой атаки наблюдающая сторона должна иметь возможность следить за трафиком в глобальных масштабах. К примеру, DNS resolver’ы Goolge обрабатывают около 40% DNS-запросов исходящих из Tor. И хотя пока Google не проявляется интереса к деанонимизации или саботированию Tor-трафика, в теории подобное возможно. Такие возможности есть и у компаний OVH и OpenDNS, хотя с масштабами Google им не сравниться.
Согласно данным исследователей, мониторинг DNS, в сочетании с известными техниками отслеживания пользователей при помощи различных цифровых отпечатков, сделают корреляционную атаку весьма эффективной. Изучение вопроса показало, что наибольший эффект атака DefecTor возымеет использовать против сайтов, которые посещают через Tor не слишком часто.
Ученые представили разработанный в рамках данного исследования инструмент ddptr (DNS Delegation Path Traceroute), который может использоваться для отслеживания всех путей делегирования для полных доменных имен, а затем, при помощи UDP, осуществлять трассировку для всех DNS-серверов маршрута.
Исследователи пишут, что на данный момент DefecTor нельзя назвать прямой угрозой сети Tor, ведь компании подобные Google и так способны мониторить значительную часть интернета. Тем не менее, исследователи рекомендуют операторам Tor relay не пользоваться публичными DNS резолверами (вроде тех, что предоставляют Google и OpenDNS), вместо этого полагаясь на проверенные решения или вообще поднимать резолверы самостоятельно.
Более подробная информация о DefecTor доступна на сайте исследователей. Также можно ознакомиться с отчетом, озаглавленным «Влияние DNS на анонимность Tor» (PDF).
Читайте также: