Архитектура системы доменных имен (DNS) за редким исключением остается неизменной с 1983 года. Каждый раз, когда вы хотите открыть сайт, браузер отправляет запрос с указанием домена на DNS-сервер, который в ответ отправляет необходимый IP-адрес. И запрос, и ответ на него передаются в открытом виде, без какого-либо шифрования. Это значит, что ваш провайдер, администратор сети или злоумышленник c MITM могут не только хранить историю всех запрошенных вами сайтов, но и подменять ответы на эти запросы. Звучит неприятно, не правда ли?
Предлагаю вспомнить несколько реальных историй перехвата и подмены DNS-запросов.
DNS hijacking
Перехват DNS-запросов (DNS hijacking) это не какая-то редкая страшилка, а вполне распространенная практика. Например, среди провайдеров. Обычно это работает следующим образом. Если пользователь пытается перейти на несуществующий сайт, то провайдер перенаправляет его на свою страницу с рекламой. А может и не на свою.
Американский провайдер Earthlink в 2006 году стал перенаправлять пользователей и информацию об их запросах рекламному партнеру Barefruit. Особенно плохо это выглядело в том случае, если пользователь запрашивал несуществующий домен известного сайта, например, webmale.google.com. Пользователь видел рекламу и контент, которые не имели ничего общего с google.com в адресной строке.
Подобная практика явно нарушает стандарт RFC для DNS-ответов и делает пользователей уязвимыми для XSS-атак. К примеру, исследователь Дэн Камински продемонстрировал уязвимость, которая позволяла встраивать в Facebook или PayPal мошеннические фреймы.
Вы, конечно же, можете отказаться от использования DNS-сервера провайдера и прописать в настройках роутера сторонние решения (например, Google Public DNS или Яндекс.DNS). Но при отсутствии шифрования это никак не решит проблему. Провайдер вполне может вмешаться и здесь, подменив ответ на свой.
Если уж провайдеры научились зарабатывать на подмене DNS-ответов, то что говорить о мошенниках. В 2007 году группа предприимчивых людей из Эстонии создала троян DNSChanger, который за несколько лет заразил 4 млн компьютеров по всему миру. Троян изменял системные настройки DNS, что приводило к появлению рекламы на веб-страницах. Это принесло создателям $14 млн и тюремный срок. Причем самое удивительное в этой истории то, что по решению суда пришлось в течение 7 месяцев поддерживать временные DNS-сервера по тем адресам, где располагались сервера мошенников. Если бы они это не сделали, то пользователи зараженных устройств одномоментно лишились бы доступа в сеть.
Масштабы трояна DNSChanger впечатляют, но бразильцы его переплюнули. 4,5 млн DSL-модемов было взломано в одной только Бразилии в 2011-2012 годах. Для этого было достаточно разослать спам со ссылкой на вредоносную страницу, которая взламывала модем и прописывала новый адрес DNS-сервера. Причем в этот раз мошенники не стали мелочиться с рекламой. На своих подставных DNS-серверах они подменяли адреса для всех крупнейших банков Бразилии.
С домашними и офисными WiFi-роутерами дело обстоит так же печально, как и с бразильскими модемами. Пользователи нередко оставляют заводские логин и пароль на админку, да и за выходом свежих прошивок с исправленными уязвимостями не следит почти никто (кроме читателей Хабра, конечно же). В прошлом году исследователи из Sentrant в своем докладе рассказали о новых случаях взлома роутеров. Мошенники перехватывали обращения к Google Analytics и благодаря этому встраивали на сайты рекламу.
Думаю, с примерами перехвата можно закончить. Вывод тут простой: DNS перехватывают много, на разных этапах и с разной целью.
DNSCrypt
Разработчики популярного сервиса OpenDNS предложили решение проблемы еще несколько лет назад. Они создали опенсорсную утилиту DNSCrypt и одноименный протокол, который играет для DNS-запросов такую же роль, как и SSL для HTTP.
Во-первых, DNSCrypt зашифрует с помощью стойкой эллиптической криптографии сообщения между вашим компьютером и DNS-сервером. Это защитит их от прослушки и MITM.
Во-вторых, вы больше не привязаны к серверу провайдера или настройкам своего роутера. DNSCrypt обращается за адресами напрямую на указанный вами сервер.
До сих пор для применения DNSCrypt пользователям было необходимо установить на компьютер отдельную утилиту. Это не сложно, но без широкого распространения знаний об угрозе и способах ее решения вряд ли стоит рассчитывать на массовое применение технологии.
Поддержка DNSCrypt в Яндекс.Браузере
Наша команда считает шифрование DNS не менее важным, чем переход на HTTPS, поэтому мы решили поддержать DNSCrypt на уровне Яндекс.Браузера. И сегодня мы начинаем тестирование новой бета-версии Яндекс.Браузера 16.4, пользователи которой могут включить в настройках защиту DNS-запросов.
При этом все запросы в зашифрованном виде будут отправляться на быстрый DNS-сервер Яндекса, который также получил поддержку протокола DNSCrypt. Ограничивать пользователей только одним сервером мы не хотим, поэтому уже в ближайшее время добавим в этом месте возможность выбрать альтернативный DNS-сервер (например, тот же OpenDNS).
И еще кое-что. Подменить IP-адрес на фишинговый можно не только через перехват запроса, но и через самый обычный системный host-файл. Поэтому мы сейчас экспериментируем с запретом использовать системный резолвер в случае недоступности DNS-сервера. Мы понимаем, что включение этой опции по умолчанию может навредить пользователям корпоративных и локальных ресурсов, поэтому пока только наблюдаем и собираем отзывы.
Установить бету вы можете с browser.yandex.ru/beta. Нам было бы интересно узнать мнение сообщества.
Комментарии (53)
dartraiden
29.03.2016 16:59+1например, тот же OpenDNS
Который точно так же, как Google или Яндекс, логгирует DNS-запросы с целью анализа предпочтений пользователей.
Лучше уж выбрать один из серверов, поддерживаемых энтузиастами, который не ведёт журнал запросов: github.com/jedisct1/dnscrypt-proxy/blob/master/dnscrypt-resolvers.csv
А вот защита против подмены DNS-серверов зловредами — это хорошо. Но ещё лучше, добавить на роутере правило файерволла, заворачивающего на роутер весь клиентский трафик по 53 порту. В таком случае, независимо от того, какой DNS указан в свойствах сетевого подключения у клиента, все DNS-запросы будут поступать на роутер. А уже там можно и DNSCrypt поднять, если нужно, или просто использовать DNS провайдера.
brun4eg
29.03.2016 17:07+5Ну, мы же написали, что не планируем ограничивать пользователей только Яндекс.DNS серверами. В настройках можно будеть выбрать любой сервер из этого списка.
Merkushov
29.03.2016 17:26+1А как насчёт обратной ситуации? Пользователи dnscrypt-proxy смогут подключаться к ресолверу Яндекса?
brun4eg
29.03.2016 17:32+5Могут:
resolver-address=77.88.8.78:15353 provider-name=2.dnscrypt-cert.browser.yandex.net provider-key=D384:C071:C9F7:4662:AF2A:CCD5:7B5D:CC97:14D4:07B6:AD36:01E1:AEDC:06D5:6D49:6327
Meklon
29.03.2016 17:30+1Если я хочу на виртуальной машине поднять локальный dnscrypt, то где искать мануал? И к какому серверу снаружи цепляться?
dartraiden
29.03.2016 17:41+3Клиентский софт под разные ОС и мануал по настройке в Unix: https://www.dnscrypt.org
В Windows удобнее всего запускать в виде службы, один из клиентов это умеет.
Мануал по настройке на OpenWRT, который я переводил с английского: https://wiki.openwrt.org/ru/inbox/dnscrypt
Цепляться можете к любому серверу с поддержкой DNSCrypt: https://github.com/jedisct1/dnscrypt-proxy/blob/master/dnscrypt-resolvers.csv (я выбрал себе сервер географически поближе и без логгирования запросов). Или вон к серверу Яндекса.
zabbius
29.03.2016 18:50+1спасибо, настроил свой openwrt
dartraiden
29.03.2016 18:57+1Добавьте ещё в Network > Firewall > Custom Rules (или в /etc/firewall.user, что одно и то же)
iptables -t nat -I PREROUTING -p tcp --dport 53 -j REDIRECT --to-ports 53
iptables -t nat -I PREROUTING -p udp --dport 53 -j REDIRECT --to-ports 53
Во-первых, это защитит от малвари, подменяющей у клиентов адрес DNS-сервера, во-вторых, защитит от утечки DNS в Windows 10. Весь клиентский DNS-трафик (по 53 порту) будет принудительно завёрнут на роутер.zabbius
30.03.2016 12:39Это мне как раз не критично, виндов у меня почти нету дома, наоборот иногда nslookup юзаю с кастомным сервером.
Meklon
29.03.2016 18:52+1Вроде разобрался. Кстати, у меня openNIC почему-то .lib не разрешает. Или я чего-то не понял?
meklon@meklon-desktop:~$ dig @89.111.13.60 http://flibusta.lib/ ; <<>> DiG 9.9.5-11ubuntu1.3-Ubuntu <<>> @89.111.13.60 http://flibusta.lib/ ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 60226 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;http://flibusta.lib/. IN A ;; AUTHORITY SECTION: . 3600 IN SOA ns0.opennic.glue. hostmaster.opennic.glue. 2016032914 1800 900 604800 3600 ;; Query time: 232 msec ;; SERVER: 89.111.13.60#53(89.111.13.60) ;; WHEN: Tue Mar 29 18:39:14 MSK 2016 ;; MSG SIZE rcvd: 100dartraiden
29.03.2016 18:59+1У меня разрешает, но я сейчас использую просто один из серверов OpenNIC (91.214.71.181), без поддержки DNSCrypt.
Meklon
29.03.2016 19:00+1Я сейчас напрямую запросил из консоли… А что отвалилось-то, интересно. Можете свою консоль показать?
dartraiden
29.03.2016 19:07+1Так может, сервер конкретный просто не поддерживает Namecoin-домены?
Meklon
29.03.2016 19:10+1Перебрал те, что висят на главной странице. Вы какой используете?
dartraiden
29.03.2016 19:13+1Ближайшие ко мне
91.214.71.181
89.111.13.60
Консоль покажу чуть позже.dartraiden
29.03.2016 19:32+1Без http:
root@ubuntu:/home/test# dig @89.111.13.60 flibusta.lib
; <<>> DiG 9.9.5-11ubuntu1-Ubuntu <<>> @89.111.13.60 flibusta.lib
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17714
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;flibusta.lib. IN A
;; ANSWER SECTION:
flibusta.lib. 86366 IN A 81.17.19.227
;; Query time: 2 msec
;; SERVER: 89.111.13.60#53(89.111.13.60)
;; WHEN: Tue Mar 29 09:31:55 PDT 2016
;; MSG SIZE rcvd: 57
root@ubuntu:/home/test# dig @91.214.71.181 flibusta.lib
; <<>> DiG 9.9.5-11ubuntu1-Ubuntu <<>> @91.214.71.181 flibusta.lib
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18675
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;flibusta.lib. IN A
;; ANSWER SECTION:
flibusta.lib. 86320 IN A 81.17.19.227
;; Query time: 2 msec
;; SERVER: 91.214.71.181#53(91.214.71.181)
;; WHEN: Tue Mar 29 09:32:41 PDT 2016
;; MSG SIZE rcvd: 57
hobbyte
29.03.2016 19:16+1http уберите.
$ dig flibusta.lib @89.111.13.60 +short
81.17.19.227dartraiden
29.03.2016 19:27+1Жаль только, что на .lib доступны не все книги, как и на "обычном" домене. Иногда можно наткнуться на "Доступ к книге ограничен по требованию правоторговца". На .onion и .i2p доменах, например, доступны все книги. Я писал администрации, но, видимо, нужно активнее тормошить, одного раза мало.
dime
30.03.2016 07:35+1Так это сделано специально против наездов копирастов. Хотя, с тех пор, как их блокируют, возможно, это потеряло смысл.
dartraiden
30.03.2016 15:03Тогда я не совсем понимаю логику.
flibusta.is — книги недоступны. Ок, против наездов, это понятно. Основной домен.
flibustahezeous3.onion и flibusta.i2p — все книги доступны
flibusta.lib — недоступны
Мне видится, что .lib ближе к .onion и .i2p. В том смысле, что для доступа к доменам в этих зонах нужен спецсофт (EmerCoin, Tor, I2P). Тогда логично и доступ к книгам там тоже сделать полный.
Meklon
29.03.2016 19:29+1О. Отлично, спасибо. Тогда надо их сервера прописать. И домены вне ICANN и DNSCrypt сразу.
hobbyte
29.03.2016 19:36+1Браузеры сейчас слишком "фрэндли".:) Видишь чистый адрес, а копируешь — .
Meklon
29.03.2016 19:46+1Firefox этим не страдает вроде) У меня другая фигня, на Mikrotik прописаны эти DNS, но lib не разрешает. Остальные адреса работают. Mikrotik кэширует запросы. Если локально поменять DNS, то все работает.
Meklon
29.03.2016 19:51+1
В динамических серверах висят сервера Ростелекома, что странно. Хотя вроде заданы openNIC.
grumbler66rus
06.04.2016 08:21Это потому, что «http: // flibusta.lib /» не является доменным именем, а в DIG нет проверки допустимости доменного имени.
Вот корректный запрос:
[root@mail mail]# dig @89.111.13.60 flibusta.lib ; <<>> DiG 9.9.8-P4 <<>> @89.111.13.60 flibusta.lib ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35962 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;flibusta.lib. IN A ;; ANSWER SECTION: flibusta.lib. 86381 IN A 81.17.19.227 ;; Query time: 46 msec ;; SERVER: 89.111.13.60#53(89.111.13.60) ;; WHEN: Wed Apr 06 10:17:17 YEKT 2016 ;; MSG SIZE rcvd: 46
hurtavy
29.03.2016 18:23+3Провайдер блокирует все DNS запросы, кроме как к своему серверу. Типа, для того, чтобы «защитить пользователей» (например, не пускать на оппозиционные сайты). Поможет ли DNSCrypt в этой ситуации?
BarakAdama
29.03.2016 18:41+6Запросы передаются в зашифрованном виде между браузером и сервером. Думаю, это должно защитить запрос от перехвата. Если скачаете бету и попробуете, то расскажите, пожалуйста.
ValdikSS
29.03.2016 21:42+150 на 50. У вышестоящего провайдера может оказаться DPI, который перехватит ваш запрос уже по URL.
Попробуйте Blockcheck.
igorddk
29.03.2016 21:39-2Когда для Linux выйдет Stable с подписью не в слабой SHA1 и чтобы ещё не нужно было зонды выковыривать и отключать из опасения что попал не в Chromium а на рекламный стенд с видеокамерами и аналитиками заглянул?
ValdikSS
29.03.2016 21:52+3Новость отличная, просто замечательная!
Не-TLD домены будут резолвится через системный резолвер, предусмотрели это?
Роутеры, кстати, до сих пор взламывают и прописывают DNS, которые проксируют сайты и добавляют рекламу. Один недоброжелатель скопировал мой сайт с моей почтой на IP, которые прописывает в качестве DNS во взломанных роутерах, и взломанные люди пишут об этом мне, т.к. на скопированном сайте не сменили почту.brun4eg
30.03.2016 10:27+2Так делать не совсем правильно, т.к. мы же не знаем, что это за домен, может человек у себя на роутере настроил DNSCrypt, который идёт в его же собственный DNS сервер, который умеет на эти домены тоже что-то отвечать.
Поэтому там логика такая: если NOT FOUND через DNSCrypt, то идём в системный резолвер.
Однако, скоро появится дополнительный флаг "Не использовать системный резолвер, если включен DNSCrypt".
Это слегка усилит приватность и позволит избежать ненужной утечки DNS запросов.ValdikSS
30.03.2016 11:43+1Ваш подход вполне правильный, мой вопрос заключался вообще в возможности открытия сайтов, о которых внешний резолвер не знает. Мне почему-то показалось, что с введением DNSCrypt, вы отказались от системного резолвера, но обрабатываете записи из hosts.
derwin
30.03.2016 11:00Позвольте узнать, а сервер DNS яндекса, к которому уходят запросы, случаем не имеет отношения к dns.yandex.ru ??
А то у меня заведён тикет в саппорт яндекса на тему его глючности — то и дело начинает валить ошибку на всё подряд "домен не найден" с редиректом на сайт яндекса. Я по этой причине отказался использовать данный сервис в корпоративной среде.
Яндекс тогда ответил "спасибо, знаем, сообщим", пока ещё не сообщали.
Tairesh
30.03.2016 12:24В собственно Chromium поддержку DNSCrypt с кастомными адресами DNS добавите? Или эта фича только для (уж простите) неприемлемого для меня Яндекс Браузера?
BarakAdama
30.03.2016 12:27+2Это зависит от желания Гугла, без которого ничего в Chromium попасть не сможет.
Antibug
30.03.2016 21:53-1Не путайте Chromium и Google Chrome.
BarakAdama
30.03.2016 23:05+2А я и не путаю. Проектом Chromium управляют сотрудники Google. И Chromium создается так, чтобы максимально просто собрать из него Google Chrome. Мы регулярно туда что-то коммитим, поэтому процесс знаем :)
altervision
А как сейчас с поддержкой самого DNSCrypt на DNS-серверах Яндекса?
Использую эти DNS-серверы для своих сайтов (через Яндекс.Почту для домена) и очень хотел бы узнать, поддерживают ли они такую защиту.
brun4eg
DNS сервера Яндекса, которые отвечают за почту для домена не нуждаются в DNSCrypt, т.к. эта защита предназначена для других целей — для защиты от подмены ответа на уровне провайдера, локальной сети, т.е. между клиентом и сервером. Применительно к хостингу почты или DNS для домена она непонятно зачем нужна.
Для подтверждения достоверности ответа DNS сервера используется другая технология DNSSEC
miron36357
А когда в DNS хостинге от Яндекса будет DNSSEC?