Комментарии 7
Очередная маркетинговая сказка про кибериммунитет, подмена понятий в виде "устранив те фундаментальные архитектурные проблемы, про которые писали выше
", которые сами и придумали - в москито есть ssl (ах да, в openssl нашли фатальный недостаток), и поддержка аутентификации и разделения доступа по топикам(ACL) (правильно, про это не пишем, ведь надо вывести пункт "3. доступ к брокеру стал возможен только авторизированным абонентам.
", и bind_address в конфигурации на локальном интерфейсе снимает поставленную проблему с атакой из внешней сети в виде выводов пунктами 1 и 2
.
И опять-таки каким-то чудесным решением представлен ssl терминатор c функционалом, давно поддерживаемым десятком отполированных до блеска решений вроде nginx и haproxy, все реализуется понятными и доверенными опенсорс инструментами в условные 2 минуты.
"Мы не просто устранили проблемы с безопасностью, которые были у исходного контроллера, а кардинально поменяли подход к его безопасности, «встроив» ее на уровень дизайна
" кардинально поменяв один софт на другой с тем же набором функционала, но меньшей степенью доверия и практически нулевым ревью комьюнити?
С одним можно согласиться - добавляя в слои логики новую, непроверенной временем и ревью кодовую базу KOS, вы добавляете поверхность атаки, сводя весь кибериммунитет до того самого неуловимого Джо, который никому не нужен. Неужели ваши "высокодоверенные компоненты" должны стать у нас высокодоверенными на основании красивых, но слабых технически, маркетинговых статей?
В чем тайный смысл надписей на корпусе контроллера- слева АЦП, а справа ADC?
А если злоумышленник просто молотком разобьет корпус контроллера и получит доступ ко всем его внутренностям? Какая защита будет задействована?
Документ про MODBUS по ссылке - не описание уязвимостей, а какой то студенческий реферарат с подтягиваением сомнительных фактов и без какой либо конкретики.
Как мы кибериммунизировали IoT-контроллер