Зашифровали сервер ESXi: как мы вернули часть данных и защитили инфраструктуру

Что произошло

В TrustShield обратилась производственная компания. Однажды утром сотрудники не смогли войти ни в одну рабочую систему: учётная программа, файловый сервер, почта, внутренние сервисы — всё перестало отвечать. Причина прояснилась быстро: единственный гипервизор VMware ESXi, на котором работали все виртуальные машины, был зашифрован. Вместо привычных виртуальных дисков — файлы с чужим расширением и записка вымогателей с требованием выкупа в криптовалюте.

Главная беда была даже не в самом шифровании, а в том, что на этом же сервере хранилось всё — и рабочие системы, и единственная «резервная копия». Отдельных, независимо хранящихся бэкапов не было.

Почему так вышло

Картина типичная для атак на ESXi. Обычно совпадает несколько факторов одновременно:

• веб-интерфейс управления и/или SSH гипервизора были доступны напрямую из интернета;
• ESXi давно не обновлялся — оставались известные уязвимости (классический пример — служба OpenSLP);
• простые или переиспользованные пароли, без второго фактора;
• резервные копии лежали на том же сервере — или их не было вовсе.

Дальше дело техники: злоумышленники получают доступ к гипервизору и запускают шифровальщик, который за минуты делает недоступными все виртуальные машины разом.

Что мы сделали

1. Изоляция и фиксация

Первым делом отключили сервер от сети, чтобы остановить возможное распространение и сохранить состояние «как есть». Сняли посекторные образы дисков: все работы по восстановлению ведутся только на копиях, а оригинал остаётся нетронутым — на случай форензики и обращения в правоохранительные органы.

2. Оценка восстановимости

Определили семейство шифровальщика и изучили, как именно он шифровал файлы. Здесь сыграла важная деталь: многие шифровальщики под ESXi ради скорости шифруют не весь файл виртуального диска, а лишь его фрагменты — например, первые мегабайты и куски с определённым шагом. Для больших файлов .vmdk это означает, что значительная часть данных физически осталась нетронутой.

3. Частичное восстановление данных

Важно честно сказать: мы не «взламывали шифр» — это практически невозможно. Мы воспользовались недоработкой самого шифровальщика: собрали виртуальные диски заново из уцелевших «плоских» данных, отбросили зашифрованные фрагменты и восстановили файловые системы внутри дисков. Часть виртуальных машин удалось полностью поднять, из остальных — извлечь критичные данные: базы, документы, конфигурации.

Как защитили сервер

Восстановление — лишь половина работы. Вторая половина — сделать так, чтобы это не повторилось. Мы перенастроили инфраструктуру:

• убрали гипервизор из публичного доступа — управление ESXi теперь только из изолированного сегмента сети и через VPN;
• обновили ESXi до актуальной версии, отключили лишние службы (в том числе SLP), включили режим блокировки (lockdown mode) и встроенный межсетевой экран;
• задали уникальные стойкие пароли, разграничили доступ, включили двухфакторную аутентификацию на управление;
• настроили журналирование и оповещения о подозрительных входах.

Настроили правильные резервные копии

Самое главное, чего не хватало клиенту, — рабочих бэкапов. Внедрили резервное копирование по принципу 3-2-1:

• 3 копии данных, на 2 разных носителях, 1 копия — вне площадки (офлайн или в изолированном хранилище);
• копии, которые нельзя перезаписать или удалить (иммутабельные) — чтобы шифровальщик до них не добрался;
• регулярные автоматические бэкапы и — что критично — периодические тестовые восстановления. Бэкап, который ни разу не проверяли восстановлением, бэкапом считать нельзя.

Итог

Клиент вернул бóльшую часть критичных данных, получил защищённый гипервизор и работающую систему резервного копирования с проверенным восстановлением. Простой бизнеса сократился с потенциальных недель до нескольких дней.

В компании сделали честный вывод: критичную инфраструктуру нельзя настраивать «по остаточному принципу». Как сформулировал руководитель:

«Надо было сразу доверить настройку профессионалам — это вышло бы в разы дешевле, чем восстановление после шифровальщика».

Чек-лист: проверьте свой ESXi сегодня

Если хотя бы один пункт под вопросом — лучше проверить инфраструктуру до инцидента, а не после.