1. Этот сайт использует файлы cookie. Продолжая пользоваться данным сайтом, Вы соглашаетесь на использование нами Ваших файлов cookie. Узнать больше.
  2. Добро пожаловать в Клуб Информационной Безопасности! Если Вы здесь впервые, то зарегистрируйтесь и прочитайте правила клуба. Если Вы забыли пароль, то перейдите по ссылке, после чего Вы сможете восстановить его через электронную почту. Помните, что некоторые возможности и разделы форума для гостей недоступны, рекомендуется пройти авторизацию.

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

Тема в разделе "Уязвимости и шпионаж", создана пользователем x-sis, 12.01.2018.

  1. x-sis
    Думаю

    x-sis Совет Клуба Команда форума Администратор

    Регистрация:
    26.02.2014
    Сообщения:
    5.881
    Симпатии:
    12.537
    Лучшие ответы:
    28
    Пол:
    Мужской
    Адрес:
    Россия
    [​IMG]

    Новый год начался очень оригинально. Вместо семейных посиделок служба эксплуатации тщательно следила за развитием ситуации с уязвимостями процессоров 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
    [​IMG]

    unpatched
    [​IMG]

    patched
    [​IMG]

    unpatched
    [​IMG]

    patched
    [​IMG]

    unpatched
    [​IMG]

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

    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
    [​IMG]

    unpatched
    [​IMG]

    patched
    [​IMG]

    patched
    [​IMG]

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

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

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

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

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

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

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

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

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

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

    [​IMG]

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

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


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

    Пожалуйста, войдите или зарегистрируйтесь для просмотра скрытого текста
     
    ANDYBOND нравится это.

Поделиться этой страницей

Загрузка...