Перейти к содержанию

Вопрос

Опубликовано

Можно ли стандартными средствами (может с помощью CLI) запретить DNS на роутере резолвить адреса из локальной сети и localhost или придется возиться с установкой сторонних DNS типа dnsmasq? Интерес связан с предотвращением атаки DNS Rebinding. Вообще неплохо было бы добавить такую возможность в интерфейс (хотя бы в виде какой-нибудь галочки).

  • Спасибо 1

Рекомендуемые сообщения

  • 0
Опубликовано
В 30.10.2019 в 21:48, SecretSanta сказал:

Можно ли стандартными средствами (может с помощью CLI) запретить DNS на роутере резолвить адреса из локальной сети и localhost или придется возиться с установкой сторонних DNS типа dnsmasq? Интерес связан с предотвращением атаки DNS Rebinding. Вообще неплохо было бы добавить такую возможность в интерфейс (хотя бы в виде какой-нибудь галочки).

Давайте подробнее. Если вы про уязвимость в ПО верндора M, то у нас работает заметно иначе.

Потому начните с того, что наблюдаете и почему это по-вашему мнению не так.

  • 0
Опубликовано (изменено)

Есть такая атака - DNS Rebinding. Она позволяет залезть внутрь периметра файервола. Если кратко, то суть в следующем: атакующий владеет доменом attack.com и DNS-сервером, обслуживающим этом домен. Когда вы заходите на этот сайт (DNS-сервер резолвит attack.com как, допустим, 5.5.5.5), вы скачиваете некий javascript. Предварительно атакующий ставит очень короткий TTL для этой А-записи. За это время он успевает поменять эту А-запись с 5.5.5.5 на, например, 127.0.0.1 или какой-нибудь адрес в LAN. Соответственно, когда TTL истекает, браузер повторно делает запрос на резолвинг attack.com и вместо 5.5.5.5 получает 127.0.0.1. А теперь самое интересное: если у вас на локалхосте или локалке крутится какой-нибудь веб-сервер или сервис с API, для работы с которыми не нужно авторизовываться, атакующий может делать к ним запросы и потом полученные данные пересылать себе посредством того самого javascript. Есть хорошая статья с диаграммами, где это более понятно и подробно описано в т.ч. с примерами.
Атака не самая простая и дешевая, да и чисто технически это не проблема роутера или прошивки, а скорее веб-сервисов, не требующих авторизации, и вы здесь не причем. Но учитываю распространение всяких в том числе IoT-устройств, которые перестают поддерживаться очень быстро, где нельзя самому прикрутить какие-нибудь креденшиалсы или проверку заголовка Host и которые, располагаясь в локалке или локалхосте, могут способствовать сливу всяких чувствительных данных, может есть смысл с вашей сторону добавить опцию, позволяющую отбрасывать ответы от апстрим серверов, возвращающих адреса из частных диапозонов.

Изменено пользователем SecretSanta
  • Спасибо 2
  • 0
Опубликовано

Отлично, спасибо за рассказ.

Насчет опции можно подумать, посмотрите на команды настройки dns в cli guide, и опишите, как она должна по-вашему выглядеть.

И еще - а это только с заданными собственноручно DNS такое проворачивать, или с провайдерскими тоже?

Ну и каких адресов это должно касаться? Только 127.0.0.0/8 или еще и из RFC1918 прихватывать?

  • 0
Опубликовано (изменено)

1. А что вы используете в качестве DNS-сервера на роутере? Что-то самописное или какой-то из относительно стандартных пакет типа dnsmasq, bind9, unbound? Вполне возможно, что там это уже реализовано в том или иной мере. Например, в dnsmasq есть ключ stop-dns-rebind. На тот случай, если пользователь имеет на локалхосте или в локалке какой-то сервис с настроенным доменным именем, можно их добавить в исключения соответветственно ключами rebind-localhost-ok и rebind-domain-ok=[<domain>]|[[/<domain>/[<domain>/].

2. Вообще говоря от любого upstream сервера надо ответы с адресами из приватных диапазонов отбрасывать. Отдельные DNS-сервера могут иметь подобную защиту (например, вроде OpenDNS), может и провайдеры отдельные промышяют чем-то подобным, но я б не стал на это надеяться.

3. И 127.0.0.0/8, и приватные диапазоны из RFC1918, да. Насчет реализации тут вам решать: можно, конечно, из всех этих диапазонов отбрасывать; можно посмотреть какой диапазон использует пользователь в локалке у себя и исключать только его. Я бы, наверно, захардкодил все диапазоны приватные на всякий случай. Это и проще.

P. S. Я не специалист по сетям или ИБ, просто интересующийся так сказать. Я, конечно, понимаю как это должно работать (вроде бы... :) ), но если вы все-таки возьметесь это реализовывать, крайне рекомендую ознакомиться со статьей из моего предыдущего ответа, там действительно очень хорошо все описано и объяснено.

Изменено пользователем SecretSanta
  • Спасибо 1
  • 0
Опубликовано

Просто так взять и отбрасывать в настройках по-умолчанию нельзя:

- USB модемы висят на приватных сетях, разрешая свое доменное имя в приватный диапазон, или вообще перехватывая все подряд домены на себя для captive portal
- провайдеры с L2TP/PPTP (Билайн - уже засел у всех в голове как пример) используют серые адреса в своих сетях, которые работают через разрешение в доменных имен

Но как отдельную галку для тех, кто уверен, что ему это точно никогда не будет нужно - сделать наверное стоит.

  • Спасибо 1
  • 0
Опубликовано

Я не совсем понял, что вы имете в виду под этими двумя примерами. Если то, что провайдеры (а-ля Билайн) и USB-модемы крутят какие-то ресурсы с доменными именами, привязанными к адресам из частных диапозонов - однозначно надо делать команду (опцию), позволяющую определнные доменные имена добавлять в исключения (чтобы они нормально резолвились). Если имелось в виду что-то другое, то прошу прощения - я не настоящий тракторист :) .

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

Ну и вы абсолютно правы, что по умолчанию врубать это все не стоит.

  • Спасибо 1
Гость
Эта тема закрыта для публикации ответов.
  • Последние посетители   0 пользователей онлайн

    • Ни одного зарегистрированного пользователя не просматривает данную страницу
×
×
  • Создать...

Важная информация

На этом сайте используются файлы cookie. Нажимая "Я принимаю" или продолжая просмотр сайта, вы разрешаете их использование: Политика конфиденциальности.