Как защитить облако от вирусов

Обновлено: 22.04.2024

Гибридная ИТ-инфраструктура, содержащая физические и облачные компоненты, стала обычным явлением во многих компаниях. Админы, программисты и обычные пользователи быстро привыкают к новой реальности. Но несмотря на все преимущества нового мира, в нём имеется масса неочевидных опасностей. В этом посте мы расскажем о том, что и как нужно защищать в облачной ИТ-реальности.

В чем, собственно, проблема?

Если не погружаться в тему, может показаться, что проблема довольно надуманная. Какая разница, где находится сервер, если это всё та же Windows Server или всё тот же Linux. Просто железо, на котором он выполняется, размещено в дата-центре. Ставим привычный антивирус, IPS/IDS, подключаем к SIEM, и готово.

Но все, кто уже частично или полностью переместился в облако, понимают, что этого недостаточно, потому что облачная инфраструктура устроена и работает иначе, а ещё потому, что во многих случаях приходится работать с гибридной средой, когда имеются физические, виртуальные и облачные серверы. А ещё добавляются контейнеры, облачные хранилища и бессерверные вычисления, которые вообще непонятно как проверять. Ну, а если в компании имеются разработчики, то процессы DevOps только добавляют тумана неопределённости в и так непростую картину мира.

Серверы - физические, виртуальные, облачные

Мы считаем, что облачное решение для защиты серверов должно сочетать в себе функции традиционного антивируса, а также IPS, межсетевого экрана и сканера уязвимостей. Нелишним будет поведенческий контроль приложений, проверка целостности и мониторинг системных журналов. И в качестве вишенки на торте — поведенческий анализ с использованием машинного обучения и интеграция с песочницами для проверки подозрительного кода.

Консоль Trend Micro XDR с информацией о возможном инциденте. Источник (здесь и далее): Trend Micro

Всё это должно иметь удобный API и интеграцию с пайплайн-решениями и интеграцией с SIEM, XDR и пайплайн-решениями для обнаружения, блокировки и расследования инцидентов.

Ещё одно требование — поддержка всех распространённых операционных систем и облачных платформ от Windows и Linux до AWS и MS Azure.

Контейнеры и системы оркестрации

Уязвимости контейнерных платформ — довольно популярный вектор кибератак последних лет. Злоумышленники пытаются скомпрометировать Docker и Kubernetes, чтобы запустить на выполнение вредоносный контейнер, обойти аутентификацию или внедрить вредоносное ПО в популярный образ в репозитории.

Чтобы предотвратить это, защитная система должна не только знать о существовании контейнеров, но и уметь с ними работать, отслеживая:

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

Введение

Очередной выпуск конференции был посвящён наложенным средствам обеспечения безопасности в облачных средах. Вместе со спикерами мы разбирались в том, для чего нужны дополнительные ИБ-решения для облака, чем они лучше (или хуже) встроенных средств безопасности, какие функции таких систем наиболее востребованны со стороны заказчиков. Отдельный блок вопросов был посвящён особенностям российского рынка наложенных средств безопасности для облака. Поскольку сфера информационной безопасности в нашей стране активно регулируется государственными органами, мы не могли не затронуть тему сертификации — тем более что на вопросы ведущего отвечали представители как отечественных, так и зарубежных вендоров.

Модератором беседы выступил Алексей Лукацкий, бизнес-консультант по безопасности Cisco.

Со стороны потенциальных заказчиков наложенных систем ИБ в облаке выступали зрители прямого эфира, которые приняли участие в нескольких опросах, дополнявших обсуждаемые экспертами темы. Предлагаем вам ключевые тезисы прошедшей конференции.

Зачем нужны наложенные средства информационной безопасности в облаке

Павел Коростелев высказал мнение, что через три–четыре года встроенных средств защиты облачных сервисов будет достаточно для обеспечения безопасной работы. Однако по мере развития мультиоблачного подхода, когда одна компания может использовать сервисы разных вендоров, а также собственную облачную среду, возрастает потребность в едином решении для управления политиками безопасности. Для этого могут потребоваться наложенные средства.

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

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

Ещё одна возможная проблема — разрозненность встроенных средств безопасности, решающих различные задачи в рамках одного сервиса. Внешняя система поможет правильно настроить все компоненты облачных средств защиты, а в случае перевода инфраструктуры в другой сервис — ускорит процесс настройки, поскольку ИБ-специалисты останутся в прежнем интерфейсе.

Три критерия необходимости наложенных средств облачной безопасности:

работа в мультиоблачной среде,
высокая критическая значимость облачных нагрузок,
зрелость бизнеса (уровень проникновения облачных технологий в бизнес-процессы организации).

С какими облаками вендорам легче работать

Какой облачный провайдер наиболее предпочтителен для разработчиков наложенных средств безопасности? Мы задали спикерам этот вопрос, чтобы понять, как видят этот рынок вендоры и в каких сегментах представлены их продукты.

Наиболее перспективные, с точки зрения разработчиков наложенных ИБ-систем, облачные сервисы — это те, которые имеют значительную долю рынка, понятную документацию и API с богатыми функциональными возможностями. На взгляд Валерия Денисова, это — в первую очередь AWS, Azure и Google Cloud.

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

Подводя итог первой части дискуссии, мы провели опрос зрителей прямого эфира и спросили у них, используются ли в их компаниях облака для критических бизнес-процессов. Оказалось, что примерно половина респондентов (49 %) не готова доверять критически важные процессы облачным сервисам. Сторонников перевода ключевых задач в облако меньше — 29 %. Ещё 22 % ответивших не обладают информацией по этому вопросу.

Рисунок 1. Использует ли ваша компания облака для критических бизнес-процессов?

Как делится ответственность между облачным провайдером, заказчиком и вендором

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

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

Переводя свои бизнес-процессы в облако, пользователь разделяет с провайдером ответственность за безопасность данных и доступа к ним. В зависимости от модели взаимодействия (IaaS, PaaS или SaaS) уровень ответственности заказчика может меняться. Наложенные решения помогают пользователю лучше контролировать его область ответственности.

Что умеют наложенные средства облачной безопасности

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

Workload Security — защита операционной системы, контроль её целостности, антивирусный мониторинг и другие средства обеспечения безопасности пользовательских виртуальных машин.
Network Security — системы предотвращения вторжений, контролирующие каждый поступающий пакет.
Системы контроля облачных хранилищ.
Технологии защиты, интегрируемые в типовые (Office 365 и другие) и пользовательские приложения.
Со стороны провайдера — поставляемые внешним вендором средства защиты персональных данных, системы для защиты инфраструктуры VMware, решения для обеспечения доверия к платформе и создания защищённого канала связи до облака.
Средства контроля корректности настроек в публичных облаках.

Михаил Кондрашин сказал, что для различных продуктов Trend Micro применяются разные модели лицензирования, среди которых есть и поминутная, почасовая и помесячная тарификация.

По мнению Павла Коростелева спрос на продукты, лицензируемые по модели SaaS, зависит от уровня зрелости рынка. На данный момент в России нет достаточного интереса покупателей для этого класса решений. Объёмы продаж, сопоставимые с выручкой от систем для защиты ЦОД, ожидаются в России через 5–7 лет.

Что эффективнее — наложенные или встроенные средства защиты облачных систем

Зрители прямого эфира тоже поделились с нами своими мнениями по поводу способов защиты облачных систем. Как показал наш опрос, 11 % считают ИБ-средства, встроенные в облачные сервисы, достаточно эффективными. Чуть большее количество ответивших (13 %) доверяют наложенным системам безопасности. Максимальное же число голосов нашей аудитории получил компромиссный вариант — гибридная модель. Его выбрали 76 % опрошенных.

Рисунок 2. Какие механизмы защиты облаков вы считаете более эффективными?

Особенности российского рынка защиты облачных сервисов

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

Представители Check Point и Trend Micro в свою очередь отметили, что они скорее ориентированы на работу с другой категорией заказчиков и не получают запросов на сертификацию облачных средств защиты.

Что же касается зрителей прямого эфира, то, как показал наш опрос, 51 % из них заинтересованы в сертификации облачного средства защиты, а 49 % не видят в этом необходимости.

Рисунок 3. Для вас актуальна сертификация облачного средства защиты?

Эксперты также сформулировали особенности, присущие российскому рынку ИБ-решений для облачных сервисов:

Очень высокий уровень локализации — 95 % всех денег, которые тратятся на облачные сервисы в России, остаются в стране.
Отечественные заказчики менее зрелы, очень мало компаний реализуют стратегию Cloud First.
Значительный объём аттестованных сегментов, например систем для хранения персональных данных.
Использование российских алгоритмов для шифрования данных.
Высокий спрос на средства защиты трафика и недоверие к облачным провайдерам со стороны служб безопасности заказчиков.
Использование заказчиками мультиоблачной стратегии для снижения рисков блокировки западных сервисов регуляторами.
Тенденция к отказу от продуктов VMware в качестве основы облачных виртуальных машин и поиск отечественного решения в рамках импортозамещения.
Взрывной рост рынка, который будет продолжаться и в ближайшие годы.

Какие механизмы защиты облака наиболее востребованны у заказчиков

Рисунок 4. Какие механизмы защиты в облаке вы будете внедрять (или уже внедрили) самыми первыми?

Как научиться доверять облачному провайдеру

Важный вопрос, который модератор беседы задал экспертам в студии, — как контролировать доступ к данным, выгруженным в облако. Каким образом заказчик может получить информацию о том, что его конфиденциальные данные не попали в чужие руки — законным (по решению суда) или нелегальным способом? Безусловно, средства защиты могут собирать телеметрию, передаваемую облачным провайдером, но где гарантия, что последний будет отдавать всю необходимую информацию?

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

Выводы

Информация занимает одно из важнейших мест в жизни нашего общества, поэтому защита информации является неотъемлемой частью ее использования.

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

Методы защиты

Вредоносное ПО постоянно совершенствуется, в связи с этим производители антивирусов постоянно обновляют базу уже известных сигнатур (участков кода известного вирусного ПО, по которому это ПО детектируется) или вовсе запрещают модификацию и добавление ПО, а также файлов в критичных местах ЭВМ.

Для борьбы с новыми угрозами используют механизмы эвристического и сигнатурного анализа и проактивные (поведенческие) защиты, которые анализируют ПО в процессе работы и выявляют подозрительные действия. Также часто используется метод проверки контрольных сумм.

Новые методы маскировки

Сейчас начали появляться концептуально новые руткиты, основанные на работе вне операционной системы.

Один из таких методов используется в Boot-руткитах. Они переписывают загрузочную запись (MBR – главная загрузочная запись) и после загрузки BIOS выполняют вредоносный код, и только затем загружается операционная система.

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

Существующие методы защиты

Атаки по времени и по производительности основаны на искажении временных и скоростных характеристик ЭВМ при внедрении гипервизора.

Облачные вычисления и будущее антивирусных систем

С развитием телекоммуникационных систем многие антивирусные компании начали обращать внимание на облачные вычисления [3, 4, 5].

Концепция облачных вычислений заключается в предоставлении конечным пользователям удаленного динамического доступа к услугам, приложениям (включая ОС и различную инфраструктуру) и вычислительным ресурсам различной мощности [Рис. 1][6].

Рисунок 1 – Интернет облако и его пользователи

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

Платформенные облака весьма специализированны и служат, обычно, большим вычислителем и накопителем статистики работы настольных антивирусных систем или базой данных новейших сигнатур. Облака услуг используются для предоставления пользователям возможности загрузки подозрительных файлов в облако и антивирусного анализа без потребления ресурсов ЭВМ пользователя [5].

Организация работы антивируса с облаком

Работа с метаданными и хеш-функциями исполняемых файлов. Их анализ в облаке экспертной системой [7];
Передача актуальных вирусных сигнатур частыми и маленькими порциями на ЭВМ пользователя [5];
Технология SONAR (выставление баллов опасности приложения, по выполняемым им операциям и анализ в облаке) [3].

Недостатки современных облачных антивирусных систем

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

Также серьезной проблемой является работа антивирусных систем в незащищенных средах [Рис. 2.]. По этой причине многие антивирусные средства содержат механизмы защиты целостности, но и сегодня эта проблема является актуальной [8, 9].

Рисунок 2 – Проблемы работы в незащищенных средах

Облачные антивирусные системы сделали лишь маленький шаг в сторону освоения всех возможностей облачных вычислений. Эти шаги призваны снизить потребление пользовательских ресурсов, ускорить обновление вирусных сигнатур [7] и создать экспертную базу современных угроз. Такое решение не станет “серебряной пулей” [10]. Оно не привнесло новых методов борьбы с вредоносным ПО, а лишь модифицировало, и без того уже сильно устаревшие подходы.

Беззащитность перед руткитами с аппаратной виртуализацией

Все подходы, применяемые в работе современных антивирусных систем оказываются беспомощны против руткитов, выполняющихся вне ОС и принципиально нового вредоносного ПО [1, 11].

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

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

Облачный антивирус с защищенной средой исполнения

Облако применяется при серьезных вычислениях для снижения нагрузки на клиентов. В антивирусных системах оно служит быстрым каналом распространения новых антивирусных баз, а так же накопителем известных угроз.

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

Главным, и самым сложным, в таком подходе будет выявление характеристик ЭВМ, которые искажаются при внедрении вредоносного ПО в ЭВМ пользователя, и безопасная передача их в облачный вычислитель.

Такой подход позволит гораздо быстрее реагировать на новые угрозы, потому что существует всего один узел, принимающий решение. Это позволит избегать эпидемий, которые сейчас приобретают все более массовый характер.

Концепция создания защищенной среды исполнения

В жизни создание настоящей защищенной среды необходимо различным государственным и военным ведомствам. Особенно если они имеют дело с государственной тайной, от их работы зависит безопасность страны.
В остальных областях использования ЭВМ такой режим почти не используется в виду его дороговизны и пониженной гибкости.

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

Под защищенной средой следует понимать сбор информации, анализ и принятие решения об инфицировании клиентской ЭВМ в среде, которая находится вне зоны сбора информации. Эта среда имеет большую надежность и управляемость, по сравнению с клиентской ЭВМ, и не может быть скомпрометирована вследствие инфицирования клиентской ЭВМ.

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

Оценка защищенности и эффективности предлагаемого решения

Клиентская ЭВМ может быть скомпрометирована, но облако останется в работающем состоянии, потому что от клиента облако получает только данные для ведения статистики и расчетов, обратно может отсылаться любая необходимая информация.

В таком случае из строя может выйти лишь клиентская часть, облачный вычислитель остается работоспособным в не зависимости от состояния клиентских ЭВМ.

По производительности. Все вычислительные операции переносятся в облако, тем самым снижая нагрузку на ЭВМ пользователя;
По латентности. Скорость обнаружения новых угроз и оповещения доступных клиентов о новой опасности увеличивается;
По защищенности. Облако не может быть скомпрометировано клиентом, поэтому база угроз будет всегда актуальна и цела;
По актуальности. Экспертная система при решении о заражении принимает во внимание все данные собранные с клиентских ЭВМ. Появляются более широкие возможности анализа, чем у подхода с выявлением сигнатур.
По внедрению новых решений. Новые методы обнаружения и обезвреживания вирусных угроз в первую очередь будут внедряться в облако, тем самым уменьшая влияние на принятие решений при устаревании ПО на ЭВМ клиента.

Выявление характеристик контроля

Актуальным методом обнаружения тонкого гипервизора можно считать контроль состава и характеристик оборудования. Работающий гипервизор, для полного контроля над пользовательской ЭВМ, должен полностью виртуализировать работу с работу ОС с оборудованием. Ввиду многообразия и различий в характеристиках оборудования, тонкий гипервизор должен обладать огромным набором подмодулей работы с оборудованием. При этом можно основываться на том же времени реакции и производительности отдельного оборудования при поиске гипервизора. Естественно весь анализ должен проводиться на безопасной ЭВМ или облаке.

Например, при проверке оперативной памяти пользовательской ЭВМ ее объем уменьшится при работе тонкого гипервизора. Некоторые эксперты по безопасности высказывали мнение, что при проверках подобного рода, гипервизор может выгрузить себя из памяти, тем самым скрыться от антивируса. При таких действиях гипервизора становятся доступны стандартные способы борьбы с вредоносным ПО: сканирование дисков, сигнатурный анализ, анализ загрузочных областей и пр.

Стоит обратить внимание на технологии динамического изменения производительности процессоров, шин, памяти и накопителей информации. В современных переносных ЭВМ существует множество технологий призванных экономить энергопотребление при работе от батарей, снижать шумность и нагрев оборудования. В большинстве случаев эти технологии динамически изменяют производительность ЭВМ для достижения нужного эффекта. В таких случаях интерпретация статистических данных, полученных от клиента, должна быть модифицирована с учетом изменяющейся производительности (ввод поправочных коэффициентов). В данной работе вопросы динамического изменения производительности ЭВМ не рассматриваются, потому что они никак не влияют на демонстрацию представленных подходов и алгоритмов.

При этом традиционные политики безопасности требуют от нас, чтобы антивирус был запущен на каждой ВМ. Однако ни одно антивирусное решение не обеспечивает 100% защиту. А значит, его тоже можно отключить или не устанавливать вовсе?

Ландшафт: облачная и традиционная инфраструктура

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

Нужен ли контроль виртуальной машины?

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

Давайте разберемся, можно ли полагаться на эту концепцию, — и для этого рассмотрим ряд сценариев.

Вирусы не запустятся в виртуальной среде

Любой современный зловред действительно будет проверять, в какой среде он оказался — на виртуальной машине или реальной железке.

Существует множество способов обнаружения виртуальных машин:

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). Это экономит ресурсы каждой машины, в том числе на проверку золотых образов или других идентичных файлов. Единожды проверив такой золотой образ или файл в рамках всего гипервизора или кластера, повторно тратить ресурсы на эту операцию решение уже не будет, а сразу даст вердикт. Это увеличивает скорость и одновременно с этим сокращает потребление ресурсов. При этом уровень защиты только растет.

Решение работает на базе нескольких компонентов.

Общий и локальный кэш
Общий кэш хранится на SVM. Буквально это таблица с хэшами файлов и их вердиктами. Каждая запись общего кэша представляет уникальный файл. Легкие агенты также используют локальный кэш, который хранится в оперативной памяти VM и содержит записи для каждого отдельного файла. Сочетание этих методов значительно улучшает и оптимизирует тяжелую задачу сканирования файлов.

Сервис, построенный на базе решения от Лаборатории Касперского с легким агентом, позволяет каждому нашему клиенту иметь свои собственные настройки, политики, выделенный карантин и управлять набором ВМ с расставленными легкими агентами выбранным для них способом. Клиент может кастомизировать такие параметры, как глубина сканирования файлов, расположение карантина и прочее.

Благодаря своей функциональности решение:

Не антивирусом единым

Если у вас некорректные настройки и вы сам себе злобный Буратино, антивирус большой пользы не принесет. Поэтому надо помнить, что кроме него существует и ряд best practices, которым мы советуем неукоснительно следовать.

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

Бэкап никто не отменял
Регулярное резервное копирование ваших ВМ жизненно необходимо. Это позволит восстановиться не только в случае вирусной эпидемии, но и при обычных технических сбоях. Но стоит помнить, что поднимая машину из бэкапа, нужно проверить актуальность настроек, применяемых политик и наличие последних обновлений.

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

Читайте также: