[KeenDNS Cloud]

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

[KeenDNS Cloud]

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

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

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

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

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

[KeenDNS Cloud]

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

[KeenDNS Cloud]

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

[KeenDNS Cloud]

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

[KeenDNS Cloud]

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

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