Meltdown и Spectre для облака: наша оценка рисков и как мы патчились

Новый год начался очень оригинально. Вместо семейных посиделок служба эксплуатации тщательно следила за развитием ситуации с уязвимостями процессоров Meltdown и Spectre. В теории они означали угрозу для данных и ключей клиентов. Если очень коротко, то реализация уязвимостей выглядит так:

— А у вас АКСУ в продаже есть?
— Нету.
— А КПВТ?
— Нету.
— А гранаты?
— Ээх, вот чего нет, того нет.

То есть можно выстроить такую систему запросов, которая опосредованно даст понять, что хранится в оперативной памяти физического хоста по замерам времени ответов процессора. В первой половине января производители ОС и гипервизоров выкатили патчи, которые отрезают возможность использовать эту возможность, но при этом режут часть производительности систем.

Мы очень беспокоились за СУБД, потому что именно на них ожидался пик syscall’ов, и потребление ресурсов облака могло вырасти больше чем на 10%.

Забегая чуть вперёд — с патчами MS SQL в некоторых тестах работает почему-то быстрее.

Тесты производительности

Поскольку ничего на облако Техносерв мы без тестов не накатываем, мы подготовились к этим патчам во всеоружии — сделали две среды для тестов, на которые поставили ESXi и WinServer 2012, — старые и, как только вышли обновлённые, соответственно обновлённые.

Результаты тестов получились странные. Смотрите, вот методология тестирования:

СТАРТОВЫЕ КОНФИГИ И УСЛОВИЯ:

Обновлённая система
Сервер:
Dell PowerEdge R630
2 x Intel Xeon E5-2690 v4 2.6 GHz
320 GB RAM
UEFI v2.7.0

Гипервизор: VMware ESXi 6.0 Build 7504637

Виртуальная машина:
VM version 11
8 vCPU (1 socket)
24 GB RAM
Disk 0 (System)Thick provision Eager Zeroed — PVSCSI Controller 0 наDell SC9000 SSD+HDD Profile
Disk 1 (DB Files) Thick provision Eager Zeroed — PVSCSI Controller 1 наDell SC9000 SSD Profile
Disk 2 (Transaction Log Files) Thick provision Eager — PVSCSI Controller 2 наDell SC9000 SSD Profile
NIC: VMXNet3
ОС: Microsoft Windows Server 2012 R2 с2018-01 Monthly Rollup (KB4056895)
DB: Microsoft SQL Server 2016 Enterprise Editions сSP1

Тесты:
7-Zip v16.04 64-Bit (4 CPU Threads / 192 MB Dictionary)
HammerDB v2.23 (32 Warehouses, 8 vUsers, Rampup time 2 min, Test Duration 10 min )

Необновлённая система
Сервер:
Dell PowerEdge R630
2 x Intel Xeon E5-2690 v4 2.6 GHz
320 GB RAM
UEFI v2.6.0

Гипервизор: VMware ESXi 6.0 Build 5572656

Виртуальная машина:
VM version 11
8 vCPU (1 socket)
24 GB RAM
Disk 0 (System)Thick provision Eager Zeroed — PVSCSI Controller 0 наDell SC9000 SSD+HDD Profile
Disk 1 (DB Files) Thick provision Eager Zeroed — PVSCSI Controller 1 наDell SC9000 SSD Profile
Disk 2 (Transaction Log Files) Thick provision Eager — PVSCSI Controller 2 наDell SC9000 SSD Profile
NIC: VMXNet3
ОС: Microsoft Windows Server 2012 R2 с2017-12 Monthly Rollup (KB4054519)
DB: Microsoft SQL Server 2016 Enterprise Editions сSP1

Тесты:
7-Zip v16.04 64-Bit (4 CPU Threads / 192 MB Dictionary)
HammerDB v2.23 (32 Warehouses, 8 vUsers, Rampup time 2 min, Test Duration 10 min)

А вот результаты:

patched

unpatched

patched

unpatched

patched

unpatched

В более тяжелом тесте обновлённая система демонстрирует немного меньшую производительность:

HammerDB v2.23 (Warehouses: 128; vUsers: 24; Total Transactions per User: 1000000; Rampup time: 2 min; Test Duration: 10 min; User Delay: 500ms; Repeat Delay: 500 ms)

unpatched

unpatched

patched

patched

SQL — в некоторых тестах результаты пропатченной системы выше (быстрее), чем в непропатченной. Это очень странно. Объяснить этот феномен я не могу — возможно, дело в том, что с кумулятивным обновлением пришло что-то ещё, что оптимизирует работу. Да, мы давали синтетическую нагрузку, но всё же довольно сильно похожую на ту, что в продакшне, поэтому вряд ли дело в самом методе исследования.

Для более сложных тестов просадка производительности заметна, но она не превысила 10%.

Оценка угрозы

На запатченном гипервизоре уже неважно, какую гостевую операционную систему (запатченную или нет) использует клиент облака. То есть после обновлений (а они уже сделаны, ушло в общей сложности 4 дня на всю инфраструктуру — это чтобы без простоев, аккуратно мигрируя ВМ туда-сюда) — облако защищено от Spectre и Metldown.

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

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

1. Знать, что цель находится именно в этом облаке.
2. Протащить зловредный процесс, который не детектится потоковой защитой.
3. Развернуть его на том же физическом хосте, где и цель.

Последнее крайне маловероятно, если вы не выкупите как минимум половину ресурсов публичного облака. VMWare DRS хоть и отрабатывает, но перемещает незначительную часть VM.

Инфраструктурные сервисы работают в отдельном ресурсном кластере, т.е. у нас есть физическое разделение хостов, где крутятся виртуальные машины клиентов, а где виртуальные машины инфраструктуры.

Те, кто находятся в приватных облаках, вообще ни о чём не беспокоились. У них общая СХД с другими системами (а с дисков уязвимость читать ничего не позволяет) и собственный набор хостов.

Когда нужно масштабироваться — добавляются чистые хосты.

Итог — сейчас мы закрылись от основной угрозы и рекомендуем клиентам пропатчить свои ОС. Хотя бы потому, что поддерживать ОС в актуальном состоянии — хороший тон. Уязвимость после детального рассмотрения кажется вопиющей, но не такой опасной и беспокоящей, как казалось в первые дни.

Это материал руководителя службы эксплуатации облака Техносерв Дмитрия Максимова

Let's block ads! (Why?)