The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо выполнить код на уровне BMC-чипа"
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Есть идеи по улучшению форума и сайта ? Пишите.
. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..." +/
Сообщение от torvn77 (ok), 25-Июл-23, 12:48 
С одной стороны вы подумали немного над изложенными мной идеями и даже заметили некоторые недостатки, но тем не менее не поняли что предложенное составляет цельную систему и ответ на ваш вопрос уже есть в другом пункте предложения.  
Начну с вопросов которые вы задали от того, что прочитали невнимательно:  

>Подразумевает наличие у сетевки проца.

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

>Потом окажется что фаер или роутер имели что-то против экзотичных пакетов - и таки поедем в датацентр лично?  

Обычай блокировать экзотические пакеты связан с отсутствием в ранних протоколах и службах сетевой безопасности как понятия, причин блокировать пакеты секюрных протоколов нет, тем более если такие протоколы по умолчанию отключены(если вы внимательно читали то могли бы заметить что чтобы WoLsec включился в сетевую карту надо заливать сертификат).  
Во вторых админы датацентра знают какие службы и пакеты используются для удалённого администрирования и будут разрешать доступ пакетов WoLsec так же как и сейчас разрешают доступ к BMC или ssh(тоже ведь можно порезать ради заботы о пользователях).

>В Linux можно цеплять хоть что как initrd - даже рут в squashfs вгружаемой как initrd можно. Но что делать если это добро или сам кернел повредились и система не грузится? В датацентр ехать?

Если вы внимательно читали то ядро и initrd грузятся по FTPs с удалённого сервера, и ни что не мешает так же грузить и menu.lst в котором вы можете прописать всё что вам нужно.  
Но вы правы, это может быть удобно админам кластеров и ДЦ, но не удобно владельцам локалхостов в арендованных у ДЦ ячейках.  
Но я понял как убрать этот недостаток и раскажу о этом в конце поста:  

>А если GRUB не взлетает то чего?  

Если GRUB заработал то сложно представить обстоятельства при которых он вдруг перестанет работать, особенно если он стоит на отдельном носителе.  
Но вы правы, тут я не последователен, протоколы DNSsec,FTPs и DHCPsec должны быть интегрированы в БИОС(сейчас для удалённой загрузки используются их несекюрные версии, причём DNS в БИОС нет вообще)

А теперь пожалуйста читайте внимательно:  

>И чем это будет отличаться от - внезапно - BMC?

Тем что этот блок будут ставить только те, кому для контроля сервера по какой-то причине нужен аппаратный отладчик, остальным имхо хватит и удалённого включения с перезапуском по WoLsec.  
Но вы правы, я предложил не самое оптимальное решение и этот вопрос натолкнул на правильное решение, которое в своё время и следовало сделать.  
Я отлично понимаю что такое устройство по сути есть внешний BMC, про главный недостаток которого вы не указали: ему нужен дополнительный порт, что и стало причиной столь лёгкого внедрения BMC интегрированных в компьютер.  
Да и провода WoL от сетевой карты выглядят как нелепость
Обдумывая как быть с этим дополнительным портом я понял одну вещь:  
На сетевой карте просто надо сделать отдельный порт на который отправлять все предназначенные для BMC паеты, для отличия которых помечать IP пакет особым образом.  

То есть предлагаемая система теперь выглядит так:  

1. WoLsec не нужен, просто на сетевой карте делается отдельный внутрикорпусный порт на который отправляются все пакеты имеющие пометку BMC и дублируются пакеты DNS,DHCP и их секюрных версий.
2. А там пользователь сам решает какой BMC ему использовать, такой что умеет только нажимать кнопки Powe/Reset и поддержку последовательного COM порта для взаимодействия с БИОСом.
Или такой что ещё умеет в эмуляцию монитора,клавиатуры и блюрея.
Или такой что имеет на борту софт для отладки программ и оборудования и умеет в шины JTAG, SMBus, IPMI и что там есть ещё.
Или не использовать BMC вообще(например сервер размещён не в ДЦ, а локально)
3. Поддержка удалённой загрузки в БИОС не нужна так как соответствующий функционал делается соответствующим внешним BMC, всё что должен уметь БИОС это только грузить GRUB с отдельного небольшого накопителя(возможно эмулируемого BMC).  

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

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

Ответить | Правка | Наверх | Cообщить модератору

Оглавление
Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо выполнить код на уровне BMC-чипа, opennews, 22-Июл-23, 12:18  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру