Сегодня мы работаем с облаками, которые состоят из множества ВМ, и каждая из них выполняет какую-то одну роль или функцию. Чем меньше запущено дополнительных сервисов или процессов в каждой ВМ, тем ниже нагрузка. И тем лучше, ведь отключение всех «паразитных» задач и процессов позволяет нам достигать экономии ресурсов, которую обещают провайдеры. Соответственно, благодаря такой экономии мы достигаем минимальной стоимости этих ресурсов в месяц.
При этом традиционные политики безопасности требуют от нас, чтобы антивирус был запущен на каждой ВМ. Однако ни одно антивирусное решение не обеспечивает 100% защиту. А значит, его тоже можно отключить или не устанавливать вовсе?
Привет, Хабр! Меня зовут Алексей Афанасьев, я менеджер продуктов ИБ в #CloudMTS. Совместно с коллегами из Лаборатории Касперского я подготовил материал, в котором хочу обсудить, насколько виртуальным машинам необходимы средства защиты от вирусов и можно ли обойтись без них. Давайте разбираться вместе: так ли нам нужен антивирус в облаке?
До облаков в офисах и ЦОДах стояли обычные железные серверы, каждый из которых имел множество функциональных ролей: сервер мог быть одновременно почтой, системой антиспама, базой данных, веб-сервером или прокси. То есть на таком аппаратном сервере запускался целый набор приложений и процессов, а сама «железка» выполняла множество ролей.
После перехода в облако от такого использования серверов отказались. Сейчас на одном хосте запускается множество виртуальных машин, при этом чаще всего применяется подход «одна ВМ — одна роль». Например, одна ВМ — база данных, другая — веб-сервер, третья — прокси и так далее.
С одной стороны, такая практика упрощает настройку и обслуживание ВМ. С другой, рост числа машин приводит к тому, что определенное количество ресурсов перестает нормально контролироваться администратором. Какая-то «заброшенная» виртуальная машина может долго работать самостоятельно, после того как он настроил ее и сконфигурировал. И пока с ней ничего «плохого» не случится, админ, вероятнее всего, на нее и не зайдет. Всем известен принцип «пока работает — не трогай».
Допустим, у нас есть ВМ с функционалом движка веб-сайта. И пока такой движок хорошо и успешно работает, очевидно, заходить на него и запускать что-то «лишнее» вроде антивируса не стоит. А если что-то пойдет не так, мы всегда сможем поднять такую виртуальную машину — преднастроенный движок — из бэкапа, верно?
С другой стороны, такая ВМ смотрит в интернет, достаточно кислотную и опасную среду. Рано или поздно блуждающие по нему вредоносы найдут какую-то необновленную библиотеку, незакрытую уязвимость и через эту машину проникнут на другие ВМ, во внутрь корпоративной инфраструктуры. И далеко не во всех случаях движок потеряет свою рабочую функциональность — мы можем просто не заметить его выход из нормального рабочего состояния.
Виртуальные машины подвержены практически полному спектру угроз, от которых могли бы пострадать и традиционные решения. Однако, в отличие от старой парадигмы установки приложений на серверы, сегодня мы можем легко и быстро удалить зараженную ВМ и затем восстановить ее из бэкапа. Такой подход делает виртуальные машины практически неуязвимыми в глазах ряда специалистов.
Давайте разберемся, можно ли полагаться на эту концепцию, — и для этого рассмотрим ряд сценариев.
Вирусы не запустятся в виртуальной среде
Любой современный зловред действительно будет проверять, в какой среде он оказался — на виртуальной машине или реальной железке.
Существует множество способов обнаружения виртуальных машин:
Однако разработчики вирусного ПО четко понимают, что заражение виртуальной машины из чьей-то корпоративной инфраструктуры дает возможность не только похитить потенциально ценные данные, но и пробраться на другие ВМ, не ограничиваться этим и вызвать эпидемию.
Уже давно можно смело говорить об интеллектуальных функциях вирусов. Например, в 2013 году аналитиками Лаборатории Касперского был обнаружен вредонос, который анализировал среду и самостоятельно решал, что запускать — майнер или шифровальщик.
При заражении можно просто «убить» ВМ и запустить новую из шаблона
Безусловно, виртуальную машину можно просто развернуть из бэкапа или шаблона — у хорошего администратора всегда есть целые каталоги готовых образов. Однако неграмотная работа с золотыми образами способна подвергнуть опасности всю ИТ-инфраструктуру. Например, если при поднятии ВМ по шаблону задается стандартный логин и пароль, его компрометация (не важно, по какой причине — простой перебор, вредоносный код или утечка) — это угроза всей инфраструктуре. После компрометации одной ВМ почти гарантирована компрометация всех машин в сети, созданных из этого образа. Кстати, это касается и машин, и модных сейчас контейнеров.
Вопрос безопасности золотых образов относится не только к паролям по умолчанию, но и к обновленности используемых библиотек и приложений. Нередки случаи, когда из каталога (или даже из бэкапа) поднимается машина с устаревшими библиотеками и модулями. Ведь на тот момент, когда образ создавался, администратор мог и не знать о каких-то угрозах, а необходимых обновлений просто не существовало. Но при запуске такой ВМ сегодня старая необновленная библиотека с уязвимостями может стать серьезной проблемой.
Важно не забывать обновлять и актуализировать используемые шаблоны, причем делать это заранее. Обновление ВМ в рабочей среде не дает гарантии, что какой-то вирус еще не успел скомпрометировать машину. Устанавливайте обновления своевременно — просто восстановления из бэкапа в большинстве случаев недостаточно.
Не могу обойти вниманием популярные сегодня виртуальные десктопы и VDI. Обычно такой рабочий стол создается автоматически из заранее сконфигурированного шаблона. Как правило, администратор закладывает стандартный пароль для встроенной учетной записи, и все это раскатывается на рабочие места сотрудников. Неприятности в таком золотом образе ведут к поражению целого парка запущенных виртуальных рабочих столов, что автоматически приводит к эпидемии во всей корпоративной среде.
К тому же, пользуясь такой практикой, администраторы не всегда помнят, что также необходимо предотвратить последствия произошедшего, даже если зараженная ВМ была удалена: например, поменять пароли, которые мог угнать вирус, или заблокировать учетную запись.
Одна зараженная ВМ — это не страшно
Пользователи облаков часто надеются, что изолирование процессов сможет защитить их инфраструктуру: например, есть миф, что вредонос не сможет мигрировать с одной виртуальной машины на соседнюю из-за изоляции процессов, памяти и прочего. И этим стереотипом нередко пользуются злоумышленники.
Сегодня вирусы уже научились «вырываться» из работающей ВМ, чтобы захватить платформу гипервизора или другие «вещи»:
Безусловно, виртуальные платформы, драйверы в виртуальных средах, как и любой другой программный код, имеют уязвимости и требуют постоянного обновления и внимательного отношения. А может быть, и контроля. Есть реальные юзкейсы, показывающие их, увы, неабсолютную надежность:
Кроме того, потенциально сама виртуальная машина может передавать информацию о своей работе или использовании ресурсов другим виртуальным машинам через вспомогательные каналы, которые включают в себя как программное, так и аппаратное обеспечение:
Многие считают, что описанные выше примеры — это экзотика и теория, которые никогда не смогут воплотиться на практике, а эксперты из антивирусных компаний вспоминают о них, чтобы как следует напугать клиента и продвинуть свое ПО.
Было бы прекрасно, если бы это было правдой.
На демонстрации в режиме реального времени, показанная еще на BlackHat 2017 в Азии, была продемонстрирована атака на облако, включая интерактивные сеансы SSH и потоковое видео между двумя виртуальными машинами.
Исследователи создали высокопроизводительный скрытый канал, который может поддерживать скорость передачи более 45 Кбит/с на Amazon EC2, и даже зашифровали его: этот метод устанавливает сеть TCP внутри кеша и передает данные с использованием SSH.
Помимо самих ВМ, есть ряд уязвимостей у самой среды виртуализации:
Антивирус — «вредный» «лишний» потребитель
Компании приходят в облака для экономии своих ресурсов. Но зачем тогда разворачивать в облаке еще один сервис, который будет потреблять мощности, если с вирусами можно справиться «бытовым» способом, описанным выше, — просто снести зараженную ВМ, развернуть новую и спокойно жить дальше?
Установка традиционного антивируса — и вовсе удар по производительности. При использовании неспециализированного решении каждая виртуальная машина будет снабжаться полным набором движков и независимо обновляющихся баз. Как результат — «шторм» одновременных сканирований или обновлений может привести к катастрофическому падению производительности СХД и сетевых ресурсов. Именно поэтому большинство администраторов укрепляются в очевидном, на первый взгляд, мнении о бесполезности и прожорливости антивирусных решений.
Отказаться полностью от антивирусной защиты достаточно рискованно. Использовать традиционные решения — тоже не лучшая идея. Можно ли среди современных решений найти оптимальный вариант, «заточенный» под работу в облаке? Ведь если вредонос умеет определять, в какой среде он находится, и адаптироваться под окружение, наверное, должен быть и антивирус, который такое умеет!
Иными словами, для защиты наших ВМ в облаке нам необходимо специализированное решение, которое:
А еще было бы неплохо, если бы оно согласовывалось с комплаенсом и регуляцией для работы с ПДн и ГИС.
Пару лет назад мы уже описывали наши подходы к выбору антивирусного сервиса для облачных сред. Не будем повторяться и рекомендуем обратиться к этой статье.
Сегодня, как и тогда, при всем богатстве выбора антивирусных решений на нашем рынке есть два вендора, которые имеют в своей линейке специализированные решения для виртуальных сред — TrendMicro и Лаборатория Касперского. Мы как провайдер выбрали решение от Лаборатории Касперского. Причины этого выбора описаны в статье по ссылке выше. Мы понимаем, что кто-то может быть не согласен с нашим мнением — в этом случае рекомендуем рассмотреть альтернативный вариант.
Сейчас у Лаборатории Касперского есть два специализированных решения — безагентский антивирус и решение на базе легкого агента. Эти решения отличаются по функциональности и принципу работы.
Безагентское решение предназначено только для VMware — у VMware есть специализированный API, который он предоставляет сторонним вендорам. Через этот API в ВМ, где стоит драйвер-перехватчик, передаются файлы для анализа, а программа сама решает, какие из них блокировать. Это решение не требует установки внутрь ВМ какого-либо специфичного софта, что снимает вопрос инсталляции и долгих тестирований на совместимость. Однако такой подход влияет на работу самого антивирусного решения, потому что у него просто связаны руки. Безагентский антивирус может получать данные, анализировать и отдавать вердикт, но не имеет возможности проводить исследования внутри ВМ и применять современные логики. Очевидно, ограниченность функционала сильно перевешивает его плюсы, поэтому он нам не подходит.
В наших облаках мы используем решение для виртуальных сред на базе легкого агента. В этом случае внутрь каждой ВМ устанавливается легкий агент, а вычислительные операции выносятся на специальную машину, которая содержит антивирусный движок. Такая ВМ называется SVM. Легкие агенты внутри ВМ на Linux или Windows служат транспортом, позволяя перехватить файловую операцию, запрос пользователя на доступ к сети или подключаемые им устройства — например, флэш-накопитель — а затем передать эту информацию для анализа на выделенную ВМ.
Объекты анализируются всего на одной ВМ (SVM). Это экономит ресурсы каждой машины, в том числе на проверку золотых образов или других идентичных файлов. Единожды проверив такой золотой образ или файл в рамках всего гипервизора или кластера, повторно тратить ресурсы на эту операцию решение уже не будет, а сразу даст вердикт. Это увеличивает скорость и одновременно с этим сокращает потребление ресурсов. При этом уровень защиты только растет.
Решение работает на базе нескольких компонентов.
Сервер защиты (Security Virtual Appliance)
Многофункциональный security appliance for virtualization поддерживает избыточность для масштабируемости и лучшей надежности, содержит самую последнюю AV-базу и регулярно ее обновляет, передает оптимизированные обновления легким агентам, управляет назначением лицензии на работающие VMs. Для оптимизации сканирования на вредоносное ПО использует технологию «Общий кэш».
Общий и локальный кэш
Общий кэш хранится на SVM. Буквально это таблица с хэшами файлов и их вердиктами. Каждая запись общего кэша представляет уникальный файл. Легкие агенты также используют локальный кэш, который хранится в оперативной памяти VM и содержит записи для каждого отдельного файла. Сочетание этих методов значительно улучшает и оптимизирует тяжелую задачу сканирования файлов.
Сервис, построенный на базе решения от Лаборатории Касперского с легким агентом, позволяет каждому нашему клиенту иметь свои собственные настройки, политики, выделенный карантин и управлять набором ВМ с расставленными легкими агентами выбранным для них способом. Клиент может кастомизировать такие параметры, как глубина сканирования файлов, расположение карантина и прочее.
Благодаря своей функциональности решение:
Весь этот функционал доступен нашим клиентам и благодаря гибким политикам клиент сам может выбрать, что из этого задействовать, а что выключить.
Сервис доступен на всех наших облачных инсталляциях — и в Elastic Cloud, и в аттестованных облаках для работы с ПДн и ГИС. Сегодня это позволяет ВМ наших клиентов чувствовать себя комфортно в небезопасной и едкой среде интернета. Вопрос регуляции также решен: продукт имеет сертификат ФСТЭК, поэтому клиенту не надо искать какое-то специфичное решение. Он получает и «бумажную», и реальную защиту в одном флаконе.
Если у вас некорректные настройки и вы сам себе злобный Буратино, антивирус большой пользы не принесет. Поэтому надо помнить, что кроме него существует и ряд best practices, которым мы советуем неукоснительно следовать.
Использовать принцип запрета по умолчанию
Концепция «одна ВМ — одна роль» хороша, но надо помнить, что машина поднимается из шаблона и наследует какие-то типовые настройки и конфигурации, а возможно, и устаревшие библиотеки. Необходимо предусмотреть, чтобы в этих предварительных настройках все разрешения по умолчанию отсутствовали. При создании машины из шаблона необходимые параметры можно просто включить или разрешить. Например, нам нужен RDP. По умолчанию эта функциональность в золотом образе должна быть отключена, а порт — закрыт.
Такая политика может показаться неудобной, но ее применение приведет к тому, что на каждой ВМ будет включён только тот функционал, который реально нужен для ее работы, а админ не попадет в ситуацию, когда кем-то уже активированы какие-то потенциально опасные функции, но он об этом даже не подозревает.
Деактивация инструментов
Аналогично рекомендуем поступить со многими инструментами. Выключите функционал Java и других прикладных интерпретаторов, включая Powershell и даже CMD.EXE, если в них нет острой необходимости для решения каких-то рабочих задач. Причина такого подхода очевидна. Сегодня Java остается одним из наиболее часто эксплуатируемых вредоносным кодом объектов, а скриптовые цепочки получают все большее распространение в качестве «легального» (т.е. использующего встроенные системные возможности) способа обхода механизмов детектирования.
Изоляция от других ВМ
Мы знаем, что интернет — это небезопасная среда, в которую мы погружаем наши ВМ. Стоит сразу предположить, что внутренняя сеть, в которой мы запускаем машины, также небезопасна.
Иными словами, если мы организуем те или иные сетевые связности между нашими ВМ, открываем порты или интерфейсы, надо реально оценивать, насколько это вообще необходимо. В любом случае, откройте только нужные порты и интерфейсы, все остальное лучше закрыть. Так вы минимизируете риск перемещения зловредов внутри виртуальной среды и возникновения эпидемии. При тщательной изоляции ресурсов поражение какой-то одной ВМ не будет источником неприятностей для других.
Бэкап никто не отменял
Регулярное резервное копирование ваших ВМ жизненно необходимо. Это позволит восстановиться не только в случае вирусной эпидемии, но и при обычных технических сбоях. Но стоит помнить, что поднимая машину из бэкапа, нужно проверить актуальность настроек, применяемых политик и наличие последних обновлений.
И напоследок небольшой чек-лист. Первые два пункта не актуальны для клиентов облака, но мы как провайдер всегда их выполняем, поэтому не можем обойти вниманием. Заказчикам рекомендуем начать сразу с третьего.
1. Безопасность хоста
2. Безопасность гипервизора
3. Безопасность интерфейсов управления
Сервис антивирусной защиты виртуальных машин на базе специализированного решения для виртуальных инфраструктур можно бесплатно протестировать в течение двух недель — достаточно оставить заявку на нашем сайте.
При этом традиционные политики безопасности требуют от нас, чтобы антивирус был запущен на каждой ВМ. Однако ни одно антивирусное решение не обеспечивает 100% защиту. А значит, его тоже можно отключить или не устанавливать вовсе?
Привет, Хабр! Меня зовут Алексей Афанасьев, я менеджер продуктов ИБ в #CloudMTS. Совместно с коллегами из Лаборатории Касперского я подготовил материал, в котором хочу обсудить, насколько виртуальным машинам необходимы средства защиты от вирусов и можно ли обойтись без них. Давайте разбираться вместе: так ли нам нужен антивирус в облаке?
Ландшафт: облачная и традиционная инфраструктура
До облаков в офисах и ЦОДах стояли обычные железные серверы, каждый из которых имел множество функциональных ролей: сервер мог быть одновременно почтой, системой антиспама, базой данных, веб-сервером или прокси. То есть на таком аппаратном сервере запускался целый набор приложений и процессов, а сама «железка» выполняла множество ролей.
После перехода в облако от такого использования серверов отказались. Сейчас на одном хосте запускается множество виртуальных машин, при этом чаще всего применяется подход «одна ВМ — одна роль». Например, одна ВМ — база данных, другая — веб-сервер, третья — прокси и так далее.
С одной стороны, такая практика упрощает настройку и обслуживание ВМ. С другой, рост числа машин приводит к тому, что определенное количество ресурсов перестает нормально контролироваться администратором. Какая-то «заброшенная» виртуальная машина может долго работать самостоятельно, после того как он настроил ее и сконфигурировал. И пока с ней ничего «плохого» не случится, админ, вероятнее всего, на нее и не зайдет. Всем известен принцип «пока работает — не трогай».
Допустим, у нас есть ВМ с функционалом движка веб-сайта. И пока такой движок хорошо и успешно работает, очевидно, заходить на него и запускать что-то «лишнее» вроде антивируса не стоит. А если что-то пойдет не так, мы всегда сможем поднять такую виртуальную машину — преднастроенный движок — из бэкапа, верно?
С другой стороны, такая ВМ смотрит в интернет, достаточно кислотную и опасную среду. Рано или поздно блуждающие по нему вредоносы найдут какую-то необновленную библиотеку, незакрытую уязвимость и через эту машину проникнут на другие ВМ, во внутрь корпоративной инфраструктуры. И далеко не во всех случаях движок потеряет свою рабочую функциональность — мы можем просто не заметить его выход из нормального рабочего состояния.
Нужен ли контроль виртуальной машины?
Виртуальные машины подвержены практически полному спектру угроз, от которых могли бы пострадать и традиционные решения. Однако, в отличие от старой парадигмы установки приложений на серверы, сегодня мы можем легко и быстро удалить зараженную ВМ и затем восстановить ее из бэкапа. Такой подход делает виртуальные машины практически неуязвимыми в глазах ряда специалистов.
Давайте разберемся, можно ли полагаться на эту концепцию, — и для этого рассмотрим ряд сценариев.
Вирусы не запустятся в виртуальной среде
Любой современный зловред действительно будет проверять, в какой среде он оказался — на виртуальной машине или реальной железке.
Существует множество способов обнаружения виртуальных машин:
- VMware and Hyper-V VMs have a (default) MAC address starting with 00-05-69, 00-0c-29, 00-1c-14 or 00-15-5D
- Записи реестра содержат “VMware” or “esx”
- Communications bus with embedded “secret” such as “VMXh”
- Hyper-V: CPUID leaves 0x40000000 — 0x40000006
- VMware BIOS серийный номер начинается на “VMware-” или “VMW
- Memory locations of data structures в IDT и ACPI таблицах
- Benchmarking: discontinuities between ICMP and TCP timestamps, IP ID header values
- Вспомогательные инструменты: Red Pill, ScoopyNG, VMDetect, virt-what, metasploit/check-vm
Однако разработчики вирусного ПО четко понимают, что заражение виртуальной машины из чьей-то корпоративной инфраструктуры дает возможность не только похитить потенциально ценные данные, но и пробраться на другие ВМ, не ограничиваться этим и вызвать эпидемию.
Уже давно можно смело говорить об интеллектуальных функциях вирусов. Например, в 2013 году аналитиками Лаборатории Касперского был обнаружен вредонос, который анализировал среду и самостоятельно решал, что запускать — майнер или шифровальщик.
При заражении можно просто «убить» ВМ и запустить новую из шаблона
Безусловно, виртуальную машину можно просто развернуть из бэкапа или шаблона — у хорошего администратора всегда есть целые каталоги готовых образов. Однако неграмотная работа с золотыми образами способна подвергнуть опасности всю ИТ-инфраструктуру. Например, если при поднятии ВМ по шаблону задается стандартный логин и пароль, его компрометация (не важно, по какой причине — простой перебор, вредоносный код или утечка) — это угроза всей инфраструктуре. После компрометации одной ВМ почти гарантирована компрометация всех машин в сети, созданных из этого образа. Кстати, это касается и машин, и модных сейчас контейнеров.
Вопрос безопасности золотых образов относится не только к паролям по умолчанию, но и к обновленности используемых библиотек и приложений. Нередки случаи, когда из каталога (или даже из бэкапа) поднимается машина с устаревшими библиотеками и модулями. Ведь на тот момент, когда образ создавался, администратор мог и не знать о каких-то угрозах, а необходимых обновлений просто не существовало. Но при запуске такой ВМ сегодня старая необновленная библиотека с уязвимостями может стать серьезной проблемой.
Важно не забывать обновлять и актуализировать используемые шаблоны, причем делать это заранее. Обновление ВМ в рабочей среде не дает гарантии, что какой-то вирус еще не успел скомпрометировать машину. Устанавливайте обновления своевременно — просто восстановления из бэкапа в большинстве случаев недостаточно.
Не могу обойти вниманием популярные сегодня виртуальные десктопы и VDI. Обычно такой рабочий стол создается автоматически из заранее сконфигурированного шаблона. Как правило, администратор закладывает стандартный пароль для встроенной учетной записи, и все это раскатывается на рабочие места сотрудников. Неприятности в таком золотом образе ведут к поражению целого парка запущенных виртуальных рабочих столов, что автоматически приводит к эпидемии во всей корпоративной среде.
К тому же, пользуясь такой практикой, администраторы не всегда помнят, что также необходимо предотвратить последствия произошедшего, даже если зараженная ВМ была удалена: например, поменять пароли, которые мог угнать вирус, или заблокировать учетную запись.
Одна зараженная ВМ — это не страшно
Пользователи облаков часто надеются, что изолирование процессов сможет защитить их инфраструктуру: например, есть миф, что вредонос не сможет мигрировать с одной виртуальной машины на соседнюю из-за изоляции процессов, памяти и прочего. И этим стереотипом нередко пользуются злоумышленники.
Сегодня вирусы уже научились «вырываться» из работающей ВМ, чтобы захватить платформу гипервизора или другие «вещи»:
- Escape to Host
- Escape to VM
- Escape to vNet
Безусловно, виртуальные платформы, драйверы в виртуальных средах, как и любой другой программный код, имеют уязвимости и требуют постоянного обновления и внимательного отношения. А может быть, и контроля. Есть реальные юзкейсы, показывающие их, увы, неабсолютную надежность:
- Cloudburst: эксплойт с повреждением памяти, который позволяет гостевой виртуальной машине выполнять вредоносный код на базовом хосте SubVirt, BluePill
- VMcat, VMChat, VM Drag-n-Sploit
- VENOM (CVE-2015-3456): уязвимость в коде виртуального дисковода гибких дисков позволяет злоумышленнику убежать от гостевой виртуальной машины и потенциально получить доступ к хосту с выполнение кода
- SNAFU (XSA-135): выход через ошибки в эмулируемом сетевом адаптере pcnet QEMU.
Кроме того, потенциально сама виртуальная машина может передавать информацию о своей работе или использовании ресурсов другим виртуальным машинам через вспомогательные каналы, которые включают в себя как программное, так и аппаратное обеспечение:
- ПО: функции, установленные для облегчения работы между виртуальной машиной и хостом, такие как буфер обмена и общий доступ к файлам.
- HW: скрытые и боковые каналы благодаря архитектуре процессора. Например. использование скрытых каналов кэш-памяти L2 для кражи небольшого количества данных с совместно установленной виртуальной машины.
Многие считают, что описанные выше примеры — это экзотика и теория, которые никогда не смогут воплотиться на практике, а эксперты из антивирусных компаний вспоминают о них, чтобы как следует напугать клиента и продвинуть свое ПО.
Было бы прекрасно, если бы это было правдой.
На демонстрации в режиме реального времени, показанная еще на BlackHat 2017 в Азии, была продемонстрирована атака на облако, включая интерактивные сеансы SSH и потоковое видео между двумя виртуальными машинами.
Исследователи создали высокопроизводительный скрытый канал, который может поддерживать скорость передачи более 45 Кбит/с на Amazon EC2, и даже зашифровали его: этот метод устанавливает сеть TCP внутри кеша и передает данные с использованием SSH.
Помимо самих ВМ, есть ряд уязвимостей у самой среды виртуализации:
- VMM имеет большую и сложную кодовую базу и, таким образом, обладает потенциально широкой поверхностью атаки.
- Между 2012-2018 было обнаружено ~170 уязвимостей высокой степени опасности* (CVSS score >7) в Xen (74), KVM (47), VMware ESXi (33), Hyper-V (46) и XenServer (26).
- Наиболее распространенным источником триггера для атак является Пользовательское пространство гостевой VM, но существуют и другие типы, такие как атаки канала управления (например, API VMM).
Антивирус — «вредный» «лишний» потребитель
Компании приходят в облака для экономии своих ресурсов. Но зачем тогда разворачивать в облаке еще один сервис, который будет потреблять мощности, если с вирусами можно справиться «бытовым» способом, описанным выше, — просто снести зараженную ВМ, развернуть новую и спокойно жить дальше?
Установка традиционного антивируса — и вовсе удар по производительности. При использовании неспециализированного решении каждая виртуальная машина будет снабжаться полным набором движков и независимо обновляющихся баз. Как результат — «шторм» одновременных сканирований или обновлений может привести к катастрофическому падению производительности СХД и сетевых ресурсов. Именно поэтому большинство администраторов укрепляются в очевидном, на первый взгляд, мнении о бесполезности и прожорливости антивирусных решений.
Идеальный антивирус: волки целы, овцы сыты
Отказаться полностью от антивирусной защиты достаточно рискованно. Использовать традиционные решения — тоже не лучшая идея. Можно ли среди современных решений найти оптимальный вариант, «заточенный» под работу в облаке? Ведь если вредонос умеет определять, в какой среде он находится, и адаптироваться под окружение, наверное, должен быть и антивирус, который такое умеет!
Иными словами, для защиты наших ВМ в облаке нам необходимо специализированное решение, которое:
- оптимизировано для работы в виртуальных средах;
- защищает от наиболее актуальных облачных угроз;
- эффективно расходует ресурсы внутри среды виртуализации и не мешает ее работе;
- может кастомизироваться под разные политики;
- учитывает сетевое окружение.
А еще было бы неплохо, если бы оно согласовывалось с комплаенсом и регуляцией для работы с ПДн и ГИС.
Пару лет назад мы уже описывали наши подходы к выбору антивирусного сервиса для облачных сред. Не будем повторяться и рекомендуем обратиться к этой статье.
Сегодня, как и тогда, при всем богатстве выбора антивирусных решений на нашем рынке есть два вендора, которые имеют в своей линейке специализированные решения для виртуальных сред — TrendMicro и Лаборатория Касперского. Мы как провайдер выбрали решение от Лаборатории Касперского. Причины этого выбора описаны в статье по ссылке выше. Мы понимаем, что кто-то может быть не согласен с нашим мнением — в этом случае рекомендуем рассмотреть альтернативный вариант.
Наш опыт использования антивируса
Сейчас у Лаборатории Касперского есть два специализированных решения — безагентский антивирус и решение на базе легкого агента. Эти решения отличаются по функциональности и принципу работы.
Безагентское решение предназначено только для VMware — у VMware есть специализированный API, который он предоставляет сторонним вендорам. Через этот API в ВМ, где стоит драйвер-перехватчик, передаются файлы для анализа, а программа сама решает, какие из них блокировать. Это решение не требует установки внутрь ВМ какого-либо специфичного софта, что снимает вопрос инсталляции и долгих тестирований на совместимость. Однако такой подход влияет на работу самого антивирусного решения, потому что у него просто связаны руки. Безагентский антивирус может получать данные, анализировать и отдавать вердикт, но не имеет возможности проводить исследования внутри ВМ и применять современные логики. Очевидно, ограниченность функционала сильно перевешивает его плюсы, поэтому он нам не подходит.
В наших облаках мы используем решение для виртуальных сред на базе легкого агента. В этом случае внутрь каждой ВМ устанавливается легкий агент, а вычислительные операции выносятся на специальную машину, которая содержит антивирусный движок. Такая ВМ называется SVM. Легкие агенты внутри ВМ на Linux или Windows служат транспортом, позволяя перехватить файловую операцию, запрос пользователя на доступ к сети или подключаемые им устройства — например, флэш-накопитель — а затем передать эту информацию для анализа на выделенную ВМ.
Объекты анализируются всего на одной ВМ (SVM). Это экономит ресурсы каждой машины, в том числе на проверку золотых образов или других идентичных файлов. Единожды проверив такой золотой образ или файл в рамках всего гипервизора или кластера, повторно тратить ресурсы на эту операцию решение уже не будет, а сразу даст вердикт. Это увеличивает скорость и одновременно с этим сокращает потребление ресурсов. При этом уровень защиты только растет.
Решение работает на базе нескольких компонентов.
Сервер защиты (Security Virtual Appliance)
Многофункциональный security appliance for virtualization поддерживает избыточность для масштабируемости и лучшей надежности, содержит самую последнюю AV-базу и регулярно ее обновляет, передает оптимизированные обновления легким агентам, управляет назначением лицензии на работающие VMs. Для оптимизации сканирования на вредоносное ПО использует технологию «Общий кэш».
Общий и локальный кэш
Общий кэш хранится на SVM. Буквально это таблица с хэшами файлов и их вердиктами. Каждая запись общего кэша представляет уникальный файл. Легкие агенты также используют локальный кэш, который хранится в оперативной памяти VM и содержит записи для каждого отдельного файла. Сочетание этих методов значительно улучшает и оптимизирует тяжелую задачу сканирования файлов.
Сервис, построенный на базе решения от Лаборатории Касперского с легким агентом, позволяет каждому нашему клиенту иметь свои собственные настройки, политики, выделенный карантин и управлять набором ВМ с расставленными легкими агентами выбранным для них способом. Клиент может кастомизировать такие параметры, как глубина сканирования файлов, расположение карантина и прочее.
Благодаря своей функциональности решение:
- позволяет выполнить анализ поведения — анализируются действия внутри виртуальной машины, при этом те из них, которые антивирус определит как вредоносные, можно откатить.
- обеспечивает функционал системы предотвращения вторжений — HIPS сочетает в себе блокировщик сетевых атак (NAB) и сетевой экран: система мониторит сетевой трафик на наличие вредоносной активности, обнаруживает и блокирует их.
- имеет две важные функции для удаленных рабочих столов и VDI. Контроль устройств управляет доступом к устройствам хранения, сетевым устройствам, устройствам печати и системным шинам, обеспечивая конфиденциальность и защиту от утечки данных. Контроль веб-трафика защищает входящий и исходящий трафик (HTTP, FTP), при этом легкий агент проверяет каждую ссылку — не является ли она фишинговой или вредоносной.
Весь этот функционал доступен нашим клиентам и благодаря гибким политикам клиент сам может выбрать, что из этого задействовать, а что выключить.
Сервис доступен на всех наших облачных инсталляциях — и в Elastic Cloud, и в аттестованных облаках для работы с ПДн и ГИС. Сегодня это позволяет ВМ наших клиентов чувствовать себя комфортно в небезопасной и едкой среде интернета. Вопрос регуляции также решен: продукт имеет сертификат ФСТЭК, поэтому клиенту не надо искать какое-то специфичное решение. Он получает и «бумажную», и реальную защиту в одном флаконе.
Не антивирусом единым
Если у вас некорректные настройки и вы сам себе злобный Буратино, антивирус большой пользы не принесет. Поэтому надо помнить, что кроме него существует и ряд best practices, которым мы советуем неукоснительно следовать.
Использовать принцип запрета по умолчанию
Концепция «одна ВМ — одна роль» хороша, но надо помнить, что машина поднимается из шаблона и наследует какие-то типовые настройки и конфигурации, а возможно, и устаревшие библиотеки. Необходимо предусмотреть, чтобы в этих предварительных настройках все разрешения по умолчанию отсутствовали. При создании машины из шаблона необходимые параметры можно просто включить или разрешить. Например, нам нужен RDP. По умолчанию эта функциональность в золотом образе должна быть отключена, а порт — закрыт.
Такая политика может показаться неудобной, но ее применение приведет к тому, что на каждой ВМ будет включён только тот функционал, который реально нужен для ее работы, а админ не попадет в ситуацию, когда кем-то уже активированы какие-то потенциально опасные функции, но он об этом даже не подозревает.
Деактивация инструментов
Аналогично рекомендуем поступить со многими инструментами. Выключите функционал Java и других прикладных интерпретаторов, включая Powershell и даже CMD.EXE, если в них нет острой необходимости для решения каких-то рабочих задач. Причина такого подхода очевидна. Сегодня Java остается одним из наиболее часто эксплуатируемых вредоносным кодом объектов, а скриптовые цепочки получают все большее распространение в качестве «легального» (т.е. использующего встроенные системные возможности) способа обхода механизмов детектирования.
Изоляция от других ВМ
Мы знаем, что интернет — это небезопасная среда, в которую мы погружаем наши ВМ. Стоит сразу предположить, что внутренняя сеть, в которой мы запускаем машины, также небезопасна.
Иными словами, если мы организуем те или иные сетевые связности между нашими ВМ, открываем порты или интерфейсы, надо реально оценивать, насколько это вообще необходимо. В любом случае, откройте только нужные порты и интерфейсы, все остальное лучше закрыть. Так вы минимизируете риск перемещения зловредов внутри виртуальной среды и возникновения эпидемии. При тщательной изоляции ресурсов поражение какой-то одной ВМ не будет источником неприятностей для других.
Бэкап никто не отменял
Регулярное резервное копирование ваших ВМ жизненно необходимо. Это позволит восстановиться не только в случае вирусной эпидемии, но и при обычных технических сбоях. Но стоит помнить, что поднимая машину из бэкапа, нужно проверить актуальность настроек, применяемых политик и наличие последних обновлений.
И напоследок небольшой чек-лист. Первые два пункта не актуальны для клиентов облака, но мы как провайдер всегда их выполняем, поэтому не можем обойти вниманием. Заказчикам рекомендуем начать сразу с третьего.
1. Безопасность хоста
- OS Hardening: Следите за критическими уязвимостями в HW.
- Проводите патч-менеджмент и контролируйте изменения управления.
- Отключите или удалите ненужные сервисы и ПО.
2. Безопасность гипервизора
- Выполняйте контроль целостности.
- Выполняйте патч-менеджмент.
- Проводите мониторинг гипервизора на наличие признаков компрометации.
3. Безопасность интерфейсов управления
- Минимизируйте поверхность атаки:
— Отключите ненужные сетевые и локальные интерфейсы администратора.
— Обеспечьте доступ через брандмауэр из ненадежных областей.
— Держите сети управления отдельно от гостевых сетей.
— Применяйте строгую аутентификацию и используйте шифрованные сетевые протоколы. - Контролируйте привилегии пользователей.
- Контролируйте журналы и проводите аудиты событий.
- Используйте защищенные интерфейсы управления гипервизоров.
Сервис антивирусной защиты виртуальных машин на базе специализированного решения для виртуальных инфраструктур можно бесплатно протестировать в течение двух недель — достаточно оставить заявку на нашем сайте.
