Admin
Администратор
Безопасность Docker: теория, уязвимости и практические рекомендации
Уважаемые читатели! Материалы, которые я публикую имеют исключительно учебную цель и призваны помочь в развитии. Использование этих знаний для взлома, несанкционированного доступа или любых других противозаконных действий недопустимо. Помните, что несанкционированное вмешательство в чужие системы влечет за собой юридическую ответственность. Все риски и последствия таких действий ложатся исключительно на вас.
--------------------------------------------------------------Часть I----------------------------------------------------------------
Что такое Docker?
Docker - это ведущая платформа в мире для контейнеризации программного обеспечения. Разработчики используют Docker, чтобы устранить проблему <на моей машине все работает>, возникающую при совместной работе над кодом. Администраторы используют Docker для параллельного запуска и управления приложениями в изолированных контейнерах, добиваясь более высокой плотности вычислений. Компании используют Docker для создания гибких конвейеров поставки программного обеспечения, чтобы быстрее выпускать новые функции для приложений на Linux и Windows Server с повышенной безопасностью и надежностью.
Docker - это один из видов оболочки для контейнеров Linux, предоставляющий простой и удобный интерфейс для работы с контейнерами. На сегодняшний день это самое популярное решение для контейнеризации, изначально для Linux, но с поддержкой Windows containers (с 2016 года) и macOS через Docker Desktop. Docker упаковывает приложение и его зависимости в один файл. При запуске этого файла создается виртуальный контейнер. Программа работает в этом виртуальном контейнере так, как если бы она работала на реальном физическом компьютере.
История Docker
Изначально Docker был внутренним проектом компании dotCloud, созданным ее основателем Соломоном Хайксом во Франции. Он стал результатом инновационного развития многолетних облачных технологий dotCloud и был открыт в марте 2013 года по лицензии Apache 2.0, а основной код проекта поддерживается на github. Позже проект Docker присоединился к Linux Foundation и выступил учредителем Альянса по стандартизации контейнеров (Open Container Initiative, OCI).
После открытия исходного кода Docker получил широкое внимание и активное обсуждение. Из-за огромной популярности проекта Docker в конце 2013 года компания dotCloud решила сменить название на Docker Inc. Изначально Docker был разработан и реализован на Ubuntu 12.04. Red Hat начала поддерживать Docker, начиная с RHEL 6.5. Google также широко использует Docker в своем PaaS-продукте.
Упрощенная схема архитектуры Docker и его ключевых компонентов
1.Клиент
Пользователи взаимодействуют с Docker через клиент Docker, вводя такие команды, как:
docker build (создает образ на основе Dockerfile)
docker pull (загрузка образа из репозитория на локальную машину)
docker run (запускает контейнер из образа)
Клиент взаимодействует с демоном Docker через переменную DOCKER_HOST (по умолчанию - локальный хост, но это может быть и удаленный хост)
2.Docker-демон
Это основной фоновый сервис, управляющий объектами Docker:
Образы - это неизменяемые шаблоны, используемые для создания контейнеров (например, образ NGINX).
Контейнеры - запущенные экземпляры образов (например, работающий экземпляр NGINX).
Демон прослушивает команды клиента и выполняет такие операции, как сборка, извлечение и запуск
3.Репозиторий образов (Registry)
Централизованные сервисы для хранения и распространения образов (такие как Docker Hub, частные репозитории).
Упомянутый на схеме NGINX - это пример образа. Пользователи могут получить его из репозитория с помощью docker pull или загрузить собственный образ с помощью docker push
Безопасность Docker
Для обеспечения изолированной работы приложений в контейнерах и гарантирования их безопасности Docker использует множество механизмов безопасности и мер изоляции, включая пространства имён (Namespaces), группы управления (Cgroups), ограничение возможностей (Capabilities), принудительный контроль доступа на уровне ядра и многое другое.
Давайте рассмотрим это более подробно.
Пространства имён ядра (Kernel Namespaces)
Пространства имён ядра обеспечивают наиболее базовую и прямую форму изоляции. Каждый раз при запуске контейнера с помощью docker run Docker в фоновом режиме создаёт для контейнера отдельный набор пространств имён. Благодаря этому процессы, запущенные внутри одного контейнера, не видят и практически не могут повлиять на процессы, запущенные в других контейнерах или на хост-машине.
Кроме того, каждый контейнер обладает собственным независимым сетевым стеком, что означает полную сетевую изоляцию между контейнерами. Конечно, при соответствующей настройке на хосте два контейнера могут взаимодействовать друг с другом через свои сетевые интерфейсы. С точки зрения сетевой архитектуры, сетевое взаимодействие между двумя контейнерами аналогично соединению двух физических машин через коммутатор. Это позволяет большинству стандартных сетевых правил и политик напрямую применяться к взаимодействию между контейнерами.
Пространства имён ядра Linux были впервые представлены в версиях ядра между 2.6.15 и 2.6.26. Это означает, что с июля 2008 года (дата выпуска ядра версии 2.6.26) код, связанный с пространствами имён уже давно и широко используется и протестирован в огромном количестве производственных систем. Несомненно, проектирование и реализация пространств имён ядра находятся на достаточно зрелом уровне.
Группы управления (Cgroups)
Control Group (сокращённо Cgroup) - это еще один важный компонент Linux-контейнеров.
Основная задача Cgroup --> учёт и ограничение системных ресурсов. Cgroup предоставляет механизмы ограничения и метрики для различных ресурсов компьютера, таких как память, процессор (CPU), дисковый ввод-вывод (I/O) и другие. Это гарантирует, что каждый контейнер получает справедливую долю ресурсов и не может исчерпать их настолько, чтобы вызвать отказ всей системы.
Таким образом, хотя Cgroups не могут предотвратить доступ одного контейнера к данным или процессам другого контейнера и не обеспечивают изоляцию на уровне безопасности, они играют критически важную роль в защите от от DoS-атак
Код Cgroup существует в ядре Linux уже довольно давно: его разработка началась в 2006 году, а в основное ядро он был включён в версии 2.6.24.
Возможности (Capabilities) ядра Linux
Возможности (Capabilities) преобразуют изначально двоичную систему управления правами root / не root в более гибкую и детализированную систему контроля доступа. Например, процессу, которому нужно просто занять порт ниже 1024 (как веб-серверу), больше не требуется запускаться от имени root. Достаточно просто наделить его специальной возможностью net_bind_service. Таким образом, почти все функции, которые раньше требовали прав root, теперь могут выполняться с использованием конкретных capabilities.
Это имеет огромное значение для безопасности контейнеров. На типичном сервере множество процессов нуждаются в правах root: SSH-демон, cron-демон, службы записи логов, управления модулями ядра, настройки сети и другие. Однако в контейнерах всё по другому - почти все эти задачи выполняются хост-системой, а не внутри контейнера. Следовательно, в большинстве случаев контейнерам вообще не нужны настоящие права root. Это означает, что root внутри контейнера обладает гораздо меньшими привилегиями, чем настоящий root на хосте.
Например, контейнер может:
- Запрещать все операции монтирования (mount)
- Блокировать доступ к raw-сокетам (что предотвращает спуфинг сетевых пакетов)
- Ограничивать определённые операции с файловой системой, например создание или запись в специальные устройства (device nodes)
- Запрещать загрузку модулей ядра
Это означает, что даже если хакер каким-то образом получит права root внутри контейнера, ему будет крайне сложно нанести серьёзный ущерб или сбежать из контейнера на хост-систему.
Такое ограничение прав не влияет на работу обычных приложений, но существенно сокращает потенциальные векторы атак для хакеров. По умолчанию Docker отключает все ненужные capabilities, используя принцип белого списка (whitelist).
Функции безопасности ядра Linux
Помимо capabilities, Docker использует ряд других функций безопасности, предоставляемых ядром Linux, для защиты контейнеров. Наиболее важными из них являются AppArmor и Seccomp.
1.AppArmor
Docker может использовать AppArmor для повышения уровня безопасности. По умолчанию Docker автоматически генерирует и загружает для каждого контейнера стандартный профиль AppArmor.
AppArmor (Application Armor) - это один из модулей безопасности ядра Linux. В отличие от традиционной модели дискреционного контроля доступа (DAC), используемой в Unix-системах, AppArmor реализует мандатный контроль доступа (MAC) через подсистему LSM (Linux Security Modules).
Это позволяет ограничить ресурсы, к которым может обращаться программа, строго определённым набором. Эти правила загружаются в ядро через так называемые профили, которые чётко определяют, к каким системным ресурсам приложение может обращаться и какие действия ему разрешены. Например, профиль может разрешить приложению сетевой доступ, использование raw-сокетов или чтение/запись файлов, соответствующих заданным путям. Любые действия, не разрешённые профилем, по умолчанию блокируются.
AppArmor - это зрелая и проверенная технология, включённая в основное ядро Linux начиная с версии 2.6.36.
2.Seccomp
Secure Computing Mode (Seccomp) - это функция безопасности ядра Linux, предназначенная для ограничения системных вызовов, доступных процессу. По умолчанию процессы могут использовать множество системных вызовов, хотя на практике большинство из них в течение всего жизненного цикла процесса никогда не используются. Seccomp позволяет сузить этот набор до действительно необходимых вызовов.
Фильтрация осуществляется с помощью правил, написанных в формате Berkeley Packet Filter (BPF). Эти правила позволяют анализировать номера системных вызовов и их аргументы, принимая решение - разрешить или запретить конкретный вызов.
Ограничивая доступ к ненужным системным вызовам, Seccomp значительно уменьшает поверхность атаки (attack surface) ядра. При запуске контейнера Docker по умолчанию включает Seccomp-защиту. Используется белый список только тех системных вызовов, которые считаются безопасными и широко применяемыми в Linux. Системные вызовы, способные потенциально привести к утечке данных, побегу из контейнера escape или недавно добавленные вызовы, ещё не прошедшие достаточную проверку на стабильность и безопасность, исключаются из этого списка.
Вывод
Docker использует множество механизмов обеспечения безопасности для гарантии изоляции и защиты контейнеров. Помимо традиционных мер безопасности - таких как устранение уязвимостей и повышение безопасности кода - Docker в своей общей архитектуре безопасности следует принципу минимальных привилегий. Согласно этому принципу, контейнер должен обладать только теми правами и возможностями, которые ему действительно необходимы, и иметь доступ исключительно к тем ресурсам, которые ему разрешено использовать.
Исходя из этого, Docker использует namespaces для изоляции процессов, cgroups для ограничения потребления аппаратных ресурсов и ограничивает capabilities (возможности), тем самым отбирая у контейнера ненужные привилегии. Кроме того, применяются механизмы Seccomp и AppArmor с политиками белого списка, строго регламентирующие, к каким системным вызовам и ресурсам может обращаться контейнер. Благодаря этим многоуровневым ограничениям, типичные методы обхода песочниц оказались неэффективны против Docker-контейнеров.
Что касается атак 0day, нацеленных на сами эти механизмы безопасности или на ядро Linux, им препятствуют два серьёзных обстоятельства:
1. Упомянутые модули безопасности и само ядро Linux существуют уже более 10 лет, прошли многократную проверку в реальных производственных средах и тщательный аудит исходного кода.
2. Принцип минимальных привилегий значительно сокращает поверхность атаки на ядро, в результате чего подавляющее большинство уязвимостей, потенциально позволяющих выполнять произвольный код в ядре, не могут быть успешно эксплуатированы из-за отсутствия необходимых условий для их срабатывания.
Кроме того, основной код Docker написан на языке Go. Встроенные в Go по умолчанию механизмы защиты памяти (memory safety) существенно снижают риски атак, основанных на повреждении памяти (memory corruption attacks), направленных непосредственно против самого Docker.
Векторы атак на Docker
Основные проблемы безопасности Docker можно разделить на следующие четыре пункта:
1. Уязвимости ядра Linux и уровень поддержки им namespaces и cgroups
2. Безопасность самого демона Docker (dockerd)
3. Неправильные или слишком слабые конфигурации (по умолчанию или пользовательские)
4. Обход или отключение механизмов усиления безопасности ядра
Рассмотрим их более подробно.
1.Атака на само ядро
Контейнеры Docker работают поверх ядра хост-машины, а базовая изоляция процессов и ограничение ресурсов реализуются модулями ядра - Namespace и Cgroup. Следовательно, безопасность самого ядра является фундаментом для безопасности контейнеров. Уязвимости в ядре могут привести к побегу из контейнера.
Кроме того, хотя основное ядро Linux уже давно стабильно поддерживает Namespace и Cgroup, если Docker запущен на пользовательском или старом ядре, в котором эта поддержка реализована некорректно или неполноценно, это может создать непредсказуемые риски.
При этом не все уязвимости ядра можно успешно эксплуатировать изнутри контейнера. Встроенные механизмы ограничения Docker - такие как Seccomp и ограниченный набор Capabilities - блокируют доступ контейнерных процессов ко многим системным вызовам и функциям ядра. Например, уязвимость CVE-2017-16995 в модуле ядра BPF не может быть использована из контейнера по умолчанию, поскольку системный вызов bpf в таком случае запрещён политикой Seccomp.
2.Атака на сам демон Docker
Хотя сами контейнеры имеют сильные механизмы защиты, сам демон Docker защищён гораздо слабее. По умолчанию он запускается от имени root и не защищён такими подсистемами безопасности, как Seccomp или AppArmor. Поэтому успешная эксплуатация уязвимости в демоне Docker немедленно даст хакеру полные права root на хост-машине без каких-либо дополнительных препятствий.
Стоит отметить, что по умолчанию Docker не включает изоляцию через User Namespace, а это означает, что пользователь root внутри контейнера обладает теми же правами на запись и чтение файлов на хосте, что и настоящий root. Таким образом, если процесс внутри контейнера получит возможность взаимодействовать с файловой системой хоста, права доступа уже не станут преградой. Яркий пример - CVE-2019-5736 (побег через runc), где перезапись бинарника хоста из контейнера была тривиальной из-за совпадения UID 0.
Поскольку Docker написан на языке Go, большинство атакующих сосредоточены на поиске логических уязвимостей, а не типичных memory corruption-проблем. Кроме того, после запуска контейнера взаимодействие между процессами внутри контейнера и демоном Docker значительно ограничено из-за изоляции. Поэтому основные атаки на Docker нацелены на фазы запуска контейнера или загрузки образа.
Для снижения рисков Docker поддерживает механизмы подписывания и верификации образов, а также настоятельно рекомендует использовать только доверенные (официальные или проверенные) образы.
3.Ошибки конфигурации
По умолчанию конфигурация Docker использует безопасные настройки контейнеров. Однако принцип минимальных привилегий иногда конфликтует с особыми требованиями приложений. Например, VPN или сетевые службы, требующие расширенных сетевых прав. Чтобы поддерживать такие случаи, Docker позволяет заменять стандартные профили безопасности пользовательскими. Однако неправильная настройка таких профилей может существенно ослабить защиту и расширить поверхность атаки.
Яркий пример ---> запуск контейнера с флагом --privileged. В этом режиме отключаются практически все механизмы безопасности Docker (namespaces, capabilities, seccomp, AppArmor и т.д.), что позволяет запускать приложения, невозможные в обычном режиме (например, VPN или системы маршрутизации). Однако это же означает, что любой хакер, получивший права root внутри такого контейнера, мгновенно получает полный контроль над хост-машиной с правами root.
4.Обход механизмов усиления безопасности ядра
Безопасность Docker во многом зависит от подсистем безопасности ядра Linux (например, AppArmor, SELinux, Seccomp и другие). Если в самих этих модулях существуют уязвимости, позволяющие обойти наложенные ограничения (или если эти механизмы намеренно отключены), безопасность контейнеров оказывается под серьёзной угрозой.
К счастью, за десятилетия развития ядра Linux такие случаи обхода были крайне редкими. За последние несколько лет не было зафиксировано серьёзных публичных уязвимостей, позволяющих обойти встроенные механизмы безопасности ядра.
--------------------------------------------------------------Часть II----------------------------------------------------------------
Как определить, запущена ли текущая машина в Docker-контейнере
Когда хакер получает доступ к хосту, первым делом ему нужно понять находится ли он внутри Docker-контейнера или на реальной машине. Вот самые распространенные и часто используемые методы:
1.Проверка наличия файла .dockerenv
ls -la /.dockerenv
Во всех Docker-контейнерах при старте автоматически создаётся пустой файл /.dockerenv. Раньше он использовался LXC (предшественником Docker) для передачи переменных окружения внутрь контейнера, однако сейчас Docker больше не использует LXC, поэтому содержимое этого файла пусто.
2.Анализ cgroup
cat /proc/1/cgroup | grep "docker"
CGroup (Control Group) - механизм ядра Linux для управления процессами по группам. Для ограничения ресурсов Docker создает для каждого контейнера контрольную группу и родительскую группу с именем docker. Если процесс запущен внутри контейнера, его cgroup будет содержать слово docker. В обычной linux системе таких записей нет.
3.Анализ списка процессов
ps aux
Внутри контейнера количество процессов обычно значительно меньше по сравнению с реальной средой.
Неавторизованный доступ к Docker API
За последние годы сообщество, работающее с контейнерами, старается применять на практике важные принципы безопасности - такие как многоуровневая защита и минимальные необходимые права. Например, раньше Docker запрещал только самые опасные возможности (capabilities), т.е. использовал чёрный список. А теперь Docker по умолчанию запрещает все capabilities и разрешает только те, которые действительно нужны для работы контейнера (белый список). Это намного безопаснее.
Но проблема в том, что пользователь всегда может изменить настройки контейнера или указать особые параметры при запуске (например, дать ему root, доступ к файлам хоста, лишние права и т.д.). И тогда даже хорошо защищенный по умолчанию контейнер становится уязвимым.
Так что чаще всего главная дыра в безопасноти - это сам пользователь.
Причина уязвимости
По умолчанию демон Docker (dockerd) использует Unix-сокет для локальной связи - это безопасно. Но если пользователь настроит его неправильно (например, чтобы он принимал подключения со всех IP-адресов 0.0.0.0), то доступ к нему можно получить из сети
Если не настроен контроль доступа (например, не включена TLS-аутентификация или отсутствуют ограничения firewall), то любой может напрямую получить доступ к API по сети и без какой-либо аутенфикации выполнять различные команды управления Docker.
Доступ к Docker API по сути эквивалентен наличию root прав на хосте, потому что через Docker API можно:
- запускать контейнеры с привилегиями (--privileged)
- монтировать корневую файловую систему хоста (-v /:/host)
- создавать новые контейнеры с возможностью полного захвата узла
- и т.д.
Проверка уязвимости
Измените файл /lib/systemd/system/docker.service и добавьте в него следующее содержимое:
ExecStart=/usr/bin/dockerd -H tcp://0.0.0.0:2375 -H unix:///var/run/docker.sock
После сохранения и выхода выполните следующие две команды:
sudo systemctl daemon-reexec
sudo systemctl restart docker
Если команда curl http://ip:2375/info | jq возвращает информацию о Docker-демоне, то существует уязвимость, указывающая на то, что Docker API открыт наружу и на нем не настроена аутентификация.
/info - один из стандартных интерфейсов Docker API, который возвращает системную информацию о демоне: версию Docker, драйвер хранения, настройки сети и т.д.
Настоятельно рекомендую прочитать ---> https://www.trendmicro.com/en_us/re...ovel-cryptojacking-attack-abusing-docker.html
Статистика CVE-уязвимостей
По данным ресурса CVE Details (https://www.cvedetails.com/vulnerability-list/vendor_id-13534/product_id-28125/Docker-Docker.html) Docker c 2014 года имеет 25 идентификаторов CVE. Согласно стандарту CVSS 4.0, 5 из них классифицируются как уязвимости с критическим риском, что составляет 20% от общего числа уязвимостей.
Воспроизведение уязвимости несанкционированного доступа в Docker Desktop (CVE-2025-9074)
Введение в Docker Desktop
Docker Desktop - это настольное приложение для Windows, Linux и macOS, которое предоставляет интуитивно понятный графический интерфейс и набор инструментов командной строки CLI, позволяющих пользователям легко создавать, совместно использовать и запускать контейнерные приложения в локальной среде.
Описание уязвимости
В Docker Desktop 20 августа 2025г обнаруженa уязвимость CVE-2025-9074, которая позволяет локально запущенным Linux-контейнерам получать доступ к Docker Engine API (по умолчанию - 192.168.65.7:2375) через настроенную подсеть Docker. Эта уязвимость присутствует независимо от того, включена ли функция Enhanced Container Isolation (усиленная изоляция контейнеров), и независимо от состояния опции expose daemon on tcp://localhost:2375 without TLS.
Затронутые версии
4.25 < Docker Desktop < 4.44.3
Влияние уязвимости
1.Позволяет выполнять обширный набор привилегированных команд через Docker Engine API. Например: контроль над другими контейнерами, создание новых контейнеров, управление образами и т.д. (без необходимости монтирования Docker socket).
2.В некоторых случаях (например, при использовании Docker Desktop для Windows с бэкендом WSL) даёт возможность монтировать диски хост-системы с теми же правами, что и у пользователя, запустившего Docker Desktop (если пользователь является администратором, то Docker Engine будет работает с правами администратора).
Это может привести к несанкционированному доступу к файлам пользователя в системе хоста.
Затронутые платформы
Windows и macOS
Воспроизведение уязвимости
Предположим, теперь у нас есть доступ к контейнеру в Docker Desktop:
Для начала выполните следующую команду в контейнере, чтобы просмотреть все запущенные контейнеры. Запишите название любого образа (оно понадобится нам позже)
Далее выполните в контейнере следующие три команды:
После выполнения этих действий проверьте папку /Users/$USERNAME/tmp. Файл pwn.txt был успешно записан на хост-систему:
Рекомендации по устранению уязвимости
1. Немедленное обновление
Создайте резервные копии данных: docker save / docker export
Установите последнюю версию: https://docs.docker.com/desktop/release-notes/
Убедитесь, что установленная версия ≥ 4.44.3.
Перезапустите все контейнеры: docker restart $(docker ps -aq)
2.Если обновление невозможно
Сетевая изоляция: блокировка брандмауэром 192.168.65.7:2375/tcp
Использования контейнеров: Запускайте только официальные или проверенные образы контейнеров. Приостановите ненужные контейнеры.
Контроль доступа: включите расширенную изоляцию контейнеров (требуется подписка Docker Business).
Интересный кейс из личного опыта
Попали мы через уязвимый Jenkins в один из контейнеров заказчика. Внутри контейнера обнаружили, что к нему смонтированы директории с хоста. Проверив одну из них, мы нашли приватные ssh-ключи. В итоге скопировали id_rsa себе, вышли из контейнера и буквально через минуту уже залогинились как root на сам хост:
ssh -i key root@ip
Побег из Docker'а через уязвимости ядра
Это тип эксплуатации, когда в ядре хост-машины есть уязвимость. Однако не все уязвимости эксплуатируемы: механизмы вроде Seccomp и capabilities часто блокируют их (например, CVE-2017-16995 не работает по умолчанию).
Уязвимости ядра обычно имеют идентификатор CVE. Например, CVE-2016-5195 (Dirty COW)
Метод эксплуатации практически ничем не отличается от обычного повышения привилегий через Dirty COW. Побег из контейнера становится возможен по следующей причине: Docker и хост-машина используют одно и то же ядро. Чтобы воспользоваться этой уязвимостью, на хосте должна быть уязвимая версия ядра
Помимо Dirty COW, существует множество других уязвимостей в ядре, которые тоже могут привести к побегу из контейнера. Ниже приведён список таких CVE:
- CVE-2019-16884
- cve-2020-14386
- CVE-2021-3493
- CVE-2021-22555
- CVE-2022-0492
- CVE-2022-0847 (Dirty Pipe)
- CVE-2022-23222
Про DockerHub
На официальном сайте Docker мы видим огромное количество образов контейнеров, некоторые из которых выпущены официально, а другие упакованы и загружены пользователями. Это создаёт серьёзную проблему безопасности: некоторые пользователи специально оставляют внутри контейнеров бэкдоры, которые выполняются во время их работы. Именно такие случаи были особенно распространены на ранних этапах развития технологий контейнеризации.
Подробнее про такой вид атаки читать здесь --->
Интеллект-карта безопасности Docker
Рекомендации по безопасности Docker
Обеспечение безопасности образов
1)Соблюдать принцип минимальной установки: выбирать официальные или проверенные базовые образы из доверенных источников (не скачивать образы без истории сборки), устанавливать только минимально необходимые зависимости. Проверять подпись образа (чтобы быть уверенным, что его не подменили)
2)Перед использованием образа проводить сканирование на уязвимости и проверку соответствия базовым требованиям безопасности. Удалить из образа все ненужные права setuid и setgid (SUID/SGID).
3)Проверять, не открыты ли порты управления Docker 2375/2376, чтобы избежать уязвимостей неавторизованного доступа. Настраивать аутентификацию, устанавливать ACL, разрешать подключение к соответствующим портам только с доверенных IP-адресов.
Безопасность самих контейнеров
1)Правильно ограничивать права контейнеров: запускать сервисы от имени НЕ-root пользователя, не рекомендуется запускать Docker в привилегированном режиме (--privileged). Вместо этого использовать механизм capabilities для гибкой настройки необходимых прав доступа (можно добавлять особые возможности по одной с помощью --cap-add и --cap-drop)
2)Обеспечить сетевую изоляцию между контейнерами. В новых версиях Docker сети изолированы по-умолчанию; используйте отдельные сети (docker network create <network-name>) вместо устаревшего параметра --icc=false и подключайте контейнеры только к тем сетям, где им положено быть. Кроме того, все соединения между Docker и хост-машиной должны быть защищены с помощью TLS-сертификатов и шифрования.
docker network create --driver bridge My_Network
docker run -d --network My_Network --name container1 image
docker run -d --network My_Network --name container2 image
3)Обеспечивать изоляцию и ограничение ресурсов контейнеров. Ограничивать сетевую пропускную способность, дисковый I/O, использование CPU. Например, настроить параметр --memory, чтобы предотвратить DoS-атаки из-за исчерпания всех ресурсов хоста одним контейнером.
docker run -d \
--name My_Container \
--memory=256m \
--memory-swap=256m \
--cpu-shares=512 \
--cpus=1 \
--pids-limit=100 \
image
Заключение
Главная мысль этой статьи: „Часто системы ломают не из-за уязвимостей, а из-за неправильных настроек.“
И с этим трудно не согласиться - на практике так и есть. Например, в ходе пентеста часто нужно повысить свои привилегии. Иногда администраторы очень умны: сразу ставят обновления и закрывают известные уязвимости. А даже если уязвимость есть, написать под неё рабочий эксплойт - дело непростое и требует много усилий. Но стоит найти всего одну ошибку в настройках - например, файл с чрезмерными правами или сервис, запущенный от root без необходимости - и получить повышенные привилегии можно буквально в пару шагов, без сложных трюков.
С точки зрения защиты это означает: устранить все ошибки в конфигурации гораздо труднее, чем закрыть известные уязвимости, особенно когда в системе много разных механизмов, которые переплетены между собой.
