Dns трафик. Уроки Wireshark: Смотрим на DNS-трафик. Установкам использование dnscrypt

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

Здравствуйте друзья! Сегодня я расскажу что такое утечка DNS, почему вы должны об этом знать и как от этого защититься используя бесплатную утилиту DNSCrypt.

• Предисловие
• Что значит утечка DNS
• Как проверить утечку DNS
• Как исправить утечку DNS используя DNSCrypt
  • Скачивание DNSCrypt
  • Установка DNSCrypt
  • Использование DNSCrypt
• DNSCrypt в Yandex браузере
• DNSCrypt в роутере
• Заключение
• Оценка и отзывы

Что значит утечка DNS?

При использовании HTTPS или SSL ваш HTTP трафик зашифрован, то есть защищен (не идеально, но защищен). Когда вы используете VPN, весь ваш трафик полностью шифруется (разумеется уровень и качество защиты зависит от правильной настройки VPN, но обычно все настроено и работает правильно).

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

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

В нашем примере на рисунке ниже вы видите как пользователь (компьютер) пытается обратиться к сайту www.. Для того чтобы попасть на сайт он должен сначала разрешить символьное имя узла в IP-адрес.

Если же конфигурация сети такова, что используется DNS-сервер провайдера (незашифрованное соединение, отмечено красной линией), то разрешение символьного имени в IP-адрес происходит по незашифрованному соединению.

Что в этом страшного?

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

Во-вторых, есть большая вероятность оказаться жертвой хакерской атаки. Такой как: DNS cache snooping и DNS spoofing.

Что такое DNS снупинг и спуфинг?

Вкратце для тех кто не в курсе.

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

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

Так как запросы не шифруются, кто-то между вами и провайдером может перехватить и прочитать DNS-запрос, после чего отправить вам поддельный ответ..com или vk.com, вы перейдете на поддельный или как еще говорят хакера (поддельным будет не только вид страницы, но и урл в адресной строке), после чего вы введете свой логин и пароль, ну а потом сами понимаете что будет. Данные авторизации будут в руках злоумышленника.

Описанная ситуация называется утечка DNS (DNS leaking). Она происходит, когда ваша система для разрешения доменных имен даже после соединения с VPN-сервером или сетью Tor продолжает запрашивать DNS сервера вашего провайдера. Каждый раз когда вы попытаетесь зайти на сайт, соединится с новым сервером или запустить какое-нибудь сетевое приложение, ваша система будет обращаться к DNS серверам провайдера, чтобы разрешить имя в IP-адрес. В итоге какой-нибудь хакер или ваш провайдер смогут узнать все имена узлов, к которым вы обращаетесь.

Если вам есть что скрывать, тогда я вам предлагают использовать простое решение — DNSCrypt. Можно конечно прописать какие-нибудь другие DNS-сервера и пускать трафик через них. Например сервера Гугла 8.8.8.8 или того же OpenDNS 208.67.222.222, 208.67.220.220. В таком случае вы конечно скроете от провайдера историю посещения сайтов, но расскажите о своих сетевых путешествиях Гуглу. Кроме этого никакого шифрования DNS трафика не будет, а это большой недостаток. Не знаю как вас, но меня это не возбуждает, я лучше установлю DNSCrypt.

Как проверить утечку DNS

Перед тем как мы перейдем к самой утилите, я бы хотел познакомить вас со специальными онлайн-сервисами. Они позволяют проверить утечку DNS.

Для работы программы требуется Microsoft .NET Framework 2.0 и выше.

Скачать DNSCrypt для Mac OS X вы можете по этой ссылке с Гитаб или с файлообменка по ссылке выше.

Разработчик программы OpenDNS.

Установка DNSCrypt

В этой статье мы разберем работу с консольной версией утилиты. Настраивать ДНСКрипт будем на Windows 10. Установка на других версиях винды не отличается.

Итак, скачанный архив распаковываем и помещаем содержимое папки dnscrypt-proxy-win32 в любое место на компьютере. В моем примере я расположил в папке “C:\Program Files\DNSCrypt\”.

После чего откройте от имени администратора командною строку.

Теперь в командной строке перейдите в папку DNSCrypt. Сделать это можно с помощью команды:

cd "C:\Program Files\DNSCrypt"

Кликаем , если не можете скопировать команды.

После этого подготовимся к установке службы прокси. Для начала необходимо выбрать провайдера DNS. В архив я положил файл dnscrypt-resolvers.csv. Этот файлик содержит список большинства DNS провайдеров, которые поддерживает DNSCrypt. Для каждого отдельного провайдера есть название, описание, расположение и поддержка DNSSEC и Namecoin. Кроме этого файл содержит необходимые IP-адреса и открытые ключи.

Выберите любого провайдера и скопируйте значение в первом столбце. В моем случае я буду использовать CloudNS, поэтому я скопировал “cloudns-can”. Теперь необходимо убедится, что прокси может подключиться. Сделать это можно с помощью этой команды:

dnscrypt-proxy.exe -R "cloudns-can" --test=0

Если у вас не получилось, попробуйте выбрать другого провайдера и повторить попытку еще раз.

Если все прошло успешно, продолжим установку и введем следующую команду:

dnscrypt-proxy.exe -R cloudns-can --install

Если все правильно работает, вы увидите следующие выходные данные:

Скрин того как это должно выглядеть в командой строке:

После чего необходимо зайти в параметры протокола TCP/IP Windows и изменить настройки DNS на 127.0.0.1.

Для удаления службы ДНСКрипт необходимо вернуть сетевые настройки DNS в начальное состояние. Делается это с помощью этой команды:

dnscrypt-proxy --uninstall

Данная команда также может использоваться для смены провайдера DNS. После применения нужно повторить установку с параметрами другого провайдера.

Если у вас после всей этой процедуры по какой-то причине во время проверки все еще определяться IP-адрес DNS вашего интернет-провайдера, кликните по кнопке «Дополнительно», которая находится под прописанным IP 127.0.0.1. В появившемся окне «Дополнительные параметры…», перейдите на вкладку «DNS» и удалите все адреса DNS-серверов кроме «127.0.0.1».

Все, теперь утечка DNS устранена.

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

DNSCrypt в Яндекс Браузере

С недавнего времени в браузере от Яндекс появилась поддержка ДНСКрипт. Ну что сказать, ребята из Яндекса работают и пытаются защитить пользователя — это здорово, но в отличие от утилиты DNSCrypt защита у Яндекса реализуется только на уровне браузера, а не уровне всей системы.

DNSCrypt в роутере

Также поддержка ДНСКрипт реализована в популярных прошивках OpenWrt. Подробнее об установке и другой дополнительной информации вы можете узнать на этой странице.

Заключение

Конечно же утилита ДНСКрипт и шифрование DNS в целом не является панацеей, да и вообще в информационной безопасности нет такого понятия как панацея. Мы только можем максимально улучшить нашу безопасность и анонимность, но сделать наше присутствие в сети неуязвимым на все 100% к сожалению не получится. Технологии не стоят на месте и всегда найдутся лазейки. Поэтому я предлагаю вам подписаться на наши новости в социальных сетях, чтобы всегда быть в курсе. Это бесплатно.

На этом все друзья. Надеюсь эта статья помогла вам решить проблему утечки DNS. Удачи вам в новом 2017 году, будьте счастливы!

Оценка утилиты DNSCrypt

Наша оценка

DNSCrypt - бесплатная утилита для защиты DNS-трафика Путем шифрования DNS-трафика и использования серверов DNS. Наша оценка - очень хорошо!

User Rating: 4.26 (39 votes)

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

Понятно, что подмена перехваченных пакетов не составит особого труда даже при использовании вами VPN -сервисов.

Закрыть дыру можно только путем шифрования DNS -трафика, но для этого вам понадобится специальное программное обеспечение, поскольку ни одна из операционных систем не поддерживает шифрование DNS из коробки. Наиболее простым инструментом для шифрования DNS -трафика является - небольшая бесплатная утилита, выгодно отличающаяся тем, что не нуждается в дополнительных настройках, а значит может использоваться новичками. Есть консольный инструмент - DNSCrypt Proxy , но с ним нужно возиться - выполнять серию команд в PowerShell , изменять адрес DNS вручную и так далее. У кого есть время и желание, пожалуйста, можете ознакомиться с ним на страничке github.com/jedisct1/dnscrypt-proxy .

Мы же предлагаем использовать более простую и удобную десктопную версию DNS -шифровальщика. Скачайте с сайта разработчика simplednscrypt.org соответствующую вашей разрядности ОС версию программы и установите.

Укомплектована легким интуитивно понятным интерфейсом да к тому же на русском языке, так что вы без труда разберетесь что к чему. Основные настройки выполняются в разделе «Меню» . Чтобы начать пользоваться программой, сразу после установки нажмите кнопку «Применить» , а затем выберите внизу вашу сетевую карту, она должна быть отмечена галочкой, как показано на скриншоте. Переключатель «Служба DNSCrypt» должен быть активным.

Проверить, всё ли работает нетрудно. Выполните в окошке Run команду ncpa.cpl , откройте свойства вашего подключения, выберите в списке IP версии 4 (TCPIPv4) и откроете его свойства. Радиокнопка «Использовать следующие адреса DNS-серверов» должна быть активной, а в поле должен быть указан предпочитаемый DNS -сервер. У нас это 127.0.0.1 , у вас адрес может быть другим.

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

Параметры раздела можно не менять, если вы не используете протокол IPv4 . В общих настройках можно включить дополнительные вкладки «Черный список доменов» , «Журнал блокировки доменов» , но это опять, если вы собираетесь работать с предлагаемыми в них функциями, в частности, составлять «черные» списки доменов.

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

Отсюда следует простой вывод - Ваши рекурсивные DNS сервера должны быть всегда доступны и в состоянии обслужить запросы клиента.

Все статьи о настройке производительного DNS сервера начинаются примерно так: «давайте померяемся различными параметрами различных рекурсивных DNS серверов и выберем из них самый-самый, и будет нам счастье». Могу сказать заранее, счастье таким методом наступит, но не на долго.

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

Вы спросите, какое-же решение задачи существует, точнее, что же делать в данной ситуации?

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

В большинстве случаев от завирусованных клиентов идет шквал DNS запросов различных типов, огромное количество MX запросов направленных на поиск ip адресов почтовых серверов, запросы типа A для экзотических доменов типа kljhajlhfqweqwe.com или ioweurtisdvfso.org.

По нашим грубым оценкам 3% клиентских машин генерировали более 90% всех DNS запросов.

Простой обзвон клиента зачастую проблему не решает, ибо клиента может и не быть дома, клиент не обладает квалификацией или же просто клиент не хочет лечиться (у меня и так все работает). Также зачастую при отключении клиентского порта, провайдеры оставляют открытым трафик до DNS сервера чтобы клиент мог войти в свой личный кабинет по его имени и посмотреть причину блокировки, но т. к. клиентский компьютер «валит» именно DNS сервер, то для решения данной проблемы надо искать другой выход.

Итак нам необходимо решить две простые задачи.
1.Определить все допустимые типы DNS запросов которые мы будем обрабатывать.
2.Найти разумные интервалы поступления запросов каждого типа от каждого клиента.

Давайте разберём запросы каких типов могут приходить от наших клиентов и что нам с ними делать.

Запись A (address record) или запись адреса связывает имя хоста с адресом IP. Самый «наиполезнейший» тип запросов. Значения 100 запросов за 10 секунд вполне приемлемы даже для тех клиентов, которые серфят «ну очень быстро»:)

Запись AAAA (IPv6 address record) связывает имя хоста с адресом протокола IPv6. Пока IPv6 распространён не сильно, можно оставить данный тип запросов к нашему DNS серверу, ограничив двумя запросами в 10 секунд от каждого из клиентов, чтобы пустые запросы типа AAAA localhost. не влияли на работу DNS сервера.

Запись CNAME (canonical name record) или каноническая запись имени. Тип запроса полезный, блокировка должна быть мягкая чтобы запросов подобного типа блокировалось как можно меньше. Также как и для запросов типа A 100 запросов за 10 секунд вполне приемлемое значение.

Запись MX (mail exchange) или почтовый обменник указывает сервер(ы) обмена почтой для данного домена. Для домашних клиентов интенсивные запросы к данным типам записей явно свидетельствуют о том, что компьютер клиента заражен заразой которая рассылает спам. 5 запросов за 60 секунд хватит для работы диагностических утилит.

Запись NS (name server) указывает на DNS-сервер для данного домена. Напрямую пользователи услуг домашнего Интернет такие запросы не генерируют, в большинстве случаев такие запросы формируются вручную через диагностические утилиты типа nslookup в целях отладки работоспособности своих доменов и пр. 10 запросов данного типа за 60 секунд вполне приемлемое значение.

Запись PTR (pointer) или запись указателя связывает IP хоста с его каноническим именем. Применительно к пользователям услуг домашнего интернета запросы подобного типа поступают достаточно часто во время работы торрент или p2p клиентов, для разрешения имен хостов с которых вы скачиваете и которым вы раздаете. Например 50 запросов за 10 секунд вполне приемлемое значение, которого в большинстве случаев хватает для любого пользователя.

Запись SOA (Start of Authority) или начальная запись зоны указывает, на каком сервере хранится эталонная информация о данном домене, содержит контактную информацию лица, ответственного за данную зону, тайминги (параметры времени) кеширования зонной информации и взаимодействия DNS-серверов. Данный тип запросов может использоваться пользователями домашнего интернет только в целях отладки, разрешим каждому клиенту делать 5 запросов за 60 секунд.

Запись SRV (server selection) указывает на серверы для сервисов. Данный тип запросов может использоваться пользователями домашнего интернет только в целях отладки, разрешим каждому клиенту делать 5 запросов за 60 секунд.

Полный список типов DNS записей можно просмотреть .

Для того чтобы понять по каким сигнатурам нам классифицировать тот или иной DNS запрос необходимо «поймать» tcpdump-ом по одному типу пакета, заглянуть в тело запроса поле Type и убедиться что:

Запрос типа MX содержит в поле type - 00 0F
запрос типа AAAA содержит в поле type - 00 1C
запрос типа A содержит в поле type - 00 01
запрос типа PTR содержит в поле type - 00 0C
запрос типа CNAME содержит в поле type - 00 05
запрос типа NS содержит в поле type - 00 02
запрос типа SOA содержит в поле type - 00 06
запрос типа SRV содержит в поле type - 00 21

Заметим также, что в DNS запросе после поля Type идёт поле Class оно всегда равно 00 01 для DNS запроса. Добавим это поле ко всем сигнатурам чтобы уменьшить количество ложных срабатываний.

Итак чтобы заблокировать DNS запросы типа MX нам необходимо на DNS серверах добавить правила iptables:
-A INPUT -p udp --dport 53 -m string --algo kmp --hex-string "|00 0F 00 01|" -j DROP

Так как нам надо закрыть данные запросы не полностью а просто ограничить их количество в единицу времени чтобы данные запросы не «ложили» нам сервер просто добавим в правила модуль recent.

Например правило которое ограничивает поступления DNS запросов типа MX в 5 запросов за 60 секунд будет выглядеть так:
-A INPUT -p udp --dport 53 -m state --state NEW -m string --algo kmp --hex-string "|00 0F 00 01|" -m recent --set --name MXFLOOD --rsource

A INPUT -p udp --dport 53 -m state --state NEW -m string --algo kmp --hex-string "|00 0F 00 01|" -m recent --update --seconds 60 --hitcount 5 --rttl --name MXFLOOD -j DROP

A INPUT -p udp --dport 53 -m string --algo kmp --hex-string "|00 0F 00 01|" -j ACCEPT

Аналогичным образом ограничиваются и другие типы DNS запросов.

Так как DNS типов существует превеликое множество и мы разрешили все нужные нам типы DNS запросов, то было бы неплохо запретить все остальные запросы чтобы они не обрабатывались вашим DNS сервером.

A INPUT -p udp --dport 53 -j DROP

Данные простейшие правила позволили нам сократить количество одновременных рекурсивных DNS запросов к нашим DNS серверам более чем в 20 раз (c 10000 до 400), без жалоб на работу DNS со стороны наших пользователей.

Программа сканирует DNS-ответы серверов (этого достаточно, внутри ответов есть запросы), и если доменное имя матчится с регулярным выражением, печатает адрес из А-записи (то, что получилось в результате разрешения).

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

Как это работает:

$ sudo ./sidmat eth0 "." iu
Мы видим доменные имена и во что они разрешаются (eth0 - интерфейс, на котором проходит DNS-трафик).

$ sudo ./sidmat eth0 "." iu | while IFS= read -r line; do printf "%s\t%s\n" "$(date "+%Y-%m-%d %H:%M:%S")" "$line"; done
Фиксируем время. Осталось перенаправить результат в файл, и можно пользоваться таблицей соответствия. Утилита может захватывать DNS-ответы с помощью pcap (в Линукс/BSD) или с помощью механизма nflog в Линуксе.

Эту же технику можно использовать и для управления трафиком. Фильтровать по доменам, получать адреса доменов с ключевым словами в именах и т.п.

Нужно иметь в виду, что управление может получиться не очень аккуратным. Если за время, когда до пользователя дойдет DNS-ответ и он начнет передавать трафик на этот узел, мы не успеем добавить адрес в ipset/iptables/таблицу маршрутизации/еще куда-то, то трафик пойдет «обычным» путем.

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

Несколько примеров:

Как получить список IP-адресов, в которые резолвится vk.com и его поддомены? (Без опции "u" будут печататься только уникальные IP-адреса)

$ sudo ./sidmat eth0 "^vk.com$|\.vk.com$" d
С опциями «d» или «i» видно какой именно домен разрешается в IP-адрес, «d» печатает имя домена в stderr.

Как заблокировать адреса в которые разрешается vk.com, его поддомены и все домены со словом odnoklassniki? (домены типа avk.com не попадут под правило, odnoklassnikii.com - попадут).

$ sudo sh -c "/sidmat eth0 "^vk\.com$|\.vk\.com$|odnoklassniki" | /usr/bin/xargs -I {} /sbin/iptables -A INPUT -s {} -j DROP"
Кроме небольших регулярных выражений можно использовать списки в файле (опция «f», второй аргумент интерпретируется как имя файла, его содержимое - как одно большое регулярное выражение). Списки могут быть достаточно большими, мы смотрели на производительность на списке доменов РКН (трафик на запретные домены перенаправлялся в VPN), обычный ПК-маршрутизатор совершенно спокойно с этим справился.

Вы можете помочь и перевести немного средств на развитие сайта