19 марта 2014 в 18:01

Атаки на отказ в обслуживании: практика тестирования

Пост — резюме


Думаю, начать стоит с того, что в последнее время все больше заказчиков обращаются не только за тестированием на проникновение, но и за проверкой устойчивости их сервисов к атакам на отказ в обслуживании, чаще всего — веб-сайтов. И на нашей практике пока не было ни одного случая, чтобы реальный работающий сайт (не заранее подготовленная площадка) не вышел из строя, в т.ч. находящийся под разными защитными системами. И этот пост — резюмирование текущего опыта (D)DoS тестирования разными методами совершенно разных инфраструктур (от банков до типичных корпоративных сайтов).

image
Визуализация DDoS-атаки

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

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


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

Согласовывается время, мощность, собирается скайп-чат в нужное время и там уже согласовываются все действия.

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

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


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

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

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

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


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

image
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 и смена пароля

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

Conclusion


Тестирование на отказ в обслуживании может выявить неявные проблемы в архитектуре, от которых не спастись внешними сервисами по защите от DoS, конфигами, новыми правилами в iptables и т.д. и стоит данному виду тестирования уделять должное внимание.
Автор: @BeLove
Digital Security
рейтинг 221,72
Безопасность как искусство

Комментарии (15)

  • +3
    Визуализация атаки очень красивая
    • +10

      Вообще это больше визуализатор логов, но тут и как ddos визуализация подойдет :)
      • +1
        Чем-то напоминает прохождение Арканоида в nightmare-режиме.
        • 0
          Скорее Pong.
      • 0
        Спасибо за визуализатор. Круто было бы его на логи доступа к диску натравить для анализа iops
    • +6
      Очень похоже на атаку охотников в Матрице)
      • +1
        На Expecto Patronum в одном из Гарри Поттеров)
  • +3
    Не все с Windows тестируют на slow POST уязвимость ;) Пользуясь случаем, передаю привет, а так же напоминаю о slowhttptest, который работает на маке/линуксе/цугвине, и симулирует все slow-type атаки.
  • 0
    > The number of denied TCP and non-TCP packets per second exceeded the system limit.

    Forefront, конечно, молодцом, но ведь такая защита элементарна в принципе. У меня то же делалость с помощью iptables, только не HTTP, а SIP, и для защиты не от DDOS, а от брутфорса (тогда в Asterisk ещё не было security-лога). Много подключений — пройдите в бан, не забанишь только спуфленые адреса, но с такими адресами дальше SYN-DDOS не пойдёшь.

    По-моему, всё сказано в первом абзаце: не подготовился — не отобьёшься. Наверное, тут есть ковбои-большие-яйцы, админящие чудовищно важные сервисы с кучей девяток, но в большинстве случаев час простоя стоит дешевле, чем год работы по подготовке ко всем возможным атакам (и ко всем ли мы подготовимся?).

  • 0
    > ZIP бомбы (42 кб архив в 8.5 петабайт)

    Ради интереса попробовал распаковать архив 7-zip'ом — получил 16 архивов. Оно само не должно дальше распаковываться? Надо еще каждый руками распаковывать? Может тогда и вирусы пусть в исходниках распространяются, будем компилировать и лечить.
    • +1
      Если сервер проверяет содержимое архивов, он проверяет все вложенные архивы.
  • –2
    собирается скайп-чат


    Специалисты по сетевой безопасности общающиеся через скайп-чат… Как мило :-)
  • 0
    Т.е. что, защититься в принципе невозможно, раз нет ни одного устоявшего? Или все же все будет упираться в стоимость атаки и защититься от большинства все же реально? Или ситуация как везде — защита поможет против «любителя», а от целенаправленной атаки не спасет ничего?
    • 0
      Если стоит задача «потушить ресурс», то нет разницы, где будет сбой.
      Забит канал => ресурс недоступен. Задача решена, даже если сервис защищен и код идеален.
      Следующий уровень — сервис http, балансировщики и прочее.
      Идеала нет, но можно комбинировать различные схемы и приемы защиты.
      Ну а уровень приложения, это отдельная песня.
      При определенном уровне упорства со стороны атакующих можно обеспечить недоступность сайта с вероятностью «много девяток».
      Но это не дает персоналу права делать халтурно свою работу ;)
    • 0
      Кто знает, думаю и встретим на практике тех, кто и устоит. Ведь это же и цель тестирования — проверить уязвим ли сервис к данному типу атаки или нет.
      Про последние вопросы — blog.cloudflare.com/understanding-and-mitigating-ntp-based-ddos-attacks. Кратко говоря — да, все чаще всего зависит от сумм и от желания найти профессионального исполнителя. Но абсолютной безопасности никто никогда и не дает, оно и логично. Но на определенный уровень все же можно вывести свою защиту, проводя подобные тестирования.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка