KeenDNS Cloud

[Denis_____]

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 раза, тогда было вот что:

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

Изменено 30 сентября, 2018 пользователем Denis_____
PS

[AndreBA]

3 минуты назад, Denis_____ сказал:

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

В шапке вашего поста посмотреть:

Цитата

 

[ndm]

пп. 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 и работает под тем же самым сертификатом.

[ndm]

SSH через облачный KeenDNS _не_ работает. Вы пытаетесь подключиться по SSH к облачному серверу, а не к своему кинетику.

[Denis_____]

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-а

Изменено 1 октября, 2018 пользователем Denis_____
PS

[Le ecureuil]

В 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. Все остальное не поддерживается.

[Denis_____]

В 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? Подойдут любые варианты

[Denis_____]

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

[Le ecureuil]

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

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

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

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

[Denis_____]

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

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

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

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

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

[Le ecureuil]

FTP - это протокол из 1970-х. Такие вещи в современном Интернет гоняют через VPN.

[Denis_____]

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

[r13]

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

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

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