Building honeypot using vcluster and Falco
Last updated
Was this helpful?
Last updated
Was this helpful?
https://habr.com/ru/companies/flant/articles/695390/
Прим. переводчика: автор статьи предлагает реализацию honeypot'а («приманки») на основе виртуального кластера Kubernetes, чтобы обнаруживать попытки взлома K8s-инфраструктуры. Также в статье рассматриваются отличия низкоинтерактивных и высокоинтерактивных приманок.
Если не вдаваться в детали, главная задача приманок — соблазнять злоумышленников, отвлекая от реальных целей, и попутно собирать информацию об их деятельности. Сегодня мы попытаемся создать такую приманку с помощью vcluster и Falco.
Изображение из оригинальной статьи Sysdig
В первой части серии речь пойдет о том, как собрать простую SSH-ловушку для выявления атак, направленных на среду исполнения.
Приманки, или honeypot'ы, могут моделировать практически любой тип цифровых активов, включая приложения, системы, сети, устройства IoT, компоненты SCADA и многое другое. Их сложность варьируется от так называемых honeytoken'ов — отдельных файлов, дополненных соответствующим инструментарием, до honeynets — разветвленных сетей, включающих множество систем и инфраструктурных компонентов.
Приманки подобного типа очень полезны для сбора оперативной информации, поскольку позволяют командам и исследователям, специализирующимся на безопасности, получить представление об инструментах, методах и процедурах злоумышленников, а также выступают основой для индикаторов компрометации* в различных инструментах безопасности.
Прим. переводчика
Indicators of compromise, IoCs — артефакты, наблюдаемые в сети или в операционной системе, которые с высокой степенью достоверности указывают на вторжение.
Приманки можно классифицировать по уровню сложности: высокоинтерактивные и низкоинтерактивные.
Низкоинтерактивные приманки — аналог утиного манка в мире инструментов для безопасности. Для их запуска не требуются значительные ресурсы. При этом они, как правило, способны только на базовые действия — например, могут выдавать относительно реалистичный баннер в ответ на запросы на стандартный порт. Обычно этим дело и ограничивается. Такая приманка может заинтересовать злоумышленника при сканировании портов и служб, но отсутствие какой-либо иной активности на принимающей стороне, скорее всего, не увлечет его надолго. Кроме того, низкоинтерактивные приманки не позволяют получить представление о том, что именно делает злоумышленник. Они не обеспечивают достаточной области атаки, с которой тот мог бы взаимодействовать.
Если низкоинтерактивные приманки — это утиные манки, то высокоинтерактивные приманки — это полноценные подсадные утки. Они гораздо лучше заманивают злоумышленников, однако существует риск потерять «утку» в процессе. Высокоинтерактивные приманки часто представляют собой реалистичные системы с реальными работающими приложениями. Они оснащены дополнительными инструментами для тщательного отслеживания вредоносной активности. Это позволяет проследить всю цепочку действий злоумышленников, идентифицировать используемые эксплойты, а также получить копии загружаемых инструментов, двоичных файлов, используемых учетных данных и т. д. С точки зрения сбора полезной информации все это замечательно. Однако не следует забывать, что в руки злоумышленников передается реальный актив, и необходимо тщательно следить за тем, что они с ним делают.
Одна из главных проблем высокоинтерактивных приманок — изоляция атакующего от остального окружения. В случае приманок, построенных с использованием инструментов контейнеризации, таких как Kubernetes, следует внимательно следить за тем, чтобы атакующий не получил доступ к частям кластера, отвечающим за работу приманки. Также нельзя открывать доступ к инструментарию для наблюдения за приманкой и управления ею. Это непростая задача. Частью притягательности приманки приходится жертвовать, защищая ее критические компоненты от доступа злоумышленников. Другими словами, приходится следить за всем, что злоумышленник может использовать для нацеливания на сам кластер или на инструментарий для наблюдения, либо создавать обходные пути для предотвращения нежелательного вмешательства.
Виртуальные кластеры работают поверх основного кластера Kubernetes. Схема позволяет запускать множество виртуальных кластеров. Каждый такой кластер будет находиться в обособленной среде, без какой-либо возможности связаться с другими виртуальными кластерами или с хост-кластером.
Изоляция позволяет раскрывать ключевые внутренние элементы виртуального кластера — ничто не будет указывать, что этот кластер работает поверх другого. Можно раскрывать элементы инфраструктуры Kubernetes, инструменты обслуживания и другие компоненты, не опасаясь за судьбу кластера.
Архитектура vcluster’а
Существуют различные проекты виртуальных кластеров, которые можно использовать для организации приманки. Среди них vcluster выглядит, пожалуй, наиболее перспективно. Кроме того, проект отличается хорошей поддержкой. Ребята из vcluster очень дружелюбны и отзывчивы, обязательно зайдите и поздоровайтесь с ними в Slack'е!
В этом разделе мы развернем простую приманку с помощью vlcuster. Специально ограничимся базовым примером. Впрочем, он будет хорошим фундаментом, на котором можно строить любые дальнейшие эксперименты.
Нам потребуются следующие инструменты с указанными минимальными версиями:
Minikube v1.26.1;
Helm v3.9.2;
kubectl v1.25.0;
vcluster 0.11.2.
Прежде всего необходимо установить исполняемый файл vcluster:
Создать кластер можно множеством способов. В нашем случае мы воспользуемся Minikube.
Примечание:
Нам подходят драйверы
virtualbox,qemuилиkvm2для Minikube, но не драйверnone. Falco не сможет правильно развернуть свой драйвер, если использоватьnone.Кроме того, поскольку используется драйвер
virtualbox, развертывание необходимо проводить на реальном оборудовании. Драйвер не будет работать в виртуальной машине, в инстансе EC2 и аналогичных средах.
Давайте создадим кластер. После запуска команды start minikube несколько минут будут собираться все нужные компоненты:
Теперь нужно установить Falco:
На запуск Pod'а с Falco уйдет несколько минут. Проверить его состояние и просмотреть журналы, чтобы убедиться, что все идет гладко, можно с помощью kubectl:
Теперь необходимо создать пространство имен для виртуального кластера в основном и развернуть в нем виртуальный:
Виртуальный кластер готов. Теперь в нем можно создать незащищенный SSH-сервер и использовать его в качестве мишени.
Для этого воспользуемся специальным небезопасным Helm-чартом SSH-сервера от sourcecodebox.io. Учетные данные для этого сервера — root/THEPASSWORDYOUCREATED.
Итак, внутри виртуального кластера теперь у нас работает некий сервис. Давайте рассмотрим два различных контекста.
Примечание:
Контекст в Kubernetes — это набор параметров для доступа к определенному кластеру. Переключение контекста меняет всё окружение для команд вроде
kubectlс одного кластера на другой.
Сперва давайте взглянем на все ресурсы, существующие в кластере, с точки зрения виртуального кластера:
Видна обычная инфраструктура Kubernetes, а также Pod и сервис my-dummy-ssh, запущенные в пространстве имен default. Обратите внимание, что ресурсы Falco не отображаются, поскольку последний установлен в хост-кластере и не виден из виртуального кластера.
Теперь давайте переключим контексты, отключившись от виртуального кластера. Это вернет нас к контексту хост-кластера:
Если теперь попросить kubectl еще раз вывести список ресурсов, картина будет совсем иной:
Видны ресурсы Falco и ресурсы SSH-инсталляции из виртуального кластера. На этот раз они отображаются как работающие в пространстве имен vcluster на хост-кластере.
Наконец у нас все готово! Давайте сделаем какую-нибудь гадость, чтобы сработало правило Falco, и посмотрим, что из этого получится.
Сымитировать реальное вторжение нам помогут три терминальных окна.
В первом окне мы настроим проброс портов, открыв SSH-сервер для локальной машины. Окно должно оставаться открытым, чтобы SSH-сессия оставалась активной.
Эта команда откроет сервис на 127.0.0.1, порт 5555. Теперь нужно убедиться, что для этого окна используется контекст vcluster. Если используется контекст для основного кластера, переключиться на нужный можно с помощью команды vcluster connect ssh -n vcluster:
В этом окне мы подключимся по SSH к сервису, который только что открыли на порту 5555. Учетные данные: root/THEPASSWORDYOUCREATED:
Подключившись по SSH, мы теперь мечтаем сделать какую-нибудь гадость, чтобы сработало правило Falco. Например, можно посмотреть /etc/shadow:
В этом окне будем просматривать логи от Pod'а Falco:
Видно множество строк вида Notice Redirect stdout/stdin to network connection — результат проброса портов. Кроме того, есть сообщения с Warning Sensitive file opened for read by non-trusted program — результат нашей попытки прочитать /etc/shadow.
Вот оно! Это Falco сигнализирует о том, что кто-то копается в вещах, не предназначенных для его глаз, подключившись к нашей приманке через SSH. И все это происходит внутри виртуального кластера vcluster, который, в свою очередь, работает в хост-кластере.
Убрать за собой беспорядок или начать все сначала (если дела пойдут настолько плохо) можно в несколько команд: удалите Falco и сервер SSH, разберитесь с Minikube и очистите временные файлы:
Виртуальные кластеры чрезвычайно перспективны для исследований в области безопасности в целом и для организации приманок в частности. Область, несомненно, интересная для наблюдения, как для будущих разработок, так и с точки зрения применения этих инструментов технологической отраслью.
В этой статье мы заложили хорошее начало, хотя многое еще можно отшлифовать и улучшить.
Следите за нашими публикациями — в следующей части этой серии мы добавим механизм реагирования на базе Falco Sidekick, запустим новые приманки во втором виртуальном кластере и подкрутим их настройки, сделав более безопасными.
Читайте также в нашем блоге:
