Любой веб-проект, будь то потерянный где-то в Сети блог или веб-приложение нового стартапа, имеет такую важную характеристику своей работоспособности как «предельная нагрузка». Этот показатель дает о себе знать, когда веб-приложение частично или полностью отказывается выполнять возложенные на него функции по обработке запросов от пользователей. Для кого-то из владельцев это может означать потерю аудитории, которая регулярно читает его блог, а для кого-то – потерю клиентов, которые из-за неработающего интернет-магазина купили товар у конкурента.
У каждого веб-ресурса есть предельное значение количества одновременно обрабатываемых запросов пользователей. Поэтому разработчики и владельцы веб-приложений уделяют особое внимание процедурам нагрузочного и стрессового тестирований.
Современные сервисы нагрузочного тестирования удобны и полезны, однако некоторые их особенности оставляют лазейку для использования этих сервисов злоумышленниками.
Нагрузочное и стрессовое тестирование
Нагрузочное тестирование информационной системы – процедура оценки характеристик работоспособности тестируемой системы в рамках значений нагрузки, не превышающей предельное. Стрессовое тестирование представляет собой аналогичную процедуру, но проводимую за рамками предельного значения нагрузки. Стресс-тесты в большинстве случаев ведут к аномальному поведению тестируемой системы или ее отказу в обслуживании ‑ аналогично атакам distributed denial of service, DDoS.
Распределение множеств тестовых сценариев по мощности нагрузки на информационную систему
Как видно на рисунке выше, нагрузочные тесты выполняются в рамках предельного значения нагрузки, а стресс-тесты, как и сценарии DDoS-атак, реализуются за пределами данного значения. Однако цели у стрессового тестирования и DDoS-атаки совершенно разные. Задача стрессового тестирования – получить показатели предельной нагрузки тестируемой системы, в то время как DDoS-атака имеет цель «положить» атакуемый объект любыми эффективными методами и тем самым нарушить работоспособность целевой инфраструктуры.
Стрессовое тестирование оказывается необходимой процедурой, когда владельцу информационной системы нужно узнать, как она будет вести себя при аномальных нагрузках. Иногда есть необходимость выяснить, как будут справляться с нагрузкой имеющиеся средства защиты от DDoS-атак – для этого также используются процедуры стрессового тестирования.
Разведка боем
Стрессовое-тестирования является частью процесса повышения уровня защищенности внешних ИТ-ресурсов целевой инфраструктуры и позволяет получить следующие результаты:
- Определить текущие предельные значения нагрузки на внешние сервисы. Если мы знаем точку отказа нашей информационной системы, то для повышения отказоустойчивости мы можем оптимизировать имеющиеся процессы или внедрить новые. Другими словами, кто предупрежден, тот вооружен.
- Проверить устойчивость внешних сервисов к некоторым сценариям распределенных атак, направленных на отказ в обслуживании. Взглянув на свой проект глазами злоумышленника, мы можем сделать какие-то выводы, например, о необходимости установки средств защиты от DDoS-атак или эффективности уже существующих решений.
В отличие от других этапов разработки веб-проекта, будь то отладка приложения или его функциональное тестирование (проверка работоспособности его функционала), нагрузочные тесты имею важную особенность, которая делает нетривиальной задачей процедуру их реализации: тестирование проводится на реальной информационной системе, которая может находиться в процессе функционирования. Согласитесь, тестировать макет никому не интересно (если только процедура тестирования не является частью процесса разработки высоконагруженного проекта), куда лучше получить картину производительности живого «образца». Однако тестирование действующего проекта может стать причиной временного прекращения какого-либо бизнес-процесса, а это значит, что мы можем получить самый настоящий отказ в обслуживании со всем вытекающими.
Именно для решения задачи тестирования работающего веб-приложения или внешних информационных ресурсов, доступных из интернета (почтовый сервер, FTP-сервер и т.п.), созданы специальные онлайн-сервисы нагрузочного тестирования, которые вполне справляются со своими задачами.
Стресс-тест
Концепция «All as a Service» позволяет владельцам веб-приложений не заморачиваться над настройкой сложных систем нагрузочного тестирования, подготовкой облачной инфраструктуры и тому подобными действиями. Все это уже сделано в фоновом режиме и предоставляется как онлайн-сервис: ввел пару «логин:пароль», задал параметры нагрузки, оплатил вычислительные мощности и знай себе, фиксируй поведение своего веб-проекта.
Конфигурация нагрузочного тестирования в одном из рассмотренных проектов: задаем сценарий нагрузки, выбираем мощность нагрузки, оплачиваем используемые вычислительные ресурсы и получаем отчет
Теперь владельцу какого-либо веб-ресурса, чтобы выяснить, как его веб-проект ведет себя при аномальных нагрузках, достаточно зарегистрироваться в одном из подобных сервисов. Особо ленивым некоторые сервисы нагрузочного тестирования предлагают моментальную проверку (без регистрации), возможности которой не особо впечатляют, но позволяют быстро познакомиться с интерфейсом сервиса.
В отчете о тестировании много статистических данных. Например, распределение времени загрузки контента в ходе нагрузочного тестирования
Результат нагрузочного тестировании веб-приложения с помощью веб-сервиса
Нагрузочное тестирование как веб-сервис – несомненно, очень полезная и удобная процедура. Однако данная реализация процедуры тестирования не так безобидна, как может показаться на первый взгляд.
Тестирование или DDoS?
Попробуем взглянуть на онлайн-сервисы нагрузочного тестирования с позиции злоумышленника. Представим, что нас не волнует этическая сторона распределенных атак, направленных на отказ в обслуживании, у нас есть только желание сделать недоступным веб-ресурс конкурента. Можно ли для этого использовать сервисы нагрузочного тестирования?
Для эксперимента я выбрал несколько популярных сервисов тестирования и в качестве объекта для тестов использовал свой блог, который «дрейфует» по не самым слабым инстансам амазоновского облака (Amazon EC2). Результат: даже в бесплатном тестовом режиме, когда пользователю предоставляется очень небольшое количество вычислительных ресурсов сервисов, нагрузки оказалось достаточно, чтобы заметно увеличить время отклика моего блога.
Тестовый режим онлайн-систем нагрузочного тестирования позволяет имитировать посещаемость в 10000 пользователей/месяц, что может оказаться фатальным для многих небольших веб-проектов. Даже нагрузка в 50 пользователей за трехминутный интервал времени может внести аномалии в поведение какого-нибудь несложного веб-проекта.
При этом многие сервисы нагрузочного тестирования не требуют подтверждения того, что веб-ресурс тестирует его владелец, а не злоумышленник, нет никаких дополнительных привязок к телефонному номеру или кредитной карте.
Так, из з 6 рассмотренных нами сервисов тестирования только на одном просят разместить на тестируемом ресурсе специальный файл, получив доступ к которому сервис убедится, что администратор тестируемого ресурса уведомлен о процедуре. Более того, два из рассмотренных веб-сервисов позволяют осуществить нагрузочное тестирование вообще без регистрации, пользователю достаточно ввести URL тестируемого ресурса.
Простота использования данных инструментов дает возможность анонимно «протестировать» чужой веб-проект без каких-либо заморочек с регистрацией и согласия на тест со стороны владельца тестируемого ресурса. Тот факт, что тестирование без регистрации является еще и бесплатным, может сделать эти сервисы очень заманчивым инструментом для DDoS-атак.
Нагрузочное тестирование веб-ресурса при помощи сервиса, который не требует регистрации. Заходим на сайт, вводим URL тестируемого ресурса и смотрим отчет о результатах процедуры
Потенциальная угроза
На наш взгляд, онлайн-сервисы нагрузочного тестирования могут являться инструментом для анонимного осуществления некоторых сценариев DDoS-атак. Быстрое создание сценариев нагрузки, простота и понятность в сочетании с пулом вычислительных ресурсов – вот особенности такой «бот-сети». Злоумышленник легко может поднять несколько независимых аккаунтов и назначить им одно и то же время нагрузки на атакуемый сайт.
Известно, что наиболее эффективными являются такие DDoS-атаки, при которых отличить легитимный трафик от нелегитимного (генерируемого ботами) практически невозможно. Достаточно представить, что количество читателей блога возросло со ста человек в день до ста тысяч и при этом все ведут себя, как положено рядовому пользователю – тратят время на «ознакомление» с содержимым страницы, пытаются писать комментарии, просматривают картинки и являются географически независимыми друг от друга. Как тут неподготовленному владельцу ресурса понять, кто свой, а кто чужой?
Некоторые сервисы предоставляют демонстрационную нагрузку вообще без регистрации, а это может означать, что владелец какого-нибудь «ущербного» ботнета из 50-100 зомби с помощью таких сервисов может в сотни раз увеличить эффективность DDoS-атаки. Один бот генерирует 10 независимых запросов на нагрузочное тестирование в различные веб-сервисы. Те, в свою очередь, независимо друг от друга инициируют сотни запросов. Результат: целевой ресурс задыхается от объемов вполне «легитимного» трафика.
Что делать?
Как же можно избежать нелегитимного использования ресурсов сервиса нагрузочного тестирования? Для начала отметим, что владельцы подобных сервисов «умывают руки», снимая с себя всю ответственность в пользовательском соглашении:
«The Use of the Service and the ability to produce accurate and effective results from it highly depends on the User’s expertise in operating the Service. Therefore, You shall be responsible for ensuring that you are competent to write the scripts required to receive optimal results from the Service…»
Другими словами: вы несете ответственность за все, что вы делаете.
Однако избежать неправомерного использования данных сервисов все же можно. Для этого каждый сервис нагрузочного тестирования должен запрашивать согласие на тест от владельца тестируемой системы. Например, можно просить его разместить какой-нибудь уникальный код или специальный баннер на тестируемом веб-ресурсе, только после чтения которого будет произведена нагрузка. В дополнение к этому можно использовать CAPTCHA при работе с сервисом. Подобные процедуры верификации заметно усложнят процесс отправки автоматизированных запросов для генерации нагрузки, которые могут осуществлять роботы.
Хакер #175
