Использовать dns сервер с шифрованием dnscrypt яндекс браузер что это

dxdt.ru: занимательный интернет-журнал

Техническое: DNSCrypt на примере “Яндекс.Браузера”

Нередко спрашивают, что такое DNSCrypt и зачем это нужно. Некоторое время назад я уже писал про DNSCrypt, применительно к “Яндекс.Браузеру”, тогда речь шла о поддержке в бета-версии браузера. В этот раз посмотрим на технологию в подробностях, а “Яндекс.Браузер” послужит примером и источником лабораторных данных. Разбор пакетов я провожу в Wireshark, для которого написал небольшой парсер DNSCrypt (в терминологии Wireshark – это dissector, на языке Lua; штатного парсера DNSCrypt в Wireshark-е мне выявить не удалось).

DNSCrypt – это прокси-сервис, создающий защищённый канал между клиентским резолвером DNS и рекурсивным DNS-резолвером, исполняемым на сервере. У DNSCrypt, соответственно, две части: клиентская и серверная. Через трафик DNS, который штатно передаётся в открытом виде, могут утекать сведения о посещаемых сайтах. Кроме того, запросы DNS – распространённый вектор атак для подмены адресов. Замена адреса системного резолвера DNS на адрес подставного сервера является общим местом троянских программ уже много лет. То же самое относится к атакам на домашние роутеры. DNSCrypt позволяет зашифровать (а также – ограниченно защитить от подмены) и запросы, и ответы DNS. Предусмотрена возможность аутентификации сервера и клиента, но эта возможность не всегда используется. Вообще, тема сокрытия DNS-трафика (DNS Privacy) сейчас набрала заметную популярность. Кроме DNSCrypt, существует, например, протокол “DNS через TLS” (DNS over TLS – свежий RFC 7858, который, несмотря на некоторую “перевёрнутость”, выглядит не хуже DNSCrypt). Есть и другие разработки.

DNSCrypt. Протокол может использовать в качестве транспорта как TCP, так и UDP. На практике, предпочтение отдаётся UDP, если он доступен, но спецификация строго требует поддержки именно TCP (не UPD, поддержка которого опциональна). TCP, естественно, привлекает сессионной природой. Но UDP – гораздо быстрее, особенно для нагруженных сервисов. Из-за проблем с DDoS-атаками и некоторых других вопросов обеспечения безопасности, сейчас наметилось модное движение в сторону перевода максимального числа сервисов на TCP, это особенно касается DNS. Тем не менее, ниже я рассматриваю работу DNSCrypt только по UDP, так как это традиционный для DNS вариант. Рекомендованный номер (серверного) порта DNSCrypt – 443 (он обычно открыт в корпоративных сетях; практика использования 443/udp, например, является стандартной для целого ряда VPN и других сервисов; 443/tcp – это TLS/HTTPS, фундамент веб-сервисов). Впрочем, “Яндекс” в своей реализации DNSCrypt использует непривилегированный номер: 15353, вероятно, это связано с какими-то идеями по преодолению разнообразных сетевых барьеров.

Чуть подробнее о барьерах: никаких проблем с блокированием трафика DNSCrypt, при наличии такого желания у провайдера канала, не возникнет. Как будет ясно из описания ниже, этот протокол никак не пытается скрыть сам факт своего использования. В трафик данного протокола включаются стандартные маркеры, которые позволят обнаружить и зафильтровать пакеты даже на самом примитивном маршрутизаторе, с помощью нехитрого правила “в две строчки”. При этом, например, доступ для других TCP-сессий, работающих на 443 порту, сохранится.

В DNSCrypt установление сессии между клиентом и сервером начинается с обычного DNS-запроса, отправленного на адрес и соответствующий номер порта узла, который будет предоставлять функции резрешения (резолвинга) имён. Это запрос TXT-записи для имени специального вида (то есть, запрос уже можно легко зафильтровать). Например, в случае с сервисом “Яндекса”: 2.dnscrypt-cert.browser.yandex.net. Это специальное имя может быть не делегировано. Значение 2 – соответствует версии DNSCrypt. Актуальная версия – вторая. В ответ сервер должен прислать один или несколько сертификатов DNSCrypt (подчеркну: они не имеют никакого отношения к SSL-сертификатам).

На скриншоте – пакет с сертификатом от сервера DNSCrypt “Яндекса”.

Сертификат представляет собой набор из нескольких полей: версия сертификата, значение подписи, открытый ключ сервера, magic-байты для клиента (они послужат идентификатором клиентских запросов – сервер сможет понять, какой ключ использовать при ответе), серийный номер и срок действия.

Спецификация предполагает, что в составе сертификата сервер передаёт кратковременный открытый ключ. (Впрочем, в случае с сервером “Яндекса”, данный ключ не меняется, как минимум, с конца марта, когда была запущена бета-версия браузера с поддержкой DNSCrypt.) Подпись на сертификате должна генерироваться от другой пары ключей. Открытый ключ этой пары известен клиенту – он необходим для проверки подписи. Очевидно, подписывать сертификат тем же ключом, который используется в рамках сессии – бессмысленно. Я не проверял, проводит ли валидацию серверного сертификата “Яндекс.Браузер”. Дело в том, что в модели угроз, на которую ориентировано использование DNSCrypt в “Яндекс.Браузере”, валидация сертификата особого смысла не имеет, как и сравнение значения ключа с сохранённой копией (я вернусь к этому моменту ниже).

В качестве криптографических примитивов DNSCrypt использует конструкции из шифра Salsa20 (XSalsa20), хеш-функции Poly1305 (для реализации аутентифицированного шифрования) и алгоритм X25119-hsalsa20 для выработки общего сеансового ключа (алгоритм использует эллиптическую кривую Curve25119 и хеш-функцию hsalsa20). Эти конструкции разработаны Даниэлем Бернштейном (Daniel J. Bernstein) и давно получили признание как весьма добротные. Алгоритм получения общего секрета (сеансового ключа) математически родственен алгоритму Диффи-Хеллмана. Отмечу, что общий секрет в данном случае можно восстановить постфактум, если станет известен соответствующий секретный ключ из пары серверных (или клиентских) ключей, это позволит расшифровать ранее записанный трафик, именно поэтому спецификация рекомендует использовать кратковременные ключи.

Шифр XSalsa20 в режиме аутентифицированного шифрования требует nonce длиной 192 бита (24 байта). Повторное использование одного и того же сочетания ключа и nonce не допускается. Это связано с архитектурой шифра XSalsa20 – повторное использование nonce приведёт к утечке: прослушивающей стороне станет известно значение XOR от пары соответствующих открытых текстов. Поэтому nonce должно быть каждый раз новым, но не обязательно случайным. Параметр nonce в DNSCrypt присутствует в двух воплощениях: клиентской и серверной.

Посмотрим на зашифрованный клиентский запрос, отправляемый “Яндекс.Браузером”.

Первое поле запроса – это клиентское значение magic (Client query magic bytes): здесь используется часть открытого ключа сервера, полученная ранее. При необходимости, данные “магические байты” могут служить сигнатурой, позволяющей выбирать в трафике запросы, отправляемые к DNSCrypt;
Следующее поле – кратковременный клиентский открытый ключ (Client public key);
Клиентское значение nonce – 96 бит (12 байтов), половина от требуемого значения nonce для шифра XSalsa20 (согласно спецификации DNSCrypt, дополняется байтами со значением 0). Можно использовать тот или иной счётчик, “Яндекс.Браузер” так и поступает: cудя по всему, здесь передаётся 64-битное значение миллисекундного таймстемпа (время формирования запроса), к которому дописываются четыре байта псевдослучайных значений. На случай, если это действительно точное время, передаваемое в открытом виде, отмечу, что параметры дрейфа системных часов служат неплохим признаком, идентифицирующим конкретное аппаратное устройство, – то есть, могут быть использованы для деанонимизации;
Последнее поле – это сам зашифрованный запрос. Для шифрования используется общий секретный ключ, который вычисляется сторонами на основании переданных открытых ключей. В случае с клиентом – открытый ключ передаётся в пакете DNS-запроса (см. выше). “Яндекс.Браузер” следует стандартной практике и генерирует новую пару ключей (открытый/секретный) для X25119-hsalsa20 при каждом старте барузера. Для выравнивания данных на границу 64-байтового блока, как предписывает спецификация, используется стандартное дополнение (ISO/IEC 7816-4: 0x80 и нулевые байты в требуемом количестве).

Блок зашифрованных данных – это, скорее всего, результат использования функции crypto_box из библиотеки libsodium (либо NaCl, на которую ссылается спецификация DNSCrypt; libsodium – это форк NaCl). Я предположил, что 16-байтовый код аутентификации (MAC), который используется для проверки целостности сообщения перед расшифрованием, находится, вероятно, в начале блока. Впрочем, так как расшифровать данные я не пытался, то и определение расположения кода не столь важно. Для расшифрования можно использовать секретный ключ, который содержится в памяти во время работы браузера, но чтобы его извлечь – нужно некоторое время повозиться с отладчиком и дизассемблером.

Зашифрованный ответ, полученный от сервера:

(Нетрудно заметить, что ответ, представленный на скриншоте, поступил почти через пять секунд после запроса, почему так получилось – видимо, тема для отдельной записки.)

Пакет открывается magic, в данном случае, это байты, содержащие маркер ответа DNSCrypt (опять же, хорошая сигнатура для обнаружения трафика). Эти байты определены протоколом и должны присутствовать в начале всякого ответа сервера на запрос DNS-резолвинга;
Следующее поле – nonce (Response nonce). Поле содержит значение nonce, использованное сервером при шифровании данного ответа. Поле строится из двух равных частей, по 12 байтов: nonce из соответствующего клиентского запроса и серверное дополнение;
Заключительная часть пакета – зашифрованные данные ответа, формат аналогичен запросу.

Теперь вернёмся к модели угроз, на примере “Яндекс.Браузера”. Если в настройках браузера включено использование DNSCrypt, например, через серверы “Яндекса”, но доступ к соответствующему серверу заблокирован, то браузер (как и бета-версия) прозрачно, без предупреждений, переходит к использованию системного резолвера. Почему это лишает смысла необходимость валидации сертификатов серверов DNSCrypt? Потому что активная атакующая сторона, которая может подменять пакеты на уровне IP, для отключения DNSCrypt в браузере может просто заблокировать доступ к серверу, вместо того, чтобы тратить ресурсы на поделку ответов. Из этого можно сделать вывод, что модель угроз “Яндекса” не включает активную подмену пакетов на пути от сервера DNSCrypt к клиенту.

В качестве завершения, пара слов о том, как DNSCrypt относится к DNSSEC. DNSSEC – не скрывает данные DNS-трафика, но защищает их от подмены, вне зависимости от канала обмена информацией. В случае с DNSSEC – не имеет значения, по какому каналу получены данные из DNS, главное, чтобы ключи были на месте. DNSCrypt – скрывает трафик и ограниченно защищает его от подмены на пути от рекурсивного резолвера (сервиса резолвинга) до клиента. Если данные были подменены на пути к резолверу (или на самом сервере резолвера), а он не поддерживает DNSSEC, то клиент получит искажённую информацию, хоть и по защищённому DNSCrypt каналу. Серверы, предоставляющие DNSCrypt, могут поддерживать и DNSSEC.

Источник

Решаем проблему перехвата и подмены DNS-запросов. DNSCrypt в Яндекс.Браузере

Когда речь заходит о защите веб-трафика от перехвата и подмены, то на ум в первую очередь приходят протокол HTTPS или даже собственный VPN-сервер. К сожалению, многие забывают еще об одной незащищенной стороне, а именно о DNS-запросах. Сегодня я еще раз привлеку внимание к этой проблеме и расскажу о том, как мы решаем ее в Яндекс.Браузере с помощью технологии DNSCrypt.

Архитектура системы доменных имен (DNS) за редким исключением остается неизменной с 1983 года. Каждый раз, когда вы хотите открыть сайт, браузер отправляет запрос с указанием домена на DNS-сервер, который в ответ отправляет необходимый IP-адрес. И запрос, и ответ на него передаются в открытом виде, без какого-либо шифрования. Это значит, что ваш провайдер, администратор сети или злоумышленник c MITM могут не только хранить историю всех запрошенных вами сайтов, но и подменять ответы на эти запросы. Звучит неприятно, не правда ли?

Предлагаю вспомнить несколько реальных историй перехвата и подмены DNS-запросов.

Перехват DNS-запросов (DNS hijacking) это не какая-то редкая страшилка, а вполне распространенная практика. Например, среди провайдеров. Обычно это работает следующим образом. Если пользователь пытается перейти на несуществующий сайт, то провайдер перенаправляет его на свою страницу с рекламой. А может и не на свою.

Американский провайдер Earthlink в 2006 году стал перенаправлять пользователей и информацию об их запросах рекламному партнеру Barefruit. Особенно плохо это выглядело в том случае, если пользователь запрашивал несуществующий домен известного сайта, например, webmale.google.com. Пользователь видел рекламу и контент, которые не имели ничего общего с google.com в адресной строке.

Подобная практика явно нарушает стандарт RFC для DNS-ответов и делает пользователей уязвимыми для XSS-атак. К примеру, исследователь Дэн Камински продемонстрировал уязвимость, которая позволяла встраивать в Facebook или PayPal мошеннические фреймы.

Вы, конечно же, можете отказаться от использования DNS-сервера провайдера и прописать в настройках роутера сторонние решения (например, Google Public DNS или Яндекс.DNS). Но при отсутствии шифрования это никак не решит проблему. Провайдер вполне может вмешаться и здесь, подменив ответ на свой.

Масштабы трояна DNSChanger впечатляют, но бразильцы его переплюнули. 4,5 млн DSL-модемов было взломано в одной только Бразилии в 2011-2012 годах. Для этого было достаточно разослать спам со ссылкой на вредоносную страницу, которая взламывала модем и прописывала новый адрес DNS-сервера. Причем в этот раз мошенники не стали мелочиться с рекламой. На своих подставных DNS-серверах они подменяли адреса для всех крупнейших банков Бразилии.

С домашними и офисными WiFi-роутерами дело обстоит так же печально, как и с бразильскими модемами. Пользователи нередко оставляют заводские логин и пароль на админку, да и за выходом свежих прошивок с исправленными уязвимостями не следит почти никто (кроме читателей Хабра, конечно же). В прошлом году исследователи из Sentrant в своем докладе рассказали о новых случаях взлома роутеров. Мошенники перехватывали обращения к Google Analytics и благодаря этому встраивали на сайты рекламу.

Думаю, с примерами перехвата можно закончить. Вывод тут простой: DNS перехватывают много, на разных этапах и с разной целью.

Разработчики популярного сервиса OpenDNS предложили решение проблемы еще несколько лет назад. Они создали опенсорсную утилиту DNSCrypt и одноименный протокол, который играет для DNS-запросов такую же роль, как и SSL для HTTP.

Во-первых, DNSCrypt зашифрует с помощью стойкой эллиптической криптографии сообщения между вашим компьютером и DNS-сервером. Это защитит их от прослушки и MITM.

Во-вторых, вы больше не привязаны к серверу провайдера или настройкам своего роутера. DNSCrypt обращается за адресами напрямую на указанный вами сервер.

До сих пор для применения DNSCrypt пользователям было необходимо установить на компьютер отдельную утилиту. Это не сложно, но без широкого распространения знаний об угрозе и способах ее решения вряд ли стоит рассчитывать на массовое применение технологии.

Поддержка DNSCrypt в Яндекс.Браузере

Наша команда считает шифрование DNS не менее важным, чем переход на HTTPS, поэтому мы решили поддержать DNSCrypt на уровне Яндекс.Браузера. И сегодня мы начинаем тестирование новой бета-версии Яндекс.Браузера 16.4, пользователи которой могут включить в настройках защиту DNS-запросов.

При этом все запросы в зашифрованном виде будут отправляться на быстрый DNS-сервер Яндекса, который также получил поддержку протокола DNSCrypt. Ограничивать пользователей только одним сервером мы не хотим, поэтому уже в ближайшее время добавим в этом месте возможность выбрать альтернативный DNS-сервер (например, тот же OpenDNS).

И еще кое-что. Подменить IP-адрес на фишинговый можно не только через перехват запроса, но и через самый обычный системный host-файл. Поэтому мы сейчас экспериментируем с запретом использовать системный резолвер в случае недоступности DNS-сервера. Мы понимаем, что включение этой опции по умолчанию может навредить пользователям корпоративных и локальных ресурсов, поэтому пока только наблюдаем и собираем отзывы.

Источник

Яндекс.Браузер первым в мире обзавёлся поддержкой DNSCrypt

Яндекс.Браузер будет защищать пользователей от любого рода мошенничества, связанного с подменой сайтов. Обновлённая система защиты основывается на внедрении технологии DNSCrypt, обеспечивающей безопасный обмен данными между браузерами и серверами DNS. Ранее такая технология не применялась в подобных программах. Суть работы DNSCrypt заключается в следующем: при открытии сайта пользователем, браузер отправляет его доменное имя на DNS-сервер провайдера и получает в ответ понятный ему числовой IP-адрес. Обычно браузеры и серверы DNS обмениваются данными без шифрования, что позволяет мошенникам перехватывать и подменивать их, отправляя людей на сторонние ресурсы. Нередко злоумышленники даже взламывают домашние роутеры с целью смены адреса сервера DNS.

Благодаря разработанной компанией OpenDNS технологии DNSCrypt возможность совершения подобных противоправных действий со стороны сетевых жуликов сводится практически к нулю: во-первых, все запросы к DNS-серверу и его ответы шифруются, что не позволяет подменить их; во-вторых, браузер направляет запросы не на тот DNS-сервер, который указан в настройках роутера или компьютера, а на сервис Яндекс с поддержкой DNSCrypt. Таким образом, пользователи не окажутся на сайтах мошенников, даже если те заменят адрес DNS-серверов на их устройствах.

Для защиты от подмены сайтов нужно обновить Яндекс.Браузер и выбрать настройках опцию «Всегда использовать защищенный DNS-сервер Яндекса с шифрованием DNSCrypt».

Подробнее о технологии можно узнать из блога компании.

Источник

В «Яндекс.Браузер» добавили DNS-шифрование для защиты от мошенников

«Яндекс.Браузер» теперь оснащен технологией DNSCrypt, говорится в сообщении компании.

Теперь все запросы от браузера направляются на безопасный DNS-сервер «Яндекса». Кроме того, DNSCrypt шифрует все данные, которыми обмениваются браузер и DNS-сервер. «Благодаря шифрованию перехват трафика становится бесполезен — не имея ключа, перехватчик вместо доменных имён и IP-адресов будет видеть лишь бессмыслицу», — сказано в сообщении.

Информация, которой обмениваются браузер и DNS-сервер, никак не защищена, и её довольно легко перехватить, говорят в «Яндексе». Например, перехватив DNS-трафик, можно узнать, какие сайты вы посещаете. Злоумышленники также могут взломать домашний роутер и заменить адрес DNS-сервера в настройках. Мошеннический DNS-сервер может давать неправильные IP-адреса — по его вине вместо интернет-банка можно оказаться на фишинговом сайте.

Протокол DNSCrypt разработала компания OpenDNS, запустившая в 2006 году одноимённый DNS-сервис. Ранее для того, чтобы включить защиту DNSCrypt, требовалось установить на компьютер специальную утилиту, сказано в сообщении. Теперь для пользователей последней версии «Яндекс.Браузера» достаточно включить DNSCrypt в настройках. Доступно для операционных систем Windows и OS X.

Включение DNSCrypt в настройках Яндекс.Браузера

Источник

HackWare.ru

Этичный хакинг и тестирование на проникновение, информационная безопасность

Как включить DNS через HTTPS и для чего это нужно

Оглавление

Такие компании, как Microsoft, Google и Mozilla, продвигают DNS через HTTPS (DoH). Эта технология будет шифровать поисковые запросы DNS, улучшая конфиденциальность и безопасность в Интернете. Давайте познакомимся поближе с технологией DNS Over HTTPS, узнаем, для чего она нужна и как её включить. Вполне возможно, что вы уже пользуетесь DNS через HTTPS даже не зная этого!

Что такое DNS через HTTPS (DoH)?

Интернет стремится, чтобы по умолчанию шифрование присутствовало везде. На данный момент большинство веб-сайтов, к которым вы обращаетесь, вероятно, используют шифрование HTTPS. Современные веб-браузеры, такие как Chrome, теперь помечают любые сайты, использующие стандартный HTTP, как «небезопасные». HTTP/3, новая версия протокола HTTP, имеет встроенное шифрование.

Это шифрование гарантирует, что никто не сможет вмешаться в работу веб-страницы, пока вы её просматриваете, или следить за тем, что вы делаете в Интернете. Например, если вы подключаетесь к Wikipedia.org, оператор сети — будь то общедоступная точка доступа Wi-Fi компании или ваш Интернет-провайдер — может видеть только то, что вы подключены к wikipedia.org. Они не видят, какую статью вы читаете, и не могут изменять статью Википедии пока она идёт до вашего компьютера.

Но в стремлении к шифрованию DNS остался позади. Система доменных имён делает так, что мы можем подключаться к веб-сайтам через их доменные имена, а не с помощью числовых IP-адресов. Вы вводите доменное имя, например google.com, и ваша система свяжется с DNS-сервером, который указан в настройках системы, чтобы получить IP-адрес, связанный с google.com. Затем ваш компьютер или телефон подключится к этому IP-адресу.

Смотрите также статьи:

До сих пор эти запросы DNS не были зашифрованы. Когда вы подключаетесь к веб-сайту, ваша система отправляет запрос о том, что вы ищете IP-адрес, связанный с определённым доменом. Любой посредник передачи данных — возможно, ваш интернет-провайдер, но, возможно, также просто общедоступная точка доступа Wi-Fi, записывающая трафик, — могут регистрировать, к каким доменам вы подключаетесь. Из-за этого возможны атаки и сбор информации, описанные в статье «Применение фальшивого DNS».

DNS через HTTPS делает этот надзор невозможным. При использовании DNS через HTTPS ваша система установит безопасное зашифрованное соединение с вашим DNS-сервером и будет передавать запрос и ответ через это соединение. Все, кто находится между ними, не смогут увидеть, какие доменные имена вы ищете, или вмешаться в присланный ответ.

Сегодня большинство людей используют DNS-серверы, предоставленные их интернет-провайдером. Однако существует множество сторонних DNS-серверов, таких как Google Public DNS, Cloudflare и OpenDNS. Эти сторонние поставщики одними из первых включили поддержку DNS через HTTPS на стороне сервера. Чтобы использовать DNS через HTTPS, вам потребуется как DNS-сервер, так и клиент (например, веб-браузер или операционная система), который его поддерживает.

Как соотносятся DNS поверх HTTPS, DNSSEC, DNSCrypt, DNS поверх TLS

Имеется несколько протоколов, обеспечивающих шифрование DNS запросов. В настоящее время на клиентском программном обеспечении лучше всего поддерживается DNS поверх HTTPS (DoH) — именно ему и посвящена данная статья. Чтобы ориентироваться в терминах, рассмотрим краткие характеристики каждого из протоколов.

DNS поверх HTTPS (DoH) — протокол для выполнения разрешения DNS по протоколу HTTPS. Целью этого метода является повышение конфиденциальности и безопасности пользователей путём предотвращения перехвата и манипулирования данными DNS с помощью атак типа «Атака посредника».

DNS поверх TLS (DoT) — предлагаемый стандартный протокол для выполнения разрешения удалённой системы DNS с использованием TLS. Целью этого метода является повышение конфиденциальности и безопасности пользователей путём предотвращения перехвата и манипулирования данными DNS с помощью атак типа «Атака посредника».

DNSSEC (англ. Domain Name System Security Extensions) — набор расширений IETF протокола DNS, позволяющих минимизировать атаки, связанные с подменой DNS-адреса при разрешении доменных имён. Он направлен на предоставление DNS-клиентам (англ. термин resolver) аутентичных ответов на DNS-запросы (или аутентичную информацию о факте отсутствия данных) и обеспечение их целостности. При этом используется криптография с открытым ключом.

DNSCrypt — это сетевой протокол, который аутентифицирует и шифрует трафик системы доменных имён (DNS) между компьютером пользователя и рекурсивными серверами имён. Первоначально он был разработан Фрэнком Денисом и Йеченг Фу.

Хотя существует несколько реализаций клиента и сервера, протокол никогда не предлагался Инженерной группе Интернета (IETF) в виде RFC.

DNSCrypt обёртывает неизмененный DNS-трафик между клиентом и преобразователем DNS в криптографической конструкции для обнаружения подделки. Хотя он не обеспечивает сквозную безопасность, он защищает локальную сеть от атак типа «злоумышленник в середине».

Он также снижает опасность атак с усилением на основе UDP, требуя, чтобы вопрос был не меньше размера соответствующего ответа. Таким образом, DNSCrypt помогает предотвратить атаки с усилением DNS.

DNSCurve — это предлагаемый безопасный протокол для системы доменных имён (DNS), разработанный Дэниелом Дж. Бернстайном.

Способы включения DNS через HTTPS (DoH)

Можно включить зашифрованные DNS запросы двумя способами — на уровне веб-браузеров и на уровне операционной системы. Каждый из этих способов имеет свои преимущества.

Включение безопасного DNS на уровне веб-браузеров выполняется очень просто, достаточно поставить галочку в настройках. Более того, в Google Chrome эта настройка уже включена по умолчанию. Недостаток этого метода в том, что все другие приложения, использующие Интернет-подключение, не смогут использовать DNS через HTTPS. Такими приложениями могут быть программы для скачивания файлов, мессенджеры, службы обновления программ и операционной системы и так далее.

Включение DoH на уровне системы делает так, что все программы будут делать DNS запросы исключительно по зашифрованному каналу. Но это требует установки программы — кэширующего DNS сервера. На самом деле, установка очень простая и программа будет потреблять минимум ресурсов. При этом собственный DNS будет кэшировать полученные данные благодаря чему немного увеличит скорость работы сети.

Какой вариант выбрать — исключительно на ваше усмотрение. В этой инструкции будут рассмотрены оба способа и вы увидите, насколько всё просто при выборе любого метода шифрования DNS запросов.

Публичные сервера имён с поддержкой DNS через HTTPS

Чтобы использовать DNS через HTTPS сервер имён должен поддерживать эту технологию. В настоящее время публичные самые популярные DNS серверы её поддерживают. Их адреса для DoH или обычных DNS запросов одинаковые.

Независимо от того, включаете вы DoH в браузерах или для всей системы, вы можете использовать любой DNS сервер из этого списка. Лично я предпочитаю DNS сервера от Google.

Как включить DNS через HTTPS (DoH) в веб-браузерах

Google Chrome

В Google Chrome в Windows уже включена опция DNS через HTTPS. Вы можете её проверить перейдя в «Настройки» → «Конфиденциальность и безопасность» → «Безопасность» → «Дополнительные» → «Использовать безопасный DNS сервер». Чтобы быстро найти эту настройку, введите в адресную строку «chrome://settings/security/» и пролистните в самый низ.

Вы можете выбрать из списка любой DNS сервер с поддержкой DoH или указать свой собственный.

На момент написания, в Google Chrome в Linux данная опция недоступна.

Firefox

Перейдите в Настройки → Основные. Пролистните в самый низ, чтобы найти кнопку «Параметры сети, Настроить».

Поставьте галочку «Включить DNS через HTTPS» и выберите провайдера из списка или введите свой IP адрес:

Opera

Перейдите в настройки (шестерёнка внизу левого сайдбара или кнопка «Простые настройки» → «Открыть все настройки браузера»).

Затем перейдите в «Дополнительно» → «Система».

Включите галочку «Использовать DNS поверх HTTPS вместо системных настроек DNS» и выберите желаемый DNS сервер.

Microsoft Edge

На момент написания предустановленный по умолчанию Internet Explorer (Microsoft Edge) вовсе не знает про DNS через HTTPS. Если скачать последнюю версию Microsoft Edge, то там эту настройку можно включить с помощью флага.

Введите в адресную строку edge://flags#dns-over-https

Включите экспериментальный флаг и перезапустите веб-браузер.

Эммм… вроде как нужно бы ещё ввести настройки DNS сервера, но я не нашёл, где это сделать в Microsoft Edge. Да и кому дело до Microsoft Edge — кто им вообще пользуется?!

Как включить DNS через HTTPS (DoH) для всех приложений

Программы для DNS через HTTPS (DoH)

dnscrypt-proxy

dnscrypt-proxy — это гибкий DNS-прокси с поддержкой современных зашифрованных DNS-протоколов, таких как DNSCrypt v2, DNS-over-HTTPS и Anonymized DNSCrypt.

У программы открыт исходный код, также программа доступна в виде предварительно скомпилированных двоичных файлов для большинства операционных систем и архитектур.

DNS-over-HTTPS

DNS-over-HTTPS — это клиентское и серверное программное обеспечение для запроса DNS через HTTPS, используя протоколы Google DNS-over-HTTPS и IETF DNS-over-HTTPS (RFC 8484).

Как включить DNS через HTTPS (DoH) на уровне операционной системы в Windows

Для операционной системы Windows мы можем использовать только dnscrypt-proxy, поскольку эта программа является кроссплатформенной.

Чтобы скачать dnscrypt-proxy для Windows, перейдите на официальную страницу https://github.com/DNSCrypt/dnscrypt-proxy/releases и скачайте файл вида dnscrypt-proxy-win64-*.zip

Распакуйте скаченный архив — в нём папка «win64». Переименуйте эту папку в «dnscrypt-proxy» и переместите в корень диска C:\. Таким образом, папка и все файлы расположены по пути C:\dnscrypt-proxy\.

Откройте командную строку с правами администратора. Для этого нажмите Win+x и выберите «PowerShell (администратор)».

Выполните там команды:

При запуске nscrypt-proxy загружает списки DNS серверов с шифрованием, тестирует доступность и скорость отклика DNS серверов с поддержкой шифрования.

Если всё запустилось нормально, то продолжайте, здесь же несколько подсказок для тех, у кого возникла ошибка:

Нет ошибок? Отлично!

Пока не закрывайте терминал. В дальнейшем мы установим dnscrypt-proxy как системную службу и нам не нужно будет каждый раз запускать её в командной строке. Но пока мы этого не сделали, dnscrypt-proxy будет работать только пока не закрыто окно консоли.

Теперь мы поменяем системные настройки DNS.

Откройте настройки сети, для этого нажмите Win+i, затем выберите «Сеть и Интернет».

И нажмите кнопку «Настройка параметров адаптера».

Кликните правой кнопкой мыши по сетевому адаптеру, который используется для выхода в Интернет, и выберите «Свойства».

Найдите и дважды кликните пункт IP версии 4 (TCP/IPv4).

В открывшемся окне поставьте переключатель на «Использовать следующие адреса DNS-серверов» и впишите 127.0.0.1:

В качестве резервного DNS сервера впишите «8.8.8.8».

Если ваш Интернет провайдер поддерживает IPv6, то повторите эту же процедуру для «IP версии 6 (TCP/IPv6)», но в качестве IPv6 адресов используйте «::1» и «2001:4860:4860::8888».

Откройте ещё одно окно командной строки и выполните там:

Также в командной строке проверим IP адрес домена с помощью утилиты nslookup:

Обратите внимание на строку:

Она означает, что IP адресом DNS сервера является 127.0.0.1.

Проверьте работу операционной системы — откройте веб сайты, загрузите файлы, используйте свою систему обычным образом, чтобы проверить, что нет никаких проблем с DNS.

Если что-то пошло не так и вы хотите вернуть всё назад, то откройте настройки сетевого адаптера, как это показано чуть выше и переключитесь на автоматическое получение адреса DNS-сервера.

Если всё нормально, то нажмите Ctrl+c в первом терминале, где запущен dnscrypt-proxy чтобы остановить DNS прокси.

Теперь зарегистрируйте его как системную службу (эту команду нужно выполнить в окне с повышенными привилегиями, то есть с правами администратора):

Если не появились ошибки, то это прекрасно! Значит ваша версия Windows совместима со встроенным установощиком.

Теперь, когда служба установлена, запустите её:

Всё готово! При перезагрузке компьютера, данная служба будет запускаться автоматически.

Если вам нужно остановить службу, то выполните:

Чтобы перезапустить запущенную службу (например, после изменения конфигурационного файла) выполните:

Для удаления службы выполните:

Для проверки DNS сервера используйте команду:

Чтобы полностью удалить dnscrypt-proxy сервер выполните:

А затем удалите папку C:\dnscrypt-proxy — всё готово!

Как обновить nscrypt-proxy

Чтобы установить новую версию, остановите службу, замените исполнимый файл (dnscrypt-proxy) на новую версию и запустите службу снова.

У dnscrypt-proxy много опций, но они будут рассмотрены в следующем разделе.

Как включить DNS через HTTPS (DoH) на уровне операционной системы в Linux

Установка dnscrypt-proxy в Kali Linux

Данная инструкция с минимальными поправками должна также работать и в Linux Mint, Ubuntu и аналогичных. Если у вас данный дистрибутив, то попробуйте этот раздел и если что-то не получится, то пишите ваши ошибки в комментариях.

Установите пакет dnscrypt-proxy:

Проверьте, чтобы порт 53 не был занят:

В выводе должна быть всего одна строка, а именно шапка:

Если вывод содержит более чем одну первую строку с названием столбцов, нужно отключить сервис, который использует порт 53. Одним из частых виновников является systemd-resolved.service (NetworkManager), но другие сетевые менеджеры могут иметь аналогичные компоненты. В общем, какая бы там ни была служба (возможно, вы уже устанавливали другой кэширующий DNS сервер), её нужно остановить и убрать из автозагрузки. Если нет процессов, прослушивающих порт 53, то можно продолжать.

Выполните проверку, чтобы убедиться, что dnscrypt-proxy работает:

Запустите службу dnscrypt-proxy и проверьте её статус:

Если всё в порядке, добавьте службу в автозагрузку:

Откройте файл /etc/NetworkManager/NetworkManager.conf:

Сделайте резервную копию файла /etc/resolv.conf:

А затем удалите /etc/resolv.conf (это важно, поскольку это может быть ссылка на файл, а не настоящий файл):

И создайте файл /etc/resolv.conf

со следующим содержимым:

Установка dnscrypt-proxy в Arch Linux, BlackArch и их производные

Установите пакет dnscrypt-proxy:

Проверьте, чтобы порт 53 не был занят:

В выводе должна быть всего одна строка, а именно шапка:

Если вывод содержит более чем одну первую строку с названием столбцов, нужно отключить сервис, который использует порт 53. Одним из частых виновников является systemd-resolved.service (NetworkManager), но другие сетевые менеджеры могут иметь аналогичные компоненты. В общем, какая бы там ни была служба (возможно, вы уже устанавливали другой кэширующий DNS сервер), её нужно остановить и убрать из автозагрузки. Если нет процессов, прослушивающих порт 53, то можно продолжать.

Выполните проверку, чтобы убедиться, что dnscrypt-proxy работает:

Запустите службу dnscrypt-proxy и проверьте её статус:

Если всё в порядке, добавьте службу в автозагрузку:

Откройте файл /etc/NetworkManager/NetworkManager.conf:

и проверьте, имеются ли там следующие строки:

Если их нет, то добавьте их и перезапустите NetworkManager:

Сделайте резервную копию файла /etc/resolv.conf:

А затем удалите /etc/resolv.conf (это важно, поскольку это может быть ссылка на файл, а не настоящий файл):

И создайте файл /etc/resolv.conf

со следующим содержимым:

Защита файла /etc/resolv.conf от изменений

Выше мы добавили настройку NetworkManager чтобы эта служба не меняла содержимое файла /etc/resolv.conf, как это делает она без предупреждений. На самом деле, NetworkManager действительно является самой частой причиной сброса настроек в /etc/resolv.conf, но не единственной. Подробности, а также способы, как определить, какая программа меняет файл /etc/resolv.conf и как надёжно заблокировать этот файл от изменения любыми программами, смотрите в статье «Как запретить NetworkManager менять файл /etc/resolv.conf».

Как настроить dnscrypt-proxy

Настройка dnscrypt-proxy выполняется с помощью файла dnscrypt-proxy.toml. В Windows этот файл расположен по пути C:\dnscrypt-proxy\dnscrypt-proxy.toml, а в Linux это файл /etc/dnscrypt-proxy/dnscrypt-proxy.toml. Независимо от операционной системы, настройка делается одинаково.

Откройте этот файл любым текстовым редактором, например, в Linux:

Содержимое этого файла зависит от вашего дистрибутива: иногда там полный дефолтный файл, иногда уже настроенный сопровождающими пакета.

Чтобы после редактирования файла dnscrypt-proxy.toml изменения вступили в силу, выполните следующую команду.

Чтобы понять, что настраивать, немного информации о том, как работает dnscrypt-proxy. Для преобразования имён в IP адреса dnscrypt-proxy скачивает большой список DNS серверов и в фоне проверяет их доступность и скорость отклика. Запросы делаются к разным DNS серверам в зависимости от скорости отклика и алгоритмов балансировки нагрузки. Это можно изменить — например, можно выбрать определённое имя или несколько имён и указать его (или их) в директиве server_names. Если директива server_names пустая, то будут использоваться все сервера. Если в директиве server_names указано одно или более имён DNS серверов, то будут использоваться только эти сервера.

К примеру, я предпочитаю DNS сервер Google, тогда значение моей директивы:

Если хотите сразу несколько DNS серверов, то укажите их используя следующий синтаксис:

Чтобы узнать, какие сервера выбраны для использования, выполните команду.

Директива listen_addresses устанавливает порт и IP адрес для прослушивания. Обычно, нет необходимости здесь что-то менять. Для работы с сокетами устанавливается следующее значение:

Установите fallback_resolvers на

Если вам зачем-то нужно вести журнал сделанных запросов, то найдите и раскомментируйте следующие строки:

Как добавить DNS сервер в исключение

Предположим, вы хотите использовать полный список DNS серверов, но хотите исключить некоторые из них. К примеру, как написали в комментарии, в данный момент у сервера rdns.faelix.net просрочен сертификат, что приводит к выводу предупреждений от антивирусного ПО. По этой причине мы хотим исключить данный сервер из списка используемых.

Это можно сделать с помощью директивы disabled_server_names, в качестве её значения нужно перечислить имена серверов, которые нужно избегать даже если они удовлетворяют всем критериям.

В первую очередь нам нужно знать имя проблемного DNS сервера. Для этого перейдите на страницу https://dnscrypt.info/public-servers

Внизу найдите выпадающий список «Rows per page» (Строк на страницу) и выберите там «All» (Все).

Нажмите в веб-браузере Ctrl+f для поиска по странице. Мы знаем, что проблемный адрес rdns.faelix.net, попробуем поискать по части имени «faelix»:

Итак, имена IPv4 DNS серверов это faelix-ch-ipv4 и faelix-uk-ipv4.

В файле настроек найдите disabled_server_names и добавьте имена туда:

Если вы используете IPv6 подключение, то также добавьте в список исключений и IPv6 имена.

Сохраните файл настроек и перезапустите службу dnscrypt-proxy.

Документация по настройке dnscrypt-proxy на русском

На странице карточки программы размещён пример конфигурационного файла dnscrypt-proxy с объяснением всех опций и переводом комментариев на русский язык: https://kali.tools/?p=5964

Проверка работы dnscrypt-proxy

Я уже упоминал, что благодаря кэшированию, повторные DNS запросы обрабатываются быстрее. Для проверки можно выполнить два раза подряд команду:

Первый ответ получен через 0,047s, а второй всего через 0,006s. Конечно, это только доли секунды, но всё равно хорошо. К тому же, вы реже будете сталкиваться с ситуацией, когда браузер «задумался» во время запроса из-за того, что по какой-то причине некоторые DNS ответы идут слишком долго или вовсе потеряны.

Можно проверить, сколько идёт запрос «напрямую», без DoH:

В моём случае это 0,058s-0,094s с периодическими таймаутами, видимо, задержка на СОРМ. Видимо, зашифрованный трафик пропускается «как есть», а незашифрованный проходит какую-то обработку, вроде как проверку доменов/IP по реестру запрещённых сайтов и т. п. Больше шифрования — больше скорости!

Запустите Wireshark и начните захват трафика. Через некоторое время проверьте с использованием фильтра

Там должно быть пусто, совсем.

Также с помощью фильтра посмотрим на пакеты, которые уходят к DNS серверу и возвращаются от него:

Как можно увидеть на скриншоте, всё зашифровано, теперь у Интернет-провайдера и других посредников нет никакой возможности узнать или изменить содержимое DNS запросов и ответов.

Настройка dnscrypt-proxy для использования с IPv6

Во-первых, измените файл /etc/resolv.conf

там должны быть строки

В файле dnscrypt-proxy.toml

Нужно установить прослушивание IPv6 интерфейса:

Помните, что сервер google это IPv4 сервер, а google-ipv6 это IPv6 сервер. Поэтому если вы установили значение server_names, то не забудьте туда вписать и IPv6 сервера, например:

Источник