как резолвить ip адрес

Как резолвить ip адрес

Этот форум закрыт. Спасибо за участие!

Лучший отвечающий

Вопрос

Ответы

1.Ничего, что разные подсети? У вас прописана маршрутизация с сети 10.7.14.х в 10.1.77.83.

route print ф студию! Я думаю что все-таки из-за маршрутизации ноги ростут

2. В файрволе прописаны правила доступа к портам? можно думаю временно его выкл.

Все ответы

Dmitriy Poberezhniy (my web blog http://dimsan.blogspot.com)

ipconfig /all

Настройка протокола IP для Windows

nslookup mechservice.ru

Server: vm-dc-101.mechservice.ru
Address: 10.1.77.83

Name: mechservice.ru
Addresses: 10.1.77.83, 10.1.77.87, 10.1.165.6

из проводника.

ЗЫ. Повторюсь, я отлавливал исходящие пакеты с помощью Network Monitor.

Источник

Чиним резолвинг адресов в VPN-локалке (openconnect) для docker и systemd-resolved

systemd-resolved

Поставил пакеты network-manager-openconnect network-manager-openconnect-gnome
Настроил соединение и оно даже подключилось. Проблема первая, каждый раз когда я подключался снова, он забывал имя пользователя, что раздражает. Я нашел решение и создал
баг. Решение простое, с консоли задаем свое имя в особом виде nmcli con mod prgcvp vpn.secrets ‘form:main:username=yourName’,’save_passwords=yes’
После чего оно будет запомнено. Да, галочку «запомнить пароль» я ставил и пароль он даже запомнил, но вот в тексте галочки про имя пользователя ничего не сказано, так что он честно его забыл 🙂 Напомню, что настройки менеджера лежат в /etc/NetworkManager/system-connections/.

И если параметры знаешь, то можно и руками отредактировать нужное соединение.

Подключаться стало удобно и возникла вторая проблема, имена ресурсов в VPN сети не разрешаются в адреса DNS сервером. Сервер есть, все настройки на месте, но nslookup someserver.local выдает ошибку, а nslookup someserver.local somednsIP выдет правильный ответ. Странно, подумал я, как так, сервер есть, отвечает, а если его конкретно не указать, ошибка? Ответ оказался прост. Когда systemd-resolved пытается найти адрес сервера по имени, он выступает фасадом для других DNS серверов. Делается это так, ссылка /etc/resolv.conf может указывать на несколько мест:

Саму ссылку /etc/resolv.conf вы можете сами настроить что бы смотрела в любое из мест.
Так вот, дело в том, что openconnect при подключении к VPN получает таблицу route, DNS сервера, а так же search domain и этот домен от VPN сервера приходил неверный (так неправильно настроен у нас). От сервера приходило somedomain.local, а надо было просто local что бы somesrver.local был распознан.

Когда systemd-resolved прикинулся локальным DNS сервером и через /etc/resolv.conf всех отправил к себе за разрешением имен, логика его работы такова. Для каждого коннекта, которые можно посмотреть командой nmcli connection show (это те коннекты, которые знает NetworkManager) systemd-resolved помнит DNS сервера, которые получил по DHCP. Это можно посмотреть командой:

Когда в 127.0.0.53 приходит запрос на разрешение имени, systemd-resolved смотрит search domain у каждого из коннектов (эти домены он при подключении от DHCP получил тоже). Домены можно посмотреть командой:

Далее имя хоста проверяется на частичное совпадение с теми доменами, которые прикреплены к коннектам и самое длинное совпадение и определяет какой конкретно DNS сервер вызвать. Либо все идет в DNS сервер где search domain «

От сервера компании мне приходил неверный search domain (somedomain.local) для VPN коннекта и потому когда я пытался разрешить адрес someserver.local, systemd-resolved их не мог найти, так как предполагал, что DNS сервера, полученные из этого соединения нужны что бы распознавать имена someserver.somedomain.local. Поправил я это подменив search domain в NetworkManager командой
nmcli connection modify yourConnectionName ipv4.dns-search «local»
Доменов может быть несколько через пробел. В итоге все заработало.
Помимо этого я удалил пакет avahi-daemon, так как службы bonjur, которые обслуживает этот демон по умолчанию тоже резолвятся на домене local, а в нашей сетке именно это имя используется для локальной сети и будут конфликты.

docker

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

Контейнер запущен с network_mode: host в таком случае будет использоваться для резольвинга то, что лежит в /run/systemd/resolve/resolv.conf и там у меня первый же днс сервер выбирается для резольва local и он для этого не подходит. Итог, не работает. Зато все сервисы хост машины видно из контейнера, что еще и неправильно.

Контейнер запущен с network_mode: bridge с созданием отдельной сети. В таком случае сервисы хоста будет не видно, помимо этого будет использован все тот же не работающий у меня /run/systemd/resolve/resolv.conf

Контейнер запущен без настроек сети и использует дефолтный bridge, созданный докером при инсталляции (docker0). В этом случае используется для резольва имен внутренний докеровский DNS, который судя по всему нормально взаимодействует с systemd-resolved и все резолвит как надо. В /etc/resolv.conf будет такое:

Если надо показать сервисы хост машины для доступа из контейнера, то просто запускаем сервисы слушать на docker0 IP и получаем доступ.

Не забываем открыть порты, например у меня ufw зарезал 8080 и пришлось открывать.
Было бы отлично если бы docker просто использовал systemd-resolved dns stub как в последнем описанном варианте всегда. Но к сожалению это не так. В версии systemd-resolved 248, которая только вышла и в дистрах ее нет в документации есть параметр DNSStubListenerExtra, который может задать адрес где слушать для stub. Подробности тут.

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

Есть другое решение, когда контейнер пойдет на порт 53 мы будем перебрасывать его запросы в стаб systemd с помощью чего то вроде
socat UDP-LISTEN:53,fork,reuseaddr,bind=yourInterfaceIP UDP:127.0.0.53:53
Соответственно, этот DNS можно указать докеру при старте и весь функционал systemd будет работать. Но не стал это использовать.

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

Источник

Опасный резолв. Разбираем на пальцах три мощных вектора атак через 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

На самом деле браузеры пытались исправить такого рода атаки и ввели кеширование соответствия domain IP на 60 секунд. Теперь злоумышленнику необходимо продержать жертву на странице больше минуты, но, думаю, это не так сложно, ведь цель оправдывает средства.

А узнать, какие внутренние ресурсы доступны, можно с помощью проверки хеша браузера или с помощью вариации 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 (обычно после браузер перестает ходить по редиректам, хотя Хром выводит ошибку и продолжает ходить).

Создаем множество скрытых загрузок на различные порты и диапазоны адресов — и мы получаем отсканированную внутреннюю сеть. Если порт открыт, даже если это не HTTP, а, например, порт 3306 (MySQL), — браузер выведет ошибку и не будет больше переходить по редиректам. Посмотрев отсутствующие записи (браузер не отправил HTTP-пакет на этот адрес), можно прикинуть, какие порты открыты.

XSS-инжекты через DNS

Некоторое время назад как иностранные, так и русскоязычные СМИ рассказывали об атаке, в которой в качестве TXT-записи отдается XSS-вектор. Настраиваем TXT-запись подобным образом (только замени квадратные скобки вокруг [script] на угловые

Check Also

Microsoft исправила баг в Azure Container Instances

Эксперты Palo Alto Networks рассказали об уязвимости, получившей имя Azurescape. Проблема …

Источник

Resolve IP адресов в Linux: понятное и детальное описание

Настройка сетевого взаимодействия сервисов не самая простая задача и часто осуществляется без глубокого понимания как требуется настраивать систему и какие настройки на что влияют. После миграции сервисов в docker контейнерах с centos 6 на centos 7 я столкнулся со странным поведением вебсервера: он пытался присоединиться к сервису по IPv6, а сервис же слушал только IPv4 адрес. Стандартный совет в такой ситуации — отключить поддержку IPv6. Но это не поможет в ряде случаев. Каких? В этой статье я задался целью собрать и детально объяснить как приложения resolve ‘ят адреса.

Публикация будет полезна начинающим администраторам и разработчикам.

Прочитав эту статью, вы узнаете:

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

Теперь, когда у разработчика есть возможность вызвать функцию семейства getaddrinfo из glibc для определения адреса, то возникает потребность конфигурировать возвращаемые значения. Например, использовать ли сперва /etc/hosts или запрос к DNS-серверу. В glibc подобное конфигурирование производится с помощью схемы под названием Name Service Switch (NSS).

Если объяснять на пальцах, то NSS позволяет задавать базы данных и очередность поиска в этих базах для предоставления сервиса. В нашем случае, сервис — это поиск по hostname, а базой данных может выступать /etc/hosts или DNS сервер. Это не единственный сервис настраиваемый посредством NSS, предоставляются сервисы mail алиасов, сервис поиска пользователей и групп. Ознакомится со списком можно в руководстве.

Можно отметить, что для localhost имеются две записи: IPv4 и IPv6 адрес. Это может сыграть злую шутку и в конце материала я расскажу почему.

В мануале еще пишут про особую логику с обработкой хостнейма _gateway, но видимо это какой-то патч, так как с Centos 7 у меня он не завелся.

База mdns4_minimal или же mdns_minimal требуется для корректной работы Avahi. При необходимости можно обратиться к документации Arch по Avahi, где коротко и понятно дана информация
по использованию.

Теперь, когда дана информация по базам и принципам их работы стоит отметить отличия в определении адресов в разных инструментах, что приводит к проблемам в рантайме.

Обычно администраторы проверяют хостнейм используя команду host. Это некорректно, так host, как и dig, используют только DNS резолвинг, но не используют NSS. Nginx, например, использует функцию getaddrinfo, а она использует NSS. Это приводит к тому, что вбитый в /etc/hosts хостнейм может работать с nginx, но не резолвится иными способами. Куда хуже, когда в /etc/hosts вбиты IPv6 адрес для хостнейма, а в настройках DNS возвращается только IPv4 адрес. В этом случае, администратор может проверить что команда host возвращает только IPv4 адрес и успокоится, а потом приложение использующее getaddrinfo из glibc запустится и найдет для того же хостнейма IPv4 и IPv6 адрес. Источник ошибок…

Для проверки результатов возвращаемой каждой из баз документация рекомендует воспользоваться утилитой getent.

Ниже немного примеров работы с getent с включенным IPv6.

В /etc/nsswitch.conf содержится следующая цепочка баз:

В /etc/hosts содержится следующее инфо

Команда getent ahosts покажет список всех адресов которые удалось найти. С такими настройками она выведет следующее:

Команда позволяет точечно опросить конкретную базу и выяснить что срезолвит база. Рассмотрим для каждой базы возвращаемые значения:

Если убрать из /etc/hosts строки для localhost, то вывод видоизменится:

Теперь база dns и myhostname возвращает ответы, а база files не содержит данных. Для DNS запросов используется неймсервер конфигурируемый в /etc/resolv.conf в моем контейнере, например

На хост машине установлен dnsmasq который проксирует и кэширует ответы DNS серверов. Ответ от DNS будет зависеть от настроек DNS сервера к которому поступил запрос. RFC 1912 рекомендует в пункте 4.1 сконфигурировать DNS сервера таким образом, чтобы localhost указывал на 127.0.0.1.

Certain zones should always be present in nameserver configurations:

These are set up to either provide nameservice for «special»
addresses, or to help eliminate accidental queries for broadcast or
local address to be sent off to the root nameservers. All of these
files will contain NS and SOA records just like the other zone files
you maintain, the exception being that you can probably make the SOA
timers very long, since this data will never change.

The «localhost» address is a «special» address which always refers to
the local host. It should contain the following line:

В моем случае, dnsmasq из коробки содержит записи для localhost, как и рекомендует RFC.

Статус IPv6 на сервере можно получить из параметров ядра. Значение 0 возвращается при включенном IPv6, а 1 при выключенном.

В выводе ifconfig интерфейсы слушающие IPv6 содержат строчку inet6. Ниже пример вывода с выключенным и включенным IPv6 соответственно:

Выключить IPv6 можно вызовом

Воу, в первом выводе у нас дублируется адрес 127.0.0.1. Чтобы разобраться почему так происходит стоит обратиться к исходному коду glibc и к коду утилиты getent. Ниже кусок кода утилиты getent.

Флаг AI_V4MAPPED функции getaddrinfo производит маппинг IPv6 адресов на IPv4 если не были найдены IPv6 адреса в результате опроса базы. Флаг AI_ADDRCONFIG вынудит getaddrinfo проверить наличие IPv6/IPv4 адресов сконфигурированных в системе и в случае отсутствия хотя бы одного IPv6/IPv4 адреса не будет возвращаться IPv6/IPv4 независимо от того что ответит конкретная база.

Чтобы лучше понять эту концепцию, приведу примеры с выводом getaddrinfo на той же системе, с разными настройками ai_flags и ai_family. В /etc/hosts включены для localhost IPv4 и IPv6 адреса.
Исходный код можно найти на моем github.

Осталось проверить как ведет себя getaddrinfo для dns базы. Для этого оставлю в /etc/nsswitch.conf для hosts только dns базу и порезолвлю google.com. Вывод ниже с включенным IPv6.

А вот вывод с выключенным IPv6:

Как видно, ситуация с AI_ADDRCONFIG очень похожа.

Напоследок приведу пример как не учитывая все вышесказанное вляпаться в проблемы. IPv6 включен, /etc/nsswitch.conf стандартный.

Какой можно сделать вывод из всего написанного?

Источник

резолв адресов в браузере

Здравствуйте. Почему то стали долго резолвиться адреса в браузере (порой по 30 сек) использую chromium-browser. Интересно, что при пинге, например:

В чем могут быть проблемы?

На других браузерах не воспроизводится?

а когда решишь эту проблему, ставь dnsmasq 🙂

МесьЁ, 196.168. не может быть роутером, который подхватывает вышестоящий днс?

«Оно работает» (с) 🙂 А кривизна как всегда она в руках 🙂 А за pdnsd tnx, попробую

192.168.1.4 это сервер с настроенным bind9:

да вот кривенько оно работает, кеширует рандомно и может забывать через минуту.

эти самые руки настраивали pdnsd и там все работает как часы. А вот как раз к dnsmasq руки не притрагивались, ибо настроек там нифига нет, и работает оно из коробки в зависимости от погоды на Марсе.

какое подключение у тебя? Откуда этот самый манагер получает адреса dns?
Фишка может быть в том, что при старте хромого resolv.conf был другим.

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

я не заморачивался, оставил по дефолту. Один черт все закешируется

NetworkManager получает настройки от dhcp сервера, которые выглядят вот так:

так что с другими браузерами? Те же проблемы? Пока могу посоветовать тяжелую артиллерию в виде wireshark

Источник