TOC

Как проверить безопасность Docker Host с помощью Docker Bench для безопасности в Ubuntu 16.04

Вступление

Использование Docker для контейнеризации ваших приложений и сервисов может дать вам некоторые преимущества безопасности из коробки, но в стандартной установке Docker все еще есть место для некоторых улучшений конфигурации, связанных с безопасностью. Https://www.cisecurity.org [Центр интернет-безопасности], некоммерческая организация, миссия которой состоит в распространении передового опыта в области интернет-безопасности, созданный шаг https://www.cisecurity.org/benchmark/docker/[a пошаговый контрольный список для защиты Docker. Впоследствии группа Docker выпустила инструмент аудита безопасности - Docker Bench for Security - для запуска этого контрольного списка на хосте Docker и отметки любых обнаруженных проблем.

В этом руководстве мы установим Docker Bench for Security, а затем используем его для оценки позиции безопасности установки Docker по умолчанию (из официального хранилища Docker) на хосте Ubuntu 16.04. Затем мы исправим некоторые проблемы, о которых он нас предупреждает.

Наши исправления в основном состоят из следующих двух обновлений конфигурации:

  • Установка + auditd + и настройка правил аудита для демона Docker и связанных с ним файлов

  • Обновление файла конфигурации Docker + daemon.json

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

Предпосылки

Для завершения этого урока вам понадобится следующее:

  • Сервер Ubuntu 16.04 с пользователем sudo, не являющимся пользователем root. Вы можете узнать, как это настроить, с помощью нашего Initial Server Setup с Ubuntu 16.04 руководства.

  • Docker устанавливается из официального репозитория Docker, как описано в Как установить и использовать Докер на Ubuntu 16.04. Обязательно предоставьте свой доступ не-пользователю root, добавив его в группу * docker *. Это описано в шаге 2 учебника.

Шаг 1 - Установка Docker Bench Security

Для начала, SSH на хосте Docker от имени пользователя без полномочий root.

Сначала мы клонируем сценарий Docker Bench for Security на сервер с помощью + git +, а затем запускаем сценарий прямо из клонированного репозитория.

Перейдите в каталог, в который пользователь может писать. В этом примере мы загрузим скрипт в домашний каталог пользователя:

cd ~

Затем клонируйте репозиторий + docker-bench-security + Git:

git clone https://github.com/docker/docker-bench-security.git

Это извлечет все файлы из репозитория и поместит их в локальный каталог + docker-bench-security +. Затем перейдите в этот результирующий каталог:

cd docker-bench-security

Наконец, чтобы выполнить аудит безопасности, запустите скрипт + docker-bench-security.sh +:

./docker-bench-security.sh
Output# ------------------------------------------------------------------------------
# Docker Bench for Security v1.3.4
#
# Docker, Inc. (c) 2015-
#
# Checks for dozens of common best-practices around deploying Docker containers in production.
# Inspired by the CIS Docker Community Edition Benchmark v1.1.0.
# ------------------------------------------------------------------------------

Initializing Tue Jun  5 18:59:11 UTC 2018


[INFO] 1 - Host Configuration
[WARN] 1.1  - Ensure a separate partition for containers has been created
[NOTE] 1.2  - Ensure the container host has been Hardened
[INFO] 1.3  - Ensure Docker is up to date
[INFO]      * Using 18.03.1, verify is it up to date as deemed necessary
. . .

Скрипт проходит через множество тестов и выдает результаты + INFO +, + NOTE +, + PASS + или + WARN + для каждого из них. Установка Docker по умолчанию в Ubuntu 16.04 пройдет многие из этих тестов, но покажет некоторые предупреждения в разделах 1,2 и 4.

В оставшейся части этого руководства мы устраняем эти предупреждения путем обеспечения безопасности установки Docker.

Шаг 2 - Исправление предупреждений о конфигурации хоста

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

  • 1.1 Убедитесь, что был создан отдельный раздел для контейнеров *

Чтобы обеспечить надлежащую изоляцию, рекомендуется хранить контейнеры Docker и все + / var / lib / docker + в собственном разделе файловой системы. Это может быть сложно в некоторых ситуациях облачного хостинга, когда у вас может не быть возможности разделить диски. В этих случаях вы можете выполнить этот тест, переместив каталог данных Docker на внешнее подключенное к сети блочное устройство.

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

  • 1.3 Убедитесь, что Docker обновлен *

Этот тест распечатывает вашу версию Docker. Вы можете проверить, какая версия является текущей стабильной версией, посетив the примечания к выпуску Docker CE. Если вы не в курсе, и вы установили Docker с помощью + apt-get install y, вы можете снова использовать` + apt-get in` для обновления пакета Docker:

sudo apt-get update
sudo apt-get upgrade

  • 1.4 Убедитесь, что только доверенные пользователи могут управлять демоном Docker *

В prerequisite учебник по установке Docker мы добавили нашего пользователя без полномочий root в Группа * docker *, чтобы предоставить ему доступ к демону Docker. Этот тест выводит строку группы * docker * из файла + / etc / group:

Outputdocker:x:999:

В этой строке отображаются все пользователи, входящие в группу * docker *. Просмотрите строку и убедитесь, что только соответствующие пользователи имеют право управлять демоном Docker. В приведенном выше примере наш авторизованный пользователь * sammy * выделен. Чтобы удалить пользователей из этой группы, вы можете использовать + gpasswd +:

gpasswd -d  docker

  • 1.5–1.13. Убедитесь, что аудит настроен для различных файлов Docker *

Нам нужно установить и настроить + auditd +, чтобы включить аудит некоторых файлов, каталогов и сокетов Docker. Auditd - это подсистема мониторинга и учета доступа в Linux, которая регистрирует важные системные операции на уровне ядра.

Установите + audd с` + apt-get`:

sudo apt-get install auditd

Это установит и запустит демон + auditd +. Теперь мы настроим + auditd + для мониторинга файлов и каталогов Docker. В текстовом редакторе откройте файл правил аудита:

sudo nano /etc/audit/audit.rules

Вы должны увидеть следующий текст:

/etc/audit/audit.rules

# This file contains the auditctl rules that are loaded
# whenever the audit daemon is started via the initscripts.
# The rules are simply the parameters that would be passed
# to auditctl.

# First rule - delete all
-D

# Increase the buffers to survive stress events.
# Make this bigger for busy systems
-b 320

# Feel free to add below this line. See auditctl man page

Вставьте следующий фрагмент внизу файла, затем сохраните и выйдите из редактора:

/etc/audit/audit.rules

-w /usr/bin/docker -p wa
-w /var/lib/docker -p wa
-w /etc/docker -p wa
-w /lib/systemd/system/docker.service -p wa
-w /lib/systemd/system/docker.socket -p wa
-w /etc/default/docker -p wa
-w /etc/docker/daemon.json -p wa
-w /usr/bin/docker-containerd -p wa
-w /usr/bin/docker-runc -p wa

Эти правила предписывают Audit наблюдать (+ -w +) указанный файл или каталог и записывать любые записи или изменения атрибутов (+ -p wa +) в эти файлы.

Перезапустите + auditd +, чтобы изменения вступили в силу:

sudo systemctl restart auditd

На этом этапе вы успешно настроили + auditd + для просмотра файлов и каталогов Docker на наличие подозрительных изменений. Вы можете перезапустить сценарий Docker Bench for Security, чтобы подтвердить, что тесты в Разделе 1 теперь пройдены.

Для получения дополнительной информации о + auditd + вы можете прочитать наш учебник How To Используйте систему аудита Linux на CentOS 7. Несмотря на то, что они написаны для CentOS, разделы по настройке и использованию системы аудита в равной степени применимы к Ubuntu.

Теперь, когда мы проверили нашу конфигурацию хоста, мы переходим к разделу 2 аудита безопасности Docker, конфигурации демона Docker.

Шаг 3 - Исправление предупреждений о настройке Docker Daemon

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

Для начала откройте файл конфигурации в вашем любимом редакторе:

sudo nano /etc/docker/daemon.json

Это представит вам пустой текстовый файл. Вставьте в следующее:

/etc/docker/daemon.json

{
   "icc": false,
   "userns-remap": "default",
   "log-driver": "syslog",
   "disable-legacy-registry": true,
   "live-restore": true,
   "userland-proxy": false,
   "no-new-privileges": true
}

Сохраните и закройте файл, затем перезапустите демон Docker, чтобы он выбрал эту новую конфигурацию:

sudo systemctl restart docker

Теперь вы можете повторно запустить аудит, чтобы подтвердить, что все предупреждения Раздела 2 были учтены.

Переменные конфигурации, которые мы вставили в этот файл, расположены в том же порядке, что и предупреждения аудита. Давайте пройдемся по каждому из них:

  • 2.1 Убедитесь, что сетевой трафик ограничен между контейнерами на мосту по умолчанию *

Это предупреждение устраняется с помощью +" icc ": false + в файле конфигурации. Эта конфигурация создает контейнеры, которые могут связываться друг с другом только при явном связывании с помощью + - link = + в командной строке Docker или параметра + links: + в файлах конфигурации Docker Compose. Одним из преимуществ этого является то, что если злоумышленник скомпрометирует один контейнер, ему будет сложнее найти и атаковать другие контейнеры на том же хосте.

  • 2.8 Включить поддержку пространства имен пользователя *

Пространства имен Linux обеспечивают дополнительную изоляцию для процессов, выполняющихся в ваших контейнерах. Перераспределение пространства имен пользователя позволяет процессам запускаться как * root * в контейнере, в то время как они переопределяются для менее привилегированного пользователя на хосте. Мы включаем переназначение пространства имен пользователя строкой " userns-remap ":" default " в файле конфигурации.

Мы устанавливаем параметр в «+ default », что означает, что Docker создаст пользователя * dockremap *, которому будут назначены пользователи контейнера. Вы можете проверить, что пользователь * dockremap * был создан с помощью команды ` id +`:

sudo id dockremap

Вы должны увидеть вывод, похожий на следующий:

Outputuid=112(dockremap) gid=116(dockremap) groups=116(dockremap)

Если переназначение пользователей контейнера на другого хост-пользователя имеет больше смысла для вашего варианта использования, укажите в файле конфигурации комбинацию пользователя или + user: group + вместо + default +.

  • 2.11. Убедитесь, что авторизация для клиентских команд Docker включена *

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

Мы не будем освещать этот процесс здесь, потому что специфика слишком сильно зависит от отдельных ситуаций. Аудит продолжит помечать этот тест как «+ WARN +», хотя доступ к стандартному локальному сокету Docker по умолчанию защищен требованием членства в группе * docker *, поэтому его можно безопасно игнорировать.

  • 2.12. Убедитесь, что централизованное и удаленное ведение журнала настроено *

В файле конфигурации демона Docker мы включили стандартное ведение журнала системного журнала с помощью строки " log-driver ":" syslog ". Затем вы должны настроить системный журнал для пересылки журналов на централизованный сервер системного журнала. Это получает журналы с хоста Docker и от любого злоумышленника, который может изменить или удалить их.

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

/etc/docker/daemon.json

   `"log-opts": { "syslog-address": "udp://:" }`

Обязательно замените IP-адрес на свой собственный адрес сервера системного журнала.

В качестве альтернативы вы можете указать драйвер журнала, например + splunk + или + fluentd +, для отправки журналов демона Docker с использованием других сервисов агрегации журналов. Дополнительную информацию о драйверах журналов Docker и их конфигурации см. По адресу consult в официальной документации по драйверам журналирования Docker.

  • 2.13 Убедитесь, что операции с устаревшим реестром (v1) отключены *

Это предупреждение исправляется строкой +" disable-legacy-registry ": true + в файле конфигурации демона. Это отключает небезопасный устаревший протокол реестра изображений. Поскольку поддержка этого протокола уже удалена из демона Docker, этот флаг в настоящее время считается устаревшим.

  • 2.14 Убедитесь, что живое восстановление включено *

Указывая +" live-restore ": true + в конфигурации демона, мы позволяем контейнерам продолжать работу, когда демон Docker не работает. Это улучшает время работы контейнера при обновлении хост-системы и других проблемах стабильности.

  • 2.15 Убедитесь, что прокси-сервер пользователя отключен *

Строка +" userland-proxy ": false + исправляет это предупреждение. Это отключает пользовательский процесс + docker-proxy +, который по умолчанию обрабатывает перенаправление портов хоста в контейнеры и заменяет его правилами + iptables +. Если доступна шпилька NAT, прокси-сервер пользователя не нужен и должен быть отключен, чтобы уменьшить поверхность атаки вашего хоста.

  • 2.18. Обеспечить ограничение доступа контейнеров к новым привилегиям. *

Строка +" no-new-privileges ": true + в конфигурации демона предотвращает повышение привилегий внутри контейнеров. Это гарантирует, что контейнеры не смогут получить новые привилегии, используя двоичные файлы + setuid + или + setgid +.

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

Шаг 4 - Включить Доверие к контенту

Последний тест, помеченный нашим аудитом: «4.5 Убедитесь, что Доверие к контенту для Docker включено +». Доверие к контенту - это система для подписи образов Docker и проверки их подписей перед их запуском. Мы можем включить доверие контента с помощью переменной окружения ` DOCKER_CONTENT_TRUST +`.

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

export DOCKER_CONTENT_TRUST=1

Запуск аудита после этой команды + export + должен показать, что Доверие к контенту включено, и сбросить это предупреждение. Чтобы включить его автоматически для всех пользователей и всех сеансов, добавьте переменную + DOCKER_CONTENT_TRUST + в файл + / etc / environment +, который является файлом для назначения общесистемных переменных среды:

echo "DOCKER_CONTENT_TRUST=1" | sudo tee -a /etc/environment

Дополнительную информацию о доверии Docker Content можно найти в the официальной документации о доверии Docker Content.

На данный момент мы рассмотрели все предупреждения, помеченные сценарием Docker Bench для безопасности. Теперь у нас есть более безопасный хост Docker для запуска контейнеров.

Заключение

В этом руководстве мы установили сценарий Docker Bench for Security, использовали его для проверки безопасности нашей установки Docker и рассмотрели предупреждения путем установки и настройки + auditd + и файла конфигурации демона Docker.

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

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

Related