как отключить защиту от dns rebinding?

[Andrew Dolgov]

keenetic viva, 3.6.12.

столкнулся с ситуацией, что рабочие станции в сети не могут отрезолвить KDC (и еще много что), похоже что ввиду навязчивой заботы разработчиков KeeneticOS, которые в одностороннем порядке запретили мне держать в днс записи, ведущие на зарезервированные диапазоны айпи адресов:

Nov 22 12:12:37 172.17.172.254 ndnproxy: possible DNS-rebind attack detected: "kdc.example.org." IN A "172.17.172.12" (client 172.17.172.1)

naboo:~:$ host -v kdc.example.org 172.17.172.254
Trying "kdc.example.org"
Using domain server:
Name: 172.17.172.254
Address: 172.17.172.254#53
Aliases:

Host kdc.example.org not found: 5(REFUSED)

Received 34 bytes from 172.17.172.254#53 in 518 ms

аналогично и с прямым запросом на днс сервер, отвечающий за зону:

naboo:~:$ host  kdc.example.org luke.ns.cloudflare.com
Using domain server:
Name: luke.ns.cloudflare.com
Address: 2803:f800:50::6ca2:c1c8#53
Aliases:

Host kdc.example.org not found: 5(REFUSED)

зона живет на клаудфларе, домен принадлежит мне. резолв идет через запущенный в entware dnsmasq+stubby (DoT).

интересно, по мнению разработчиков, какое должно быть решение этой проблемы?

- не держать сервера в локалке?

- выдать каждому серверу белый IP?

- иметь отдельный днс сервер в локалке с отдельным поддоменом для неё?

- заменить кинетик на роутер, который не пытается быть умнее Папы Римского?

- что-то ещё?

второй вопрос: opkg dns-override в теории должен отключить встроенный днс форвардер кинетика и освободить 53ий порт для днс сервера в opkg/entware. почему при этом описанная выше фильтрация не отключается?

я зарепортил вышеописанную ситуацию через https://help.keenetic.com/ (тикет 566790).

Изменено 22 ноября, 2021 пользователем Andrew Dolgov

[sergeyk]

35 минут назад, Andrew Dolgov сказал:

- что-то ещё?

 

(config)> no dns-proxy rebind-protect
Dns::Manager: Disabled rebind protection.

 

[Andrew Dolgov]

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

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

алсо, мне всё еще непонятно почему днс прокси работает при включенном opkg dns-override.

 

Изменено 22 ноября, 2021 пользователем Andrew Dolgov

[Andrew Dolgov]

кстати, я сейчас пролистал ченжлоги всех версий от 3.6.12 до 3.6.1 включительно, и там нет никаких упоминаний защиты от dns rebinding вообще, я уж молчу про изменения её работы по умолчанию (которые явно произошли, т.к. до недавнего времени резолв работал нормально и жалоб от пользователей не было) и то как ее отключить.

[Le ecureuil]

5 минут назад, Andrew Dolgov сказал:

кстати, я сейчас пролистал ченжлоги всех версий от 3.6.12 до 3.6.1 включительно, и там нет никаких упоминаний защиты от dns rebinding вообще, я уж молчу про изменения её работы по умолчанию (которые явно произошли, т.к. до недавнего времени резолв работал нормально и жалоб от пользователей не было) и то как ее отключить.

Включено еще со времен самой первой 3.4: https://help.keenetic.com/hc/ru/articles/360013779360-Информация-о-релизе-KeeneticOS-3-4-1

[Le ecureuil]

20 минут назад, Andrew Dolgov сказал:

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

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

алсо, мне всё еще непонятно почему днс прокси работает при включенном opkg dns-override.

 

1. Ломающие изменения произошли почти два года назад.

2. Циски не для конечных пользователей и вообще без какой-либо конфигурации не используются.

3. Для внутренних нужд.

 

Жалобы на включенную защиту от rebind минимальны, вы второй  или третий на моей памяти, кому это повредило.

[Le ecureuil]

1 час назад, Andrew Dolgov сказал:

интересно, по мнению разработчиков, какое должно быть решение этой проблемы?

- не держать сервера в локалке?

- выдать каждому серверу белый IP?

- иметь отдельный днс сервер в локалке с отдельным поддоменом для неё?

- заменить кинетик на роутер, который не пытается быть умнее Папы Римского?

- что-то ещё?

Почему нет опции "просто выключить и продолжать использование"?

[Andrew Dolgov]

10 minutes ago, Le ecureuil said:

Ломающие изменения произошли почти два года назад.

почему тогда сломалось только сейчас?

10 minutes ago, Le ecureuil said:

Циски не для конечных пользователей и вообще без какой-либо конфигурации не используются.

это не аргумент. Juniper SRX поставляется с дефолтной конфигурацией работающей для типового бранча из коробки без настроек вообще. можно ничего не настраивать, просто воткнуть пипку от провайдера в один порт, и локалочников в другие. при этом он почему-то не пытается быть самым умным и молча подменять транзитный трафик на ложное сообщение REFUSED, который сервер на самом не отправлял.

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

сегодня фальшивый REFUSED, завтра фальшивый HTTP 401. как это вообще предполагается отлаживать, обвешивать кинетики с двух сторон тцпдампом?

9 minutes ago, Le ecureuil said:

Почему нет опции "просто выключить и продолжать использование"?

я пока так и не понял где мне узнать про эту опцию, кроме как спросив на форуме. поддержка мне до сих пор не ответила. для придания легкой остроте ситуации давайте предположим что в данный момент 16384 пользователей локалки не могут получить доступ к KDC, со всеми вытекающими последствиями.

Изменено 22 ноября, 2021 пользователем Andrew Dolgov

[Le ecureuil]

59 минут назад, Andrew Dolgov сказал:

почему тогда сломалось только сейчас?

Могу задать к вам аналогичный вопрос. Если обновлялись с < 3.3, тогда еще можно объяснить, остальное гадание.

 

59 минут назад, Andrew Dolgov сказал:

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

сегодня фальшивый REFUSED, завтра фальшивый HTTP 401. как это вообще предполагается отлаживать, обвешивать кинетики с двух сторон тцпдампом?

я пока так и не понял где мне узнать про эту опцию, кроме как спросив на форуме. поддержка мне до сих пор не ответила. для придания легкой остроте ситуации давайте предположим что в данный момент 16384 пользователей локалки не могут получить доступ к KDC, со всеми вытекающими последствиями.

1. В changelog было отражено, и на форуме, и в официальном. Причем на форуме и с командами для отключения сразу.

2. Запрос в поддержку был написан в 11:55, ответ вам еще не успели подготовить, вопросов много. Мы с вами вроде SLA на "ответ по существу через 10 минут" не подписывали. Причем даже здесь ответили быстро и по теме.

[Andrew Dolgov]

12 minutes ago, Le ecureuil said:

Причем даже здесь ответили быстро и по теме.

да, за это еще раз спасибо, ваш пост спас положение

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

а есть рсс фид для ченжлогов?

ред:

172.17.172.254.log.4.gz:Oct 26 13:24:39 172.17.172.254 ndm: Dns::Manager: enabled rebind protection.

т.е. включено-то оно было давно. но при этом никаких проблем с резолвом не было. сейчас посмотрел, роутер ребутался 2 недели назад. :shrug:

Изменено 22 ноября, 2021 пользователем Andrew Dolgov

[Le ecureuil]

Как минимум можно подписаться на любую из тем в "Журнал изменений" или создать свой кастомный поток по темам из Журнала, там и RSS есть.

[DeniDoman]

Привет! Очень люблю Кинетики, и хочу сказать спасибо всей команде (и технарям, и не-технарям) за такой классный продукт. Искренне желаю вам развития и процветания. Это мой первый коммент на форуме, поэтому позволил себе такой вот оффтоп

Теперь к делу. Я хочу поделиться своим болезненным опытом, связанным с этой фичей. Сейчас все популярнее становится selfhosting тематика, тем более что Raspberry PI позволяет это реализовать за адекватные деньги. А там и home assistant, и Pi-hole для блокировки рекламы на уровне DNS, и всякие Nginx-ы с красивым UI для настройки доменов.

Собственно, захотел чтобы все было "как у людей" - и для захода в админку какого-то сервиса, вместо неуклюжего 192.168.1.10:12345, можно было бы написать симпатичное service.home.lab. Тем более что и Pi-hole, и AdGuard Home, помимо блокировки рекламы, позволяют делать DNS Rewrite. А Nginx, в режиме реверс-прокси, успешно роутит в нужный порт. 

Я сделал все по инструкции:

• Поднял свой DNS-сервер на 192.168.1.3
• Прописал его в Кинетике как основной, запретив остальные
• В DNS-сервере настроил Rewrite, чтобы service.home.lab домен шел на 192.168.1.3 домен
• В конфигурации Nginx (который слушает порты 809 и 443) прописал чтобы запросы на service.home.lab роутились на порт 12345

И не работает. 3 вечера я сидел, разбирался, менял настройки фаервола в Docker контейнерах и на самом сервере. Пока, наконец, не зашел от безысходности в логи роутера, и не увидел роковую надпись possible DNS-rebind attack detected. Дальше нагуглил эту тему, выключил и все заработало. 

Я благодарен вам за эту защиту, но очень хочу попросить команду разработки: Пожалуйста, сделайте эту функциональность более очевидной для пользователя. Я бы хотел узнавать об этой специфике из UI, когда сетапил DNS сервер. Вы же видите, что введенный DNS адрес находится во внутренней сети - показывайте, пожалуйста, попап, что нужно выключить вашу защиту. А лучше сразу создавайте правила для ndnproxy, чтобы у юзера в принципе не было проблем с локальным DNS сервером. 

Еще раз спасибо за продукт и за этот форум. Здорово, что нашел решение, но жаль, что потратил столько времени. 

Изменено 25 февраля, 2023 пользователем DeniDoman

[nstddd]

On 11/22/2021 at 5:38 PM, Le ecureuil said:

вы второй  или третий на моей памяти

Буду четвертым или пятым тогда.

Прошу добавить эту штуку в UI для более понятной конфигурации.

Вечером всё настроил - было ок, на утро всё отвалилось без явных причин.
Также часа 3 сидел с этой проблемой, пока не решил заюзать старый tp-link, где все хорошо, на кинетике - нет. Тут то и дошло, что нужно глядеть в логи роутера, где нашел это сообщение и, соответственно, эту тему.