Два года мы с командой строили платформу киберучений. Мы начали с пары виртуалок c 2 Гб RAM на борту в EVE-NG (причем это была вложенная в VMWare ESXi виртуализация) и домасштабировали до самостоятельной инфраструктуры с контейнеризованными сервисами для обучения по ИБ и возможностью подключения практически неограниченного количества обучающихся. Это статья о нестандартных решениях, самой платформе и участии в мероприятии CyberCamp, для которого предоставили виртуальную инфраструктуру.
Переходи под кат, если интересно, как пробросить большое количество пользователей в виртуальную среду с помощью одного браузера, не давая им прямой RDP\VNC\ssh доступ, да еще и бесплатно. Также поделюсь нашими наработками и планами по развитию платформы Jet CyberCamp.
Спойлер: тут будет мало воды, много о самой инфраструктуре, немного High-level design и личных впечатлений, а еще россыпь граблей, на которых мы станцевали, куда же без них.
Что такое Jet CyberCamp, зачем нужна и какие цели преследует
Если кратко, платформа киберучений — это место и средство проведения практических учений для команд ИБ. С ее помощью можно воссоздать типовую инфраструктуру предприятия, провести атаки и попытаться защититься от них, можно сделать песочницу и тестировать новые решения, создать лабораторию и исследовать действия атакующих или отдельных вредоносов.
Причем платформа киберучений — это не только виртуальные машины (ВМ) и средства защиты (СЗИ). Еще она выполняет роль образовательного портала, на котором можно найти учебные материалы, текущий прогресс каждого обучающегося, описание заданий, систему учета их выполнения, централизованный доступ ко всем используемым в заданиях ВМ.
Интерфейс платформы киберучений
Платформу Jet CyberCamp можно рассматривать в двух вариантах:
Цельный готовый коробочный продукт для конечного заказчика со своим сервисом. Решение, которое мы можем внедрять заказчику «под ключ», обеспечивать новыми сценариями, новыми компонентами (в т. ч. СЗИ) и предоставлять обновления инфраструктуры.
Онлайн-сервис, который мы готовы предоставлять неограниченному кругу лиц. Это почти та же Jet CyberCamp, что и в п. 1, но плюс геораспределенная инсталляция, использование новых технологий, удобная и оперативная техподдержка, глубокий мониторинг всех компонентов Jet CyberCamp, а также продвинутая веб-защита.
Немного истории Jet CyberCamp
ЭТАП 1. Началом начал стала EVE-NG, на базе которой мы пытались научить новых коллег пользоваться средствами защиты. Мы разрабатывали сценарии, погружающие обучающихся в детали: состояние инфраструктуры, предшествующие события и цели задания. Основным инструментом для описания сценариев нам служили презентации PowerPoint.
Ученики выполняли задания, сообщали устно свои результаты тренеру (рассказывали, как развивалась атака, что и где нашли). Далее тренер вручную оценивал результат каждого. (Небольшая ремарка: тогда еще не было названия Jet CyberCamp, поэтому назовем этот этап «Платформа киберучений 1.0».)
Личные впечатления от EVE-NG
Впечатления от EVE-NG — так себе: тяжеловесное, глючное, медленное, ограниченное в возможностях развертывания и сложное для проведения киберучений решение. К тому же в нем нельзя было развернуть все средства защиты информации и пригласить много обучающихся.
ЭТАП 2. Мы оценили потенциал киберучений и решили проводить их для некоторых наших заказчиков. Закупили отдельный сервер под проект, чем обозначили новый этап развития нашей платформы киберучений (тут все еще нет названия проекта, поэтому пусть будет «Платформа киберучений 2.0»).
На этот сервер поставили VMware ESXi, установили все нужные СЗИ для существующих сценариев, настроили портал для обучения LMS Moodle и шлюз удаленных рабочих столов Guacamole. Таким образом у обучающихся появилась возможность подключаться не к каждой ВМ по отдельности, а к единому порталу через web, откуда они пробрасывались к целевым ВМ.
На этом этапе появились возможности:
Создавать сценарии с любым СЗИ.
Выкладывать теоретический материал на портал, в том числе видео.
Видеть и контролировать процесс выполнения заданий. Guacаmole позволяет тренеру подключиться к сессии обучающегося и помочь/направить его в случае проблем.
Бесшовно пробрасывать подключения к ВМ при помощи Guacamole без запуска RDP- или VNC-сессии обучающимся и без ввода пароля в этой сессии.
Делать снэпшоты и откатываться к ним после «окирпичивания» ВМ обучающимися.
Подавать копию сетевого трафика (SPAN) на отдельные ВМ внутри «Платформы киберучений 2.0». Это позволило нашим тренерам и методистам создать сценарии с углубленным обучением расследованиям и работе с СЗИ, а также использовать вложенную виртуализацию. Например, это требуется для СЗИ класса «песочницы».
Личные впечатления
При архитектуре «Платформы киберучений 2.0» и ограниченных серверных мощностях мы могли пробрасывать через Guacamole не более 20 человек. Если выдать больше мощностей LMS и Gaucamole, то меньше ресурсов останется на ВМ для сценариев, и наоборот. Но это в какой-то мере было еще «терпимое» ограничение. Ряд других проблем все же требовал кардинальных изменений: отсутствие автоматизации развертывания и настройки ВМ для сценариев, масштабирование количества обучающихся (каждому нужна УЗ, эту УЗ нужно внести в LMS и Guacamole, настроить их, сконфигурировать jump host, с которого обучающийся будет иметь доступ к другим ВМ сценариев), отсутствие отказоустойчивости на всех уровнях, отсутствие мониторинга и учета IP-адресов и пр.
ЭТАП 3. А затем родилась идея глобальных киберучений для 200 человек или 40 команд.
Как появилась платформа киберучений 3.0 Jet CyberCamp
Новая идея подстегнула нас к решению фундаментальных проблем, описанных выше. Плюс мы захотели тратить меньше сил и времени на обновление и администрирование гипервизора, сделать нашу платформу киберучений менее ресурсоемкой и более гибкой, перенести часть инфраструктуры в код (т. е. не держать настроенные ВМ на хосте, а иметь только шаблоны ОС и инструмент для их полноценного развертывания и настройки компонентов внутри ВМ). Также необходимо было найти новые проблемы и мужественно их преодолеть!
Поэтому мы:
Придумали название проекту! Как назовешь
корабльплатформу киберучений, так она и поплывет. С этого момента мы стали строить Jet CyberCamp!Докупили мощностей в серверы, подключили их к vSphere, СХД, настроили мониторинг, создали ресурс-пулы, структурировали все ВМ по определенной логике.
Структура папок и именование машин в среде виртуализации
Ниже на скрине логика такая: папка с машинами в разработке, есть золотые образы, которые полностью готовы и их можно клонировать (Golden Images), есть разбивка папок по дням: в первый день есть как общие машины, входящие в домен, так и машины команд (Teams). Логика именования машины: [день_учений-номер_сценария]тип_машины_в_сценарии.
Ввели правила именования ВМ, создали IP-план, описали правила учета настроек ВМ: всё, что делается внутри ВМ, должно быть описано на confluence, а затем, когда начали писать код, то завели для этого GitLab.
Стали проводить внутренние (на небольшую группу работников «Инфосистемы Джет») прогоны сценариев для выявления ошибок в архитектуре сценариев и поиска путей их оптимизации. В общем, собирали любую обратную связь от коллег.
Определили формат легенд для сценариев (например, «Инсайдер поневоле») и создали профиль для каждого сценария. В профиле сценария указывается детальная информация по всем возможным аспектам, начиная от целей сценария и заканчивая его маппингом на MITRE. Детали методологической составляющей Jet CyberCamp мы опишем в следующей статье.
Пример профиля для сценария
Стали рисовать первые робкие схемы уровней High-level design, L3 и L1-L2.
Решили доработать LMS Moodle под наши нужды. Уже в процессе доработки поняли, что его не надо доделывать, а нужно полностью создать свой собственный портал. LMS Moodle содержал много лишнего для нас по умолчанию и оказался слишком негибким при доработке. Эта история достойна отдельного поста.
Горящие сроки и приближение онлайн-конференции CyberCamp 2022 подтолкнули нас к быстрым и кардинальным изменениям в проекте. Все первые робкие схемы резко превратились в солидные и детальные, сформировались сетевые сегменты «ядра» и сценариев, в ускоренном темпе изучались ITSM (модели здоровья для мониторинга всех компонентов и планы по восстановлению, формализация и разделение задач, ролей и многое другое).
Ну и напрашивался переход от парка отдельных виртуальных машин Jet CyberCamp к контейнерам для удобства администрирования и непрерывной доставки сервиса обучающимся.
Расчеты требуемых ресурсов и мощностей
Этот этап мы проходили несколько раз: сначала при закупке первого сервера, затем при закупке второго, а далее — при расчете мощности для мероприятия CyberCamp 2022.
Мы спросили у наших тренеров:
сколько всего машин планируется поднимать для каждого сценария (допустим, для сценария «Инсайдер поневоле» нужны были: 1 SIEM, 1 IRP, 1 TIP, 1 портал ГосСОПКА, 1 машина Kali для Red Team, 2 рабочие станции, 1 файловый сервер, 1 почтовый сервер с OWA, 1 сканер уязвимостей, 1 МСЭ),
какие они должны быть (готовые апплаенсы или ПО поверх ОС),
их ОС,
потребляемые ресурсы,
расчет каналов при разной архитектуре,
расчет количества серверов.
Ну и потом надо было перемножить полученное количество на 40 (такое количество команд заявлялось к участию) 🙂
Конечно же, 40 SIEM мы не поднимали и уточнили у вендора, сколько пользователей выдержит каждая нода. Спойлер: вендор не знал, но очень оперативно выяснил и подсказал. И так по каждому СЗИ.
Расчеты сильно усложнялись тем, что мы только-только переходили в k8s и не было понимания, сколько будет потреблять ресурсов такой кластер, а точнее, три кластера k8s: один кластер — для сервисов платформы, где в том числе находилась LMS; второй — для Kali-машин, с которыми работал каждый участник команды, и третий — для кейса с атакой и защитой средствами WAF уязвимых веб-сервисов. И этих сервисов надо было тоже 40! В целом, у нас не было понимания, заработает ли такая архитектура.
Важной особенностью стало гибридное размещение платформы киберучений — часть инфраструктуры располагалась в «Яндекс.Облаке». Это тоже требовало расчета мощностей: нужно было «забронировать» мощности и расширить квоты, а также обеспечить безопасность размещаемых в «Яндекс.Облаке» компонентов.
Получилась большая экселька, в которой учитывались:
Самый плохой сценарий — в случае, если мы не сможем контейнеризовать большинство решений и компонентов.
Какие именно ВМ должны работать в каждый из трех дней мероприятия CyberCamp 2022. Например, в первый день не требовались машины с уязвимыми веб-сервисами, поэтому они должны были включаться только во второй день. Цель — оптимизация используемых ресурсов в каждом из дней CyberCamp 2022.
Пример расчетов мощностей на каждый день киберучений
Оптимизация использования ресурсов и поиск решений после ухода вендоров
Как видно из скринов, ресурсов требовалось немало. И у нас их в таком количестве не было (так как такой объем мощностей для проведения учений на постоянной основе просто не нужен). Поэтому мы пошли несколькими путями:
Оперативно договорились и одолжили у коллег из соседних департаментов немного RAM и СХД (после CyberCamp 2022 всё это отдали обратно).
Вынесли часть сервисов (и, как следствие, мощности для них) в «Яндекс.Облако».
Провели оптимизацию требуемых ресурсов для каждого компонента платформы Jet CyberCamp. Например, зачем давать Kali аж 25 Гб HDD, можно дать 15. Или зачем давать серверу с AD 40 Гб, дадим 20! При этом все необходимые задачи такие ВМ смогут выполнить.
Провели оптимизацию используемых решений. Если что-то можно было «затолкать» в контейнер, то это срочно делали. Если мы понимали, что для какого-то сценария не обязательно использовать WinServer, а можно немного переиграть эксплуатируемую уязвимость (без потери UX для обучающихся), то использовали Ubuntu, которая гораздо менее требовательна к ресурсам, и т. п.
Были и ограничения, которые пришлось учитывать и как-то обходить.
Нужны были очень широкие интернет-каналы и защита от потенциальных DDoS-атак. Да еще и такие, чтобы в случае атак не пострадали основные сервисы «Инфосистемы Джет». Это был еще один довод в пользу частичного переезда в облако!
Изначально доступ к платформе Jet CyberCamp был возможен только через VPN. Но для большого количества участников такая схема была крайне неудобной: нужно рассылать конфигурации для VPN, траблшутить проблемы с VPN, да и в целом это снижение UX. Следовательно, нужно было уходить в сторону прямого доступа к сервисам Jet CyberCamp, а значит, обеспечивать веб-защиту (установку и настройку WAF).
Изначально наша инфраструктура была готова предоставлять сервис для 20–30 участников (5–7 команд) одновременно. Но в ходе подготовки к CyberCamp 2022 мы замахнулись на 200 пользователей (40 команд по 5 человек в каждой), поэтому должен был оставаться хоть какой-то запас мощностей на случай падения одного из хостов виртуализации. При этом каждая команда не должна была мешать другим. Плюс все время подготовки к мероприятию платформа должна была функционировать и предоставлять возможность как проведения небольших учений, так и тестирования СЗИ и проведения других исследовательских задач нашими коллегами.
В итоге решили делать так:
Машины, в которые «приземляются» обучающиеся и из которых они выполняют все дальнейшие действия, нужно сделать контейнерными (200 подов, которые легко поднять, обновить и администрировать).
Машины, задействованные в сценариях, при возможности тоже нужно «запихнуть» в контейнеры — например, описанные выше уязвимые веб-сервисы на базе Ubuntu.
Произвести расчет мощностей и сайзинг каждого СЗИ совместно с вендором. Цель — выяснить, сколько пользователей может «держать на себе» каждое задействованное СЗИ в кейсах. Как пример, SIEM у нас было 5 на 200 пользователей.
Если есть возможность, нужно использовать СЗИ с функционалом multitenancy. Например, использовался PT AF версии 4, которую с пылу с жару нам любезно предоставил вендор. В нем можно поднять до 30 стабильных тенантов. Итого: было 2 штуки PT AF v.4, в каждом из которых было 20 тенантов — всего 40, по одному на каждую команду.
Для всего, что не удалось контейнеризовать, решили сделать золотые образы для клонирования. Например, все Windows-машины были не контейнерными, поэтому кейс с поиском вирусов — это 40 ВМ, развернутых из золотого образа, по одной штуке на команду.
Для обеспечения отказоустойчивости на всех уровнях:
«Яндекс.Облако» предоставила широкие каналы;
обеспечили доступность «фронта» путем использования региональных кластеров k8s, дублированием архитектуры. В каждой зоне находилась своя копия «фронта» + внешняя балансировка трафика;
выполнили интеграцию с Anti-DDoS провайдером QRator: при обнаружении L7-атак WAF’ом последний отдает в QRator список IP-адресов или сессий для бана;
ну и, естественно, организовали бэкапирование, снэпшоты, распределение по нодам кластера виртуализации, подняли Git и описали принципы его использования, внедрили CI\CD с участием Terraform и его манифестов для всего, что находится в «Яндекс.Облаке».
Проблемы, с которыми столкнулись (грабли, на которых станцевали)
Помимо очевидных проблем: нехватка времени, недостаток ресурсов, позднее — согласование схем размещения (гибридная: часть — в «Яндекс.Облаке», часть — on-premise), поиска серверов, согласования возможных расширений каналов, были и интересные:
Касающиеся «Яндекс.Облака»:
Важное уточнение: «Яндекс.Облако» и их команда поддержки — нереально крутые! Они действительно молодцы, реагировали быстро, советовали по делу, были максимально лояльны к нам.
Но отразить в этой летописи наши печали я обязан 🙂:
Невозможно создать ВМ с произвольными параметрами. Например, нельзя выбрать много RAM, но немного HDD (или SSD) — выбирая много RAM, ты будешь вынужден брать много HDD (или SSD). Ну и платить за это придется больше.
Некоторые фичи недоступны из коробки, включаются вручную через техподдержку (internal LB и ingress в k8s, использование внутренней адресации).
Решение проблем с приложениями в k8s возможно только через рестарт всего кластера k8s. Рестарт приложения не помогал. Да, пробовали много раз, нет, мы не ламеры 🙂
Метки (labels в k8s) на ноды можно поставить только при их создании и только на группы нод. Это влияет на дальнейшее администрирование и попытки файерволинга с использованием этих labels. После написания правил на основе labels пришлось переразворачивать кластер.
Невозможно зафиксировать IP-адреса нодов (воркеров).
В Ingress не работают healthchecks. Сервисы рандомно отваливаются, хотя на самом деле они живы, просто нет проверок их состояния и балансировщик самостоятельно решает, что они мертвы.
«Яндекс.Облако» не работает с трафиком на уровне L2, а на этот функционал у нас завязано одно из СЗИ в сценариях — получение копии трафика.
Вложенная виртуализация в «Яндекс.Облаке» пока что не работает.
Постановка на мониторинг всего, что только можно, стало отдельной проблемой. У нас был Zabbix, но мы же ИБ-шники, поэтому готовых знаний, как и почему надо мониторить, не было. При внедрении СЗИ мы составляем документацию по мониторингу, но вот КАК настраивать Zabbix, пришлось осваивать на ходу. К тому же компонентов для мониторинга оказалось достаточно: всего было около 200 ВМ, которые мы хотели видеть хоть в какой-то мере в дашбордах Zabbix.
Microsoft ушел, поэтому официально мы не могли использовать машины из маркетплейса «Яндекс.Облака». Мы пробовали развернуть Windows самостоятельно в «Яндекс.Облаке», параллельно прорабатывая возможность и правомерность такого использования. При этом провели несколько экспериментов по «засовыванию» старых версий Windows (XP, 7): а это установка cloud-init и необходимых драйверов для среды виртуализации в каждый образ Windows и попытки запустить их в «Яндекс.Облаке». И так раз 10! В итоге отказались от этого сценария, но наработки на будущее остались.
Мы, ИБ-шники, решили стать гуру во всех областях: контейнеризации, облаках, мониторинге, развертывании и администрировании Active Directory, Terraform, Git плюс CI\CD и DevOps, ITSM, Agile и вот это всё. Все грабли были наши и по несколько раз.
Реализация техподдержки. Если все прочие проблемы были полноценными граблями, на которых мы станцевали, то реализация ТП для нас оказалась детскими шалостями: сказался опыт коллег из дружественных подразделений «Инфосистемы Джет», их помощь и поддержка. Но все равно оставлю это как проблему — есть что исправить 🙂 Тем не менее, мы всего лишь ЗА НЕДЕЛЮ написали чат-бот для Telegram, создали маршрутизацию проблем (зоны ответственности каждого, кто был вовлечен в ТП, а также пути эскалации проблем), определили то, что может «пойти по бороде», и заранее набросали варианты решений таких проблем или просто снизили риск их появления. Как итог: лучшая техподдержка и приятные отзывы (да, они действительно были, и это очень грело душу!).
Общая концепция нынешнего состояния платформы киберучений
Что сейчас представляет собой Jet CyberCamp:
Аппаратные мощности, достаточные для проведения мероприятий, подобных CyberCamp 2022 (на 200 и более человек).
Полностью подготовленная среда виртуализации VMware. Плюс мы начали проводить тесты совместимости с KVM и Proxmox: значит, практически любая иная среда виртуализации будет поддерживаться.
Набор готовых ВМ как шаблонов для разных сценариев. Сами сценарии и ВМ для них регулярно добавляются в платформу.
Скрипты для внутренних компонентов и ядра Jet CyberCamp в виде Infrastructure as a Code, код в Git, контейнеры в Registry.
Набор СЗИ для любых возможных сценариев, оттестированные всеми возможными способами. Мы провели внутренние пентесты, нагрузочные тестирования этих СЗИ, оптимизировали их настройки под все возможные варианты использования.
Ну и, конечно же, вагон решенных и тележка нерешенных проблем!
Выводы, советы, полезности
Если вы хотите построить свою платформу киберучений, оптимизировать доступ сотрудников в свою виртуальную среду, в целом оптимизировать использование ВМ, начинаете строить «с нуля» или переезжаете с одной платформы виртуализации на другую, то:
Освойте k8s. Это будет очень полезно: по сути, мы сделали терминальные серверы на базе связки Guacamole → k8s → Kali pods в кратчайшие сроки. При этом обновление компонентов подов было моментальным и практически незаметным. Прямо во время мероприятия мы несколько раз апдейтили поды, улучшая их производительность, и ничего при этом не упало!
Спланируйте IP-адресацию (у нас — phpIPAM в контейнере k8s), введите правила именования ВМ, структуру размещения ВМ в среде виртуализации, настройте мониторинг всех важных компонентов и выборочно мониторьте типовые машины.
Планируйте аппаратные мощности: сколько всего будет ВМ, когда каждая из них должна включаться и когда ее можно погасить. Задайте вопрос себе и владельцам ВМ, что именно должно быть настроено в этих ВМ. И на основе этого выдавайте минимальный набор необходимых ресурсов (RAM, vCPU, Disk-Space). Обязательно ведите этот план в едином документе.
Просчитайте риски по каждой возможной проблеме. Если что-то может пойти не так, к этому НАДО быть готовым. Пример:
Внедрите корпоративный парольный менеджер и все пароли ведите только в нем. Иначе будет мучительно больно искать пароль от ВМ по всей компании, если кто-то уйдет в отпуск, заболеет или уволится.
Обязательно рисуйте схемы. Не на салфетках, а такие, при «рисовании» которых можно
помедитироватьпереложить мысли в графику и получить очень много осознаний.Выстраивая инфраструктуру для ИБ, не забывайте о самой ИБ: тонкие правила на файерволе, глубокий анализ всего трафика, корреляция событий, защита от DDoS, защита веб-трафика, защита контейнеров, анализ кода, анализ образов (images), обеспечение минимально необходимых привилегий пользователям и круглосуточный мониторинг всех компонентов.
Что дальше?
Планов по развитию много:
Переход на Open Source среду виртуализации.
Оптимизация «фронта» и «ядра» Jet CyberCamp, а также в целом k8s.
Использование новых (дополнительных) средств защиты контейнеризации, а также более плотное следование заветам DevSecOps.
Структуризация и формализация всех изменений. Много дополнений и правок (схем, расчетов мощностей, кодов) было прямо в ночь перед мероприятием CyberCamp 2022 и, как часто это бывает, все такие изменения сохранились только в головах команды.
Антон Конопак
Архитектор инфраструктуры информационной безопасности, компания "Инфосистемы Джет"