keenet07

Ну т.е. сначала всё-равно необходимо синхронизироваться открытым способом по NTP. А потом уже свериться с помощью TLS по NTS. И все дальнейшие проверки проводить уже по NTS. Метод конечно не идеальный получится, но защитит от дальнейшей возможной подмены времени пока устройство активно и не перезагружается. В общем понятно.

Я не пентестер. Нет, ну если вы что-то знаете, и есть какие-то механизмы помимо обычной синхронизации времени по указанным в системе NTP серверам. Или почему это не сработает именно на кинетике. То прямо и скажите. Понятно, что вероятность подобной атаки низка, просто потому-что это должно происходить чуть ли не на уровне провайдера или на устройстве до него. Но тем не менее это возможно. Вот эти товарищи (cloudflare) применяют в своей инфраструктуре. Этого мало? Или фигней страдают? Зря ресурсы тратят? https://developers.cloudflare.com/time-services/nts/ Повсеместное внедрение дело времени.

Вы не можете представить как это можно сделать? Если допустить возможность подмены всех ответов по NTP, установив в систему некорректное время или время сдвинутое на необходимый период, то уже это может вызвать нежелательные последствия. Сделать недоступными какие-либо сервисы. На текущем этапе данная проблема решается в крупных системах другими методами. Но точно не в роутере.

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

Да нет, 128 это полный объем памяти устройства. Прошивка в памяти хранится в двух экземплярах для надежности перепрошивки и возможности отката. Т.е. изначально размер прошивки не может превышать половину памяти устройства. А на практике он ещё меньше. И то что там выделено как свободная память это остаток разный для моделей с разным объемом памяти зависящий от нужд самого устройства к размеру прошивки.

На 5.1.1 на дашборде 5 и 2.4. И в точках доступа также. А вот на плитке Монитор WIFI и в самом меню осталось 2.4 и 5.

@Anna_ Предлагаю к рассмотрению также выделение диапазонов частот WIFI ещё и цветом. В общепринятой практике, в частности на схемах, более медленные диапазоны обычно выделяют холодными цветами, а более скоростные теплыми. Так к примеру галочку на переключателях 2.4ГГц диапазона можно сделать синей (как сейчас и есть), а на диапазоне 5ГГц оранжевой. Ну и в будущем 6ГГц диапазон можно красным обозначать.

А лог роутера в этот момент что пишет?

У меня там IGMP прокси и mDNS. Если ничего из этого не установлено, то наверное пустота отображается. Хотя можно было бы скрывать раздел.

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

5.1.0 Спасибо. Сделали выделение диапазонов. Даже чуть перевыполнили, добавили ещё галочку на переключатели. Как будто бы можно было и без неё. ) Не знаю, ну ладно.

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

Командами выше можно воспользоваться в WEB-CLI и из интерфейса. Но всё же было бы не плохо иметь отдельный пункт меню с настройками различных расписаний и действий в самом веб-интерфейсе.

Как будто бы что-то сделано, или мне уже кажется. Но всё равно не достаточно.