Jump to content
  • 5

Запрет резолвинга адресов из локальной сети (DNS Rebinding)


SecretSanta

Question

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

  • Thanks 1
Link to comment
Share on other sites

8 answers to this question

Recommended Posts

  • 0
В 30.10.2019 в 21:48, SecretSanta сказал:

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

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

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

Link to comment
Share on other sites

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

Edited by SecretSanta
  • Thanks 2
Link to comment
Share on other sites

  • 0

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

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

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

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

Link to comment
Share on other sites

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

Edited by SecretSanta
  • Thanks 1
Link to comment
Share on other sites

  • 0

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

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

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

  • Thanks 1
Link to comment
Share on other sites

  • 0

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

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

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

  • Thanks 1
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...