CrowdStrike: 8,5 млн устройств, $5 млрд ущерба и учения по bootcd-восстановлению

Прошло несколько дней с момента инцидента, и теперь есть цифры. Microsoft опубликовала оценку масштаба: более 8,5 миллиона Windows-устройств получили BSOD от обновления CrowdStrike. Страховые компании суммируют убытки отрасли - оценки аналитиков уже превышают $5 млрд только по застрахованным потерям. Незастрахованные потери, похоже, никто считать не берётся.

Нас эта цифра не удивила, но она хорошо рифмуется с тем, что мы наблюдали у клиентов в реальном времени: выпал не один сегмент инфраструктуры, а сразу всё - рабочие станции, серверы, ВМ, терминалы. Удар пришёлся именно туда, где Falcon был наиболее распространён: крупный Enterprise, транспорт, здравоохранение, финансы.

Почему мы провели учения, а не просто написали регламент

После разбора механики сбоя и пересмотра процедуры обновлений агентов стало понятно: написать процедуру восстановления мало. Нужно знать, как она работает под давлением, когда у тебя несколько сотен машин в BSOD и нет физического доступа к части из них.

Мы собрали стенд - несколько физических хостов плюс виртуальные машины на разных гипервизорах - и прогнали сценарий: агент безопасности сам становится вектором отказа, загрузка в нормальный режим невозможна. Никаких ярлыков: воспроизвели реальную картину, где Safe Mode не помогает без предварительной подготовки, а файловая система недоступна из-под работающей ОС.

Нас интересовал один вопрос: можно ли отработать аварийное восстановление без физического присутствия у машины - и при каких условиях это реально.

Что обнаружили

Результаты честные, без приукрашивания.

Первое - bootcd-сценарий работает, но требует заранее подготовленного образа. WinPE с правильным набором драйверов и сетевым доступом к файловому хранилищу позволяет зайти в систему, найти нужный каталог и удалить проблемный файл без физического присутствия - при условии, что у вас есть IPMI/iDRAC/iLO и образ заранее смонтирован как виртуальный привод. Без предварительной подготовки всё это нужно делать руками у каждой машины.

Второе - на VMware и Hyper-V картина лучше. Для ВМ достаточно прав на гипервизоре: подключить ISO, перезагрузить ВМ в режим загрузки с образа, удалить файл. Среднее время на машину у нас получилось около четырёх минут. Проблема масштабирования: при ста ВМ это уже шесть-семь часов последовательной работы, нужна автоматизация.

Третье - автоматизация через скрипт работает, но только если ВМ доступны по управляющей сети. Мы написали простой PowerShell-скрипт, который через API гипервизора перебирает ВМ по списку, монтирует образ, запускает восстановление через WinPE-автоматизацию и размонтирует образ. На двадцати тестовых машинах скрипт прошёл без сбоев. Потенциальная точка отказа - сама управляющая сеть: если она поднята на том же Windows-стеке, который лежит, вы в ситуации «лестница на пожаре».

Четвёртое - физические хосты без удалённого управления - это отдельный класс проблемы. Рабочие станции без IPMI, терминалы, банкоматы, специализированные стенды - там нет другого пути, кроме физического доступа. Для таких устройств единственная реальная стратегия - заранее знать их список и заранее знать, у кого есть физический доступ и сколько времени займёт добраться.

SOP для ситуации «агент безопасности уронил хост»

По итогам учений зафиксировали процедуру в виде конкретных шагов. Это не универсальный шаблон - это то, что проверили на своём стенде.

• Шаг 1 - инвентаризация пострадавших. Мониторинг покажет, какие хосты перестали отвечать. Разделить: ВМ на управляемых гипервизорах, физические с IPMI, физические без удалённого доступа. Три разных потока восстановления.
• Шаг 2 - ВМ через гипервизор. Смонтировать заранее подготовленный WinPE-образ, перезагрузить в него, удалить целевой файл агента, извлечь образ, перезагрузить. При наличии скрипта - запустить на пул машин.
• Шаг 3 - физические с IPMI. Через консоль управления подключить виртуальный CD с образом WinPE, аналогичная процедура.
• Шаг 4 - физические без удалённого доступа. Загрузочная флешка с WinPE. Список машин с адресами и ответственными - должен быть готов заранее, не в момент инцидента.
• Шаг 5 - проверка и фиксация. После восстановления каждого хоста - логировать время и результат. Это нужно для постмортема и для страховщиков, если речь идёт о застрахованном ущербе.

Что изменилось в нашей работе

Аудит инфраструктуры теперь включает отдельный блок: «что происходит с хостом, если агент безопасности становится причиной сбоя». Проверяем наличие подготовленного WinPE-образа, доступность удалённого управления для физических хостов, покрытие скриптом восстановления для ВМ-парка.

Это не паранойя и не реакция на один случай. Это признание простого факта: агент, работающий на уровне ядра с правом автообновления, - это системный компонент с системными рисками. Относиться к нему нужно соответственно.

Учения заняли один рабочий день. SOP задокументирован. Насколько он выдержит реальное давление при следующем инциденте - посмотрим. Надеемся, что проверять его в деле не придётся.