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

В настоящее время многие разработчики и DevOps-инженеры предпочитают использовать контейнеры для развёртывания сложных вычислительных систем в качестве альтернативы виртуальным операционным системам (ОС).

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

Однако, как и виртуальные ОС, контейнерные системы подвержены множеству проблем безопасности. В отличие от виртуализации, где создаётся новая виртуальная ОС (ядро, пользовательский интерфейс и т. д.), контейнеры используют ядро хостовой ОС, что повышает показатели производительности, но при этом вносит дополнительные риски и проблемы безопасности (рис. 1). Таким образом, если хостовая ОС — Linux, то и внутри контейнера тоже будет Linux. Показательно в данном случае, что неправильно настроенный контейнер, запущенный в привилегированном режиме, может быть использован для монтирования диска хостовой ОС из контейнера, что позволяет злоумышленнику осуществить атаку-побег из контейнера (Docker escape). Если использование вычислительных ресурсов для контейнера никак не ограничено, злоумышленник может выполнить DOS-атаку (Denial of Service), направленную на CPU (Central Processing Unit), тем самым вывести из строя не только целевой контейнер, но и всю операционную систему. Это происходит из-за того, что неконтролируемое потребление процессорных ресурсов вредоносным контейнером приводит к полной утилизации CPU хоста, что вызывает отказ в обслуживании всей системы.

Виртуальные операционные системы

Атаки на виртуальные операционные системы бывают двух основных видов: классические и специфические.

Классические атаки:

1. Brute force. Злоумышленник выполняет подбор учётных данных (логин, пароль и т. д.) методом грубого перебора.
2. DDOS (Distributed Denial of Service). Вывод злоумышленником из строя целевого ресурса.
3. MITM (Man-in-the-Middle). Злоумышленник находится между целевым ресурсом и клиентом, перехватывает и анализирует весь сетевой трафик. Например, находясь в одной беспроводной сети с жертвой, он может выполнить атаку ARP spoofing (Address Resolution Protocol), после чего подменить SSL-сертификаты, создав видимость безопасного соединения с веб-ресурсом. В результате злоумышленник получает возможность похищать конфиденциальные данные.
4. Вредоносное ПО (программное обеспечение): шифровальщики (шифрование данных с целью получения выкупа или уничтожения данных), стилеры (кража данных), майнеры (эксплуатация вычислительных ресурсов с целью заработка криптовалюты) и т. д.
5. Неправильные конфигурации. Злоумышленник может повысить свои привилегии, как вариант, с помощью механизма setuid. Для поиска возможностей повышения привилегий в операционной системе Linux можно использовать скрипт Linux Privilege Escalation Awesome Script (LinPEAS) [1], а для Windows — Windows Privilege Escalation Awesome Scripts (WinPEAS)

Специфические атаки (атаки на средства виртуализации):

1. CVE-2012-1518: уязвимость гипервизоров первого типа (аппаратного) ESXi и ESX версий 3.5–5.0 и 3.5–4.1 соответственно, которая позволяет пользователю гостевой операционной системы повысить свои привилегии через переполнение буфера в VMware Tools; это повышение привилегий возможно только в том случае, если права доступа к директории с VMware Tools настроены неправильно;
2. CVE-2013-1405: уязвимость в средствах виртуализации ESX 3.5–4.1, ESXi 3.5–5.0 и vSphere Server 4.0–4.1, которая может привести к переполнению буфера и запуску произвольного кода; эта уязвимость становится возможной, если у пользователя получается отправить специально сформированный пакет авторизации;
3. CVE-2012-2448: уязвимость, которая может привести к переполнению буфера, позволяя выполнить запуск произвольного кода или вызвать отказ в обслуживании, если пользователь отправляет специально сформированный NFS-пакет на системы ESX 3.5–4.1 и ESXi 3.5–5.0;
4. CVE-2019-5544: уязвимость в ESXi версий 6.7, 6.5, 6.0 и Horizon DaaS 8.x, связанная с протоколом OpenSLP: она возникает из-за переполнения кучи, что позволяет злоумышленнику выполнять произвольный код или вызывать отказ в обслуживании;
5. CVE-2020-3992: уязвимость в гипервизоре ESXi, затрагивающая версии 7.0 (до ESXi_7.0.1-0.0.16850804), 6.7 (до ESXi670-202010401-SG) и 6.5 (до ESXi650-202010401-SG). Она связана с ошибкой типа ‘use-after-free’ в службе OpenSLP, что позволяет злоумышленнику, имеющему доступ к порту 427 на машине ESXi, удалённо выполнять произвольный код.

Какие меры будут эффективными для защиты виртуальных операционных систем?

1. Использование средств защиты информации: антивирусное ПО, средства продвинутой поведенческой аналитики, средства защиты информации от несанкционированного доступа (НСД), Network Access Control (NAC), Firewall и другие.
2. Обновление ПО: регулярное обновление ПО гипервизора и виртуальных ОС для устранения известных проблем безопасности (неправильные конфигурации и уязвимости).
3. Контроль доступа к виртуальным машинам и гипервизору: разграничение прав доступа с использованием политики аутентификации и авторизации, а также ограничение количества открытых сетевых портов и другое; также рекомендуется применять средства контроля целостности конфигурации для снижения рисков, связанных с эксплуатацией уязвимостей, таких как CVE-2013-1405 и CVE-2012-2448.

Контейнерные системы

Атаки

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

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

Неправильная конфигурация:

DoS из контейнера: если ресурсы, которые может использовать контейнер, не ограничены, то скомпрометированный контейнер может провести DoS-атаку на хосте, на котором он запущен.

# DoS ЦП # Start container root@msx:/home/qwerty/Desktop# docker run -d —name malicious-container busybox root@msx:/home/qwerty/Desktop# docker exec -ti id_container /bin/sh # Run in command line root@19cf8c5aa7bd:/# :(){ :|:& };:

Privileged + hostPID: в контексте контейнера, запущенного в привилегированном режиме и в пространстве имён хостовой операционной системы (ОС), команда ‘nsenter —target 1 —mount —uts —ipc —net —pid – bash’ предоставит доступ к пространству имён процесса с идентификатором (PID, Process IDentifier) 1: обычно это процесс init или systemd в хостовой ОС. Таким образом, nsenter позволяет выполнять команды в окружении хоста, обеспечивая доступ ко всем его ресурсам и процессам.

root@msx:/home/qwerty/Desktop# docker run —rm -it —pid=host —privileged ubuntu bash root@5dd06594e9f8:/# nsenter —target 1 —mount —uts —ipc —net —pid — bash root@msx:/# cat /etc/shadow root:*:19837:0:99999:7::: daemon:*:19837:0:99999:7::: bin:*:19837:0:99999:7::: sys:*:19837:0:99999:7::: sync:*:19837:0:99999:7::: games:*:19837:0:99999:7:::

hostNetwork: если контейнер настроен с использованием сетевого драйвера хоста (—network=host), его сетевой стек не изолирован от хоста. Таким образом, контейнер разделяет сетевое пространство имён хоста и не получает своего собственного выделенного IP-адреса: это позволяет контейнеру напрямую связывать все службы с IP-адресом хоста. Более того, контейнер может перехватывать весь сетевой трафик, который хост отправляет и получает через общий интерфейс, используя команду tcpdump -i eth0.

qwerty@msx:~/Desktop$ docker run —rm -it —network=host ubuntu bash root@msx:/# tcpdump -i ens33 … 10:59:30.395347 IP msx > lo-in-f113.1e100.net: ICMP echo request, id 5834, seq 12, length 64 10:59:30.408605 IP lo-in-f113.1e100.net > msx: ICMP echo reply, id 5834, seq 12, length 64 10:59:31.397126 IP msx > lo-in-f113.1e100.net: ICMP echo request, id 5834, seq 13, length 64 10:59:31.406124 IP lo-in-f113.1e100.net > msx: ICMP echo reply, id 5834, seq 13, length 64 …

Монтирование диска внутри контейнера: если контейнер запущен в привилегированном режиме, то злоумышленник, находясь внутри, сможет смонтировать диск хостовой ОС и совершить атаку Docker escape.

root@msx:/home/qwerty/Desktop# fdisk -f root@msx:/home/qwerty/Desktop# docker run —rm -it —privileged ubuntu bash root@062421d595b9:/# mkdir -p /mnt/hola root@062421d595b9:/# mount /dev/sda2 /mnt/hola root@062421d595b9:/# cd /mnt/hola root@062421d595b9:/mnt/hola# ls -l total 4194412 lrwxrwxrwx 1 root root 7 Apr 22 2024 bin -> usr/bin drwxr-xr-x 2 root root 4096 Feb 26 2024 bin.usr-is-merged drwxr-xr-x 3 root root 4096 Nov 5 05:45 boot dr-xr-xr-x 2 root root 4096 Apr 24 2024 cdrom

Какие способы защиты контейнерных систем мы рекомендуем, исходя из своего опыта?

• Сканирование образов на наличие уязвимостей и вредоносного ПО c gjvjom. Trivy [3], Snyk [4]; использование команды docker scan.
• Изоляция контейнеров осуществляется с помощью пространств имён (Namespaces) и контрольных групп (Cgroups), что позволяет разделять процессы на группы и выделять им системные ресурсы. Всего в системах Linux существует шесть пространств имён: MNT (Mount), UTS (Unix Time Sharing), PID (Process IDentifier), NET (Network), IPC (inter-process communication), USER.
• Использование минимальных привилегий (Capabilities). Например, скрипт для сбора метрик сетевых интерфейсов может обладать привилегией CAP_SYS_ADMIN, что позволяет ему выполнять системные вызовы, такие как bpf, mount, umount и setns. Это создаёт риск, поскольку злоумышленник может использовать данный скрипт для монтирования диска хостовой ОС из контейнера через системный вызов mount. Кроме того, системный вызов bpf может быть использован для загрузки произвольных eBPF-программ в ядро ОС, что также представляет угрозу безопасности.
• Seccomp (secure computing) — механизм, ограничивающий системные вызовы, которые может выполнять процесс. Он создаёт профиль, в котором заранее определяются разрешённые системные вызовы. Если злоумышленник попытается выполнить произвольный код, то seccomp предотвратит использование системных вызовов, которые не были заранее объявлены. Профиль Seccomp по умолчанию [5].
• AppArmor — реализация системы Mandatory Access Control (MAC), которая позволяет ограничить возможности, системные вызовы, а также доступ к файлам и папкам. В Docker доступен шаблон AppArmor [6].
• Управление доступом: разграничение прав доступа с использованием политики аутентификации и авторизации для ограничения взаимодействия между контейнерами.

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

Автор: Максим Мельник, инженер – аналитик компании «Газинформсервис».