Как проверить, что маркетинговые презентации или видео от производителей действительно отражают технические возможности продукта? Как объективно проверить достоверность слайдов: оценить готовность предлагаемого решения, реализованный набор функций, понять процесс и эргономику управления?
Все эти вопросы возникают при принятии решения о приобретении и внедрении узкоспециализированных высокотехнологичных продуктов, включая средства защиты информации.
Содержание
Представляю вашему вниманию инструмент для тест-драйва продукта PT Application Firewall PRO (PT AF PRO), с помощью него вы можете развернуть персональный лабораторный стенд менее чем за одну минуту — быстрее, чем заваривается чай.
Позвольте провести вас по пути создания инструмента для тест-драйва, который превращает теорию в живой опыт: отвечает на поставленные выше вопросы, создает индивидуальную среду с мгновенным стартом, где нет никаких сложных подготовок. На стенде вы полностью управляете процессом, тестируете функции в своем ритме, «прикасаетесь» к технологиям: запускаете сценарии, имитируете атаки, анализируете результат и сразу видите, как продукт решает ваши задачи.
PT AF PRO — это решение класса web application firewall (WAF), которое анализирует трафик веб-приложений, выявляет и блокирует вредоносные запросы, направленные на получение несанкционированного доступа, изменение данных или сбои в работе приложений. Система работает как обратный прокси-сервер (reverse proxy), интегрируясь в цепочку обработки трафика.
Стенд включает уязвимые веб-приложения, реализацию атак и защиту приложений с помощью PT AF PRO, чтобы показать, как продукт работает в реальных условиях. Моя цель — помочь заказчику быстро понять, подходит ли продукт под его требования, и потратить на это минимум времени — выделить удобный день на полноценное тестирование и изучение продукта и не ждать подготовку стенда.
От идеи к интерактиву
Пройдя свой профессиональный путь от инженера по эксплуатации до эксперта-консультанта в зарубежном производителе телекоммуникационного оборудования, я понял, что действительно качественный инструмент должен соответствовать следующим критериям:
Простой процесс знакомства с продуктом на основе лабораторных стендов.
Быстрое получение доступа к стенду и отсутствие бюрократии.
Индивидуальный стенд, на котором у пользователя есть возможность делать все самому и не только по сценарию.
Интерактивный лабораторный стенд с полноценной обвязкой в виде генераторов трафика и атак, уязвимых приложений и самого продукта для обеспечения защиты приложений.
Пользователь реализует готовый сценарий, а также имеет возможность проверить свои гипотезы и применить собственные тесты.
Изоляция стендов между собой: действия пользователя не должны влиять на другого пользователя, работающего параллельно.
Ресурсы для развертывания стенда предоставляются производителем продукта и не требуют затрат со стороны пользователя.
Сервис является облачным, что упрощает поддержку и обновление.
Масштабируемая архитектура сервиса: готовность обеспечить одновременную работу не менее 100 пользователей и при необходимости увеличить это количество.
Получение доступа к лабораторному стенду по запросу, когда это удобно пользователю, всего за несколько минут.
Фокус на проверках и реализации концепции (proof of concept, PoC) без превращения работы со стендом в обучающий курс.
Выбор методологии тестирования продукта: «пилот», испытания по ПМИ, PoC
Следует выделить три типа процесса оценки соответствия продукта техническим требованиям:
пилотное внедрение;
испытания по ПМИ (программа и методика испытаний);
подтверждение концепции.
Разберемся, что представляет собой каждый из процессов на практике и насколько они релевантны и эффективны для тест-драйва продукта.
Пилотное внедрение
Это комплексная проверка готовности системы защиты. WAF встраивается в роли обратного прокси-сервера в сервисную цепочку доставки трафика существующих приложений в продуктивной или тестовой среде. Основным источником трафика и запросов являются живые пользователи и автоматизированные системы (machine to machine, M2M), реже — синтетически генерируемый трафик, адаптированный под специфику приложения.
Базовая задача «пилота» — проверить работоспособность самих приложений при внедрении системы защиты, настроить правила обработки и фильтрации трафика для исключения ложноположительных срабатываний.
На этом этапе выявляются отказы в обслуживании приложений и влияние на логику их работы без угроз кибербезопасности. Результат пилотного внедрения — адаптация и настройка WAF под конкретную инфраструктуру и приложения, понимание, что сама система защиты не оказывает негативного влияния на их работу.
Увидеть и проанализировать реальный вектор атаки за короткий срок «пилота» маловероятно, реально можно рассчитывать на активности ботнетов и сканеров, за исключением проведения пентеста целевой системы. Но здравый смысл подсказывает, что эти процессы не должны быть синхронны и что подготовка к пентесту предполагает полноценное внедрение системы защиты.
В сценарии упускается основная ценность WAF — встроенная и настраиваемая экспертиза детектирования угроз безопасности, специфика поведения инспекции трафика.
Такой «пилот» целесообразно проводить на поздней фазе принятия решения — на этапе, близком к опытной эксплуатации, непосредственно до внедрения, но уже после первичной оценки соответствия техническим требованиям и проведения тестирования продукта.
Испытания по ПМИ
Такое тестирование является ресурсоемким по времени, так как охватывает функции и производительность WAF. Результат напрямую зависит от степени проработки программы, насколько она соответствует фактически необходимым техническим требованиям и отражает специфику защищаемых приложений. Адаптированные под реальные потребности заказчиков программы встречаются реже, потому что требуют глубокого погружения в инфраструктуру.
В реальных проектах встречаются программы испытаний из набора разрозненных тестов, составленных на основе функций продуктов одного или разных производителей, с искаженными приоритетами в сторону второстепенной функциональности. Например, делается акцент на требования к графическому интерфейсу редактора правил защиты или работу с событиями безопасности, при этом не учитывается, что каждый производитель имеет свой подход к реализации архитектуры механизмов правил и детектирования атак, и, как следствие, некоторые требования не являются применимыми. В то же время упускается основная цель — обеспечение максимальной точности распознавания атак.
Кроме того, встречаются программы с тестами тех функций, которые не планируется использовать в реальной работе, — их необходимость никак не обоснована.
Для иллюстрации: в программе включены требования и блок тестов режима работы WAF в «прозрачном» режиме (инспекция трафика на уровне L2), при этом фактическое внедрение планируется в режиме обратного прокси, который является типовым в отрасли для такого класса решений.
Подобные программы не имеют практического смысла и никак не приближают к конечной цели — эффективной работе самого продукта WAF и построению результативной кибербезопасности, которая является ключевой на уровне менеджмента компаний.
Существуют альтернативный подход к испытаниям по ПМИ — применение автоматизированных тестов с готовыми benchmark-утилитами. Преимущество такого подхода — использование большого набора готовых сигнатур атак (payload) и наличие открытого исходного кода в публичных Git-репозиториях. К недостаткам можно отнести то, что утилиты не учитывают специфику защищаемых приложений заказчика и актуальные для них векторы атак, а также то, что если утилита связана с разработчиками конкретной системы WAF, то она ориентируется на особенности именно этого продукта. Полученные таким образом результаты эффективности работы WAF являются спорными и субъективными.
При таком подходе есть риск получить некорректные результаты оценки работы продукта. Вдобавок идеально пройденные тесты лишь создают иллюзию безопасности, а защита в реальных условиях эксплуатации будет просто неэффективной.
Таким образом, испытания по ПМИ целесообразно проводить по результатам проектирования систем защиты под конкретные случаи и на основе практических результатов завершенных «пилотов».
Подтверждение концепта
Цель PoC — подтвердить работоспособность продукта и проверить его соответствие заданным техническим требованиям и критериям. Тест-план PoC не является фрагментарным набором тестов отдельных функций продукта, а превращается в единую систему, демонстрация концепта выполняется последовательно по сценарию. Например, пользователь, анализируя реальную атаку, автоматически знакомится с интерфейсом системы, с тем, как выполняется настройка обратного проксирования и доставки трафика приложения, разработка пользовательских правил, как работают встроенные механизмы детектирования и предотвращения атак, журналирования и анализа полученных данных.
В тест-плане присутствуют функциональные и нагрузочные тесты, помогают проверить, все ли необходимые функции защиты выполняет продукт, и оценить его производительность, PoC показывает работоспособность WAF и то, как его можно подстроить под конкретную практическую задачу. Формирование таких требований достигается через системный анализ и понимание работы приложений, что предполагает совместную работу инженеров по информационной безопасности, разработчиков, DevOps- и SRE-инженеров.
Подтверждение концепта включает моделирование инфраструктуры с защищаемыми приложениями, легитимными пользователями, злоумышленниками и самой системой защиты. Это позволяет оценить работоспособность системы при выполнении полного и замкнутого цикла эксплуатации WAF.
Спецификой моделирования является не только наличие на стендах инструментов выполнения атак на веб-приложения, но и наличие уязвимостей в приложениях, существует возможность эксплуатации этих уязвимостей. В процессе PoC через WAF пропускается не просто образец запроса, который соответствует атаке (сигнатура атаки со специфичным содержимом — payload), а по факту реализуется атака на уязвимое приложение и оценивается поведение WAF отдельно в режиме детектирования, а также блокировки атаки или нелегитимных запросов.
Можно выделить два направления PoC — пользовательский сценарий и типовой.
Эталонная методология PoC подразумевает формирование пользовательского сценария тестирования WAF на основе детально проработанного тест-плана или программы испытаний (ПМИ).
Подготовка и реализация эффективного PoC закладывает фундамент для последующей результативной защиты при эксплуатации продукта.
При подготовке типовых сценариев установлена цель — охват не менее 70–80% базовых технических требований, на основании которых выстраивается каркас системы защиты приложений WAF и принимается решение о применимости такой системы. Это происходит на первом этапе оценки применимости продукта, что сокращает трудозатраты на проектирование ПМИ и проведение испытаний и (или) пилотного внедрения.
В основе разработанного инструмента для интерактивного тест-драйва системы защиты веб-приложений PT Application Firewall PRO используются типовые сценарии с возможностью их адаптации под фактические потребности пользователей.
Тест-драйв 1.0. Противостояние: «синие» против «красных»
Инструмент для тест-драйва имеет два поколения. В статье речь пойдет о первом поколении, а также о том, какой из этого был получен опыт.
По сценарию пользователь обеспечивает защиту уязвимого приложения от атакующего бота.
Пользователь-защитник получает собственный изолированный стенд с уязвимым приложением Juice Shop, который является вымышленным интернет-магазином, разработанным сообществом OWASP. Затем обнаруживает его взломанным: бот-злоумышленник меняет товары на подозрительные и выполняет дефейс с размещением сообщения о взломе на главной странице. Выполняя лабораторные задания, наш слушатель настраивает защиту приложения от атак, снижает нагрузку на него, блокирует вредоносную активность бота.
Пользователь обнаруживает взлом не сразу, а только через 5 минут после активации стенда — первого обращения к порталу интернет-магазина. Таким образом, в процессе знакомства с лабораторным стендом обнаруживается проблема незащищенных приложений, опубликованных в свободном доступе.
Алгоритм работы пользователя
Знакомcтво с пользовательским интерфейсом PT AF PRO, смена пароля для входа.
Подключение и настройка внешнего агента PT AF PRO — модуля для реверс-прокси nginx.
Создание профиля защиты приложения и настройка политик безопасности.
Анализ событий безопасности.
Настройка детектирования успешной и неуспешной аутентификации в личный кабинет приложения, защита от автоматического перебора паролей (bruteforce).
Знакомство с механизмом работы глобальных динамических списков, куда отправляются IP-адреса с нелегитимной активностью для временной блокировки, настройка способов блокировки. Для примера, ответным действием на запросы с IP адресов из списков является сброс TCP-соединения вместо стандартного HTTP-ответа с кодом 403 Forbidden.
Блокировка активности из некоторых зарубежных стран с сохранением доступа из Рунета.
Детектирование активности бот-сканера и ограничение количества одновременных запросов с одного IP-адреса, настройка агрегации событий превышения количества одновременных запросов.
Создание пользовательского правила для защиты от атаки с применением нулевого байта. Poison Null Byte — обход фильтров проверки веб-приложений путем добавления нулевого байта (%00 или 0x00) в имя файла, когда для работы с файловой системой используются нижележащие функции на языке C, в котором нулевой байт обозначает конец строки.
Создание собственной страницы блокировки для ответов HTTP 403 от PT AF PRO, применение ее к различным видам атак.
Создание исключения для обработки ложноположительных срабатываний системы.
Модификация параметров проксирования: настройка передачи реального IP-адреса клиента в PT AF PRO из HTTP-заголовка для случая иерархического проксирования (когда запросы на агент приходят через вышестоящий прокси-сервер, который, как правило, является внешним балансировщиком нагрузки).
Действия атакующего бота
Выполнение запросов с реальных IP-адресов разных стран — зарубежных и российских с заданным количеством RPS (запросов в секунду).
Бот-активность для эмуляции работы сканеров с заданным количеством RPS.
Перебор паролей для входа в личный кабинет интернет-магазина (bruteforce-атака).
Дефейс-атака — замена заглавной страницы портала с всплывающим сообщением и блокировкой бизнес-логики работы приложения.
Замена товаров в интернет-магазине (межсайтовый скриптинг (XSS) в API и удаленное выполнение команд (RCE)).
Получение нелегитимного доступа (внедрение SQL-кода).
О чем может рассказать бот
Чтобы действия атакующего бота были наглядными, пользователю предоставлялся доступ к статистике в Grafana.
В интерфейсе представлена следующая информация:
Графики количества запросов в секунду (RPS) c HTTP-кодом ответа 200, 403 и Close Connection с распределением по странам.
RPS Bruteforce — с какой частотой обеспечивается перебор паролей для попытки авторизоваться в интернет-магазине.
Индикаторы работоспособности приложения, состояния бота (включен или выключен (off/on), пользователь может включить или отключить бота через телеграм-бот).
Успешность атаки (XSS API + RCE), направленной на замену главной страницы, на которой размещается сообщение от «хакера», замену изображений и подмену товаров.
SQL-inject — индикатор успешности атаки, связанной с внедрением SQL-кода.
Hacked — индикатор, показывающий, что главная страница приложения была атакована.
Получить информацию о действиях и состоянии атакующего бота можно только в тестовой лабораторной среде. Это инструмент мониторинга, предназначенный для быстрого информирования администратора продукта о том, насколько эффективна защита и работает ли приложение.
Интерфейс работы с пользователями: телеграм-бот
На основании опыта использования порталов и систем резервирования лабораторных стендов и других совместно используемых ресурсов в различных компаниях мы приняли решение использовать альтернативный способ взаимодействия с пользователями и сделать точкой входа телеграм-бот.
Это позволило сократить срок выхода инструмента для тест-драйва, упростить регистрацию и валидацию пользователей, получить нативную интеграцию уведомлений и управления через мессенджер, сократить трудозатраты на поддержку дополнительных процессов внутри компании и разработку самого портала. Нет необходимости тратить время на адаптацию к выделенному порталу — пользователь сразу же переходит к освоению продукта.
Взаимодействие с пользователем через чат-бот на этом этапе развития проекта отвечает его главной идее — упрощению, легкости и скорости.
Функциональность телеграм-бота
Наш телеграм-бот делает сложные процессы простыми, удобными и интуитивно-понятными, чтобы работа была комфортной и эффективной.
1. Регистрация: быстрая и простая, где мы просим указать фамилию, имя, телефон и компанию. Все — вы готовы к работе.
Запрос и получение тестового стенда: одна команда — и бот разворачивает стенд, в ответ отправляет учетные записи, уникальные URL стенда и все необходимое для тестирования.
Опрос и обратная связь: после работы со стендом бот поможет собрать ваши впечатления и предложения, чтобы мы могли стать лучше.
Управление атакующим ботом: полный контроль над тестовыми атаками, их можно включать и отключать вручную, чтобы оценить, как продукт справляется с угрозами.
Автопилот: бот может стать помощником в настройке PT AF PRO, выполнить автоматизированную настройку агента, очистить параметры, если что-то пошло не так, сбросить пароль.
Восстановление приложения после атак: бот поможет вернуть исходные товары на портале интернет-магазина после их подмены, восстановить главную страницу.
Функции для администратора или сопровождающих инженеров: бот уведомляет о регистрации пользователя, управляет доступом к лабораторным стендам; контролирует доступность ресурсов; получает результаты опросов для улучшения сервиса.
Организация доступа к индивидуальному стенду
Следуя идее «быстро и просто», было принято решение об исключении доступа через VPN — все должно работать из браузера и использовать стандартный TCP-порт 443, так как в некоторых корпоративных средах доступ к внешним интернет-ресурсам может быть ограничен по нестандартным портам и (или) VPN-протоколам.
Приложение становится доступным по публичному URL-адресу: xxxxx.ptaf.ru, где xxxxx — уникальный идентификатор стенда, состоящий из пяти символов.
По сценарию задания необходимо добавить модуль агента PT AF PRO к прокси-серверу nginx, для этого организуется консольный доступ по SSH, но также используется веб-шлюз по SSH в самом браузере без использования дополнительных TCP-портов.
Тест-драйв 1.0. Выводы
Первый пробный запуск проекта был на практических офлайн-мероприятиях под названием «Тест-драйв», где слушатели одновременно развертывали стенды и знакомились с продуктом PT AF PRO.
Наблюдая за одновременной работой нескольких десятков пользователей и имея возможность быстро получить обратную связь, мы сделали следующие выводы:
Пользователь работал только с продуктом PT AF, механика выполнения атаки осталась за кулисами, сценарий лабораторной работы выполнялся быстро, пользователь не погружался глубоко в суть происходящих процессов выполнения атак.
Для лабораторных стендов использовался продуктивный PT Cloud AF, который работает для клиентов облачного сервиса Positive Technologies. Это накладывало ограничения: только один способ обработки трафика — на внешнем агенте; отсутствие доступа администратора к системе управления PT AF для анализа происходящих процессов. У меня — у организатора и модератора мероприятия — не было возможности оперативно разобраться, когда что-то шло не по плану (а это нормальное явление, когда используются живые стенды и продукты, а еще это вызывает больший интерес и приносит дополнительный опыт).
-
Атакующий бот в связке с прокси-сервером nginx генерирует трафик от реальных IP-адресов различных стран. Для этого в контейнерах использовалась пара интерфейсов — для управления и для трафика, плюс маршрутизация предполагала использование дефолтного маршрута в контейнере прокси-сервера nginx в сторону контейнера генератора трафика.
Из-за сжатого срока подготовки проекта было принято решение использовать нативный Docker без оркестрации в виде Kubernetes (два интерфейса и нестандартная маршрутизация — это отдельный предмет анализа и выбора, подходящего для этой задачи CNI-плагина).
Монолитная архитектура и использование Docker усложнило процесс масштабирования стендов, которое выполнялось через API Docker: контроль сети, назначение IP-адресов, нейминг, распределение контейнеров по разными виртуальным машинам, политики безопасности для изоляции стендов.
Тест-драйв 2.0. Все в одном
Принципы и мотивация переработки проекта
Эволюция проекта привела к переработке полученных выводов о тест-драйве первого поколения и сформировало гипотезу, что в основе проекта должны лежать технологии, а продукт — лишь один из возможных инструментов для решения задачи обеспечения защиты. Кроме того, я убежден, что выполнение продуктовых тестов должно приносить пользу в любом случае. Будет ли в дальнейшем приобретен и эксплуатироваться продукт или нет — это второстепенный фактор.
Процедуры реализации атак были интегрированы в процесс выполнения лабораторных заданий, чтобы было понятно, как можно проэксплуатировать определенные уязвимости и как они устроены, поэтому было добавлено пошаговое описание их реализации для пользователя системы.
Так, во-первых, можно убедиться, что используемое приложение действительно содержит уязвимость, поскольку вся механика атаки полностью раскрыта.
Во-вторых, исследуется поведение инструмента защиты — детектирование атаки без блокировки и с блокировкой нелегитимных запросов.
Для инженеров, которые только начинают погружаться в тему, возникает полное системное понимание некоторых типовых способов реализации атаки, способов их детектирования и предотвращения.
Опытные инженеры получают подтверждение и синхронизацию ожиданий: в процессе исследования логики работы продукта возникает понимание, удовлетворяет ли поведение и функциональность продукта заданным требованиям.
Косвенно решается задача принятия решения о дальнейших и более глубоких тестах и целесообразности выделения инженерных ресурсов на них со всех заинтересованных сторон: заказчика, интеграторов, производителя продукта.
Лабораторный стенд
Каждый пользователь получает свой индивидуальный и изолированный стенд, но все компоненты стали автономными — перешли от PT Cloud AF к PT AF PRO, что дало возможность использовать самые свежие релизы, обеспечить максимальный охват функций продукта и повысить управляемость стендами в целом.
Сохранился принцип доступа к стендам через браузеры Chrome или Chromium (рекомендация для PT AF PRO), все работает через HTTPS-порт 443 без использования VPN или нестандартных TCP-, UDP-портов для доступа пользователя.
Интерактивное выполнение атак и защиты
В этом релизе инструмента для тест-драйва мы предлагаем последовательно выполнить набор заданий, состоящий из двух групп: в уязвимом приложении Juice Shop c обработкой трафика на worker PT AF PRO и в приложении VulnBank на внешнем агенте PT AF PRO. Разные типы обработки трафика охватывают различные варианты архитектуры интеграции системы защиты в инфраструктуру, а также различные типы вариантов использования PT AF PRO: on-premises (система управления инсталлируется внутри инфраструктуры заказчика) и PT Cloud AF (облачная система управления с внешними агентами обработки и инспекции трафика).
Выполнение испытаний начинается со знакомства с пользовательским интерфейсом PT AF PRO, с особенностями параметров обработчика трафика, затем мы предлагаем опубликовать приложение, как это делается в реальной жизни.
После успешной публикации начинаются эксперименты с атаками на уязвимые приложения: сначала выполняется сама атака, при этом система защиты только наблюдает и ничего не блокирует, ведь необходимо убедиться, что уязвимость действительно имеет место.
Сложность атак растет по мере выполнения прохождения тестов: в начале выполняются полностью автоматизированные и не требующие дополнительной настройки атаки, такие как подмена товаров в интернет-магазине и дефейс главной страницы.
В списке угроз OWASP Top Ten 2021 нарушение контроля доступа находится на первом месте, на седьмом — ошибки идентификации и аутентификации, поэтому такие типы атак, которые обозначены выше, включены в базовые тесты. Переходя к действиям, предлагается разобраться, как настроить PT AF для детектирования успешной и неуспешной аутентификации, причем каждое приложение использует свой способ: интернет-магазин Juice Shop использует структуры JSON-данных, а в приложении интернет-банкинга аутентификационные данные передаются на сервер с помощью стандартных полей HTML-формы и POST-запроса.
Для проверки работы правил используются брутфорс-атаки, которые непосредственно используют механизм детектирования фактов аутентификации пользователей, исследуется и модифицируется поведение системы при агрегации однотипных событий за определенные промежутки времени: настраивается способ журналирования событий, изменятся реакции системы со стандартного ответа блокировки с кодом ответа HTTP 403 Forbidden либо на собственную страницу блокировки, чтобы сложнее распознать систему защиты, либо на сброс TCP-соединения с клиентом, чтобы уменьшить нагрузку на систему в целом.
Проводится атака и защита от неавторизованного доступа к данным через внедрение SQL-кода, а также реализуется утечка данных и извлечение схемы базы данных SQL. Такой вид угрозы — Injection — находится в OWASP Top Ten 2021 на третьей позиции. На исследуемом стенде дается пример атаки из этой же категории — XEE (XML External Entity). XML-формат документов позволяет включать внешние ресурсы. В случае некорректной конфигурации XML-парсера или анализатора приложения, возникает уязвимость, злоумышленник может выполнить атаку XEE, которая позволяет получить доступ к файлам на сервере, спровоцировать отказ в обслуживании, совершить произвольные сетевые запросы от имени сервера (это действие имеет отношение к уязвимости SSRF (Server-Side Request Forgery)), а иногда и выполнить произвольные команды на сервере (RCE, Remote Code Execution). Предотвращение удаленного выполнения кода демонстрируется с использованием пакета обработки графических изображений ImageMagick в приложении.
В исследование базовых параметров включено активное сканирование и адаптация системы для ограничения количества одновременных запросов, обнаружение загружаемых злоумышленником web-shell для удаленного управления сервером, детектирование ранее загруженных скриптов web-shell, которые могли оказаться на сервере до внедрения системы защиты WAF, а также блокировка запросов из различных стран.
Набор встроенной экспертизы PT AF PRO включает в себя более ста различных правил детектирования и блокировки атак, при этом могут возникнуть задачи разработки и использования собственных правил. В качестве иллюстрации даны примеры, как реализовать защиту от атаки Poison Null Byte (не включена в основную экспертизу из-за редкой применимости), ограничения доступа с определенных IP-адресов, ограничения по регионам, а также защита бизнес-логики приложения с использованием пользовательских правил.
И в заключительной части лабораторных тестов представлены методы работы с ложноположительными срабатываниями системы защиты, когда специфика приложения вызывает срабатывания WAF на легитимные запросы. Правила исключений из обработки и пропускаемые части HTTP-запроса настраиваются индивидуально под каждое приложение и специфику правил.
Техническая инфраструктура
Инструмент размещен в изолированном виртуальном частном облаке. Улучшение управляемости и упрощение автоматизации осуществилось с переходом с нативного Docker на кластер Kubernetes, в котором размещается вся обвязка лабораторных стендов: уязвимые приложения, веб-шлюзы по SSH, прокси-серверы с агентами. В качестве сетевого CNI-плагина используется Calico.
Каждый стенд размещается в свой индивидуальный namespace, а также применяются унифицированные сетевые политики безопасности, которые позволяют изолировать стенды на сетевом уровне между собой, а также заблокировать базовый доступ в интернет. Учитывается риск, что пользователь потенциально может навредить инфраструктуре, так как имеет консольный доступ к Linux-узлам на стенде.
K8s network policies
Уровень абстракции сетевых политик для Calico и Kubernetes заключается, по существу, в четырех правилах безопасности:
разрешение на обмен трафиком между подами внутри выделенного namespace для стенда;
разрешение на передачу трафика с внешним L7-балансировщиком для публикации сервисов;
доступ к внутреннему сервису DNS для разрешения имен сервисов;
туннельный трафик в сторону виртуальных машин PT AF PRO. Все остальное по умолчанию блокируется.
Публикация сервисов в интернете
Для доступа к стендам был зарегистрирован независимый от остальной инфраструктуры Positive Technologies домен ptaf.ru, предназначенный только для публикации доступа к лабораторным стендам PT Application Firewall PRO.
В роли внешнего балансировщика и Ingress-контроллера используется Traefik.
Автоматически вместе с развертыванием сервисов и подов стенда в Kubernetes создаются Ingress Routes, обеспечивающие доступ к компонентам стенда из интернета с использованием уникальных ссылок и доменов 3-го уровня (ограничение тремя уровнями обусловлено спецификой используемого wildcard-сертификата SSL от Let’s Encrypt).
В текущей версии лабораторного стенда создаются шесть Ingress Routes:
Уязвимое приложение Juice Shop через Worker PT AF — URL вида: juiceshop-xxxxx.ptaf.ru.
Уязвимое приложение VulnBank через агент PT AF — URL вида: vulnbank-xxxxx.ptaf.ru.
Пользовательский интерфейс продукта PT AF PRO — URL вида: af-xxxxx.ptaf.ru.
Web SSH консольный доступ к Linux-узлу с nginx и модулем агента PT AF — URL вида: agent-xxxxx.ptaf.ru.
Web SSH консольный доступ к Linux-узлу с инструментами для атаки на уязвимый Juice Shop — URL вида: attacker-js-xxxxx.ptaf.ru.
Web SSH консольный доступ к Linux-узлу с инструментами для атаки на уязвимый VulnBank — URL вида: attacker-vb-xxxxx.ptaf.ru.
В URL присутствует уникальный пятисимвольный идентификатор стенда («xxxxx» в примере выше), который генерируется при создании стенда.
Чтобы ограничить свободный доступ к уязвимым приложениям через интернет, мы используем промежуточный HTTP Middleware — Authelia, выполняющий роль обязательной аутентификации через SSO для доступа через все перечисленные выше сервисы и по URL. Этот же механизм контролирует доступ пользователя только к своему выделенному стенду. Логин и пароль пользователь получает после запроса нового стенда.
Еще одна особенность, связанная с аутентификацией через SSO, — это наличие второго HTTP Middleware, который вырезает куки с идентификатором пользователя при запросе к приложениям, чтобы, например, не допустить утечку сессионной информации стенда в процессе демонстрации этого стенда — во время выполнения атак и их блокировок часто исследуются и показываются сырые запросы и ответы прямо из карточки события PT AF PRO.
Решение задачи масштабирования и использования нескольких инстансов PT AF PRO
Особенностью архитектуры организации лабораторных стендов является отделение виртуальных машин PT AF PRO от компонентов обвязки самих стендов, существующих внутри одного выделенного кластера Kubernetes.
Архитектура реализует динамическое масштабирование и возможность обновления PT AF PRO, не влияющего на создание новых стендов, а также минимизирует потребляемые ресурсы в зависимости от текущего количества одновременно работающих пользователей. Поэтому в окружении создаются несколько виртуальных машин с минимально необходимым количеством CPU, RAM, а не одна с большим потреблением ресурсов памяти и процессора.
Выбор распределенной инфраструктуры и динамическое развертывание нескольких виртуальных машин PT AF в инфраструктуре имеет следующие особенности:
Масштабирование компонентов обвязки осуществляется за счет увеличения количества нод кластера Kubernetes, а масштабирование PT AF — за счет увеличения числа виртуальных машин.
Развертывание виртуальной машины PT AF осуществляется из готового образа (клонирование) с преднастроенной и статически заданной группой сетевых интерфейсов (WAN, LAN, кластерный и сетевой интерфейс управления), необходимых для функционирования продукта. Такой способ обеспечивает быстрое развертывание и гарантирует работоспособность продукта по сравнению с установкой продукта на чистой Linux-системе по типовой процедуре.
Максимальная унификация образа PT AF и отсутствие постнастройки после развертывания образа — разница в назначаемом инфраструктурном IP-адресе, он же идентифицирует определенный инстанс PT AF.
Независимость статически настроенных сетевых интерфейсов продукта от сети интерфейса взаимодействия компонентов стенда инфраструктуры виртуального частного облака, где IP-адресация назначается динамически при развертывании виртуальной машины. В итоговом решении у виртуальной машины только один сетевой интерфейс, остальные, необходимые для работы продукта, — виртуальные и туннельные.
Каждая виртуальная машина PT AF способна обслуживать нескольких пользователей (быть частью нескольких стендов) — это ресурс для совместного использования, разделение осуществляется на уровне изолированных пространств в самом PT AF PRO и интегрированной модели. Управление доступом пользователей происходит на основе ролей.
Виртуальная машина PT AF PRO является внешней для кластера Kubernetes, при этом хотелось упростить сущности, связывающие PT AF и защищаемое приложение, и уменьшить их количество. В итоговом решении трафик отправляется в сторону PT AF изнутри кластера — создан сервисный под, который выполняет роль шлюза (gateway pod) между кластером Kubernets и PT AF через виртуальный оверлейный туннель. При этом PT AF является сервером, а под — клиентом внутри кластера, между которыми поднимается WireGuard-туннель.
Шлюз для каждого стенда свой. При его развертывании определяется, к какому инстансу PT AF PRO будет подключение. Таким образом, PT AF PRO становится частью стенда и осуществляется балансировка между разными инстансами PT AF PRO.
Доступ по URL-адресу (af-xxxxx.ptaf.ru) пользовательского интерфейса PT AF PRO и его публикация осуществляются также через под шлюза. Именно так решается задача маршрутизации пользователя на нужный ему инстанс (мы также рассматривали вариант, когда пользователю отдается URL с идентификатором не стенда, а конкретного инстанса PT AF, например af00.ptaf.ru, но такой вариант неконсистентный и может привести к путанице при использовании нескольких стендов).
Решение задачи по генерации трафика с поддельными IP-адресами источников
Использование WireGuard-туннеля между контейнерами стенда (pod) внутри кластера Kubernetes позволило реализовать честную генерацию трафика с подменой IP-адресов источников на реальные IP-адреса, принадлежащие разным странам, а не просто использовать HTTP-заголовки типа X-Real-IP или X-Forwarded-For.
Выбранный способ не потребовал модификаций или использования нестандартных конфигураций CNI-плагинов со стороны узлов кластера, каждый под на стенде имеет один сетевой интерфейс для взаимодействия с пользователем и связности с другими компонентами в стенде, в том числе для того, чтобы поднять туннель. Далее по уже описанному в разделе «Тест-драйв 1.0» алгоритму используется default-маршрут в контейнере агента, а в генераторе трафика loopback-интерфейсу назначаются IP-адреса, с которых выполняются необходимые запросы.
Таким генератором трафика можно проверить встроенные и пользовательские правила, в которых используются GeoIP-модули.
Архитектура телеграм-бота
Архитектура учитывает разделение на уровни — для управления стендами и для управления пользовательскими интерфейсами. Это необходимо для адаптации проекта к новым условиям работы, например оперативно заменить Telegram на любой другой мессенджер, включить выделенный портал или вовсе задействовать параллельно несколько интерфейсов для работы с пользователями. В текущей версии проекта применяется шлюз для работы через мессенджер и поддерживается микросервисом Telegram-бота.
Микросервис testbed manager является базовой системой управления стендами, реализует балансировку стендов по разным инсталляциям PT AF PRO, выполняет функции развертывания обвязки стендов в кластере Kubernetes и настраивает изолированные пространства в PT AF PRO через API. Взаимодействие с этим сервисом осуществляется через API, а сохранение состояний происходит в базе данных MongoDB.
Процесс выполнения PoC-тестов и лабораторных испытаний
Шаг 1. Регистрация (команда бота /start)
Пользователь вводит данные, чтобы его можно было идентифицировать не только по профилю в Telegram. Как только пользователь завершает регистрацию, администратор бота получает уведомление, а также возможность разрешить доступ.
Шаг 2. Инструкция по работе с ботом и со стендами (команда /howto)
Справка по процессу, информация обо всех командах, последовательности выполнения работы, а также о том, где получить поддержку и связаться с администратором.
Шаг 3. Запрос стенда и подтверждение доступа (команда /request)
Если на первом шаге доступ не был разрешен, то пользователь имеет возможность запросить его вручную, актуализировав себя в ленте уведомлений администратора. Если же доступ разрешен, то выполняется динамическое развертывание стенда.
Как только стенд развернут, то есть система получает подтверждение об успешном запуске всех необходимых контейнеров (подов) и параметров PT AF PRO, пользователь получает детальное сообщение с данными для доступа к стенду:
Уникальные URL-адреса для доступа к PT AF PRO, приложениям, консолям узлов через Web-SSH для реализации атак.
Логин и пароль для аутентификации через SSO ко всем URL.
Логин и пароль для доступа к изолированным пространствам (тенантам) PT AF PRO.
Параметры для публикации приложения с использованием worker PT AF PRO (listen IP, backend IP).
В этом же сообщении находятся команды управления стендом:
«Перезагрузить» — рестарт подов; используется, если поведение приложения или агента не соответствует ожиданиям (например, что-то сломалось по результатам атаки и работу невозможно восстановить).
«Продлить» — продление работы стенда.
«Завершить» — завершение работы стенда по команде от пользователя (поды стенда и тенанты PT AF удаляются).
Шаг 4. Выполнение лабораторных заданий (команда /task)
Команда показывает карточку выполняемого задания.
Содержание карточки задания:
Краткое описание задания.
Статус задания: выполняется, выполнено или пропущено. Время изменения каждого статуса фиксируется, чтобы, набрав достаточный объем данных, проанализировать затрачиваемое время на выполнение каждого шага.
Кнопка «PDF» — загрузка инструкции по выполнению задания (lab guide), бот отправляет в виде PDF-файла.
Кнопки навигации — последовательное переключение между карточками заданий.
Шаг 5. Проверка выполнения задачи
Автоматизированная обратная связь со стороны системы о найденных событиях безопасности является отличительной особенностью текущей версии тест-драйва.
В карточке задания есть опции (кнопки):
«Выполнено» — пользователь обозначает готовность задачи и переходит к автоматизированной проверке.
«Пропустить» — пользователь пропускает проверку задачи. Если выбрать эту опцию, то вернуться к проверке нельзя. Задания выполняются последовательно, так как связаны между собой. Повторно выполнить задание можно создав новый стенд.
Во всех задачах проверка выполняется путем отправки необходимого идентификатора (UUID) события — это может быть событие аудита, событие безопасности или событие агрегации.
Пользователь отправляет UUID события в телеграм-бот, инструкция, как его получить из URL пользовательского интерфейса PT AF, находится в PDF-файле с описанием первого задания.
Бот через API PT AF PRO выполняет проверку полученного события:
Его релевантность (тип события, тип атаки, содержание атаки и т. п.).
Оно должно быть получено после начала выполнения задания.
Концепция проверки мотивирует пользователя анализировать события и исследовать результаты работы системы защиты PT AF. Поиск событий и реагирование на них являются неотъемлемым процессом расследования и предотвращения инцидентов безопасности.
Статусы выполнения заданий уникальны для каждого развернутого стенда (не для пользователя), при завершении работы с одним стендом и запуске другого все результаты обнуляются.
Срок работы стенда
Каждый лабораторный стенд потребляет определенные ресурсы в инфраструктуре проекта, поэтому по умолчанию стенд действует 24 часа, а потом его работа автоматически завершается. Можно продлить стенд на 24 часа, максимально от текущего момента — на три дня (чтобы, например, сохранить стенд на выходные). При приближении окончания срока жизни стенда пользователь получает уведомление и технически может продлевать его бесконечно.
Однако есть исключение. Если инстанс PT AF или нода кластера Kubernetes, на которых расположен стенд, отмечены администратором для вывода в режим обслуживания, то такой стенд продлить нельзя. В таком случае пользователь может завершить текущий стенд и создать новый — система автоматически разместит его на активных нодах.
Такой сценарий связан либо с обновлением инстансов, либо с уменьшением масштабирования. В текущей версии проекта перенос стенда не предусмотрен, но не исключается в новых версиях проекта.
Планы на развитие инструмента для тест-драйва
Мы стремимся к тому, чтобы наш инструмент становился еще более удобным, функциональным и полезным. Можно выделить три ключевых направления развития: расширение сценариев использования продукта PT AF PRO, учет используемых ресурсов и мониторинг.
-
Расширение сценариев использования продукта PT AF PRO
Наша цель — предоставить больше возможностей для тестирования и экспериментов. Мы добавляем новые сценарии, которые помогут вам глубже погрузиться в функциональность продукта и оценить его работу в различных условиях. Перечислю основные задачи:
Команды автоматизированной настройки PT AF и агента (автопилот уже был в первой версии проекта, но не был востребован из-за специфики концепта). Такая опция необходима для проведения быстрых ознакомительных демо, когда нет возможности уделить достаточно времени на настройку и выполнение заданий.
Добавление новых уязвимых веб-приложений — переход от OWASP Juice Shop к другим и более актуальным приложениям.
Расширение охвата функциональных тестов правил безопасности (встроенных и пользовательских).
-
Контроль времени использования стендов
По мере роста числа пользователей возникает необходимость учитывать и ограничивать количество ресурсов, используемых для работы стендов PT AF PRO. Одним из вариантов решения вопроса является внедрение так называемой системы доступа по «инвайт кодам».
Инвайт — это ключ доступа к развертыванию стендов, который генерируется сотрудниками компании Positive Technologies и имеет базовые атрибуты:
Срок регистрации: период, в течение которого можно активировать инвайт.
Срок действия стендов: период, в течение которого можно пользоваться стендами.
Количество пользователей на один инвайт (допускается вариант без ограничений).
Количество часов на одного пользователя: суммарное время работы стендов в активном состоянии.
-
Количество часов на всех пользователей инвайта.
У владельца инвайта появляется возможность получать уведомления о работе своих пользователей: о регистрации, создании и удалении стендов, прохождении задач. Таким образом, можно отслеживать, насколько эффективно использовался предоставленный ресурс. Пользователь, в свою очередь, получает более фокусную поддержку. У меня есть гипотеза, что так можно улучить коммуникацию между сотрудниками производителя продукта и будущими пользователями. Важно не лишить систему гибкости, поэтому будут и другие опции, позволяющие активировать несколько инвайтов, отзывать или редактировать их, создавать группу сопровождения тест-драйва, проверять бесконечные атрибуты на противоречия. Например, если не задан срок действия стенда, то обязательно должен быть установлен лимит на количество часов его использования.
-
Мониторинг
Несмотря на то, что проект изначально был сфокусирован на лабораторных стендах и обеспечение его бесперебойной работы не было в приоритете, ключевая задача, которую решает инструмент для тест-драйва, — это удовлетворенность пользователя в процессе экспериментов и исследования. Поэтому важно проактивно отслеживать состояние системы и не дожидаться, пока пользователь сообщит о проблемах, нужно анализировать журналы аудита, чтобы изучать действия пользователей во время работы с самим продуктом PT AF PRO и со стендами. Помимо мониторинга состояния всех компонентов с системой нотификаций, планируется внедрение автоматизированных тестов масштабируемости: максимального количества стендов, скорости развертывания, стабильности работы.
Заключение
Созданный мной и описанной в этой статье проект «Тест-драйв» c телеграм-ботом @TryPTAFBot позволяет интерактивно оценить технические возможности продукта для обеспечения безопасности веб-приложений PT Application Firewall PRO, провести демонстрацию, испытания и подтверждение концепции (PoC).
Тест-драйв помогает:
Изучить и проверить функциональные и технические возможности продукта, встроенную и настраиваемую экспертизу детектирования угроз безопасности.
Оценить готовность продукта обеспечивать защиту веб-приложений.
Согласовать ожидания пользователя и возможности продукта.
Быстро понять, подходит вам продукт или нет, и тем самым экономит ваше время.
Получить навыки работы с продуктом и снизить порог вхождения, понять процесс и эргономику управления.
Исследовать специфику поведения продукта в процессе инспекции трафика.
Хотите понять, как защититься от атак при помощи PT AF PRO или автоматизировать демонстрацию вашего концепта, сделайте первый шаг — напишите мне: t.me/dkaryakin.
И оставляйте комментарии по теме под этой статьёй :)