Вы думаете что ваша анонимность надежно защищена. Но к сожалению это не так. Существует один очень важный канал утечки вашей приватной информации – служба DNS. Но к счастью на это тоже придумано решения. Сегодня я раскажу как зашифровать свой DNS трафик с помощью утилиты DNSCrypt.
При использовании HTTPS или SSL твой HTTP трафик зашифрован, то есть защищен. Когда ты используешь VPN, шифруется уже весь твой трафик (конечно, все зависит от настроек VPN, но, как правило, так оно и есть). Но иногда, даже когда используется VPN, твои DNS-запросы не зашифрованы, они передаются как есть, что открывает огромное пространство для «творчества», включая MITM-атаки, перенаправление трафика и многое другое.
Тут на помощь приходит опенсорсная утилита DNSCrypt, разработанная хорошо известными тебе создателями OpenDNS, - программа, позволяющая шифровать DNS-запросы. После ее установки на компьютер твои соединения также будут защищены и ты сможешь более безопасно бороздить просторы интернета. Конечно, DNSCrypt - это не панацея от всех проблем, а только одно из средств обеспечения безопасности. Для шифрования всего трафика все еще нужно использовать VPN-соединение, но в паре с DNSCrypt будет безопаснее. Если тебя такое краткое объяснение устроило, можешь сразу переходить к разделу, где я буду описывать установку и использование программы.
Попробуем разобраться глубже. Этот раздел предназначен для настоящих параноиков. Если ты ценишь свое время, тогда можешь сразу перей ти к установке программы.
Итак, как говорится, лучше один раз увидеть, чем сто раз услышать. Посмотри на рисунок.
Допустим, клиент (ноутбук на рисунке) пытается обратиться к google.com Первым делом он должен
разрешить символьное имя узла в IP-адрес. Если же конфигурация сети такова, что используется DNS-сервер провайдера (незашифрованное соединение, красная линия на рисунке), то разрешение символьного имени в IP-адрес происходит по незашифрованному соединению.
Да, какие данные ты будешь передавать на dkws.org.ua, никто не узнает. Но есть несколько очень неприятных моментов. Во-первых, провайдер, просмотрев логи DNS, сможет узнать, какие сайты ты посещал. Тебе это нужно? Вовторых, вероятна возможность атак DNS спуфинг и DNS снупинг. Подробно описывать их не буду, об этом уже написано множество статей. В двух словах ситуация может быть следующей: некто между тобой и провайдером может перехватить DNS-запрос (а так как запросы не шифруются, то перехватить запрос и прочитать его содержимое не составит никакого труда) и отправить тебе «поддельный» ответ. В результате вместо того, чтобы посетить google.com, ты перейдешь на сайт злоумышленника, как две капли воды похожий на тот, который тебе нужен, введешь свой пароль от форума, ну а дальше развитие событий, думаю, ясно.
Описанная ситуация называется DNS leaking («утечка DNS»). DNS leaking происходит, когда твоя система даже после соединения с VPN сервером или Tor продолжает запрашивать DNS серверы провайдера для разрешения доменных имен. Каждый раз, когда ты посещаешь новый сайт, соединяешься с новым сервером или запускаешь какое-то сетевое приложение, твоя система обращается к DNS провайдера, чтобы разрешить имя в IP. В итоге твой провайдер или любой желающий, находящийся на «последней миле», то есть между тобой и провайдером, может получить все имена узлов, к которым ты обращаешься. Приведенный выше вариант с подменой IP-адреса совсем жестокий, но в любом случае есть возможность отслеживать посещенные тобой узлы и использовать эту информацию в собственных целях.
Если ты «боишься» своего провайдера или просто не хочешь, чтобы он видел, какие сайты ты посещаешь, можешь (разумеется, кроме использования VPN и других средств защиты) дополнительно настроить свой компьютер на использование DNS серверов проекта OpenDNS (www.opendns.com). На данный момент это следующие серверы:
208.67.222.222
208.67.220.220
При этом тебе не нужно никакое другое дополнительное программное обеспечение. Просто настрой свою систему на использование этих DNS-серверов.
Но все равно остается проблема перехвата DNS-соединений. Да, ты уже обращаешься не к DNS провайдера, а к OpenDNS, но все еще можно перехватить пакеты и посмотреть, что в них. То есть при желании можно узнать, к каким узлам ты обращался.
Вот мы и подошли к DNSCrypt. Эта программулина позволяет зашифровать твое DNS соединение. Теперь твой провайдер (и все, кто между тобой и им) точно не узнает, какие сайты ты посещаешь! Еще раз повторюсь. Эта программа не замена Tor или VPN. По-прежнему остальные передаваемые тобой данные передаются без шифрования, если ты не используешь ни VPN, ни Tor. Программа шифрует только DNS трафик.
В КАЧЕСТВЕ ЗАКЛЮЧЕНИЯ
Статья получилась не очень большая, поскольку сама программа очень проста в использовании. Но она была бы неполной, если бы я не упомянул и о VPN. Если ты прочитал эту статью, тебя она заинтересовала, но ты еще не пользуешься услугами VPN-провайдера для шифрования своих данных, то самое время это сделать.
VPN-провайдер предоставит тебе безопасный туннель для передачи твоих данных, а DNSCrypt обеспечит защиту DNS-соединений. Конечно, услуги VPN провайдеров платны, но ведь за безопасность нужно платить?
Можно использовать, конечно, и Tor, но Tor работает относительно медленно, и это, как ни крути, не VPN - весь трафик «торифицировать» не получится. В любом случае (какой бы вариант ты ни выбрал) теперь твои 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), обычный ПК-маршрутизатор совершенно спокойно с этим справился.
Вы можете помочь и перевести немного средств на развитие сайта
С помощью nstx возможно создать IP-туннель внутри DNS. Одноименный протокол позволяющий достичь этого называется « » и расшифровывающийся как «NameServer Transfer Protocol ».
Итак, предположим, провайдер выдаёт и разрешает использовать вам свой сервер DNS. Представим обычный DNS запрос: мы запрашиваем информацию на сервере имен провайдера, сервер провайдера передаёт запрос другому серверу имен, который отвечает за нужную нам зону. А последний DNS-сервер, в цепочке, отправляет полученный ответ по тому же маршруту обратно.
А теперь представьте, что можно оформить IP-пакеты в DNS-запросы сервера имен и «сформировать» входящий трафик в нужные нам пакеты. И вот у нас уже есть все, что бы построить полноценный «IP over DNS» — свой собственный скрытый туннель для проброса трафика через почти любые сторонние файрволы!
Теперь остается только настроить фальшивый сервер имен и клиент, но на практике сделать это не всегда так просто.
Максимальный размер пакета, который можно передать — максимум 512 байт по протоколу UDP. Поэтому нам потребуется механизм сборщик / разборщик, который будет собирать и разбирать фрагментированные пакеты и проверять их на корректность. В такой схеме наш фальшивый DNS-клиент может связываться с нашим же фальшивым сервером DNS постоянно, а вот наш DNS-сервер может только отвечать. Поэтому клиент будет ответственен за сверку и поддержание двухсторонней связи.
Впервые, я попробовал сделать это в 2008 году. Две недели неспешно я разбирался с этим пакетом, правил исходных текст под себя, перечитывал руководства, и в результате — я получил работающий туннель успешно проложенный через сверхзащищенный файрволл нашей корпоративной сети. Тогда для меня это было просто невероятно!
Вообще, немного желания, времени, и вы самостоятельно можете запустить фальшивый сервер имен клиента для создания тоннеля «IP-over-DNS».
Играйтесь, пробуйте. Ищите способы защиты от этого. Заранее предупреждаю, что здесь очень много технических нюансов
Привет всем! Пришла пора посмотреть на трафик DNS через увеличительное стекло WireShark-а.
Напоминаю, что протокол DNS служит для преобразования понятного людям символьного имени, такого как, к примеру, сайт в IP адрес, на который выполняется запрос.
Качаем файл трафика. Открываем его в WireShark и смотрим:
Как видим, протокол DNS (в выделенной зоне он самый нижний – domain name system) является надстройкой в протокол UDP, лежащий на 4-ом уровне. То есть без установки постоянного соединения, а простой отправкой пакетов (дэйтаграмм). Как и TCP, протокол UDP имеет порты. Для DNS это порт с номером 53, что легко прослеживается в дереве протоколов.
Спускаемся ещё ниже, UDP протокол опирается на IP – протокол передачи между сетями. В настоящее время – основной протокол передачи данных в сети Internet. На этом уровне у нас имеется информация об IP-адресах источника и назначения. Ну и так же сведения об инкапсулированном пакете UDP.
В качестве адреса источника будет наша машина (запросившая информацию по DNS), а в качестве IP адреса назначения – сам DNS сервер, который (подразумевается), должен иметь базу данных таких соответствий.
В этой базе данных хранятся записи нескольких видов:
- A (host) – связывает имя узла и его IP адрес;
- AAAA (host) – связывает имя узла и его IPv6 адрес;
- CNAME (alias) – связывает имя узла и его псевдоним, для перенаправления на другое имя узла;
- MX (mail exchange) – указывает на IP адрес почтового сервера, обрабатывающего этот домен;
- NS (name server) – указывает на DNS-сервер, обслуживающим данный домен;
- SOA (start of authority) – указывает на начальную зону для этого домена, содержит IP основного DNS-сервера, адрес и контактные данные лица, владельца домена, временные метки и т.д.;
- PTR (pointer) – указатель на обратную связь, преобразующую IP адрес в каноническое имя;
- SRV (server) – указатель на различные сервисы;
- Полный список записей можно посмотреть на http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml
Итак, вернёмся к нашему запросу. Рассматриваем первый пакет:
Как видим, если развернуть дерево информации в анализе пакета, то видно, что поступил запрос (Queries), получения стандартной записи хоста (Type: A) по имени (Name: www.iana.org). То есть в переводе с DNS на русский будет так:
“Эй, 68.87.76.178 ! Сообщи-ка мне, какой IP у чувака по имени www.iana.org , хочу ему кое-что сообщить”.
Вот такие у них беседы протекают. На что сервер ему отвечат (пакет № 2):
Здесь мы видим ответ на вопрос. Иначе говоря, DNS-сервер отвечает хосту, отправившему запрос:
“Эй, 71.198.243.158 , ты спрашивал какой адрес у www.iana.org , так вот, его адрес 192.0.34.162 !, теперь пиши ему напрямую”
Детально тут так же следовало бы обратить внимание на поля Flags, которые показывают характеристики запросов и ответов:
Здесь я снова обратился к 1-ому пакету, в котором происходит запрос на сервер.
Обратите внимание на Transaction ID: Это числовое значение должно повториться в ответе, что будет означать, что ответ именно на этот запрос.
Стандартное двухбайтовое поле, значения которого складываются из бит:
- первый бит (1) показывает, что это запрос;
- 2-5 биты (4) – что это стандартный запрос;
- 7 бит (1) – что это не обрезанный запрос;
- 8 бит (1) – рекурсивный запрос (т.е. если наш ДНС-сервер не знает IP хоста, который мы запросили, он сам уже будет опрашивать другие DNS-сервера, пока не найдёт ответ;
- 10 бит (1) – зарезервирован;
- 12 бит (1) – принимать неавторитетные ответы. Авторитетным называется ответ от сервера, если тот заявляет, что сам обслуживает данную зону. Если же сервер получил ответ от других серверов, то такой ответ для нас является неавторитетным.
Теперь рассмотрим флаги ответа:
Обратите внимание на ID транзакции. Она совпадает с ID предыдущего пакета.
- Первый бит (1) – что это ответ;
- 2-5 биты (4) – стандартный ответ;
- 6 бит (1) – авторитетность ответа, если сервер сам обслуживает эту зону – вернётся “1”, если получил ответ из другого места – будет “0”;
- 7 бит (1) – укороченный пакет. На тот случай, если ответ не умещается в размер UDP датаграммы (512 байт);
- 8 бит (1) – желательно использование рекурсивных запросов. Если флаг будет стоять в “0”, то в ответе клиент получит список других серверов, от которых он может попытаться узнать нужную информацию.
- 9 бит (1) – сервер делает рекурсивные запросы;
- 10 бит (1) – зарезервирован;
- 11 бит (1) – получен авторитетный ответ, то есть сервер сам обслуживает эту зону;
- 12 бит (1) – принимать неавторитетные ответы?
- 13-16 биты (4) – код ошибки. Если 0, то всё в порядке.
Ну в целом разобрались со стандартными вопросами-ответами по DNS.
Кстати, существовал троян, который похищал данные с компьютера, отправляя их в виде DNS-запросов на сервер. Представляете себе, как это. Большинство файрволлов разрешает DNS, это ведь нормальная работа клиентского компьютера. А червяк под видом DNS-запросов отсылал на “левый” DNS-сервер приватные данные. Мол, “эй, сервер хозяина, скажи мне IP узла с именем “почта [email protected], пароль yyyyy”?”. А сервер фиксировал запросы и мог отправлять ничего не значащие ответы, тем самым записывая все запросы в какой-то файл. Количество DNS-запросов был большим и под их видом можно было передать мегабайты данных совершенно незаметно для пользователя. Если специально не прослушивать трафик, то утечку данных обнаружить не реально.
В браузерах, а в этой статье речь пойдет об утечке 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\”.
После чего откройте от имени администратора командною строку.
Запуск командной строки от имени администратора в Windows 10 Теперь в командной строке перейдите в папку 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)
