Table of Contents
Вначале были веб-приложения, которые предоставляли информацию пользователям Сети. Потом появились сервисы, которые позволяли владельцам веб-приложений предсказать допустимую нагрузку. И с помощью этих сервисов придумали хакеры способ вывести любое веб-приложение за пределы допустимой нагрузки…
Любой веб-проект, будь то потерянный где-то в Сети блог или веб-приложение нового стартапа, имеет такую важную характеристику своей работоспособности, как «предельная нагрузка». Эта метрика дает о себе знать, когда веб-приложение частично или полностью отказывается выполнять возложенные на него функции обработки запросов от пользователей. Для кого-то из владельцев это может означать потерю аудитории, которая регулярно читает его, а для кого-то — потерю клиентов, которые из-за неработоспособного веб-ресурса интернет-магазина решили купить товар у конкурента. Не всегда причиной отказа в обслуживании становится распределенная атака. Просто у каждого веб-ресурса есть предельное значение количества обрабатываемых пользователей. Этот факт заставил разработчиков и владельцев веб-приложений уделять особое внимание процедуре нагрузочного тестирования.
Стресс как сервис
Десктопные приложения постепенно перебегают в облака, и браузер просто необходим любому уважающему себя интернет-пользователю. Концепция «ПО как сервис», с одной стороны, облегчает нам жизнь. Не нужно заморачиваться над установкой приложений, тратить гигабайты своего жесткого диска. Мы теперь совсем не привязаны к конкретной рабочей станции с фиксированным набором ПО — теперь любой девайс, имеющий в своем арсенале веб-браузер, может стать фотошопом, средой разработки, блокнотом и трансформироваться во многие другие приложения. С другой стороны, концепция работы с облачным программным обеспечением таит в себе подводные камни. Во-первых, мы доверяем продукты своей облачной деятельности третьему лицу. Доверяем ли мы ему? Вдруг он подсматривает наши фотографии или исходный код наших приложений, который мы у него храним? А может быть, он не следит за своей безопасностью и у любопытных умельцев есть возможность просматривать наши файлы (вспомним инцидент с Dropbox). Однако речь не об этой стороне облачной концепции. На просторах Сети веб-сервисом стали совсем не безобидные приложения для нагрузочного и стресс-тестирования…
Разведка боем
Формально процедура нагрузочного тестирования является частью процедуры тестирования производительности — более комплексного теста, в который также входит стресс-тестирование. В свою очередь, стресс-тестирование — оценка поведения целевой системы при нагрузке, выходящей за рамки допустимого значения. Частный пример стрессового тестирования информационной системы — DDoS-атака на ее компоненты.
Например, мы знаем, что наш блог может одновременно выдержать 1000 пользователей. Мы начинаем проверку и имитируем активность 50 пользователей, затем 100 и, наконец, 900. Мы занимаемся нагрузочным тестированием. Затем мы решили проверить, как поведет себя блог, если его будут читать сразу 1050 пользователей, а это значит, что мы приступили к процедуре стрессового тестирования.
Стрессовое тестирование помогает повысить уровень защищенности внешних ИТ-ресурсов целевой инфраструктуры и позволяет получить следующие результаты:
- Определить текущие предельные значения нагрузки на внешние сервисы. Если мы знаем точку отказа нашей информационной системы, то мы можем попробовать повысить отказоустойчивость: оптимизировать имеющиеся процессы или внедрить новые. Другими словами — кто предупрежден, тот вооружен.
- Проверить устойчивость внешних сервисов к некоторым сценариям распределенных атак, направленных на отказ в обслуживании. Взглянув на свой проект глазами злоумышленника, мы можем делать прогнозы «черных дней» для своего бизнеса либо развернуть превентивную защиту под наши потребности.
- Оценить эффективность средств защиты от DDoS-атак при реализации соответствующих сценариев распределенных атак. Например, жизнь заставила нас встать под защиту какого-нибудь сервис-провайдера Anti-DDoS, но мы хотим проверить, действительно это эффективная мера или же пустая трата бюджета. DDoS — ответ на наш вопрос.
- Сделать противодействие данному типу угроз эффективнее и подготовить себя и своих коллег к взаимодействию в ходе DDoS-атаки. В данном случае нагрузочное и стресс-тестирование дают ответы на вопросы «Кажется, наш сервис загибается… Что делать?» или «Нас атакуют! Что делать?».
- Разработать рекомендации по повышению защищенности от DDoS-атак.
В отличие от других этапов разработки веб-проекта, будь то отладка приложения или его функциональное тестирование (проверка работоспособности его функционала), нагрузочные тесты имеют ряд особенностей, которые делают их реализацию нетривиальной задачей. Во-первых, тесты проводятся на реальной информационной системе, которая может находиться в процессе функционирования. Согласись, тестировать макет никому не интересно (если только процедура тестирования не является частью процесса разработки высоконагруженного проекта), куда лучше получить картину производительности живого «образца». В свою очередь, прогруз действующего проекта может стать причиной временного прекращения какого-то бизнес-процесса, а это значит, что мы можем получить самый настоящий отказ в обслуживании со всем вытекающими.
Во-вторых, сценарии проведения стресс-тестов могут включать в себя нагрузку, которая имитирует действия злоумышленников, но не ограничиваются ею. В этом случае мы получаем более комплексную оценку нашей производительности, нежели оценку эффективности парочки DDoS-атак.
Перфоманс на сцене Web
Задача: создать контролируемую нагрузку на сервис, которая также должна превысить текущее значение предельной (если только мы не хотим заниматься прогнозированием точки отказа нашего сервиса). Решение: нетривиальное.
Можно попросить владельца посещаемого веб-проекта сделать редирект его пользователей на наш ресурс. В таком случае нужно найти доброго владельца, у которого посещаемость проекта значительно превышает наши показатели.
Можно настроить standalone-приложение вроде Apache JMeter, написать для него сценарий поведения пользователя и отправить бродить по нашему веб-приложению. Однако имитация сотни пользователей с локалхоста вряд ли создаст ощутимую нагрузку для более-менее серьезного приложения (если только мы грузим не свой блог на площадке Google). В таком случае лучше раскидать этот скрипт по нескольким машинам или воспользоваться прелестями облачных IaaS-площадок вроде Amazon EC2. Кстати, в нашем журнале был интересный материал на тему использования приложений для нагрузочного тестирования (www.xakep.ru/post/43327).
То, что пять лет назад несло в себе ноу-хау, теперь становится объектом археологии. Это касается и описанных выше способов тестирования производительности. Теперь концепция «All as a service» позволяет владельцам веб-приложений не заморачиваться над настройкой сложных систем нагрузочного тестирования, подготовкой облачной инфраструктуры и тому подобными действиями. Теперь уже все это сделано в бэкграунде и предоставляется как онлайн-сервис: залогинился на симпатичном веб-ресурсе, задал параметры нагрузки, оплатил вычислительные мощности и знай себе фиксируй поведение своего веб-проекта. Кстати, для мониторинга состояния веб-ресурса также есть отличные веб-сервисы, но обо всем по порядку.
Load Impact
Одним из первопроходцев в направлении сервисов нагрузочного тестирования стал проект Load Impact (loadimpact.com). Теперь владельцу веб-ресурса, чтобы выяснить возможности своего детища, достаточно зарегистрироваться в этом проекте. Особо ленивым сервис предлагает моментальную проверку без регистрации, возможности которой не особо впечатляют, но позволяют быстро познакомиться с интерфейсом сервиса. Надо отметить, что даже бесплатная нагрузка оказала заметное влияние на время отклика моего блога, который «дрейфует» по инстансам амазоновского облака.
За кулисами красивого интерфейса в глаза бросается потенциал, который открывается вместе с возможностями по конфигурированию процедуры нагрузочного тестирования. Здесь можно задать как основные параметры нагрузки (количество пользователей, максимальный интервал времени для их подключения, привязка IP-адресов), так и дополнительные (географическое распределение пользователей, их сценарий работы с веб-приложением, агенты для измерения показателей работоспособности приложение и так далее).
Особенно радует гибкая система вывода результатов тестирования. Графическое представление огромного числа метрик позволяет получить детальную и наглядную отчетность о процессе.
Прайс-лист для нагрузочного тестирования в рамках сервиса Load Impact позволяет за 225 долларов генерировать нагрузку, эквивалентную показателю посещаемости нашего проекта в 100 тысяч посетителей в месяц. Дорого, но оценить возможности сервиса можно в тестовом режиме, который позволяет имитировать посещаемость в 10 тысяч пользователей в месяц. Стоит отметить, что даже бесплатная нагрузка в 50 пользователей позволила за трехминутный интервал заметить аномалии в поведении системы дистанционного банковского обслуживания небольшого банка. Зафиксируем факт генерации нагрузки с помощью Load Impact в рамках демонстрационных возможностей и перейдем к следующему сервису.
BlazeMeter
«JMeter as a service» — говорят о своем проекте создатели. Концепция действительно простая: берем JMeter, раскидываем его по инстансам облачной инфраструктуры Amazon EC2 и делаем фронтенд, который позволит нашим пользователям готовить сценарии тестов, оплачивать нагрузку и наслаждаться отчетами.
Не перегруженный пестрыми элементами веб-интерфейс за своей простотой скрывает весь необходимый функционал для организации нагрузочного тестирования. «Под капотом» у BlazeMeter прячется пул амазоновских инстансов, которые разработчики сервиса предоставляют своим пользователям. Гибкая система отчетов позволяет максимально детально проанализировать каждую секунду процедуры тестирования и получить картину поведения целевой информационной системы.
Инициализацию нагрузки можно проводить по расписанию, что наталкивает на мысль о возможности активации данного сервиса в час пик приложения-жертвы.
Здесь мы также видим гибкую тарификацию в зависимости от потребности клиента. За 40 тысяч пользователей (при максимальном количестве IP-адресов 40 штук) придется отдать около 299 долларов. В рамках бесплатной демонстрации возможностей сервиса предоставляется базовая нагрузка из 1000 одновременно подключенных пользователей. «Маленький ботнет» — вновь промелькнула мысль, которую мы зафиксируем.
И им подобные
Пробежимся по функционалу еще нескольких сервисов нагрузочного тестирования.
Load Storm. И вновь за красивым интерфейсом онлайн-сервиса прячется облачная инфраструктура, с набором ПО для генерации нагрузки. После регистрации Load Storm предлагает создать новый план нагрузочного теста. В этот план входит определение (запись) шагов манипуляций с целевым веб-ресурсом. Так, тест может состоять из одного шага — открытия главной веб-страницы.
Что примечательно, так это процедура верификации всех проверяемых сервисом проектов. Вдруг пользователь Load Storm хочет вывести из строя сайт конкурента. Для того чтобы пройти процедуру верификации, пользователю требуется разместить на целевом веб-ресурсе специальный файл с кодом, прочитав который проект Load Storm поверит, что его пользователь действительно владелец проверяемой системы.
Loaddy. Еще один представитель онлайн-проектов, которые позволяют в экспресс-режиме осуществить нагрузочное тестирование без регистрации. Помимо этого, сервис предлагает зарегистрированным пользователям бесплатные проверки, в которых обещается до 100 активных посетителей.
Обратная сторона медали
Теперь попробуем взглянуть на концепцию нагрузочного тестирования и онлайн-сервисов с позиции злоумышленника. Представим, что у нас нет своего веб-ресурса, который приносит нам доход, нас не волнует этическая сторона распределенных атак, направленных на отказ в обслуживании, в нашем словарном запасе вообще нет понятий «этика» и «мораль». У нас есть только страстное желание вынести веб-ресурс конкурента за пределы онлайна.
Вариантов достижения нашей цели достаточно. Можно сломать дюжину посещаемых веб-ресурсов и поставить редирект на целевой сайт, но это удовольствие будет длиться недолго, так как такой трафик легко блокируется на уровне правил файрвола, да и процедура компрометации нескольких посещаемых проектов может затянуться.
Можно заказать DDoS-атаку у владельца ботсети. Стоит эта услуга не очень дорого (около 15 долларов в час за 4-гигабитную нагрузку), что делает ее легкодоступной. Однако стоит помнить, что объем дешевенького ботнета может не дать нужного эффекта, если целевой веб-ресурс рассчитан на большую аудиторию. Также задачу осложняет то, что DDoS-атака может использовать сценарии, которые легко фильтруются различными Anti-DDoS средствами.
Наиболее эффективной будет такая DDoS-атака, при которой отличить легитимный трафик от нелегитимного (генерируемого ботами) практически невозможно. Достаточно представить, что количество читателей блога возросло со ста человек в день до ста тысяч и при этом все ведут себя, как положено рядовому пользователю, — тратят время на «ознакомление» с содержимым страницы, пытаются писать комментарии, просматривают картинки и при этом географически независимы друг от друга. Как тут неподготовленному к такому повороту событий владельцу ресурса понять, кто свой, а кто чужой?
Каждый из онлайн-сервисов нагрузочного тестирования, которые мы рассмотрели, по своей сути является ботнетом. Легкость определения поведения каждого бота, простота и понятность в сочетании с пулом вычислительных ресурсов — вот что отличает такую бот-сеть от бот-сетей, использующих традиционные сценарии DDoS-атак и предоставляемых на черном рынке киберпреступности. Конечно, дорогие тарифы не позволяют серьезно относиться к угрозе, которая может исходить от онлайн-сервисов нагрузочного тестирования. Давайте посмотрим, как легко можно превратить процедуру нагрузочного тестирования в стресс-тест с успешными результатами.
Проектов, подобных Load Impact, огромное множество, и большинство из них предоставляют свои ресурсы пусть в очень ограниченном, но дееспособном и бесплатном варианте. Чего стоит, например, на том же Load Impact поднять несколько независимых аккаунтов (привязка к телефонному номеру или кредитной карте не обнаружена ни на одном из описанных сервисов) и назначить им одно и то же время нагрузки на вражеский сайт? BlazeMeter официально поддерживает систему мультиаккаунтов. Некоторые проекты предоставляют демонстрационную нагрузку вообще без регистрации, а это может означать, что владелец какого-нибудь «ущербного» ботнета из 50–100 зомби с помощью таких сервисов может в сотни раз увеличить эффективность DDoS-атаки. Как? Все просто — на одного бота приходится десять независимых запросов на нагрузочное тестирование в различные сервисы типа Load Impact и Loaddy. Те, в свою очередь, независимо друг от друга инициируют сотни запросов. Результат: целевой ресурс задыхается от объемов вполне «легитимного» трафика. И все это «без регистрации и SMS».