Как потерять 80% виртуальной инфраструктуры организации, сэкономив на внешних ИТ-подрядчиках, и выжить

Всем привет, меня зовут Захаров Антон и я владелец ИТ-аутсорсинговой компании Апсистемс, которая занимается администрированием, системной инженерией и построением сетей по подписке.

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

Компания Х использовала размещения своих облачных проектов облачные решения VMWare, при этом в качестве хранилищ данных использовались решения NetApp. Инфраструктурно проект выглядит как три независимых физических сети: внешняя (для доступа виртуальных машин к интернету), сеть управления кластера (связывает ноды виртуализации и VMware vCenter) и сеть для хранилищ данных (связывает ноды виртуализации и хранилища данных). Это значит, что виртуальные машины клиента должны были иметь доступ только к интернету, но не иметь доступа в сеть хранилищ данных и управления кластером. Как оказалось впоследствии, VMware vCenter Server, из-за ряда драматичных ошибок внутренних инженеров Компании Х, имел доступ одновременно во все три сети, как и несколько виртуальных машин, созданных инженерами клиента для своего удобства.

Никакого VPN не требовалось для подключения к vCenter - торчало прямо в интернет, так же ни vCenter ни ноды виртуализации не были обновлены до актуальных версий. В результате, в какой-то момент, инженеры Компании Х обратили внимание на нарастающую степень недоступности виртуальных машин на кластере и выход из строя VMware vCenter... В этот момент Компания Х обратилась к нам за помощью. В результате проведенного аудита оказалось, что VMware vCenter был атакован с использованием малоизвестной уязвимости, далее с него атакующие попали на ноды виртуализации и начали шифровать некоторые типы файлов по маске, сетевые хранилища для нод виртуализации были, разумеется, доступны. Это привело, в том числе, к шифрованию фалов виртуальных машин на сетевых хранилищах NetApp, на которых файлы виртуальных машин хранились по NFS.

Отдельного сетевого контура для хранения холодных копий не было, не зашифрованных копий виртуальных машин не осталось. Я упоминал ранее, что Компания Х потеряла 80% внутренней инфраструктуры.

Почему 80%, спросите вы, а не все 100? Дело в том, что несколько лет назад мы посоветовали клиенту для высококритичных виртуальных машин использовать сервера с Ubuntu, на которых производились ZFS-снапшоты readonly каждые 15 минут. Это значит, что несмотря на то, что на хранилищах на Ubuntu данные хоть и были зашифрованы, но уцелели все снапшоты с полной доступной глубиной хранения.

Хочется отметить, что зная размер машин и пропускную способность канала, можно предположить, что утащить атакующие много не смогли бы, даже если бы и сильно захотели. Но и на такие случаи, ИТ-аутсорсеры обычно дают клиенту внешний сервер для фиксации системных событий и мониторят условным заббиксом пропускную способность каналов и банальные события перебора паролей и изменения паролей на системах…