Wi-CAT LLC

Wireless Comprehensive Advanced Technology. Build your network now.

Wi-CAT LLC
Навигация Форума
Вы должны войти, чтобы создавать сообщения и темы.

(а надо ли?) Реализация ssh key auth/nvram delete

Добрый день,

По поводу работы с nvram...

  1. На данный момент есть возможность устанавливать и менять значения переменных через nvram_set 2860 varxxx dataxxx и возможность стереть все переменные разом через nvram_clear. Возможно ли сделать удаление переменных избирательно по имени?
  2. Есть ли возможность записать в nvram ключ(и) для авторизации по SSH? Если нет, то будет ли сделана?
  1. Фирмварь не использует нигде добавление того что потом нужно удалять. nvram это таки  не FS. Нет ну сделать можно но нафиг не нужно. Если в экспериментах добавили левое поле то либо забейте (мешает чтоль? наэксперементируетесь сделаете начистовую без ошибок), либо ну выгрузка состояния, удаление поля, загрузка назад. Не вижу смысла в удалении полей ибо юзверь может наудалять выборочно потом получишь коллапс и систему в позе раком. А при полной очистке так и сяк заново заполнится из дефолтов при ребуте. Ну и чесслово так можно и до переименования дойти.
  2. Мы не поддерживаем из коробки авторизацию в ssh по ключам, а значит остальная часть вопроса не имеет смысла. Оставляйте заявку на wifi@nag.ru При накоплении критического числа запросов функционала его можно будет добавить, независимо есть ли сейчас возможность или нет. Либо можете сами разобраться, реализовать (включая управление из UI) и предложить патч для включения. В планах подобного нет т.к. нет запроса, да и устройство называется end user cpe, что-то крайне сомнительно, что оно end user`у надо. Тут часто пароль сменить неосиливают, а уж ключи и прочие эт вообще из области фантастики. Почему просто не использовать пароль пожирнее?

P.S. Если вы представляете ЮР лицо закупающее железо у НАГ - просьба представляться, что за компания (при запросе функционала так обязательно). Думаю понятно зачем. Глянул доменное имя, можете не представляться. Продублируйте хотелки на wifi@nag.ru, они собирают запросы и систематизируют их что бы можно было выделить что стоит делать, а что отложить в самый конец, т.к. задач всегда больше чем времени на их решение. Особенно сейчас, когда новая железка на носу и горит.

PP.S. Просьба в будущем корректно называть темы и размещать их в соответствующих разделах. Ну и не лепить в кучу. Иначе гарантированно всё это в процессе потеряется. Лучше создать 2 темы с разными запросами, если они касаются разных сущностей, и внятным заголовком, чем слепить в одну.

Ну т.е. моё предложение простое и понятное.

nvram_set MngmtStoreSettings 1
nvram_set MngmtLogin "абракатаберлогин"
nvram_set MngmtPassword "абракатаберпароль"

И вперёд. Учитывая rate limit на все remote managment в фаерволе уже с 16 символьным логином и паролем перебор будет вечным.

Плохо конечно, что не поддерживается авторизация по ключу из коробки. Но ещё хуже, что при обновлении прошивки меняется ssh host key - очень неудобно каждый раз обновлять привязку.

Не знаю как вам мешает смена hostkey, вы считаете лучше его вообще сделать фиксированным и одинаковым на всех устройствах? Почему не автоматизировать обновление "привязки". В wive-ng-control например руками ничего перепривязывать не требуется.

Просто если что-то реализуете из вне, стоит это учитывать в алгоритмах. А так много чего ещё перегенериться при обновлении. А у большинсва "конкурентов" вообще всё прибито гвоздями.

И если авторизация по ключам ещё как-то понятна, то хранить hostkey смысла не видно вообще.

Если вы используете hostkey для идентификации устройства, то может стоит какое-то другое поле для этого выбрать? Ну например hostname или вообще при первом подключении создать свою переменную с идентификатором аля:

nvram_set routerid "абракатабра" и потом читать его через nvram_get "абракатабра".

Проще говоря нужно понимать какую задачу решает эта самая привязка.

Нет ну можно всё запихать в nrvam прекрасно. И сертификаты туда же и прочие нагородить. Но вопервых nvram это оочень маленький кусочек флэша. Во вторых а оно точно надо?

Есть возможность и ещё блок под отдельную какую CERT-FS выделить по типу RWFS, нет проблем. Но вот нафиг все эти городушки не очень ясно.

Ладно, допустим вы боитесь MiTM атак, и решили таким образом перестраховаться. В случае парольной аутентификации с длинным сложным паролем атакующий так и сяк обречён на провал. Максимум что он сможет вытащить это имя юзверя, на которое можно смело забить и заюзать пароль в 64 символа уникальный для каждой железки при первом же к ней подключении (см поля выше, они кстати даже по резету не сбрасываются пока MngmtStoreSettings в 0 не выставишь.

Собсно для этих целей (сервисный операторский доступ) и делалось.

База пар login/сложныйпароль и никаких гвоздей.

Вообще для управления операторами из коробки есть CWMP реализующий поддержку любимого всеми TR-* . Никто не мешает развернуть какую-нить свободную acs и юзать его.

Проще говоря нужно понимать что в итоге всем этим пытаетесь достичь.

Опишите финальную задачу, будет ясно что можно и/или нужно таки сделать.

Да нет ни какой задачи особой, просто верификация host key включена по-умолчанию в ssh, в случае её не прохождения подключится не даёт. Отключать совсем - не хочется, уже несколько раз по изменению ключа опознавали постороннее вторжение на сервера.

Обычно, ключ генерируется при первом запуске и остаётся далее неизменным.

 

Цитата: AlexeyS от 30/11/2018, 01:20

уже несколько раз по изменению ключа опознавали постороннее вторжение на сервера.

Обычно, ключ генерируется при первом запуске и остаётся далее неизменным.

=)

Изменение hostkey никак не говорит о постороннем вторжении на сервера. Он не перегенериться при подключении левого юзверя, если он по глупости его сам не удалит или не перегенерит.

Единственная его задача это превентивно отсекать атаки типа человек по середине. Т.е. если вы уже однажды коннектились к серверу, а кто-то вклинился между вами и сервером то хосткей верный он вам передать не сможет и проверка хэшей не пройдёт, получите ругань на клиенте.

Собсно ни для чего другого он не нужен. Посторонние вторжения на сервера лечатся прямыми руками, актуальным софтом, сложными паролями и терморектальным криптоанализом админу который этим пренебрегает.

MITM атаки на SSH настолько интересная задачка, что даже если злоумышленник не только умудрился вклиниться между сервером и клиентом, и даже заполучил как-то корректную копию hostkey то ничего крое юзверя и хэша пароля он не получить. Что бы восстановить сложный пароль по хэшу ему придётся лет на 600 пару каких-нить суперкомпов загрузить этой задачкой.

Что-то мне кажется черезчур расточительно для получения пароля доступа к ssh в end user устройстве. Гораздо проще юзверю мозг сломать послав что-нить типа "хочешь быть королём аськи - ткни сюда".

Атаки на end user cpe идут чаще всего по вектору в виде известных уязвимостей в софте или дефолтовых паролей. Даже перебор после нескольких десятков попыток (видимо задетектив rate limit на числе подключений) обычно прекращается.

Для большинства маршрутизаторов с закрытым ПО можно найти почти всегда более простой вектор атаки. Почти все они это либо крашеные SDK от чипмэйкера с софтом царя гороха и часто торчащими во все стороны сервисами.

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

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

Вот это действительно проблема. И она технически не решаема особо.

Я в курсе, но всех не перевоспитаешь. Не известно, что гуляет в сети, mtim (методом arp spoofing) тоже пытались неоднократно провернуть.

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

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

Цитата: AlexeyS от 30/11/2018, 01:35

Я в курсе, но всех не перевоспитаешь. Не известно, что гуляет в сети, mtim (методом arp spoofing) тоже пытались неоднократно провернуть.

Да пусть пытаются. Толку с такого mitm никакого если установлены надёжные пароли.

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

Буд-то ключ это что-то такое в вакууме. Точно так же вытаскивается с носителя с затрояненной машины, можно вместе с путти, или что там под виндой нынче модно =)))

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

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

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

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

С паролем придётся ждать пока юзверь к железке полезет, вспомнит пароль и введёт его наконец. А ключик вот он уже лежит. А "по копии hostkey" на клиенте можно выяснить от чего ключик.

Т.е. в случае безолаберных юзверей таки заученный (или даже записанный на бумажке) пароль лучше ключа на носителе. =)

Собсно тут как раз и есть тот самый единственный вариант усложняющий задачу атакующему. Использование прослойки в виде ACS/Wive-NG-Control которая сама будет ходить до роутеров используя сложные криптостойкие пароли о которых обслуживающий персонал знать вообще не будет.

А персоналу оставили дырочку до UI ACS/Wive-NG-Control и пусть рулят. Один фиг делать на роутере им нечего особо.

А вот доступ до UI ACS/Wive-NG контрол можно хоть 2х факторной утентификацией закрыть что бы точно знать кто полез чего крутить. Собсно других способов не переучивая и не пересаживая с дырявой винды обезопасить конечные устройства от утечки данных на стороне обслуживающего персонала мне не видится.

Цитата: sfstudio от 29/11/2018, 20:04

P.S. Если вы представляете ЮР лицо закупающее железо у НАГ - просьба представляться, что за компания (при запросе функционала так обязательно). Думаю понятно зачем. Глянул доменное имя, можете не представляться. Продублируйте хотелки на wifi@nag.ru, они собирают запросы и систематизируют их что бы можно было выделить что стоит делать, а что отложить в самый конец, т.к. задач всегда больше чем времени на их решение. Особенно сейчас, когда новая железка на носу и горит.

Компания "Макснет системы" г. Обнинск

Все доводы понятны, но все-таки остаюсь при своем мнении, что авторизация по ключу вашим устройствам бы не помешала ... на НАГ напишу.

PP.S. Просьба в будущем корректно называть темы и размещать их в соответствующих разделах. Ну и не лепить в кучу. Иначе гарантированно всё это в процессе потеряется. Лучше создать 2 темы с разными запросами, если они касаются разных сущностей, и внятным заголовком, чем слепить в одну.

Ок, постараюсь. Остальные вопросы перенесу в раздел Опыт настройки

 

 

Цитата: vik44 от 30/11/2018, 13:42

Все доводы понятны, но все-таки остаюсь при своем мнении, что авторизация по ключу вашим устройствам бы не помешала ... на НАГ напишу.

Насчёт не помешала тут всегда одна и та же беда. Попытка найти золотую середину. Ибо когда начинаешь тащить у UI что-то крайне редко юзаемое начинаются стоны о переусложнённости. А юзвери часто крутят всё подряд и т.д.

Поэтому число опций и проего пытаемся держать хотя бы относительно в стабильном по числу оных состоянии не добавляя чего-то просто так.

Если бы железку ориентировали бы чисто на операторов - вопросов бы не было. Но железо сами крутят и энд юзеры.  И каждому нужно что-то своё. Утащить всё - будет ёжик со слабо предсказуемым поведением.

Тянуть 2 ветки банльно не хватит времени.

Потому выработан такой подход, в виде обоснованности наличия чего-то перед реализацией, без попыток тянуть в рот всё подряд.

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

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

Ок, доводы понятны...

Кстати, еще раз спасибо за EOIP - с поры создания продолжает работать на W4N-MT без проблем и зависаний

Да не за что, как бы если цель ясна и полезность не призрачна.. =)

Добавил BtnRstTimeout по дефолту 10. Если задан > 10 то таймаут резета будет равен заданному значению. fullreset корректируется как deault timeout fullreset (100s) + BtnRstTimeout.

Параметр так же сохраняется при  MngmtStoreSettings 1.

Будет доступен с 7.8.10 + вытащим в админскую часть UI.

Ок, спасибо...

Ну если уже и в UI опцию сделали, может не сложно будет сделать возможность вообще отключать Сброс через кнопку,- например, установкой данной опции = 0 ...?

Сложно ибо кто-нить себе гарантированно ноги отстрелит. А вот выставить таймаут в 3 минуты и удержать эти 3 минуты кнопку спичкой (или чем там) уже терпения ни  у кого не хватит факт, особенно если не знаешь что такой таймаут. Или ещё выше закрутить.

P.S. Если стоит задача оторвать сброс вообще, вы можете тупо заказать у НАГ партию без кнопки, ещё и цента 1,5 скинут. =))))) Возможность обрезетить девайс должна оставаться. И цель не оторвать возможность совсем, что бы потом самим если вдруг случись что не пришлось к физической консоли цепляться, а минимизировать шанс сброса по дури (например по совету google chrome =)).

PP.S. Кстати попробуйте так минуты 3 спичкой резет подержать, эт ещё то развлечение что бы за это время контакт ни разу не потерялся и отсчёт не начался сначала. =)

Ок, спасибо, услышал...

всё-таки с точки зрения безопасности ключ с парольной фразой надёжнее (MITM) и удобнее (несколько ключей для одной учётки в ОС) — поэтому must have для безопасности и авторитета вашей системы (можно будет на проекты требующие безопасности претендовать), да и включить эту функцию не так уж сложно (в dropbear всё есть уже)

поэтому не понимаю почему вы не хотите потратить несколько часов (сам сделаю как только появится свободное время)

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

А не хочу потому что, читайте выше.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: