How to become an author
Search
Write a publication
Pull to refresh

Comments 49

Сегодня изучал данный вопрос в связи с последними событиями.
Плохо что сетевое оборудование не очень активно продвигается в сторону DNSSEC.
Пришлось пускать DNS запросы через GRE туннель.
This comment wasn’t rated yet0
GRE туннель не шифрован и запросы продолжают пересылаться открытым текстом. В будущем ничто не мешает извлекать их из трафика каким-нибудь dpi. Тут VPN туннель подошел бы куда лучше, так как по умолчанию шифрован.
Total votes 1: ↑1 and ↓0+1
Из статьи не понял, поддерживают ли современные роутеры эти протоколы? Например, такой: EA9500
This comment wasn’t rated yet0

На данный момент, возможно, только кастомные прошивки поддерживают из коробки DNSCrypt. С другой стороны, можно под конкретную платформу самостоятельно компилировать. Я как-то собирал под EdgeRouter.


С другой стороны, вроде бы для v2 есть уже под большинство платформ
https://github.com/jedisct1/dnscrypt-proxy/releases


TomatoUSB, AsusWRT Merlin, DD-WRT и OpenWRT вроде бы все поддерживают.

This comment wasn’t rated yet0
Keenetic поддерживает «из коробки», я пользуюсь DNS over TLS на сервера cloudflare и google
Также ничего не мешает поднять DNS на своем собственном VPS у хостера и использовать его разместив впереди nginx который будет слушать 853 порт и проксировать запросы к локальному резолверу, например, так blog.ispsystem.info/2020/01/dns-over-tls-nginx-proxy-debian-9.html
This comment wasn’t rated yet0
Я профессиональный параноик. Моя модель угроз отличается от вашей, и я предпочел бы сохранить в безопасности как можно больше своих действий в онлайне. Но учитывая количество нынешних угроз приватности и безопасности из-за манипуляций с трафиком DNS, у многих людей есть веские основания использовать какую-либо форму шифрования DNS. Я с удовольствием обнаружил, что некоторые реализации всех трёх протоколов не оказывают сильно негативного влияния на скорость передачи трафика.

Я хоть и не сильно параноик, но когда обнаружил, что мой провайдер подменяет ответы других серверов для DNS запросов на, якобы, запрещённые сайты, то сразу понял, что пора что-то менять. В итоге выбрал dnscrypt-proxy, установил и забыл. Какой либо заметной просадки в скорости резолвинга не заметил, зато ответы DNS теперь правильные.
Total votes 2: ↑2 and ↓0+2

Простите, а как вы обнаружили, что провайдер подменяет запросы? Я тоже хочу так уметь! :)

Total votes 2: ↑2 and ↓0+2
Это стало заметно из-за того, что провайдер изначально реализовал блокировку только на своём DNS, и для её обхода достаточно было прописать любой другой DNS, кроме провайдерского. Но в какой то момент это перестало работать, и при резолве доменов из списка запрещённых, вместо реальных IPv4 записей прилетает адрес провайдерской заглушки, а вот IPv6 адреса не трогаются. Проверить можно просто выполнив команды «nslookup rutracker.cr днс.сервер.провайдера» и «nslookup rutracker.cr 8.8.8.8», если ответы будут отличаться, значит провайдер не подменяет ответы DNS и можно прописать в настройках интерфейса любой публичный DNS сервер.
Total votes 1: ↑1 and ↓0+1
если ответы будут отличаться, значит провайдер не подменяет

Может, наоборот? Ответы не должны различаться? Точно не опечатка?

This comment wasn’t rated yet0
Это наверное будет зависеть от конкретного провайдера. Если он DNS не фильтрует ни на своём сервере, ни в трафике, то ответы отличаться не будут, в обоих случаях в ответе окажется реальный адрес сайта (195.82.146.114 + 2a02:4680:22::214). Если он фильтрует на своём DNS, но не фильтрует в трафике, то в ответ на первый запрос будет IP заглушки/DPI, а во втором ответе будет реальный адрес сайта. Если он фильтрует и там и там, то в обоих ответах будет IP заглушки.
Total votes 2: ↑2 and ↓0+2

Спасибо за развёрнутый ответ :)

This comment wasn’t rated yet0
выполнив команды «nslookup rutracker.cr днс.сервер.провайдера» и «nslookup rutracker.cr 8.8.8.8», если ответы будут отличаться

Увы, много где отличаться они уже не будут. Провайдеры тупо перехватывают все по 53 порту.
Я если делаю запрос вида «nslookup rutracker.org любойсервер» в ответ в любом случае получаю ip адрес заглушки. решается только vpn или dnscrypt, или перечисленными в статье технологиями.
This comment wasn’t rated yet0
> Провайдеры тупо перехватывают все по 53 порту.
Но при этом всё «заворачивается» на свой DNS. Да, как раз DNSCrypt и призван помочь предотвращать такое. Но DNS-over-TLS, помимо этого, скрывает сами запросы. Остаётся только атака на TLS…
This comment wasn’t rated yet0
Программа Blockcheck умеет определять такие подмены, вроде как.
Total votes 1: ↑1 and ↓0+1
у меня часто сервера для dnscrypt перестают резолвить некоторые отечественные домены, на какое-то время, но обидно. Иногда просто падают, и нужно менять сервер из списка предлогаемых, проблема тут получается следующем — нужно получить новый список серверов dnscrypt, а у тебя не резолвит ничего -> отключаешь dnscrypt-proxy -> получаешь список серверов -> включаешь dnscrypt-proxy. так себе схема которую прихоить проделывать на моем роутере
This comment wasn’t rated yet0
Хм, я вот смотрю, что в конфиге указано кеширование списка резолверов в файл «public-resolvers.md», и их там много, вряд ли все разом перестанут быть доступны. Ещё в конфиге вижу опцию fallback_resolver, и судя по описанию, она как раз используется для запроса список резолверов в случае если закешированный список отсутствует.
This comment wasn’t rated yet0

при использовании dnscrypt на openwrt частенько не резолвились домены третьего уровня. В итоге ломались некоторые сайты, например нельзя было скачать драйвер с сайта nvidia. Может конечно я что-то не так настроил, но прописывать домены в исключения в итоге надоело

This comment wasn’t rated yet0
используемое в соединениях HTTPS, всё равно может показать открытым текстом название сайта


А если используется QUIC/SPDY?
This comment wasn’t rated yet0
Сначала автор пишет:
Он также обещает полностью скрыть DNS-трафик от посторонних глаз, используя шифрование.
А потом такое:
Тем не менее, важно отметить, что одно лишь шифрование DNS не скроет ваши действия в интернете. Если на сервере хостятся несколько сайтов, то расширение TLS под названием Server Name Indicator (SNI), используемое в соединениях HTTPS, всё равно может показать открытым текстом название сайта, на который вы зашли.
А потом продолжаем прятать трафик DNS. Не странно ли?

Кроме того, вот эта формулировка: Если на сервере хостятся несколько сайтов... неверна, ибо решает отправлять в заголовке SNI или нет, решает браузер, а не сервер. И современные HTTPS-клиенты, включая браузеры, сначала пробуют создать соединение указывая домен.

Так что, если хотите конфиденциальности, то нужно заворачивать весь трафик в туннель.
Total votes 3: ↑3 and ↓0+3

… и конфиденциальность закончится на выходе из туннеля.


Если известен IP юзера и IP сайта, то конфиденциальности уже нет — без SNI на данном IP может быть ровно один сайт, так что достаточно скачать его сертификат и там будет его имя (ну или через reverse DNS посмотреть), а со SNI имя сайта необходимо передать до того, как можно будет установить надёжное шифрование, а значит MitM всегда сможет его перехватить, даже если бы его пытались шифровать (это в ответ на коммент Garrett выше насчёт QUIC/SPDY — вряд ли там это смогли решить, это не проблема конкретного протокола).


Хотите конфиденциальности — I2P или Tor, там крайне сложно связать IP юзера и IP сайта.


А что касается DNS — его шифровать бессмысленно, по вышеописанным причинам. А вот обеспечить защиту от поддельных ответов — стоит.

This comment wasn’t rated yet0
Не ну почему, шифровать DNS иногда имеет смысл, не сильно большой но например:
Если собственный провайдер собирает данные по вашему трафику из DNS запросов как через их DNS сервера так и через DPI (судя по комментариям к оригинальной статье, актуальная вещь в США), то шифрование DNS трафика этот род деятельности как раз таки пресекает. Другое дело что SNI все равно всё палит =)
Total votes 1: ↑1 and ↓0+1
Чтобы завернуть весь трафик в туннель, нужно сначала подключиться к этому туннелю. Обычно это происходит через резолвинг DNS-имени сервера, обеспечивающего туннелирование типа vpn.example.com. То есть по дефолту минимум один DNS-запрос уйдёт открытым текстом.
This comment wasn’t rated yet0
Ну и пусть уйдёт. Что это показывает помимо того, что имярек пользуется VPN? Провайдер это и так знает, видя, на какие IP-адреса идут от клиента пакеты.
This comment wasn’t rated yet0
IP-адреса знает, например, что они Amazon принадлежат. А вот какому сервису здесь и сейчас не знает в общем случае.
This comment wasn’t rated yet0
stubby включён в репозитории debian и ubuntu, как минимум, так что скорее надо говорить об отсутствии поддержки со стороны производителей некоторых ОС, а не о полном отсутствии поддержки.

А проблемы с табами — это не особенность парсера stubby (libyaml), а требование стандарта yaml: «Note that indentation must not contain any tab characters.».
This comment wasn’t rated yet0
Несколько лет уже ноем чтобы mikrotik запилили пакет dnscrypt, но в ответ тишина(
This comment wasn’t rated yet0
на банальном роутере от xiaomi с прошивкой падаван и то dnscrypt есть :)
This comment wasn’t rated yet0
А как насчет связки Mikrotik+MetaROUTER+OpenWRT+DNSCrypt?
This comment wasn’t rated yet0

Вряд ли его кто-то специально блокирует. Просто в некоторых сетях распространена практика использовать этот адрес для внутренних целей.

Total votes 2: ↑2 and ↓0+2
Кто-нибудь рассматривал Nearby Connections 2.0? Кажется это становится актуальным.
This comment wasn’t rated yet0

Я что то не понимаю как шифровка DNS запросов СКРЫВАЕТ о провайдера посещаемые сайты ?? От подмены да спасает, но остальной трафик кроме DNS запросов же не шифруется или шифруется по HTTPS, но источник его всё равно известен!!! IP адрес же не шифруется.

This comment wasn’t rated yet0
На одном IP могут сидеть куча сайтов.
Другое дело, что РосКомНадзор в войне с Телеграмом (вернее, с самим собой) блочит именно диапазоны IP-адресов, а не сайты, в этом вся проблема.
Здесь поможет VPN или простой и доступный Tor.
Ну и чтобы зайти на сайт, надо (системе) сначала узнать его IP, а как это сделать, если провайдер DNS-запрос блочит/подменяет или редиректит на заглушку? А шифровка DNS просто скрывает DNS-запросы. Абырвалг по UDP на такой-то IP, и в ответ Йопрст по UDP. Провайдер не знает, куда вы хотите зайти, всё норм.
This comment wasn’t rated yet0
Если сидит куча сайтов то хост шлется в открытом виде, в вике описано это, если 1 сайт то не шлётся но тогда легко вычисляется и так.
This comment wasn’t rated yet0

В случае HTTP шлётся в открытом виде, для TLS со SNI (например HTTPS) хост шл'тся в зашифрованном. Собственно отсюда баны по IP в случае Телеграма.

This comment wasn’t rated yet0

Оно и не скрывает куда ты ходишь. Оно скрывает запрос (а лучше маскирует под другой тип трафика) по 53 udp на получение ip адреса с днс сервера, которое могут перехватывать/подменять и применить разнообразные другие манипуляции. Например весь 53 udp пропускать через себя и на некоторые сайты выдавать адрес загрушки или фейковый сайт злоумышленника. Например при днс через https днс запросы провайдер от тебя не увидит вовсе, а будет видеть белибербу по https, как обычный веб траффик. В статье же есть информация и некоторые решаемые таски. Ну и стоит помнить, что запрос на конкретный ip ещё значит запрос на конкретный сайт. Их может быть много на одном адресе к примеру, они могут быть спрятаны за клаудфлеир к примеру. Да и не будет запросов минуя средства прокси/vpn/…. Если надо скрыть всё — то нужно много инструментов в связке. dnssec лишь один из них. Сам по себе он анонимности не даст, а от некоторых проблем может избавить.

This comment wasn’t rated yet0
SNI всё спалит за Вас :) Его шифрование только планируется в новом стандарте. Большие DPI умеют бигдату и нейросети, спокойно вычислят куда вы ходили на основе других, без шифрованного DNS.
This comment wasn’t rated yet0
Похоже на то, что основной месседж статьи — пока поддержка не будет встроена в каждый DNS клиент (в том числе в обычных свичах), о каком-то качественном решении проблемы говорить не стоит.
This comment wasn’t rated yet0
Но всегда есть некоторые решения, которые можно уже использовать
Скриншот

This comment wasn’t rated yet0
Плохо, что гораздо более правильный и менее ёмкий DNSCurve никак не освещён.
This comment wasn’t rated yet0
Простите за чайниковский вопрос, но возможно ли сделать настройку таким образом, чтобы имена местных национальных доменов резолвелись через провайдерские DNS, а все остальные уже через сабжевый сервис? (*.ru, *.рф, *.рус в России, *.ua, *.укр, в Украине) Просто так ИМХО будет убедительнее прикидываться «Неуловимым Джо» для местных властей.

Вообще, наблюдаю такую тенденцию: чем дальше этот мир сходит с ума, тем сложнее программная часть сетевой подсистемы для комфортного использования Интернет. Причём в некоторых случаях уже настолько, что её имеет смысл выносить на физически отдельную машину. Но если дома можно поставить маршрутизатор с кастомной прошивкой и настройками под себя любимого, то что будет с ноутбуками? Не начнут ли производители в скором времени встраивать отдельный SoC с собственной ОС для управления всей сетевой подсистемой ноута, тунеллирования, шифрования трафика (как вам идея)?
This comment wasn’t rated yet0
С помощью дополнительных тулзовин можно. Как минимум, с помощью локально поднятого полноценного DNS сервера.
This comment wasn’t rated yet0
Sign up to leave a comment.

Articles

Show the best of all time

Your account

Sections

Information

Services

Support
© 2006–2024, Habr