Привет, Хабр, с вами Вера Орлова и Саша Журавлев (@Zhurma) — мы отвечаем за контейнерную безопасность в Cloud.ru и возглавляем команду спасателей для решения проблем в этой сфере. Атаки на инфраструктуру с каждым днем становятся всё изощреннее, поэтому при организации безопасности контейнеров важен комплексный подход.
В прошлой статье мы уже делились нашим опытом защиты от киберрисков. В этой — расскажем историю, что бывает, если вовремя не защитить контейнер, и что делать, чтобы с вами такого не приключилось. И помогут нам в этом несколько базовых сервисов, которые быстро приходят на помощь, чтобы устроить полную доминацию над уязвимостями в контейнерной инфраструктуре.
Что может произойти, если не использовать инструменты контейнерной безопасности, или как минимум не пройтись по шагам новичка, чтобы себя обезопасить? Расскажем вам одну историю.
Что бывает, если не защитить контейнер: история «Рокфор»
Жила-была небольшая компания «Рокфор», которая недавно вышла на IPO. Компания спокойно развивалась, зарегистрировала домен и развернула сайт в контейнере на Kubernetes.
Он получился небольшой и крутиться всего лишь на одном поде. Один из основных компонентов сайта — лендинговая страница, на которой всё работает. Технический лидер Гаечка, которая его разрабатывала, взяла, как ей показалось, уже проверенную технологию — Apache. Ведь в нем удобный открытый исходный код, который позволяет подстроить программу под специфические нужды пользователя!
Но в момент принятия решения Гаечка не сильно думала о безопасности и взяла старую версию Apache. Получается, страницу можно обновлять, но саму сборку — нет. Какие могут быть последствия? Любой злоумышленник может легко «убить» приложение с помощью заранее заготовленного скрипта.
Что и произошло с Гаечкой — наш злоумышленник «Нимнул» решил эксплуатировать уязвимость с некорректной обработкой открытия коннекта в HTTP/2 и совершил Slowloris-атаку — разновидность DoS-атаки на потоковые веб-серверы:
Как у него это получилось? Он открыл очень много HTTP-соединений с атакуемым веб-сервером и держал их как можно дольше, отправляя частичные запросы и заголовки HTTP. При этом запросы никогда не завершались полностью — сервер держал соединения открытыми, пул параллельных соединений исчерпался, и в результате сервер отказал клиентам в подключении...
Так с помощью запросов злоумышленник смог убить весь под и уронить приложение «Рокфора»:
В тот момент Гаечка еще имела доступ к сайту, ведь его приподнимал Kubernetes. Но будем честны — ей просто повезло. Если бы в дело вмешались другие нарушители и атака была с больших виртуальных машин, а не одного ноутбука или ботнета, она бы уже не смогла этого сделать.
Можно было обезопасить себя от такого? На самом деле вариантов было много, например, поставить Firewall или ограничения по IP. Наша Гаечка решила, что нет ничего лучше, чем защититься с помощью WAF. Только вот прошлую проблему пофиксить она… забыла.
Тут «Нимнул» и получил все доступы — к кластеру, конфигу, смог посмотреть всю инфраструктуру, на чем крутиться сайт, а еще обнаружил, что роли в Kubernetes настроены неправильно и вытащил секреты. В итоге злоумышленник заменил образ в запущенном деплойменте и сайт «Рокфор» превратился в тыкву.
Как снова не попасть в такую ситуацию?
Как защитить приложение или контейнер: «командная работа» плагинов
Как минимум, познакомиться с основными принципами безопасности ?
Основные принципы безопасности контейнеров от NIST
NIST (Национальный Институт Стандартов и Технологий) выпустил документ Cybersecurity Framework, который помогает компаниям любых размеров лучше понимать и снижать риски кибербезопасности, а также защищать свои сети и данные. В документе — обзор передовых методов, чтобы помочь вам решить, на чем лучше сосредоточить время и финансы для защиты кибербезопасности.
Cybersecurity Framework 1.0 мы подробно разбирали в первой статье, а недавно вышел Cybersecurity Framework 2.0. В нем предлагается пять основных шагов:
1.Определить область действия (идентифицировать). Или иначе — провести инвентаризацию, составить список всего используемого оборудования и ПО. Затем создать политику кибербезопасности компании, которая будет охватывать роли и обязанности сотрудников, поставщиков и всех, кто имеет доступ к конфиденциальным данным.
2.Защитить основные компоненты на разных уровнях.
Изолировать контейнеры:
Имя пространства (Namespaces): использовать механизмы изоляции, предоставляемые Docker или Kubernetes, чтобы каждый контейнер имел собственные пространство имен, управление процессами и системой файлов.
Контроль групп (Cgroups): использовать контроль групп для управления ресурсами и ограничения их использования каждым контейнером, чтобы избежать отказа в обслуживании.
Создавать минималистичные образы:
Упрощать образы: минимизировать количество программного обеспечения и зависимостей в контейнере, чтобы уменьшить поверхность для атак.
Использовать безопасные базовые образы: выбирать проверенные базовые образы из надежных источников и регулярно обновляйте их.
Контролировать доступ:
Использовать минимальные привилегии: настроить контейнеры так, чтобы они запускались с минимальными привилегиями. Избегайте запуска контейнеров с правами суперпользователя, где это возможно.
Контролировать доступ к API: определить и применять строгие политики доступа к Docker API или другим связанным с контейнерами ресурсам.
Управлять секретами и конфиденциальными данными: не хранить пароли, токены или ключи доступа в образах контейнеров. Использовать внешние системы управления секретами.
Регулярно обновляться и делать патчинг: убедиться, что все образы контейнеров и их зависимости регулярно обновляются и патчатся для устранения известных уязвимостей.
Регулярно делать сканирование и мониторинг: использовать инструменты для сканирования контейнеров на наличие уязвимостей, например, Clair или Trivy. Настроить мониторинг активности контейнеров и вести журнал событий для быстрого обнаружения и реагирования на подозрительную активность.
Настроить сетевые политики:
Сегментацию сети: разделяйте сетевой трафик между контейнерами, чтобы предотвратить нежелательное взаимодействие и повысить безопасность.
Настраивать брандмауэры и ограничения доступа для каждого контейнера.
Следить за оркестрацией и безопасностью:
Обновлять оркестраторы: убедиться, что используемые платформы оркестрации контейнеров Kubernetes или Docker Swarm актуальны и настроены с учетом лучших практик безопасности.
Настраивать роли и права в оркестраторе через механизмы RBAC (Role-Based Access Control).
3.Выявлять аномалии:
контролировать свои компьютеры на предмет несанкционированного доступа персонала, устройств (например, USB-накопителей) и программного обеспечения;
расследовать любые необычные действия в сети или со стороны ваших сотрудников;
проверять сеть на наличие неавторизованных пользователей или подключений.
4.Соответствовать политикам. Составить план:
уведомлять клиентов, сотрудников и других лиц, чьи данные могут быть подвержены риску;
поддерживать бесперебойную работу бизнеса;
информировать о нападении в правоохранительные органы и другие органы власти;
расследовать и локализировать атаки;
обновлять политики и планы кибербезопасности с учетом полученного опыта;
подготовиться к непредвиденным событиям (например, чрезвычайным погодным условиям).
5.Восстанавливать инфраструктуру: восстанавливать оборудование и затронутые части сети, информировать сотрудников и клиентов о мерах реагирования и восстановления.
А лучше — призвать на помощь «дуэт» плагинов Connaisseur и Trivy Operator.
Connaisseur — проверяет целостность и авторство подписей
Плагин Connaisseur проверяет образы — есть ли у них подпись и соответствует ли образ политикам, настроенным внутри кластера:
Его можно установить через UI-консоль или через API — на выбор. Под капотом запускаются поды и создается необходимая конфигурация — указывается ключ, с помощью которого будут подписываться образы, и выдается разрешение на запуск сторонних образов.
Теперь, если очередной злоумышленник вновь попытается заменить образ на свой, при запуске сработает вебхук, который поможет быстро проверить, есть ли у него подпись или нет.
Connaisseur работает в Kubernetes так же, как и остальные поды, поэтому для тотальной доминации над уязвимостями нашей Гаечке следует по максимуму исключать к нему доступ.
По политикам Connaisseur используется дайджест-образ. В конфиге для подписи указывается публичная пара. Эта подпись храниться рядом со всеми образами и перед отправкой запаковывается с ними в архив.
Теперь при изменении образ будет обновляться на новую версию:
Trivy Operator — автоматически сканирует образы на уязвимости
Плагин Trivy Operator проверяет образы контейнеров и конфигураций ресурсов:
на уязвимости,
ошибки конфигураций,
секреты, доступные в открытом виде.
Он сканирует кластер на наличие проблем безопасности и публикует результаты в отчетах, которые доступны через Kubernetes API. Благодаря этому можно просматривать отчеты и находить риски, связанные с различными ресурсами кластера. Проверка запускается автоматически при изменении состояния кластера Managed Kubernetes, например, при создании нового пода.
Плагин удобно вызвать на помощь по кнопке через UI-консоль:
После установки в кластере запускаются необходимые поды:
Как конкретно он помогает? Теперь по расписанию, которое настроит Гаечка, будут запускаться нужные джобы. Они будут сканировать инфраструктуру «Рокфор», выводить уязвимости, найденные в образах, и подсвечивать ошибки в конфигурациях.
А пока джобы выполняют сканирование, Гаечка запускает утилиту Карантин — систему в Evolution Artifact Registry, которая запрещает скачивание образов выше выбранного уровня уязвимостей. Она выбирает уровень High, поскольку в образе, который попытался подкинуть «Нимнул», есть критические уязвимости:
Теперь, если кто-то попытается его скачать, то получит «ошибку»:
Пока создавался Карантин, джобы отработали и сформировали CRD, в которой можно проверить ошибки в конфиге:
Но Гаечка может и не заметить, что деплоймент развернут неправильно: нет security context, не прописаны лимиты и т. д.
Поэтому Trivy Operator вовремя дает подсказку, например, что израсходованы все ресурсы или что в под провалился другой пользователь. Для этого он постоянно проверяет и обновляет CV и выдает отчеты, в которых собран список проблемных мест:
Выводы: финал истории
Теперь наученная горьким опытом Гаечка знает — любой продукт по безопасности является необходимостью, поскольку на регулярной основе помогает проверять и мониторить инфраструктуру. Отныне она не пренебрегает такими помощниками, поэтому сайт «Рокфор» в полной безопасности. Чего и вам желаем. Ведь никогда не знаешь, в какой момент может появится уязвимость и чем смогут воспользоваться злоумышленники. Конец.