Нагрузочное тестирование как метод предупреждения DDOS атак.

В последнее время все больше компаний приходят к заключению что безопасность интернет проекта не пустая фраза. И одной из важных задач которые приходится решать на этапе внедрения проэкта это нагрузочное тестирование. Нагрузочное тестирование направлено на анализ работы сайта и определение на сколько сайт будет живуч в реальных условиях. В том числе под воздействием различных атак на отказ в обслуживании (DDOS атак). Ранее на страницах нашего сайта мы рассказывали о Концепции краудсорсинга в вопросах защиты от ДДОС-атак.

Сегодня мы подробнее остановимся на более расширенных практиках нагрузочного тестирования интернет сайтов.

Сейчас все больше заказчиков обращаются не только за тестированием на проникновение, но и за проверкой устойчивости их сервисов к атакам на отказ в обслуживании, чаще всего — веб-сайтов. И на нашей практике пока не было ни одного случая, чтобы реальный работающий сайт (не заранее подготовленная площадка) не вышел из строя, в т.ч. находящийся под разными защитными системами. И этот пост — резюмирование текущего опыта DDoS тестирования разными методами совершенно разных инфраструктур (от банков до типичных корпоративных сайтов).
Итак, давайте еще раз. Задача — вывести ресурс из строя любыми доступными методами, будь мы злоумышленниками. В 99% в качестве исходных данных дается домен/IP.

Как проходит работа?

  • Для начала выбирается методика тестирования и согласовывается с заказчиком. Выбор состоит из:
  • Атаки на канал (достигнуть максимальной пропускной способности);
  • Атаки на сетевые сервисы (slow http, использование эксплойтов для ддоса определенных веб-серверов, атаки на SSL, другие техники);
  • И самое крутое и интересное — атака на application уровень (использование особенностей работы данного приложения).
  • Согласовывается время, мощность, собирается скайп-чат в нужное время и там уже согласовываются все действия.

А теперь о каждой из методик.

Атака на канал

Или атака в лоб. Задача — забить канал сервера и привести к его недоступности для легитимных клиентов. В реальности атакующие используют разные техники — от реальных ботнетов до атак через публичные dns/ntp сервера. Что же мы делаем? На Хабре была статья — Миллион одновременных соединений на Node.js. Отличная идея — использовать облако Амазона! Добавляем несколько своих тулз для генерирования трафика в образ/ставим после запуска на ноды и получаем свой мини бот-нет со 100 мбит карточками на борту! В итоге количеством нод мы можем регулировать атаку и ударить по цели с разных регионов мира (так как Амазон предоставляет сервера в разных странах), достигая атаку в несколько гигабит (большинство реальных атак по скорости < 1 ГБит/с, судя по разным статистикам). На практике — то вся стойка у хостера отвалится, то еще что-нибудь. Ответственность за работу с хостером берёт на себя заказчик (предупредить, что будет тестирование и т.п.). Был опыт тестирования серверов и под разными защитами от подобных атак, например сервисами, подобных CloudFlare.

Схема работы CloudFlare и многих других сервисов по защите против DDoS’а

И на практике — они действительно обеспечивают защиту. Сайт как работал, так и работает. Но сервера под защитой встречаются о-о-о-очень редко. Но всё равно стоит помнить, что было при использовании dns/ntp серверов. От таких мощностей не то что сервису по защите от DDoS’а станет плохо, но порой и самим точкам обмена трафиком.

Атаки на сетевые сервисы

Суть — положить именно сам сетевой сервис (веб-сервер, прокси, балансировщик, еще что-то, смотрящее наружу) любым способом. Конечно же, первое, что приходит на ум — slow http! О котором не раз писалось на хабре. Попробую объяснить суть в пару предложений на примере Slow POST: отсылаем http запрос, указывая большой content-length и медленно передаем всего по одному байту, обрывая на одном из моментов свой коннект и начиная новый. По стандарту, сервер должен дождаться полной отправки данных (полной — получив содержимое в Content-Length байт), прервав только по таймауту. Всё! Сервер открывает тучу коннектов, расходует ресурсы (чаще всего — количество открытых файловых дескрипторов в системе) и ложится. Тот же апач падает за одну две-секунды. В домашних условиях можно скачать тулзу с OWASP.

OWASP HTTP Post Tool

По подобной же схеме, в случае SSL сервера, пробуется атака на «медленный SSL» (очень медленно получаем SSL сертификат). Также флуд на порт, если есть возможность — эксплойт для самого веб-сервера. И делать это всё так же можно с нод, сервер может просто не обслужить такое количество соединений (даже легитимных).
Кстати, из практики. Один раз столкнулись с тем, что на тестируемом объекте был установлен Microsoft Forefront и мы пробовали slow http. И он её успешно отбил — в логах было.

The number of denied TCP and non-TCP packets per second exceeded the system limit. As a result, Forefront TMG reduced the number of records of denied packets that are written in the log.
One or many zombie hosts may be attempting an attack against a victim server, but Forefront TMG policy blocks the attack traffic.
See the product documentation for more information about Forefront TMG flood mitigation.

Но позже все равно лёг от атаки на канал. Здесь методов решения «на дому» много, все зависит от атаки. Кстати, методы защиты с примерами скриптов и конфигов описано в русской статье Википедии про DoS (а ванглийской — только теория).

Атака на application уровень

Суть в том, чтобы найти особенности работы данного приложения и через них положить сервер. Никакие защиты, балансировщики, внешние сервисы не спасают от такого. Что я имею ввиду? Различные «тяжелые» запросы, например выборка больших объемов данных. По одному совершенно легитимному запросу с пары десятков машин — и «приехали». Естественно, такие места проще найти если тестирование на DoS в рамках пентеста и есть время изучить приложение.

В качестве реальных примеров:

  • ZIP бомбы (42 кб архив в 8.5 петабайт)
  • XML бомбы — en.wikipedia.org/wiki/Billion_laughs (если есть XXE, но нельзя подключать внешние сущности, только внутренняя пересылка)
  • Как говорил — просто очевидно большая выборка данных
  • Parameter tampering при выборке различных данных (например сказано, что можно выбрать 100 товаров, а мы вручную меняем HTTP запрос и выбираем 999999+ товаров)
  • Функционал поиска
  • Другие специфичные случаи, например Django и смена пароля

В основном, конечно, все это направлено на атаку бэкенда (пост обработка данных, база данных), но проблема в том, что какой-то универсальной защиты от этого нет, и нужны админы/программисты/люди из безопасности на анализ ситуации и её исправление. Бывает так, что проблему вообще нельзя решить, не пересмотрев архитектуру и тогда начинаются костыли (хорошо, что если вообще возможны).

Заключение:

Тестирование на отказ в обслуживании может выявить неявные проблемы в архитектуре, от которых не спастись внешними сервисами по защите от DoS, конфигами, новыми правилами в iptables и т.д. и стоит данному виду тестирования уделять должное внимание.

Рейтинг материала
[Голосов: 0 Рейтинг: 0]
24 декабря 2015, 10:56

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *