Вирус запросы к dns
Рассмотрим подробнее схему реализации и методы защиты от подобного рода атак.
По мере того как пользователи становятся все более осведомленными относительно сетевых угроз, создатели вредоносов придумывают все более изощренные техники кражи персональной информации. Отравление кэша DNS (или DNS-спуфинг) – один из наиболее хитрых методов перенаправить потенциальную жертву на вредоносный сайт.
Рассмотрим подробнее схему реализации и методы защиты от подобного рода атак.
Как работает DNS сервер
DNS сервер можно сравнить с огромной телефонной книгой, но только для сайтов. После отсылки компьютером веденного URL’а, DNS сервер ищет в своей базе и сообщает компьютеру найденный IP-адрес. Теперь, когда связь между URL и IP-адресов установлена, компьютер сможет добраться до сайта.
Как работает кэш в DNS
Теперь, когда вы захотите повторно проверить банковский счет, нет нужды обращаться к DNS серверу еще раз, поскольку компьютер найдет нужный IP-адрес в кэше, сохраненным после недавнего визита. Можно сказать, что кэш DNS похож на миниатюрную телефонную книгу, где хранятся адреса сайтов, которые вы уже посещали.
Когда компьютер использует кэш, то не отлеживает обновление IP-адреса с момента последнего посещения сайта указанного сайта. В некотором смысле кэш DNS схож с памятью компьютера. Если значения внутри кэша изменились, компьютер, ничего не подозревая, будет использовать обновленное значение.
Предположим, что ваш кэш был атакован и IP-адрес банковского сайта изменен. Теперь во время ввода соответствующего URL’а компьютер находит в кэше вредоносный IP-адрес и переходит на поддельный сайт.
Уязвимы ли DNS сервера?
Поскольку компьютеры общаются с DNS сервером для получения IP-адреса, сразу же возникает вопрос, могут ли хакеры пойти альтернативным путем и взломать сам сервер? К сожалению, да. И последствия могут оказаться катастрофическими.
DNS сервера работают сродни вашему компьютеру. В случае поступление запроса на получение IP-адреса если сервер не знает, куда перенаправить пользователя, то делает запрос к другим DNS серверам, которые также хранят кэши.
Более того, сервера, не имеющие информации об IP-адресах для конкретного сайта, будут делать запрос к скомпрометированному серверу, что приведет к цепочке заражений.
Как избежать отравления кэша
Как бы ужасно не выглядела тема, связанная с отравлением кэша, существуют методы противодействия этой угрозе.
1. Регулярно обновляйте антивирус
В хорошем антивирусе должны быть реализованы средства защиты от отравления кэша DNS. Поскольку интернет полон разных рисков, важно использовать современные средства противодействия угрозам, желательно в режиме реального времени. Рекомендуем устанавливать проверенные антивирусы, некоторые из которых даже бесплатны.
2. Не загружайте подозрительные файлы
Риск стать жертвой отравления кэша DNS станет еще меньше, если вы не будете загружать сомнительные файлы и кликать на подозрительные ссылки и баннеры, часто используемые для распространения вредоносов, заточенных в то числе и на изменение кэша.
3. Используйте проверенные сервера
После того как предприняты базовые меры безопасности, настало время задуматься о DNS серверах.
Хороший DNS сервер никогда не будет доверять первому попавшемуся ответу от другого сервера, а будет перепроверять полученную информацию до тех пор, пока не будет полной уверенности в отсутствии отправления. Используя надежные сервера, вы можете быть уверенными в легитимности ответов на отправляемые запросы.
Обычно используются DNS сервера, предоставляемые провайдером. Соответственно, надо пользоваться таким провайдером, который придерживается высоких стандартов безопасности.
Альтернативный вариант: использовать независимые DNS сервера с хорошей репутацией.
4. Периодически удаляйте кэш
В случае каких-либо подозрений немедленно обнуляйте кэш DNS, и еще раз проверьте сервера, которыми вы пользуетесь. Конкретные методы удаления кэша зависят от используемой операционной системы.
5. Тщательно перепроверяйте посещаемые сайты
При посещении важных сайтов, как, например, интернет-банка, всегда следует проявлять особую бдительность. К сожалению, URL поддельного сайта может выглядеть именно так, как вы ввели, поскольку компьютер полагает, что получен легитимный IP-адрес.
Однако если вы заметили отсутствие HTTPS-шифрования или нечто подозрительное, высока вероятность, что вы находитесь на поддельном сайте. В этом случае не следует вводить логин с паролем, тут же проверить систему на вирусы и очистить кэш.
6. Перезагружайте роутер
Роутеры также могут хранить собственный кэш DNS, который также может оказаться отравленным. Для большей уверенности в безопасности следует периодически перезагружать роутер с целью сброса кэша.
DNS сервера ускоряют просмотр страниц, но также могут стать причиной серьезных неприятностей. Однако если вы предпримите хотя бы базовые методы защиты, то никогда не станете жертвой атак, связанных с отравлением кэша DNS.
Семейство файловых инфекторов Win32/Sality известно уже давно и использует ботнет на основе P2P еще с 2003 г. Sality может выступать как в роли вируса, так и даунлоадера других вредоносных программ, которые используются для рассылки спама, организации DDoS, генерации рекламного трафика или взлома VoIP аккаунтов. Команды и файлы, передаваемые через сеть Sality, зашифрованы с использованием RSA (т. н. цифровая подпись). Модульная архитектура вредоносной программы, а также долговечность ботнета показывает насколько хорошо злоумышленники подошли к созданию этого вредоносного кода.
IP-адрес, который используется в качестве основного DNS-сервера на скомпрометированном роутере, на самом деле, является частью сети Win32/Sality. Существует еще одна модификация вредоносной программы – Win32/RBrute.B, она устанавливается Sality на скомпрометированных компьютерах и может выступать в качестве DNS или HTTP прокси-сервера для доставки поддельного установщика браузера Google Chrome к пользователям, которые были перенаправлены через вредоносный роутер.
Можно сказать, что техника модификации основного DNS роутера уже достаточно распространена для различных целей, начиная, с целей кражи данных онлайн-банкинга и заканчивая блокированием подключений клиента к веб-сайтам security-вендоров. Особенно это стало актуально в связи с недавним обнаружением уязвимостей в firmware различных моделей роутеров. Win32/RBrute.A пытается найти административные веб-страницы роутеров путем сканирования диапазона IP-адресов, полученных с C&C-сервера. В дальнейшем, отчет об этой операции будет отправлен обратно на C&C-сервер. На момент проведения нашего анализа, Win32/RBrute.A использовался для получения доступа к следующим моделям роутеров:
Эта вредоносная программа чем-то напоминает известный DNSChanger, который перенаправлял пользователей на установку вредоносных программ через рекламу поддельного ПО. На сами рекламные сайты пользователь перенаправлялся через вредоносный DNS.
После того как операция установки DNS-сервера завершена, DNS-запись роутера для этого ПК становится бесполезной и ОС будет использовать явным образом прописанный в реестре сервер. С другой стороны, другие компьютеры, которые будут пытаться подключиться к этому роутеру, подвергнутся вредоносным перенаправлениям, так как DNS-запись роутера по-прежнему модифицирована.
Вредоносный код Win32/Sality, который занимается модификацией DNS-сервиса роутера, состоит из двух исполняемых файлов: сканер адресов роутеров и DNS/HTTP-сервер.
Рис. Блок-схема работы Win32/RBrute.A.
После того как IP-адрес отправлен на C&C, бот получает команду на вход в панель управления роутером. При этом используются логин и пароль, выданные C&C. В случае успешного входа, вредоносный код модифицирует адрес основного DNS-сервера, который теперь будет указывать на другой компьютер, зараженный другой модификацией RBrute – Win32/RBrute.B.
Ранее мы упоминали компонент вредоносной программы, который выполняет роль DNS/HTTP-сервера. Он обнаруживается как Win32/RBrute.B и выполнение его кода делится на три потока: управляющий поток, поток DNS-сервера и поток HTTP-сервера. Хотя этот вредоносный компонент может одновременно запустить и DNS- и HTTP-сервисы, на самом деле, он выбирает для запуска какой-то один из них с использованием случайно сгенерированной величины. Специальная константа в формуле используется для гарантии, что в 80% случаях бот будет работать как DNS-сервер, хотя в начальный период отслеживания операции с использованием этой вредоносной программы мы наблюдали константу, которая гарантировала 50% случаев работы в качестве DNS.
Рис. Код выбора DNS- или HTTP-сервера для старта.
RBrute.B имеет и другую ветвь кода, которая исполняется в том случае, когда вышеприведенный код отработал неверно.
Рис. Иной механизм запуска потоков HTTP/DNS-серверов в коде вредоносной программы.
Управляющий поток (control thread) используется для отправки данных, собранных вредоносной программы, обратно на C&C-сервер. Каждые две минуты RBrute.B отправляет пакет данных по жестко зашитому IP-адресу. Этот пакет содержит информацию о системе, в которой работает бот. Затем управляющий сервер предоставит боту IP-адрес, который будет использоваться для доставки поддельного установщика Google Chrome. Если бот работает в режиме DNS-сервера, то IP-адрес C&C-сервера будет совпадать с адресом, который нужно использовать в качестве сервера распространения поддельного установщика браузера. В противном случае, управляющий сервер отправит тот IP-адрес, который находится за пределами инфраструктуры Sality P2P и будет использоваться для распространения поддельных установщиков Chrome.
Ниже приводится информация о системе, которая отправляется управляющим потоком на удаленный сервер.
- Имя системы – GetComputerName().
- Зафиксированное время – GetLocalTime().
- Страна – GetLocaleInfo().
- Путь к директории Windows – GetWindowsDirectoryA().
- Название продукта ОС – из системного реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Product Name.
- Названия процессоров – из системного реестра HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\ \ProcessorNameString.
- Объем памяти GlobalMemoryStatus().
- Присутствие отладчика – IsDebuggerPresent().
- Количество памяти, используемое вредоносной программой GetProcessMemoryInfo().
- Время работы вредоносной программы – в минутах.
- Количество работающих потоков.
Пакет с информацией имеет следующий формат:
0x00 DWORD контрольная_сумма (CRC32)
0x04 WORD размер_полезной_нагрузки
0x06 BYTE не_используется
0x07 BYTE режим_работы (HTTP – 0x32 или DNS – 0x64)
Ниже показан скриншот с информацией пакета, отправленного на C&C.
Рис. Пакет, отправляемый ботом на удаленный сервер. Синим отмечено поле контрольной суммы, красным поле размера полезной нагрузки, черным зашифрованная константа режима работы сервера, зеленым зашифрованная информация о системе.
Информация о системе может иметь вид (в пакете зашифрована с использованием RC4):
9BC13555|24.03.2014 21:56:27|United States|C:\WINDOWS|Microsoft Windows XP|proc#0 QEMU Virtual CPU version 1.0|1|358|511|1117|1246|0|2|0|0|
Управляющий сервер затем ответит пакетом, который содержит IP-адрес для использования. Пакет имеет вид.
0x00 DWORD контрольная_сумма (CRC32)
0x04 WORD размер_полезной_нагрузки
0x06 BYTE не_используется
0x07 BYTE команда (0x02 – запустить или 0x03 – остановить сервис)
0x08 DWORD IP_адрес_сервиса (Система с запущенным Win32/Rbrute.B или другой HTTP-сервер)
Мы упоминали отдельный поток HTTP-сервиса в Win32/RBrute.B. Рассмотрим его более подробно. Этот сервис обслуживает пользователей, которые были перенаправлены через вредоносный DNS роутера на скачивание поддельного дистрибутива браузера Google Chrome. При получении запроса через HTTP, поток сервиса сначала проанализирует параметр User-Agent в заголовке. Дальнейшее поведение сервиса зависит от того, что находится в этом параметре.
В компоненте Win32/RBrute.B эта функция вызывается в начале исполнения вредоносной программы.
Рис. Отсюда производится вызов функции add_to_firewall_exception.
Аналогичный код находится в компоненте спам-бота, который принадлежит Sality.
Рис. Код спам-бота Sality, в котором вызывается add_to_firewall_exception.
Наши данные телеметрии показывают, что активность Win32/Sality в настоящее время снижается или, по крайней мере, остается на таком же уровне как в 2012 г. Мы полагаем, что сокращение числа обнаружений связано с низкой эффективностью текующих векторов заражения пользователей. Это могло бы объяснить тот факт, что злоумышленники ищут новые способы для распространения Win32/Sality.
Если мы посмотрим на статистику обнаружений Sality за последний год, то увидим небольшое увеличение количества обнаружений, примерно, в декабре 2013. Эта дата совпадает со временем первой активности компонента RBrute, который выполняет подмену DNS-сервиса роутера.
Мы не уверены в настоящей эффективности компонента RBrute для злоумышленников, поскольку подавляющее количество роутеров прослушивают только жестко фиксированное адресное пространство (т. е. 192.168.0.0/16), что делает панель управления недоступной из интернета. Кроме этого, компонент RBrute не выполняет сильный перебор паролей, а только пытается применить десять паролей из своего списка.
Простые векторы заражения пользователей вредоносным кодом Win32/Sality не могут быть достаточно эффективными, чтобы поддерживать популяцию ботнета на соответствующем уровне. Злоумышленники нуждались в новом способе распространения вредоносной программы и таким способом стал DNS hijacking для роутера. В зависимости от того, подвержен ли выбранный роутер эксплуатации, его жертвами перенаправлений может стать множество подключенных к нему пользователей. Мы рекомендуем использовать безопасные пароли для аккаунтов панелей управления роутеров, а также проверять действительно ли необходимо разрешать доступ к ней из интернета.
Необычный троянец для Android не делает со смартфоном ничего ужасного — вместо этого он захватывает Wi-Fi-сеть, к которой подключен зараженный аппарат
28 декабря 2016
Но что, если поддельная страница содержится по настоящему адресу? Оказывается, такой неприятный вариант тоже возможен, и для этого злодеям даже не надо взламывать сервер, на котором хранится заветная страница. Вот как это работает.
Перехват и подмена DNS-запросов
Например, если ввести в строке браузера google.com, то DNS-сервер вернет вам адрес 87.245.200.153 — и именно по этому адресу вы и перейдете на самом деле. Происходит это примерно так:
Дело за малым: остается каким-то образом обмануть пользователя, чтобы он вместо настоящего DNS-сервера использовал вредоносный, перенаправляющий на поддельный сайт. Вот как данную задачу решили создатели трояна Switcher.
Они создали пару программ для Android, одна из которых имитирует приложение поисковой системы Baidu (это такой китайский Google), а вторая — также достаточно популярную в Китае утилиту для поиска паролей к Wi-Fi-сетям, которыми обмениваются пользователи.
После того как приложение попадает на смартфон, подключенный к Wi-Fi, оно связывается с командным сервером злоумышленников и сообщает, что троян активирован в Wi-Fi-сети с таким-то идентификатором.
Затем Switcher приступает к взлому Wi-Fi-роутера: он по очереди проверяет различные пароли администратора для входа в веб-интерфейс настройки маршрутизатора. Если судить по тому, как устроена эта часть трояна, на данный момент он умеет работать только с роутерами TP-Link.
После того как трояну удается угадать пароль, он заходит на страницу сетевых настроек роутера и прописывает в них адрес одного из вредоносных DNS-серверов в качестве используемого по умолчанию. А в качестве запасного DNS-сервера троян указывает настоящий DNS-сервер Google 8.8.8.8 — чтобы пользователь не заметил сбоев в случае отказа DNS-сервера злоумышленников.
Поскольку в большинстве беспроводных сетей все устройства получают сетевые настройки, и в том числе адреса DNS-серверов, от роутера, то все пользователи, подключившиеся к уже захваченной злоумышленниками Wi-Fi-сети, автоматически будут использовать вредоносный DNS.
Об успехе операции троян сообщает на командный сервер. На нем нашим экспертам помимо всего прочего удалось обнаружить статистику успешных атак, которую злоумышленники по неосторожности оставили в открытой части сайта. 
Если верить этой статистике, за неполные четыре месяца работы им удалось захватить уже 1280 беспроводных сетей, и трафик всех пользователей этих сетей может быть перенаправлен по команде злоумышленников.
1. Чтобы защитить свою беспроводную сеть от подобных атак, следует правильно настроить роутер. В первую очередь — на странице настроек сменить пароль по умолчанию на сложный и надежный.
2. Не стоит устанавливать подозрительные приложения на свои Android-устройства. К сожалению, даже в официальных магазинах нередко встречаются трояны.
Команда AdGuard инвестирует много времени и усилий в разработку решений защиты конфиденциальности пользователей, и многие пользователи ценят продукты AdGuard именно по этой причине. Самым большим вызовом для разработчиков AdGuard является не только обеспечение эффективной защиты, но и предоставление ее любому пользователю, независимо от используемого устройства.
Схематическое изображение работы DNS
На самом деле система DNS является более сложной, но этой информации достаточно, чтобы получить базовое понимание. Обычно ваш интернет-провайдер (или оператор используемой сети) сам решает, какой DNS-преобразователь следует использовать.
Заметили ли вы проблему на схеме выше? Действительно, случайное лицо, которое предоставляет вам доступ в Интернет, знает каждый домен, который вы посетили и когда происходил сеанс посещения. Одно из исследований на практике продемонстрировало, что модель поведения, полученная путем анализа исключительно данных DNS, позволила правильно идентифицировать 86% пользователей.
Это звучит не очень хорошо, особенно если учесть, сколько усилий многие люди прилагают для защиты своей конфиденциальности: использование HTTPS, VPN-сервисов, блокировщиков рекламы и др. Все эти активности можно отследить с помощью DNS с последующей монетизацией Интернет-провайдерами. Думаете, они не будут получать дополнительную прибыль при наличии соответствующей возможности?
DNS-трафик уязвим для злоумышленников
К счастью, существуют эффективное решение данной проблемы. Почти все устройства, которые позволяют вам выходить в Интернет, также дают возможность выбрать собственный преобразователь DNS. Какой выбрать? На рынке доступно много различных вариантов, но не все из них ставят в приоритет конфиденциальность. AdGuard предлагает сервис, который не только сохранит ваши действия в Интернете в тайне, но и предоставит дополнительные возможности защиты от сетевых угроз.
Давайте подробнее рассмотрим AdGuard DNS и выясним, почему это один из самых безопасных для вас вариантов на сегодняшний день.
Выбор альтернативного DNS-резольвера является первым шагом для повышения конфиденциальности, но этого может быть недостаточно. Если никто не может иметь доступ к вашему DNS-трафику сейчас, это не значит, что никто не мог ранее. Протокол DNS совсем не новый, и тогда, когда он был разработан, стандарты конфиденциальности практически отсутствовали. В результате сегодня существует высокий риск того, что ваши DNS-запросы могут быть подслушаны или даже изменены злоумышленниками. Чтобы противостоять им, команда AdGuard приняла несколько действенных мер.
С AdGuard DNS ваш трафик защищен
Проблема DNSCrypt заключается в том, что протокол никогда не становился официальным стандартом и не получал документ RFC (документ с техническими спецификациями) в отличие от его альтернатив: DNS-over-HTTPS и DNS-over-TLS. Ожидается, что со временем DNSCrypt станет менее популярным и не получит особой поддержки на уровне операционной системе. К счастью, существуют и другие современные инструменты, которые не так широко распространены, но обеспечивают гораздо более высокий уровень безопасности и могут стать новыми стандартами конфиденциальности DNS в обозримом будущем.
DNS-over-TLS или DoT – протокол шифрования DNS-запросов и передачи по TLS-протоколу. DoT более надежен, чем DNSCrypt. Все больше и больше DNS сервисов поддерживают его, и AdGuard с гордостью вступает в их ряды.
Стоит упомянуть, что начиная с Android 9, устройства Android имеют встроенную поддержку DNS-over-TLS. Вы можете настроить свой смартфон или планшет на использование этого протокола в несколько нажатий без необходимости установки какого-либо дополнительного программного обеспечения.
DNS-over-HTTPS или DoH выполняет удаленное преобразование DNS по протоколу HTTPS. Это еще один безопасный способ защитить ваш трафик DNS от перехвата и подмены. Есть ли разница между DoT и DoH? Для обычного пользователя – практически никакой.
AdGuard DNS недавно получил поддержку DoH, которая выводит сервис на передний план защиты конфиденциальности. К сожалению, этот протокол все еще относительно новый, и способов применения его на вашем устройстве немного. Тем не менее, новая версия AdGuard для Android уже поддерживает эту опцию .
AdGuard DNS блокирует запросы к рекламным и отслеживающим доменам
Как же настроить AdGuard DNS? Укажите DNS-сервера для вашего подключения или прямо на маршрутизаторе, используя нашу инструкцию.
DNS сервера
DNS-over-TLS
DNS-over-HTTPS
Помните, что AdGuard DNS – проект с открытым исходным кодом, как и все бесплатные продукты AdGuard. Компания считает чрезвычайно важным, чтобы услуги и продукты, которым вы доверяете защиту конфиденциальности данных, были максимально прозрачными и заслуживающими доверия. Чтобы просмотреть исходный код, узнать все о AdGuard DNS или даже оставить предложение, посетите репозиторий в GitHub.
Команда разработчиков надеется, что пользователям понравится AdGuard DNS. Они убеждены, что проект будет только расти. В будущем будет добавлено больше расположений серверов и новые дополнительные функции.
Речь идет о том, как следует шифровать DNS-трафик — сетевые запросы, которые преобразуют понятные людям доменные имена (адреса сайтов) в IP-адреса серверов. Когда пользователь вводит доменное имя в браузере, тот запрашивает у ближайшего указанного в настройках DNS-сервера IP-адрес, связанный с этим доменным именем.
Никто не спорит с тем, что DNS должен быть зашифрован. Третьи стороны не должны иметь возможность перехватывать и перенаправлять пользователей на сторонние сайты, на которых могут быть размещены вредоносные программы или поддельные формы авторизации. Разногласия заключатся лишь в том, как это шифрование должно быть сделано.
Существует два варианта: так называемые DNS поверх TLS и DNS поверх HTTPS. Первый подчеркивает безопасность и дает администраторам сетей больше контроля, а второй подчеркивает конфиденциальность пользователей. С точки зрения удобства использования пользователи не заметят различий с любым из этих подходов, чего нельзя сказать о системных администраторах.
Два способа шифрования
Современные сети полагаются на протокол защиты транспортного уровня (TLS) для безопасного обмена данными, например, для просмотра веб-страниц, передачи файлов, VPN-подключений, сеансов удаленного рабочего стола и передачи голоса по IP-телефонии. Одна сторона соединения, обычно сервер, имеет сертификат с цифровой подписью, выданный доверенным центром сертификации. Другая сторона соединения, обычно клиент, использует сертификаты для проверки того, с кем он обменивается данными. 
Поскольку протокол TLS уже широко используется для обеспечения конфиденциальности, аутентификации и целостности данных, расширение протокола для работы с DNS является вполне логичным. DNS поверх TLS (IETF RFC 7858) определяет, как DNS-пакеты будут шифроваться с помощью TLS и передаваться по широко используемому протоколу управления передачей (TCP).
По умолчанию DNS проходит через порт 53 по протоколу TCP или UDP. При использовании DNS поверх TLS все зашифрованные пакеты отправляются через порт 853. Большинство общедоступных DNS-серверов, включая Cloudflare, Quad9 и Google, уже поддерживают DNS поверх TLS, и компании, использующие собственную DNS-инфраструктуру, также могут использовать такое шифрование.
Google включил поддержку DNS поверх TLS в Android Pie (Android 9), чтобы пользователи могли настраивать шифрование DNS как для Wi-Fi, так и для мобильной сети, и многие приложения и устройства уже умеют работать с этой опцией.
DNS поверх HTTPS (IETF RFC8484) в значительной степени разработан с оглядкой на принципы работы современного интернета, поскольку он вбрасывает все пакеты данных в поток HTTPS вместе с другим зашифрованным веб-трафиком. В отличие от своего конкурента, DNS поверх HTTPS не шифрует отдельные запросы, а вместо этого пропускает их через зашифрованный туннель между клиентом и сервером. 
Поскольку соединение использует HTTPS и HTTP/2, все пакеты выглядят одинаково. Любой, кто отслеживает порт 443 — стандартный порт HTTPS — не сможет идентифицировать DNS-запросы из всего остального веб-трафика.
Плюсы и минусы каждого подхода
Для сторонников конфиденциальности DNS через TLS недостаточно хорош, потому что любой, кто контролирует сеть, будет знать, что любая активность на 853-ем порту связана с этим DNS. Хотя наблюдатель не будет знать фактическое содержание запроса, поскольку и ответ, и запрос зашифрованы, тот факт, что сетевой администратор или провайдер будут знать, что есть такая активность, уже может привести к последствиям для пользователя (в худшем случае этот порт может быть вообще закрыт). Хотя DNS поверх TLS безопасен, он не так удобен с точки зрения конфиденциальности, как DNS поверх HTTPS.
Еще один недостаток DNS поверх TLS заключается в том, что разработчикам программного обеспечения и производителям устройств необходимо внести изменения, чтобы их приложения и оборудование поддерживали этот протокол. И если такой поддержки нет, даже если указанный DNS-сервер может работать с таким шифрованием, оно не будет защищать данные пользователя.
DNS поверх HTTPS более демократичен, поскольку любой пользователь, использующий поддерживаемый веб-браузер, автоматически получает шифрование DNS. DNS поверх HTTPS лишает любые третьи стороны — в том числе поставщиков интернет-услуг и правительственные учреждения — возможности просматривать информацию о том, какие сайты посещает пользователь. Это именно то, что хотят защитники конфиденциальности, но это противоположно тому, что нужно сетевым администраторам.
Конфиденциальность против безопасности
DNS поверх HTTPS возводит конфиденциальность в абсолют, но создатели приложений родительского контроля, антивирусных программ, корпоративных брандмауэров и других сетевых инструментов не разделяют эту идеологию. Включение DNS поверх HTTPS по умолчанию в веб-браузере означает, что все DNS-запросы передаются на указанный DNS-сервер, который может не являться собственным DNS-сервером организации или провайдера.
Mozilla объявила, что DNS поверх HTTPS будет использоваться по умолчанию для пользователей Firefox в Соединенных Штатах, и это изменение в настоящее время активно внедряется. Firefox автоматически передает весь DNS-трафик популярному серверу Cloudflare 1.1.1.1 и игнорирует существующие настройки DNS пользователя. Это обходит все связанные с DNS сетевые правила фильтрации, в том числе позволяет попасть на сайты, доступ к которым блокируется по DNS.
Google также включил DNS поверх HTTPS для пользователей Chrome, но тут его принцип работы немного отличается, поскольку браузер по умолчанию использует DNS поверх HTTPS только в том случае, если у пользователя есть служба, совместимая с DNS поверх HTTPS.
Microsoft, как обычно, хочет усидеть на двух стульях одновременно: с одной стороны, компания планирует поддерживать DNS поверх HTTPS в Windows, с другой — хочет дать системным администраторам некоторый контроль.
Отчасти поэтому Mozilla не включает DNS поверх HTTPS для пользователей Firefox в Соединенном Королевстве, так как там закон требует от интернет-провайдеров блокировать доступ к нелегальным веб-сайтам, таким как те, которые связаны с детской порнографией. 
DNS поверх HTTPS против DNS поверх TLS — это еще одна разновидность борьбы за данные о просмотре веб-страниц пользователем и за то, кто получит доступ к ним. DNS-запросы от Firefox будут отправляться в Cloudflare, что означает, что Cloudflare будет иметь доступ к огромному количеству данных DNS. По словам Викси, технологические компании, которые управляют централизованными DNS-серверами, такие как Cloudflare и Google, в конечном итоге получат выгоду от DNS поверх HTTPS, поскольку именно они будут получать информацию о том, что люди просматривают в интернете.
Сторонники конфиденциальности считают, что не провайдеры, а сами пользователи должны отвечать за то, как они попадают на сайты в интернете. Но решение Mozilla заставляет пользователей Firefox использовать Cloudflare независимо от их собственных предпочтений.
Большинство пользователей не заметят никакой разницы, когда шифрованный DNS станет стандартным, что уже произошло для пользователей Chrome. Для компаний и интернет-провайдеров социально-сознательный, ориентированный на пользователя подход вынуждает идти на компромисс: ценой повышения конфиденциальности является снижение безопасности.
Реальность современного интернета заключается в том, что интернет-провайдеры и компании играют определенную роль в предотвращении угроз для пользователей. В идеале веб-браузеры должны позволять пользователям выбирать, следует ли использовать DNS поверх TLS или DNS поверх HTTPS, а также предоставлять пользователям возможность контролировать, какого поставщика DNS использовать.
Читайте также:
