Комментарии 10
Заключение: нельзя использовать VMWare, он дырявый?
Прошу в заголовке уточнить что дело идет о VMware ESX only, а другие гипервизоры не рассматриваются в принципе.
Более того разговор идет не о обзоре уязвимостей и видах атак, но происходит перечисление известных недостатков устаревших версий конкретной платформы.
Более того разговор идет не о обзоре уязвимостей и видах атак, но происходит перечисление известных недостатков устаревших версий конкретной платформы.
Тема затронута правильная. Сейчас все больше хостингов предоставляют выделенные гипервизоры (ESXi и Xen чащe всего), которые, будучи поставленными из коробки и видимые извне, выглядят весьма голыми и незащищенными. Последнее время я активно использую ESXi на толстых хостингах и первой командой обычно прописываю на командном интерфейсе route на свои выделенные адреса и дропаю default )
Как защититься от атак на «помогающие защититься» наложенные средства защиты виртуализации?
Тут два аспекта. Первый — подобные средства проектируются с учетом требований к высокой степени защиты, разработка ведется по методологиям защищенного программирования и, как следствие, актуальных угроз для этих средств гораздо меньше. Второй — эшелонирование обороны, для реализации атаки нужно найти такой вектор, который позволит пробить и наложенное средство защиты и встроенные механизмы среды виртуализации, что усложняет задачу многократно.
Что касается требований к проектированию, то мне представляется, что при создании коммерческих продуктов вендорами мирового класса, также используются все необходимые технологии. И даже более, ведь для них реальная безопасность чуть-чуточку важнее, чем «условная», прикрытая, как правило, сертификатом того же ФСТЭК. Таким образом, уж если у крупнейших вендоров есть эксплуатируемые ошибки в ПО, то грезить тем, что таких ошибок возможно избежать при разработке наложенных средств защиты «с учетом требований к высокой степени защиты» и разрабатываемых по «методологиям защищенного программирования» — неразумно.
Что касается эшелонирования и прочих верных мер, то тут стоит ответить на такой вопрос. Если аппаратная реализация поддержки виртуализации реализована в железе, то где гарантия того, что данное «железо» не имеет внутри себя «потайных» ходов, которые позволят любому исполняющемуся на процессоре коду с любыми привилегиями выполнить «секретную' последовательность команд и эксалироваться до уровня того же гипервизора?
Что касается эшелонирования и прочих верных мер, то тут стоит ответить на такой вопрос. Если аппаратная реализация поддержки виртуализации реализована в железе, то где гарантия того, что данное «железо» не имеет внутри себя «потайных» ходов, которые позволят любому исполняющемуся на процессоре коду с любыми привилегиями выполнить «секретную' последовательность команд и эксалироваться до уровня того же гипервизора?
Что касается требований к проектированию, то мне представляется, что при создании коммерческих продуктов вендорами мирового класса, также используются все необходимые технологии. И даже более, ведь для них реальная безопасность чуть-чуточку важнее, чем «условная», прикрытая, как правило, сертификатом того же ФСТЭК. Таким образом, уж если у крупнейших вендоров есть эксплуатируемые ошибки в ПО, то грезить тем, что таких ошибок возможно избежать при разработке наложенных средств защиты «с учетом требований к высокой степени защиты» и разрабатываемых по «методологиям защищенного программирования».
Что касается эшелонирования и прочих верных мер, то тут стоит ответить на такой вопрос. Если аппаратная реализация поддержки виртуализации реализована в железе, то где гарантия того, что данное «железо» не имеет внутри себя «потайных» ходов, которые позволят любому исполняющемуся на процессоре коду с любыми привилегиями выполнить «секретную' последовательность команд и эксалироваться до уровня того же гипервизора?
Что касается эшелонирования и прочих верных мер, то тут стоит ответить на такой вопрос. Если аппаратная реализация поддержки виртуализации реализована в железе, то где гарантия того, что данное «железо» не имеет внутри себя «потайных» ходов, которые позволят любому исполняющемуся на процессоре коду с любыми привилегиями выполнить «секретную' последовательность команд и эксалироваться до уровня того же гипервизора?
Касательно первой части комментария — наложенные средства «заточены» на задачу обеспечения безопасности. Производители гипервизоров вполне могут решать этот вопрос по остаточному принципу — это не основная функциональность, поэтому я бы не рассчитывал на хорошую защиту «из коробки».
По второй части — всё верно, от закладок в ПО и аппаратной части таким методом не защититься. Для этого предусмотрены сертификации по «РД НДВ» и т.д., но сертифицированных по этим требованиям гипервизоров нет. Поэтому можно говорить о невозможности универсальной защиты от данной угрозы, с другой стороны, риск реализации достаточно низкий, пока эти закладки не становятся публично известными.
По второй части — всё верно, от закладок в ПО и аппаратной части таким методом не защититься. Для этого предусмотрены сертификации по «РД НДВ» и т.д., но сертифицированных по этим требованиям гипервизоров нет. Поэтому можно говорить о невозможности универсальной защиты от данной угрозы, с другой стороны, риск реализации достаточно низкий, пока эти закладки не становятся публично известными.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Уязвимости гипервизора – угроза виртуальной инфраструктуре и облаку