Jump to content
  • 0

KeenDNS Cloud


Denis_____
 Share

Question

1. Как я понял, если ISP выдает серый IP адрес есть возможность пройти за NAT к маршрутизатору через DyDNS, в частности - встроенный KeenDNS. Его я настроил, все работает. Вопрос в том, что подключение идет на 80 порт -> авторизация там basic, просто в base64 кодируются login:password. Достаточно перехватить пакет авторизации и данные учетки утекут. Получается, что при работе через мобильное приложение тоже используется такая система? Если да, то как переопределить такое поведение - кроме как поднять VPN только для этой цели, это слишком накладно будет.

2. Вопрос связан с предыдущим: если настроить проброс портов в KeenDNS для, например, transmission, встроенного в NDMS, то соединение инициируется тоже через 80 порт и тоже через Basic Autorization. Вопрос как переопределить, если это возможно.

3. Тоже связанный вопрос: поставил Debian в OPKG, настроил проброс на 22 порт кинетика в KeenDNS, но подключиться не могу. То есть клиентский ssh видит, что соединение открыто, но через какое-то время "Connection closed by foreign host". В локалке все нормально работает если подключиться к 192.168.1.1:22

PS: если зайти с браузера на URL ssh-а, то всегда было "не могу открыть страницу", кроме 1 раза, тогда было вот что:

То есть протокол браузер даже увидел.

IMG_1946.jpg

Edited by Denis_____
PS
Link to comment
Share on other sites

12 answers to this question

Recommended Posts

  • 0

пп. 1 и 2 — Вы неправильно поняли, не вводите никого в заблуждение! При работе через KeenDNS и мобильное приложение данные зашифрованы (в первом случае HTTPS до облачного сервера, во втором случае — RSA + AES-шифрование). Также в новом веб-интерфейсе используется авторизация через Cookie/Nonce/Hash, пароль в открытом виде не передается даже при обращении на порт 80 без HTTPS. Вдобавок на имя KeenDNS вида keenetic.link и keenetic.pro автоматически ставится сертификат безопасности HTTPS от Let's Encrypt, после чего сессия SSL начинает устанавливаться через облачный сервис end-to-end. Ну а интерфейс transmission проксируется через https://{имя_keenDNS}/app/transmission и работает под тем же самым сертификатом.

Link to comment
Share on other sites

  • 0
4 часа назад, ndm сказал:

в первом случае HTTPS до облачного сервера

По запросу myname.mykeenetic.com:443 (порт для https) страница не грузится. По http-запросу на 80 порт - да, digest-auth со всеми этими

 

4 часа назад, ndm сказал:

Cookie/Nonce/Hash

, причем иногда все же сбрасывается до basic auth (трафик смотрел wireshark-ом). Трафик с мобильного приложения не ловится (странно), по этому поводу ничего сказать не могу.

Идея начет SSL - круто, только у меня версия 2.08 (последняя). Бета-канал тоже не выбирается, говорит 404.

Насчет ssh - понятно, но разве облако не просто проксирует sshAccess.keeneticName.mykeenetic.com: -> 192.168.1.1:22, где sshAccess - доменное имя 4 уровня, настроенное во вкладе KeenDNS? Как тогда иначе работает эта фича?

PS: учитывая скорость перебора md5 на гпу и ограничение в 32 символа на пароль, digest auth не особо и лучше basic-а

Edited by Denis_____
PS
Link to comment
Share on other sites

  • 0
В 01.10.2018 в 10:20, Denis_____ сказал:

, причем иногда все же сбрасывается до basic auth (трафик смотрел wireshark-ом).

Ну-ка покажите. Такого не должно быть для не-SSL соединений.

 

В 01.10.2018 в 10:20, Denis_____ сказал:

Идея начет SSL - круто, только у меня версия 2.08 (последняя). Бета-канал тоже не выбирается, говорит 404.

Думаю, сами найдете где тут взять legacy, delta и draft. Повнимательнее.

В 01.10.2018 в 10:20, Denis_____ сказал:

Насчет ssh - понятно, но разве облако не просто проксирует sshAccess.keeneticName.mykeenetic.com: -> 192.168.1.1:22, где sshAccess - доменное имя 4 уровня, настроенное во вкладе KeenDNS? Как тогда иначе работает эта фича?

Нет, проброс работает только для SSL с расширением TLS ServerName и для HTTP/1.1. Все остальное не поддерживается.

Link to comment
Share on other sites

  • 0
В 05.10.2018 в 16:51, Le ecureuil сказал:

Ну-ка покажите. Такого не должно быть для не-SSL соединений

Цитата

Дайджест-аутентификация уязвима к атакам человека посередине (MitM). Например, MitM-злоумышленник может сказать клиентам использовать базовую аутентификацию доступа или режим дайджест-аутентификации RFC 2069. В более широком смысле, дайджест-аутентификация доступа не предоставляет клиентам механизма проверки подлинности сервера

(С) Википедия. Тут видимо либо был какой-то баг, либо меня пытались mitm-нуть. .cap я естественно не сохранил. Хотя сейчас попробовал - (внимание!) transmission всегда работает по basic. Это вот вообще никуда не годится, типа есть у меня HDD на кинетике, я хочу управлять торрентами, а в итоге ими управляет кто хочет, потому что basic. Причем, он делает это по HTTP/1.1!  Скриншот во вложении.

В 05.10.2018 в 16:51, Le ecureuil сказал:

Думаю, сами найдете где тут взять legacy, delta и draft. Повнимательнее.

Поискал, нашел ничего. Можно поподробнее?

Насчет 3 вопроса - понятно. То есть вообще никакими средствами не получится сделать из маршрутизатора мини-debian server? Подойдут любые варианты

Basic.PNG

Link to comment
Share on other sites

  • 0

Так, а если я запущу какой-нибудь WebUI на каком-нибудь порту с HTTP.1/1, чтобы он эмулировал терминал и все это было достаточно секьюрно? есть похожие готовые решения?

Link to comment
Share on other sites

  • 0

А, так вы про transmission.

Если что, то basic-авторизация в transmission единственная из доступных, другой там просто нет.

Плюс доступ к transmission - это максимум удаленные или закачаные файлы, а не доступ к настройкам ОС. Потому во времена 2.08 считалось, что этого достаточно.

Начиная с 2.12 transmission защищается через SSL, потому этой проблемы больше нет.

Link to comment
Share on other sites

  • 0
3 часа назад, Le ecureuil сказал:

Плюс доступ к transmission - это максимум удаленные или закачаные файлы, а не доступ к настройкам ОС

В общем-то да, но не особо просвещенные пользователи могут и admin-ом подключаться к transmission, более просвещенные - создадут отдельно admin, отдельно - regularUser, с доступом не только к торрентам, а, например, еще и ftp. Если там только basic, можно, например как-нибудь заблокировать права доступа - чтобы не было одновременно доступа к transmission и к настройкам ОС.

Обновился до 2.13 - да, там можно сделать сертификат и все будет очень здорово.

Встроенный ftp в NDMS (Pure FTPD, насколько я понял) - не поддерживает SNI -> нельзя иметь доступ к FTP из внешнего мира? Но в настройках есть пункт "Разрешить доступ из Интернета" - при любом его значении я могу подключиться внутри локальной сети к серверу ftp. Видимо, этот чекбокс все-таки влияет на внешний интернет за NAT-ом, как это работает в transmission. Но сделать так, чтобы он работал, не получилось. Это возможно или нет?

Link to comment
Share on other sites

  • 0
1 час назад, Denis_____ сказал:

Так если сделать сертификаты, то весь трафик будет в TLS завернут не?

без vpn ftp будет идти открыто

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • Recently Browsing   0 members

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