TOR общается с провайдером
Я поставил TOR и Privoxy на WinXPSP2.
Хожу по инету и смотрю в Ethereal.
Вижу, что идут частые (несколько в 10 минут) запросы DNS к моему провайдеру. Типа такие:
PTR xx.xxx.xx.xxx.in-abbr.arpa
response, PTR xxx-xxx-xxx-xx.vaslui.cablelink.ro
где х – цифра.
Домены в ответ возвращаются разные.
Соединения по этим адресам использует TOR.
Так и должно быть, или я что-то напутал?
комментариев: 44 документов: 3 редакций: 0
Помню, обсуждал с arma вопрос анонимизации DNS, и, что интересного, лишь корректно написанный клиент SOCKS 4a умеет разрешать DNS-запросы анонимным образом. Эта самая корректность реализации определяется лишь выбранной программистом политикой передачи параметра в функцию, так что анонимность DNS-запросов – дело очень шаткое. Даже не принимая во внимание, условно говоря, активное содержимое веб-страниц.
HTTP: localhost 8118
SSL: localhost 8118
FTP: null 8118
SOCKS: ничего не указано
Ниже выбран: SOCKS v5
No Proxy for: localhost, 127.0.0.1
Недавно я сменил Outpost на ZoneAlarm Pro. Собственно после этого и заметил, что пошли такие запросы. Это было вчера. Но я не уверен, что это началось вчера, может и раньше.
Но как я понимаю, это не запрос адресов, на которые я хожу браузером, а это TOR соединяется сам с этими адресами. Я не сольно разбираюсь в тонкостях. TCPView показывает, что это TOR держит соединения по этим адресам. Может это и есть узлы TOR?
Ситуация повторяется железно.
Насколько я понимаю запросы in-abbr.arpa – это запросы, цель которых по IP узнать Имя. Какая-то лабуда получается.
А когда FireFox ходит по сайтам, то DNS запросов по этому поводу нет.
комментариев: 44 документов: 3 редакций: 0
Возвращаясь к вопросу наличия механизма проверки синхронизации записей A (ассоциирующих IP-адрес с именем хоста) и PTR в ZoneAlarm, такая проверка имеет смысл и вполне себе практикуется, преимущественно на стороне сервера. Либо же PTR-запрос может использоваться для идентификации организации, ответственной за IP-адрес. В любом случае, считать это побочным эффектом я не склонен... Адреса же, с которыми устанавливает связь Tor, могут быть, кроме входного узла (entry node), серверами каталогов. Проверить утверждение по поводу севреров каталогов должно быть нетрудно...
PTR 1.0.0.199.in-addr.arpa
response, No such name
PTR 87.191.114.213.in-addr.arpa
response PTR c-57bf72d5.029-58-73746f48.cust.bredbandsbo1aget.se
PTR 102.191.140.150.in-addr.arpa
response PTR 1fme.chemeng.upatras.gr
PTR 114.0.244.18.in-addr.arpa
response PTR BELEGOST. MIT. EDU
PTR 102.158.169.81.in-addr.arpa
response PTR h3373.serverkompetenz.net
PTR 122.67.127.216.in-addr.arpa
response PTR galaxy.pton.co.pt
PTR 120.168.26.24.in-addr.arpa
response PTR CPE-24-26-168-120.mn.res.rr.com
PTR 28.132.37.195.in-addr.arpa
response PTR saeft1.franken.de
PTR 83.250.190.80.in-addr.arpa
response PTR www.bOred.de
К сожалению Outpost у меня 2-3 раза в неделю дает BSOD. Поиск в инете доказал, что у многих такая проблема.
комментариев: 44 документов: 3 редакций: 0
Полагаю, этот механизм используется в нём, к примеру, для контроля "взрослого" контента (если ZoneAlarm наделён такой функцией) или ещё каких-то высокоуровневых проверок.
Запросы, фигурирующие в Ethereal как A (порой AAA, AAAA), – это и есть нормальный DNS-запрос. При корректной настройке приложений на разрешение имён посредством Tor они скрыты. Но TCPView, судя по скриншоту на sysinternals.com/Utilities/TcpView.html, пытается выполнить разрешение имён, потому неудивительно, что A-запрос просачивается к Вашему ISP (TCPView ведь не соксифицирован).
комментариев: 73 документов: 1 редакций: 0
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 9796 документов: 488 редакций: 5664
В снифферах же всё видно. Любой DNS-пакет можно разобрать по содержимому.