Подробности о атаке DNS leak.

Утечка IP DNS-сервера упоминалась на нашем сайте в описании DNS Crypt технологии. Но хотелось бы разобрать ее поподробнее и создать описание на русском. А также расписать ступени реализации самого сервиса по проверке на утечку.

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

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

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

Собственно поэтому утечка и возможна, ведь прикрыв свою машину посредником в виде прокси-сервера или VPN-соединения и др., мы скрываем ее адрес в сети, но не адрес ее DNS-сервера, которым по умолчанию является DNS-сервер у провайдера.
[ad name=»Responbl»]
Теперь важно отметить еще одну особенность, балгодаря которой возможно узнавать IP именно DNS-сервера машины, а не какого-то другого при обычно резолве. Эта особенность заключается в самой схеме резолва, то есть как работает «общение» между DNS-серверами в сети: наш сервер запрашивает адрес доменного имени site.com у ближайшего известного ему DNS-сервера, если тот знает, то возвращает, иначе возвращает адрес другого сервера (или серверов), который может это знать.

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

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

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

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

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

И решение напрашивается само собой — надо орагнизовать что-то вроде прокси для нашего DNS, а именно выставлять в настройках SOCKS4a, SOCKS5 или VPN использование DNS-серверов провайдеров этих прокси или VPN. Хотя у VPN это, как правило, стоит по умолчанию, но не всегда.

Реализация схемы DNS leak со стороны атакующего.
Представленная ниже схема будет общей, то есть без технических подробностей, а просто шаги чего нужно сделать, а детали можно узнать у гугла или по соответствующим ссылкам.
Чтобы смастерить свой сервис проверки на DNS leak, надо иметь как минимум одно доменное имя. Сам принцип такой:

• В настройках нашего домена прописываем ему IP нашего сервера, как IP DNS, который отвечает за этот домен;
• На наш сервер ставим какой-нибудь программынй DNS, можно Bind, но имхо DNSChef для этих целей будет удобней;
• Корректируем наш DNS-сервер так, чтобы на все входящие запросы отдавал один и тот же IP-адрес (адрес нашего сервера), и чтобы записывал адреса входящих запросов куда-нибудь в БД или файл вместе с запрашиваемым доменом (точнее поддоменом);
• Пишем скрипт, на сервре, который будет вести счетчик того, какие доменные имена он уже давал, а какие еще не были. Самое простое — для нашего домена site.com создавать поддомены 1.site.com, 2.site.com, 3.site.com и тд., а для определения следующего неиспользуемого брать последний поддомен, сохраненный нашим DNS-сервером и увеличивать его цифру каждый раз на единицу. Так каждый раз будет уникальный поддомен, гарантированно не кэшируемый ни одним из DNS-сервером в интернете;
• Написанный нами скрипт будет определять новое доменное имя и выдавать его в ответ на запрос в таком виде, чтобы клиенту его пришлось резолвить (например, в виде src картинки);

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

[ad name=»Responbl»]

Клиент по обычной схеме обращается через DNS своего провайдера к другим DNS, пока не дойдет до нашего DNS-сервера (а он так или иначе дойдет до него, так как он ответственный за наш домен).

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

А чтобы наш сервер узнавал, когда он получит DNS клиента, можно написать скрипт на стороне клиента (то есть JavaScript, отдающийся вместе со страницей в начале), который будет определять, когда загрузилась картинка (то есть произошел резолв, а следовтельно и утечка) и передавать через XMLHttpRequest серверу сигнальное сообщение, что тот может забирать из БД или логов нужный ему IP и делать с ним, что задумано (напрмер, отправка обратно клиенту и вывод у него в браузере).
Примерно по такой схеме и работают сервисы, тестирующие клиента на утечку DNS.