Пособие для самостоятельного изучения "Docker Sercurity"

# Пособие для самостоятельного изучения "Docker Sercurity" :::info ### Содержание документа 1. Моделирование атак 2. Особеннсти работы docker, которые можно использовать для атаки 3. Полезные функии docker с точки зрения безопасности 4. Практика ::: ## Моделирование атак ::: danger Самым главным аспектом настройки безопасной среды является определение основных видов атак, которые возможны на систему. Для контейнеров выделяют следующие наиболее опасные вектора. Все атаки перечисляются без конкретных наименований сервисов. ::: ### Вектор №1: Container Escape (System) Выход за пределы контейнера злоумышленника, которых смог скопрометировать через любую уязвимость приложение работающее в контейнере. При использовании этого вектора атакующий попадает в основную систему, которая управляет контейнерами и захватывает полностью её. ### Вектор №2: Other Containers via Network Вектор атаки при котором компроментация приложения в контейнере завершилась успешно, однако выйти в основную ОС атакующий не смог. Поэтому он может начать атаку на контейнера, которые так же доступны в одной сети. При успехе, атакующий попадает в основную систему через уязвимость в соседнем контейнере той же системы контейнеризации. ### Вектор №3: Attacking the Orchestration Tool via Network Вектор, при котором атакующий может работать с системой оркестрации контейнеров через сетевой интерфейс. Это может быть осуществлено через стандартный API, а так же через возможности ОС, где работает система оркестрации. ### Вектор №4: Attacking the Host via Network Вектор, при котором злоумышленник может атаковать приложение, которое работает совместно с системой оркестрации контейнеров в одной локальной сети. Посредством уязвимого хоста атакующий может обращаться к системе оркестрации, которая имеет активный сетевой интерфейс. ### Вектор №5: Attacking other Resources via Network Вектор, при котором происходи компроментация сервисов или систем хранилищ на оснвании которых работает контейнер или вся система орекстрации. Это могут быть как банально файловые системы так и системы, которые в инфраструктурах используются для организации аутентификации - LDAP AD и т.д. ### Вектор №6: Resource Starvation Вектор, который появляется в следствии того, что все контейнеры так или иначе расширивают ресурсы, которые есть в одной и той же ОС. Поэтому перегрузка одного из контейнеров может вызвать нарушение работы всех контейнеров. ### Вектор №7: Host compromise Вектор, при котором происходит компрометация операционной системы, где установлена система оркестрации контейнеров. ### Вектор №8: Integrity of Images Вектор при котором осуществляется так называемая атака на цепочку поставок. При этой атаке может быть внедрено вредоносное программное обеспечение в любую часть исходного кода или компонента легитимного приложения. ## Сценарии атак на системы контейнерезации и методы противодействия ### Особеннсти работы docker, которые можно использовать для атаки Демон запущен от пользователя `root` соответственно может стать достаточно интересной целью для проведеиня побега из контейнера или экскалации привелегий на основнйо ОС. Для митигации этого сценария можно воспользоваться **Rootless** режимом. Его настройку и особенности использования можно найти [тут](https://docs.docker.com/engine/security/rootless/). Основная фишка этого режима заключается в том, что система где запускается демон не будет стартовать команды , контейнеры с привелегиями `root`. Только доверенные пользователи должны иметь доступ к привелегиям `root`. По-умалчанию, при монтировании файловой системы для работы с контейнером docker может позволять изменять любые данные внутри расшаренного ресурса. Так же может быть произведена атака на монтирование всей корневой директории в контейнер. docker может управляться через API, поэтому если используется контейнер, который может использовать функционал docker для создагия новых контейнеров, то мкханизм передачи данных от пользователя в docker должен максимально проверяться перед запуском в системе. Пропущенные параметры, которые останутся без дополнительного исследования могут стать стартовой точкой для проведения атак. В качестве механизма по-умолчанию, в docker используется REST API докера, с которым работает и CLI в том числе. Начиная с docker 0.5.2, из-за больших проблем с безопасностью используется UNIX сокет вместо loopback интерфейса. Такое решение позволяет контроллировать доступ к управляющему интерфейсу с помощью разграничений доступа файловыой системы. Однако, если достаточно прав на обозрение, то можно использовать для доутпа к интерфейсу туннель ssh: ssh -L /path/to/docker.sock:/var/run/docker.sock На демон так же могут быть проведены атаки типа атак на данные. При этих атаках заставляют приложение работать неожиданным образом. Это может произойти при предоставлении кофигов для демона или образа для обработки. Не рекомендуется хранить вместе с демоном и системой docker на сервере еще какие-либо инструменты для мониторинга или работы с инфраструктурой. ### Полезные функии docker с точки зрения безопасности 1. Использование механизма проверки подписи image, которые используются для старта контейнеров. Контроль и настройка функции может быть осуществлена по интсрукции, которую можно найти [тут](https://docs.docker.com/engine/security/trust/). 2. Мехнизмы предоставления доступа к сетевому интерфейсу с API можно изучить [тут](https://docs.docker.com/engine/security/protect-access/). ## Практические примеры 1. [Практика побега из контейнера из-за не верной конфигурации.](https://hackmd.io/0WKzcXNDQa6mAXp1e3QfUg?view) 2. [Практика побега из контейнера из-за использования непропатченной версии ядра.](https://hackmd.io/y3Xz3UazRk2t2vP9Wehdyg) ## Полезные материалы для изучения: - [ресурс о безопасности и способах атак на контейнеры и системы оркестрации](https://www.container-security.site/general_information/container_cve_list.html)