Зарезолвить dns это как
Обновлено: 04.07.2024
Ситуация следующая:
в локальной сети есть Windows 2003 Server, на нем работает служба DNS.
на все локальные машины по DHCP раздается его IP-адрес в качестве основного (и единственного) DNS.
Проблема:
Все машины, кроме собственно этого сервера, могут резолвить имена в ip-адреса.
Ответ от 213.180.204.8: число байт=32 время=270мс TTL=56
Ответ от 213.180.204.8: число байт=32 время=139мс TTL=56
.
Если же подобную операцию проделать на самом сервере, то МГНОВЕННО получаю ответ
Но по ip-адресу все прекрасно резолвится и, соответственно, пингуется:
Обмен пакетами с 213.180.204.8 по с 32 байт данных:
Ответ от 213.180.204.8: число байт=32 время=141мс TTL=56
Ответ от 213.180.204.8: число байт=32 время=489мс TTL=56
.
Обмен пакетами с 192.168.0.1 по с 32 байт данных:
Ответ от 192.168.0.1: число байт=32 время<1мс TTL=128
Ответ от 192.168.0.1: число байт=32 время<1мс TTL=128
.
Вот конфигурация с сервера
Настройка протокола IP для Windows
Имя компьютера . . . . . . . . . : server
Основной DNS-суффикс . . . . . . : lan
Тип узла. . . . . . . . . . . . . : неизвестный
IP-маршрутизация включена . . . . : нет
WINS-прокси включен . . . . . . . : нет
Порядок просмотра суффиксов DNS . : lan
NIC1 - Ethernet адаптер:
DNS-суффикс этого подключения . . :
Описание . . . . . . . . . . . . : Generic Marvell Yukon Chipset based Gigabit Ethernet Controller
Физический адрес. . . . . . . . . : 00-0E-0C-3B-A0-3A
DHCP включен. . . . . . . . . . . : нет
IP-адрес . . . . . . . . . . . . : 192.168.0.253
Маска подсети . . . . . . . . . . : 255.255.255.0
Основной шлюз . . . . . . . . . . : 192.168.0.254
DNS-серверы . . . . . . . . . . . : 192.168.0.253
Примечание: за день до появления этой проблемы на сервере пришлось сделать
netsh int ip reset
netsh winsock reset
и заново перенастроить ип-адреса.
Замечу также, что сам сервер с ДРУГИХ компьютеров резолвится по имени, т.е.
Обмен пакетами с server [192.168.0.253] по с 32 байт данных:
Ответ от 192.168.0.253: число байт=32 время<1мс TTL=128
Ответ от 192.168.0.253: число байт=32 время<1мс TTL=128
.
Также на сервере установлен mail-server (MDaemon), который прекрасно работает и отвечает как с и-нета, так и локально.
Просто в дальнейшем сетка полностью "перебазируется" на резолвинг только по DNS
Тут дело в другом - но в чём именно не ясно.
По идее такого быть не должно, но если работает у Jilted, тогда я вообще ничего не понимаю. Куда хоть копать?
Единственный момент, но о нём я упомянул еще в самом вопросе, так это
netsh int ip reset
netsh winsock reset
Я думаю что собака где-то здесь порылась и не признается
Там досутпно описано как это происходит, правда на английском. Но если в кратце, то поведение при резолве прямо зависит от Node Type. Но мы тут уже вяснили что в данном случае Node Type тут не при чем.
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 отвечает на произвольное доменное имя, — расскажи разработчикам об этой атаке :).
А узнать, какие внутренние ресурсы доступны, можно с помощью проверки хеша браузера или с помощью вариации CSS History Hack. Последнюю использовали в исследовании этой уязвимости PTsecurity (ссылки на материалы, как всегда, в конце статьи). Но можно воспользоваться и еще одной фичей.
Как мы выяснили, если доменное имя имеет несколько IP-адресов, то браузер (или другой клиент) при недоступности первой записи переходит на вторую.
Тема такая. Специально настроенный сервер DNS возвращает на доменное имя злоумышленника подобные записи:
Теперь смотри. Когда жертва открывает страницу злоумышленника, на странице находится картинка, которая должна загрузиться с адреса test.evil.host, браузер резолвит доменное имя и получает массив IP-адресов.
Первым он пытается открыть 192.168.1.1:80, которого нет в нашей сети. Недоступен? Идет дальше и открывает 192.168.1.1.evil.host. Так как это подконтрольный сервер, мы фиксируем, что такого IP-адреса с таким портом нет.
И-и-и. Делаем перенаправление на test2.evil.host! И так до тех пор, пока ответа не будет или количество редиректов не достигнет 20 (обычно после браузер перестает ходить по редиректам, хотя Хром выводит ошибку и продолжает ходить).
XSS-инжекты через DNS
Некоторое время назад как иностранные, так и русскоязычные СМИ рассказывали об атаке, в которой в качестве TXT-записи отдается XSS-вектор. Настраиваем TXT-запись подобным образом (только замени квадратные скобки вокруг [script] на угловые <script>):
и там, где веб-приложение показывает эту запись, скрипт выполнится. Разумеется, если не фильтруются спецсимволы в пользовательских данных.
«А что тут такого?» — подумал я. У меня XSS-вектор в домене висит полдесятка лет (еще Agava не может ее нормально пофиксить, алерт вылезает прямо в кабинете), ведь завести подобную запись можно в любой панели управления. А как насчет других записей?
Вот что отдавал мой DNS-сервер
Самое смешное, что в самом начале теста я завел запись
(IP-адрес ns.hack нужно получить у домена ns.hack). И попробовал посовать этот домен во всякие формы сайтов. Ну и что ты думаешь?
Часть DNS-клиентов стала рекурсивно запрашивать у меня записи, а когда лог достиг сотни мегабайт, эксперимент пришлось прервать. Технологии используются несколько десятков лет, а поломать все можно логической ловушкой, ну офигеть теперь!
Ну ладно, продолжим. Открываем dnschef.ini, пишем туда следующий конфиг (опять же, не забудь заменить скобки для [script]):
Также на сервере может быть закрыт доступ на 80/443-й порт, а DNS обычно открыт. Используя все эти трюки, я составил такой RCE-полиглот:
Команда ping выполнится на один из моих доменных имен, но, чтобы узнать, какой IP у домена, он придет ко мне — тут-то я и увижу, что выполнение произвольного кода сработало. Иду в конфиг, делаю так:
Ну и что? А ничего. Посовал на всяких сайтах домен, а отстука о выполнении произвольного кода нет. Не было. Где-то неделю. А потом та-да-ам!
Логи запросов с сервера
Действительно, кто-то собирал соответствие домен — запись и недостаточным образом фильтровал данные от DNS-сервера. Так может, таким образом можно и Shodan хакнуть? 🙂
Outro
Куда еще копать? DNS-туннели, DNS hijacking, OOB attacks, DNS cache poisoning, DNS flood. Я уверен, что можно таким образом выполнять SQL-инъекции и их будет много больше, — правда, это получается совсем вслепую. Хотя, может, попробуешь OOB-вектор в MS SQL?
Почему-то не определяются IP с DNS, хотя адрес DNS вроде прописан и связь с ним есть. Вот содержимое конфигов:
search local nameserver 192.168.0.14
allow-hotplug eth0 iface eth0 inet static
Маршрутизатор работает нормлано, т.е. пинг до любого хоста по IP идет, а по имени нет.
Система на Debian 5.0, DNS на Win2k3 сервере.
В чём трабл никак не пойму. Как можно определить причину?
Да как бы DNS на AD под Win2k3 и моя виндовая раб.(очень точное сокращение :-)) станция все пингует нормально.
Но я уже разобрался: забыл про
domain domain.local вместо search local
А то что инет адреса не пингуются это заморочки с форвардингом к DNS провов.
Так что всем спасибо, проблема решена.
Хотя нет, проблема одна осталась: нет пингов по ping domain.local. Ping host или ping host.domain.local есть, а ping domain.local нет. Или их и не должно быть (всетаки не винда)?
ну так
dig domain.local что пишет?
лучше использовать search domain.local local
всё должно быть, если настроено нормально
с винды для тестов nslookup
>Как можно определить причину?
dig domain.local +qr +search +recurse +showsearch
как-то так
Или я чего-то недопонимаю или как-то топорно резолв работает. ping domain есть, ping domain.local отсутствует, dig domain.local срабатывает. Такое ощущение, что к указанному имени сразу лепится что-то и search, а не делается сначала попытка найти запись как есть.
search local nameserver 192.168.0.14
чо, так в одну строку и прописано? nameserver с новой строки надо.
nslookup нормально срабатывает при любой форме записи.
Видимо это какие-то недоработки утилиты ping.
если хочется как есть, то писать надо ping domain.local. с последней точкой, вроде так должно работать
Проверил, не работает. :)
Ну сделай strace ping chmz.local, и посмотри, чего ему не хватает
по ип пингуется?
тогда только tcpdump в помощь и dig с выводом пакетов запроса
Прочтите это руководство, чтобы узнать, как внести постоянные изменения DNS в resolv.conf на Linux.
Файл предназначен для чтения человеком и содержит список ключевых слов со значениями, которые предоставляют различные типы информации о резолвере.
Файл конфигурации считается надежным источником информации DNS (например, информация о битах AD DNSSEC будет возвращена из этого источника без изменений).
Если этот файл не существует, будет опрошен только сервер имен (nameserver) на локальном компьютере, а список search будет содержать имя локального домена, определенное по имени хоста.
Внесем постоянные изменения DNS в resolv.conf
Внесем постоянные изменения DNS в resolv.conf
Любые изменения, внесенные вручную в файл конфигурации /etc/resolv.conf, обязательно будут перезаписаны при изменениях в сети или перезагрузке системы.
Согласно комментариям, сделанным в файле, файл является динамическим. «DO NOT EDIT THIS FILE BY HAND — YOUR CHANGES WILL BE OVERWRITTEN».
Итак, возьмем, к примеру, если вы хотите добавить DNS-сервер в свой Linux-сервер, вы обычно обновляете этот файл, указывая IP-адрес сервера имен, который должен запрашивать резолвер.
См. Приведенную ниже команду, которая обновляет файл resolv.conf общедоступным первичным DNS-сервером Google DNS, выполнив такую команду:
Использование фреймворка Resolvconf
Он настраивается как посредник между программами, которые предоставляют эту информацию (такими как ifup и ifdown, DHCP-клиенты, демон PPP и локальные серверы имен) и программами, которые используют эту информацию, такими как кэши DNS и библиотеки resolver).
В дистрибутивах Ubuntu/Debian вы можете установить resolvconf, выполнив команду ниже;
После установки фреймворк стартует и запускается при загрузке системы.
Затем отредактируйте файл конфигурации /etc/resolvconf/resolv.conf.d/base и введите настройки DNS.
Затем обновите файл /etc/resolv.conf, чтобы внести постоянные изменения в DNS:
Обновление настроек DNS-сервера в dhclient.conf
Если вы используете DHCPd для автоматического назначения IP-адреса, отредактируйте файл /etc/dhcp/dhclient.conf и добавьте следующую строку;
supersede domain-name-servers IP1, IP2;
Замените IP1 и IP2 соответствующими IP-адресами DNS:
Сохраните файл и выйдите.
Теперь, если вы запустите dhclient, ваш /etc/resolv.conf будет обновлен с использованием серверов DNS, определенных в dhclient.conf.
Вы можете использовать опцию prepend вместо supersede, чтобы добавить дополнительные IP-адреса к IP-адресу по умолчанию, предоставленному интернет-провайдером.
Как уcтановить IP-адрес сервера имен в настройках вашего интерфейса.
Отредактируйте файл конфигурации сетевого интерфейса и добавьте адрес сервера имен.
В Ubuntu 18.04/20.04 вы должны обновить файл конфигурации Netplan, например:
Мы устанавили DNS на публичный адрес DNS-сервера Google, 8.8.8.8.
В вашем случае все может быть иначе.
Перезапустите сеть, чтобы изменения вступили в силу;
На CentOS и аналогичных производных отредактируйте соответствующий интерфейс следующим образом.
Замените INTERFACE своим именем интерфейса.
Также отключите управление сетевым интерфейсом с помощью демона NetworkManager.
Читайте также: