Шифрование dns-запросов

Содержание

Содержание 3
Введение 4
1 DNS-запросы 6
2 Незашифрованный DNS 7
3 Шифрование DNS-запросов 9
4 Технологии защиты DNS 12
Заключение 14
Список использованных источников 15

Введение

DNS является одним из фундаментальных строительных блоков Интернета. Он используется каждый раз, когда пользователи посещают веб-сайты, отправляют электронные письма, общаются в чате или делают что-либо еще в Интернете.
DNS (Система доменных имен), имеет длинную историю и по-прежнему использует протокол, который не шифрует данные запросов. Это означает, что запросы на разрешение адресов веб-сайтов передаются в открытой форме. DNS-трафик уязвим для злоумышленников, поскольку существует возможность «подслушать» канал связи и затем перехватить незащищенные личные данные. Интернет-провайдеры могут отслеживать трафик и собирать статистику сайтов, которые посещал пользователь.
Актуальность данной работы заключается в том, что большая часть трафика в Интернете сегодня все чаще шифруется и предназначена для нескольких крупных сетей. Растущий акцент на защиту конфиденциальности отдельных пользователей также меняет потребности в безопасности в пространстве DNS, что делает важным защиту DNS-запросов, чтобы избежать утечки информации об услугах, к которым осуществляется доступ.
Объектом исследования является DNS (domain name system).
Предметом исследования является шифрование DNS-запросов.
Тема «Шифрование dns-запросов» была хорошо раскрыта статье «Защита dns-запросов» от авторов Матвеев М.В, Трифонов Д.И. В данной статье рассмотрена проблема безопасности устаревшего протокола DNS. Исследованы новые протоколы, позволяющие защитить DNS – запросы, их различия, а также недостатки. На основе проведенного исследования авторами дана оценка о потенциале использования новых протоколов с шифрованием вместо текущего.
Уязвимости DNS были хорошо продемонстрированы в статье «Перехват сеанса. Атака MAN-IN-THE-MIDDLE-Подделка DNS» от автора Литвиненко Денис Сергеевич. Статья раскрывает содержание понятий перехват сеанса, атаки типа Man-in-the-Middle-подделка DNS. Раскрывается принцип работы некоторых вариантов подделки DNS, а также рассмотрены защита от нее - система DNSSEC и принцип ее действия.
Ответ на вопрос «Зачем нужно шифрование в DNS» был получен в статье Егора Морозова «Битва за данные пользователей: зачем нужно шифровать DNS-запросы». В статье рассказывается о нескольких подходах шифрования DNS-трафика.
Целью данной работы заключается в определении способов шифрования трафика.
Для достижения поставленной цели, требуется решить следующие задачи:
1. Изучить особенности DNS-запросов.
2. Изучить, как передаётся трафик при отсутствии шифрования DNS-запросов.
3. Изучить, как передаётся трафик в случае шифрования DNS-запросов.
4. Изучить способы шифрования DNS-запросов.
5. Изучить технологии для шифрования DNS-запросов.
1 DNS-запросыСистема доменных имен (DNS) – это адресная книга Интернета. Когда пользователь посещает cloudflare.com или любой другой сайт, браузер запрашивает у DNS-преобразователя IP-адрес, по которому можно найти веб-сайт. К сожалению, DNS-запросы и ответы обычно не защищены. Шифрование DNS улучшит конфиденциальность и безопасность пользователей.
Приложения, которые хотят преобразовать доменное имя в IP-адрес, обычно используют DNS. Это, как правило, не делается явно программистом, написавшим приложение. Вместо этого программист пишет что-то вроде fetch(«https://example.com/news») и ожидает, что программная библиотека будет обрабатывать перевод «example.com» на IP-адрес.
По умолчанию DNS-запросы и ответы сервера отправляются по сети в виде обычного текста, что означает, что кто-то может перехватить их и перенаправить пользователя в другое место назначения.
Есть много причин, чтобы сделать DNS-трафик более безопасным. Хотя веб-трафик и другие коммуникации могут быть защищены криптографическими протоколами, почти весь трафик DNS передается в незашифрованном виде. Это означает, что интернет-провайдер (или кто-либо еще между пользователем и остальной частью Интернета) может регистрировать посещаемые пользователем сайты, даже когда он использует другую службу DNS, и использовать эти данные для ряда целей, включая фильтрацию доступа к контенту и сбор данных для рекламных целей [1].
Простое использование службы DNS без регистрации помогает в некоторой степени. Но это не мешает кому-то фильтровать эти запросы по содержимому или захватывать адреса внутри них с помощью захвата пакетов или механизма глубокой проверки пакетов. В дополнение к простым пассивным атакам подслушивания, существует также угроза более активных атак на DNS-трафик – попытки интернет-провайдера или правительства по сети «подделать» идентификацию DNS-сервера, направляя трафик на их собственный сервер [2].
Подделка DNS представляет собой MITM прием, используемый для предоставления ложной DNS информации на компьютер, чтобы при попытке просмотра, например, сайта www.bankofamerica.com по IP адресу XXX.XX.XX.XX, этот компьютер был направлен на поддельный www.bankofamerica.com сайт, расположенный по IP адресу YYY.YY.YY.YY, который взломщик создал для того, чтобы украсть интерактивные банковские учетные данные и информацию учетной записи у ничего не подозревающего пользователя [3].
2 Незашифрованный DNSС тех пор, как DNS был создан в 1987 году, он в основном не был зашифрован. Все, кто находится между устройством пользователя и преобразователем DNS, могут отслеживать или даже изменять DNS-запросы и ответы. Это может повлиять на конфиденциальность, раскрывая доменные имена, которые посещает пользователь [4].
На рисунке 1 показано, что видит злоумышленник, при перехвате пакетов.
Рисунок 1 – Результат перехвата сетевых пакетов
Из перехваченных пакетов можно сделать следующие выводы:
Могут быть сделаны следующие наблюдения:
1. Исходный порт UDP – 53, который является стандартным номером порта для незашифрованного DNS. Таким образом, полезная нагрузка UDP может быть ответом DNS.
2. Исходный IP-адрес 192.168.2.254 является преобразователем DNS, а целевой IP 192.168.2.14 является клиентом DNS.
3. Полезная нагрузка UDP действительно может быть принята как ответ DNS и показывает, что пользователь пытался посетить twitter.com.
4. Если в будущем будут какие-либо подключения к 104.244.42.129 или 104.244.42.1, то, скорее всего, трафик направляется на «twitter.com».
5. Если к этому IP-адресу добавляется еще один зашифрованный трафик HTTPS, за которым следуют дополнительные DNS-запросы, это может указывать на то, что веб-браузер загрузил дополнительные ресурсы с этой страницы. Это может потенциально раскрыть страницы, которые просматривал пользователь при посещении twitter.com.
Так как сообщения DNS не защищены, возможны другие атаки:
1. Запросы могут быть направлены на распознаватель, который выполняет перехват DNS. Например, в Великобритании Virgin Media и BT возвращают поддельный ответ для несуществующих доменов, перенаправляя пользователей на страницу поиска. Это перенаправление возможно, потому что компьютер/телефон слепо доверяет преобразователю DNS, который был выбран DHCP маршрутизатором шлюза, предоставленным провайдером.
2. Брандмауэры могут легко перехватывать, блокировать или изменять любой незашифрованный трафик DNS, основываясь только на номере порта. Стоит отметить, что проверка открытого текста не является «серебряной пулей» для достижения целей видимости, поскольку распознаватель DNS можно обойти.
3 Шифрование DNS-запросовШифрование DNS значительно усложняет злоумышленникам просмотр DNS-сообщений или их повреждение при передаче. Так же, как сеть перешла от незашифрованного HTTP к зашифрованному HTTPS, теперь есть обновления до протокола DNS, который шифрует сам DNS. Шифрование в сети позволило процветать частным и безопасным коммуникациям и коммерции. Шифрование DNS еще больше улучшит конфиденциальность пользователей.
Существуют два стандартизированных механизма для защиты транспорта DNS между пользователем и распознавателем: DNS по TLS (2016) и DNS-запросы по HTTPS (2018). Оба основаны на безопасности транспортного уровня (TLS), которая также используется для защиты связи между пользователем и веб-сайтом, использующим HTTPS. В TLS сервер (будь то веб-сервер или распознаватель DNS) аутентифицируется для клиента с помощью сертификата. Это гарантирует, что никакая другая сторона не сможет выдать себя за DNS-сервер (распознаватель).
При использовании DNS через TLS (DoT) исходное сообщение DNS напрямую внедряется в защищенный канал TLS. Со стороны нельзя узнать имя, которое запрашивалось, а также изменить его. Предполагаемое клиентское приложение сможет расшифровывать TLS (рисунок 2).
Рисунок 2 – Дешифрование TLS
В трассировке пакетов для незашифрованного DNS было ясно, что запрос DNS может быть отправлен непосредственно клиентом, а затем получен ответ от DNS-распознавателя. Однако в случае зашифрованного DoT некоторые сообщения TLS handshake обмениваются перед отправкой зашифрованных DNS-сообщений:
1. Клиент отправляет сообщение «Client Hello», рекламируя свои поддерживаемые возможности TLS.
2. Сервер отвечает «Server Hello», согласовывая параметры TLS, которые будут использоваться для защиты соединения. Сообщение сертификата содержит идентификатор сервера, в то время как сообщение подтверждения сертификата будет содержать цифровую подпись, которая может быть проверена клиентом с помощью сертификата сервера. Клиент обычно проверяет этот сертификат по своему локальному списку доверенных центров сертификации, но в спецификации DoT упоминаются альтернативные механизмы доверия, такие как закрепление открытого ключа.
3. После того, как рукопожатие TLS завершено и клиентом, и сервером, они могут наконец начать обмениваться зашифрованными сообщениями.
4. В то время как вышеупомянутая картинка содержит один DNS-запрос и ответ, на практике безопасное TLS-соединение останется открытым и будет повторно использоваться для будущих DNS-запросов.
Проблема с введением нового порта заключается в том, что существующие брандмауэры могут блокировать его. Либо потому, что они используют подход белого списка, где новые службы должны быть явно включены, либо подход черного списка, где сетевой администратор явно блокирует службу. Если безопасный вариант (DoT) менее доступен, чем небезопасный вариант, то у пользователей и приложений может возникнуть искушение попытаться использовать незашифрованный DNS. Это впоследствии может позволить злоумышленникам заставить пользователей использовать небезопасную версию.
Такие атаки не являются теоретическими. Разбор SSL ранее использовался для понижения веб-сайтов HTTPS до HTTP, позволяя злоумышленникам украсть пароли или взломать учетные записи.
Другой подход «DNS Queries over HTTPS» (DoH), был разработан для поддержки двух основных вариантов использования:
1. Предотвратить вышеупомянутую проблему, где устройства на пути мешают с DNS. Это включает проблему блокировки портов.
2. Разрешить веб-приложениям доступ к DNS через существующие API-интерфейсы браузера.
DoH – это, по сути, HTTPS, тот же зашифрованный стандарт, который используется в Интернете, и использует тот же номер порта (tcp / 443). Веб-браузеры уже отказались от небезопасного HTTP в пользу HTTPS. Это делает HTTPS отличным выбором для безопасной передачи сообщений DNS [5].
4 Технологии защиты DNSЕсть много технологий, которые помогают защитить DNS-запросы. Рассмотрим некоторые из них.
VPN. До появления каких-либо конкретных решений для шифрования DNS всегда существует общий VPN (виртуальная частная сеть), который будет шифровать не только трафик DNS, но и весь трафик в сети. Существуют буквально сотни и тысячи различных продуктов VPN, которые могут обеспечить конфиденциальность [6].
DNSCurve. DNSCurve – это запатентованное решение, изобретенное исследователем безопасности Дэниелом Дж. Бернштейном. Доктор Бернштейн предложил DNSCurve в качестве замены технологии DNSSEC для обеспечения аутентификации, целостности данных и конфиденциальности в одном лице. Сила DNSCurve заключается в том, что он обеспечивает более сильное и более эффективное использование криптографических ключей, чем DNSSEC, и обеспечивает полную конфиденциальность при обмене данными с DNS-сервером.
DNSCrypt. DNSCrypt решает проблему «последней мили» между DNS-клиентом и сервером. Он шифрует немодифицированный DNS-трафик через порт 443 (без использования HTTP) и требует установки специального клиентского и серверного программного обеспечения. DNSCrypt в настоящее время предлагается OpenDNS (теперь является частью Cisco) в качестве услуги, а также несколькими другими поставщиками услуг.
IPSECA. В некоторой степени похожий на подход VPN, этот проект IETF предлагает новую настройку, в которой клиенты могут получать и проверять идентичность IPSEC, запрашивая DNS-сервер (с помощью DNSSEC-DANE), и использует оппортунистическое шифрование для установления туннеля IPSEC к DNS-серверу. Обязательным условием этого подхода является полное развертывание DNSSEC [6].
Конфиденциальный DNS. В этом проекте IETF предлагается опубликовать ключ шифрования DNS-сервера, поэтому, когда клиент подключается, то он может получить ключ шифрования от DNS-сервера, а затем использовать ключ шифрования для защиты всего взаимодействия с этого момента с сервером. Предварительным условием является то, что ключ шифрования от сервера проходит проверку подлинности и не подделывается, что требует использования механизма проверки подлинности, такого как DNSSEC.
DNS через TCP (DoT). Этот новый стандарт (RFC 7858) отправляет зашифрованный трафик DNS через TCP-порт 853. С 2019 года многие поставщики начали предоставлять поддержку DoT как на стороне клиента, так и на стороне сервера. Технология защищает «последнюю милю» между клиентом и сервером, а также может использоваться для защиты обмена данными между серверами. DoT может быть развернут как дополнение к DNSSEC.
DNS через DTLS. Подобно DoT, этот новый стандарт (RFC 8094) отправляет зашифрованный трафик DNS через UDP-порт 853. Эта технология решает все те же проблемы, что и DoT, и ведет себя так же, как DoT, за исключением использования DTLS для шифрования по UDP.
Новый - DoH (8484). Этот новый стандарт IETF (RFC 8484) оборачивает трафик DNS в зашифрованный сеанс HTTPS, защищенный TLS для конфиденциальности «последней мили». Он работает через стандартный TCP-порт 443, и большинство реализаций внедряют клиента в веб-браузер.
Заключение

Одним из краеугольных камней Интернета является сопоставление имен с адресами с использованием DNS. DNS традиционно использует незащищенные незашифрованные каналы. Это использовалось интернет-провайдерами в прошлом для демонстрации рекламы. Любопытные посетители в кафе могут использовать незашифрованный DNS, чтобы следить за деятельностью другого пользователя. Все эти проблемы могут быть решены с помощью DNS через TLS (DoT) или DNS через HTTPS (DoH). Эти методы защиты пользователя являются относительно новыми и находят все большее применение.
Mozilla приняла другой подход. Вместо того чтобы полагаться на локальные средства распознавания, которые могут даже не поддерживать DoH, они позволяют пользователю явно выбирать средство распознавания. Распознаватели, рекомендованные Mozilla, должны соответствовать высоким стандартам защиты конфиденциальности пользователей.
Какой бы продукт или решение ни выбрал пользователь, важно помнить, что шифрование – это комплексная технология, и поэтому пользователь все равно должен доверять другому концу. Просто потому, что связь DNS между пользователем и его провайдером зашифрована, она не защищает конфиденциальность пользователя, если его провайдер делает данные DNS пользователя доступными для всего мира.
В ходе выполнения данной работы, поставленная цель была достигнута, а именно были рассмотрены способы шифрования DNS-запросов.
В ходе достижения поставленной цели, были решены следующие задачи:
1. Изучены особенности DNS-запросов.
2. Изучен, принцип передачи трафика при отсутствии шифрования DNS-запросов.
3. Изучен, принцип передачи трафика в случае шифрования DNS-запросов.
4. Изучены способы шифрования DNS-запросов.
5. Изучены технологии для шифрования DNS-запросов.
Список использованных источников

1. Битва за данные пользователей: зачем нужно шифровать DNS-запросы [Текст]. – https://www.iguides.ru/main/other/bitva_za_dannye_polzovateley_zachem_nuzhno_shifrovat_dns.
2. Матвеев М.В. Защита DNS Запросов [Текст] / М.В. Матвеев, Д.И. Трифонов // Роль инноваций в трансформации современной науки: сб. науч. ст. / МИИТ. – Москва, 2019. – С. 55-60.
3. Литвиненко Д. С. Перехват сеанса. атака MAN-IN-THE-MIDDLE-Подделка DNS е [Текст] / Д. С. Литвиненко // НАУЧНЫЙ ЖУРНАЛ. – 2016. - № 11 (12). – С. 39-53.
4. How to keep your ISP’s nose out of your browser history with encrypted DNS [Текст]. – https://arstechnica.com/information-technology/2018/04/how-to-keep-your-isps-nose-out-of-your-browser-history-with-encrypted-dns.
5. DNS security and why it’s time for change [Текст]. –https://www.ericsson.com/en/blog/2020/3/dns-security.
6. Are DNS requests encrypted? [Текст]. – https://www.infoblox.com/dns-security-resource-center/dns-security-faq/are-dns-requests-encrypted.