Статья описывает новый вид DDoS-атаки, затронувшей сервисы Google. Такие атаки отличаются увеличенным масштабом и основаны на быстром сбросе потоков протокола HTTP/2. Здесь мы разбираем варианты атаки Rapid Reset и меры смягчения, а также предлагаем стратегии для минимизации рисков.
Ряд сервисов Google и клиентов Cloud недавно подверглись новой DDoS-атаке на основе HTTP/2, пик которой пришелся на август. Атаки были значительно масштабнее, чем любые ранее зарегистрированные DDoS-атаки на уровне приложений (Layer 7 согласно уровням модели OSI), причем самая крупная атака превысила 398 миллионов запросов в секунду .
Атаки были остановлены на границе сети глобальной инфраструктурой балансировки нагрузки Google и не привели к каким-либо сбоям в работе. Хотя воздействие было минимальным, группа реагирования на DDoS-атаки Google рассмотрела их и добавила дополнительные средства защиты для дальнейшего смягчения подобных атак.
В этой статье мы объясним методологию атак уровня 7 за последние несколько лет, что изменилось в новых атаках, что сделало их более масштабными, а также эффективные стратегии смягчения подобного типа атак.
Статья написана с точки зрения архитектуры обратного прокси-сервера, в которой HTTP-запрос завершается обратным прокси-сервером, пересылающим запросы другим службам. Те же концепции применимы к HTTP-серверам, интегрированным в сервер приложений, но с несколько иными соображениями, которые потенциально могут привести к различным стратегиям снижения риска.
Одним из основных ограничений при организации DoS-атаки уровня 7 является количество одновременных транспортных соединений. Каждое соединение требует затрат, включая память операционной системы для записей сокетов и буферов, время процессора для подтверждения TLS-рукопожатия, а также то, что для каждого соединения требуется уникальный набор из четырёх элементов (four-tuple) – комбинация IP-адресов (отправитель и получатель) и пара портов (отправитель и получатель). Ограничение количества уникальных four-tuple наборов влияет на то, сколько одновременных соединений может быть установлено между двумя IP-адресами.
В версии HTTP/1.1 запросы обрабатываются по очереди: сервер получает запрос, обрабатывает его, отправляет ответ, и только после этого переходит к следующему запросу. Это значит, что скорость отправки запросов через одно соединение ограничивается временем, необходимым для обработки каждого запроса и временем передачи данных через сеть. Хотя есть технология «конвейерной обработки» в HTTP/1.1, которая может ускорить обработку запросов, она не широко используется в обычных клиентских приложениях.
С помощью HTTP/2 клиент может открывать несколько одновременных потоков в одном TCP-соединении, причем каждый поток соответствует одному HTTP-запросу.
Максимальное количество одновременных открытых потоков теоретически контролируется сервером, но на практике клиенты могут открывать 100 потоков на один запрос, и серверы обрабатывают эти запросы параллельно. Важно отметить, что лимиты сервера не могут быть изменены в одностороннем порядке.
Например, клиент может открыть 100 потоков и отправить запрос по каждому из них за один проход; прокси-сервер будет читать и обрабатывать каждый поток последовательно, но запросы к внутренним серверам снова можно распараллелить. Затем клиент может открывать новые потоки по мере получения ответов на предыдущие. Это обеспечивает эффективную пропускную способность для одного соединения, равную 100 запросам за один проход, с константами времени прохождения туда и обратно, аналогичными запросам HTTP/1.1. Обычно это приводит к почти 100-кратному увеличению использования каждого соединения.
Атака называется Rapid Reset, поскольку она основана на способности конечной точки отправить кадр RST_STREAM сразу после отправки кадра запроса, что заставляет другую конечную точку начать работу, а затем быстро сбрасывает запрос. Запрос отменяется, но соединение HTTP/2 остается открытым.
Шаблон запроса и ответа HTTP/1.1 и HTTP/2
Атака HTTP/2 Rapid Reset достаточно проста: клиент открывает большое количество потоков одновременно, как и в стандартной атаке HTTP/2, но вместо того, чтобы ждать ответа на каждый поток запроса от сервера или прокси, клиент немедленно отменяет каждый запрос.
Возможность быстрого сброса потоков позволяет каждому соединению иметь неопределенное количество запросов в процессе. Явно отменяя запросы, злоумышленник никогда не превышает ограничение на количество одновременных открытых потоков. Количество текущих запросов больше не зависит от времени приема-передачи (round-trip time, RTT), а только от доступной пропускной способности сети.
В типичной реализации сервера HTTP/2 серверу по-прежнему придется выполнять значительный объем работы для отмененных запросов, например выделять новые структуры данных потока, анализировать запрос и выполнять распаковку заголовка, а также сопоставлять URL-адрес с ресурсом. Для реализаций обратного прокси-сервера запрос может быть передан на внутренний сервер до обработки кадра RST_STREAM. С другой стороны, клиент практически не платил за отправку запросов. Это создает полезную асимметрию затрат между сервером и клиентом.
Еще одно преимущество, которое получает злоумышленник, заключается в том, что явная отмена запросов сразу после создания означает, что обратный прокси-сервер не будет отправлять ответ ни на один из запросов. Отмена запросов до записи ответа уменьшает пропускную способность нисходящей линии связи (сервер/прокси-сервер для злоумышленника).
Первый вариант не отменяет потоки моментально, а открывает сразу пакет потоков, ждет некоторое время, затем отменяет потоки и сразу открывает еще один большой пакет новых потоков. Такая атака может обойти средства защиты, основанные только на скорости входящих кадров RST_STREAM (например, разрешать не более 100 RST_STREAM в секунду для соединения перед его закрытием). Подобные атаки не позволяют максимизировать использование соединения, но все же имеют некоторую эффективность по сравнению со стандартными DDoS-атаками HTTP/2.
Второй вариант полностью отказывается от отмены потоков и вместо этого пытается открыть больше одновременных потоков, чем заявлено сервером. Преимущество подхода по сравнению со стандартной DDoS-атакой HTTP/2 заключается в том, что клиент может постоянно поддерживать поток запросов полным.
Спецификация предполагает, что попытка открыть слишком много потоков должна аннулировать только те потоки, которые превысили лимит, а не всё соединение. Отметим, что большинство серверов HTTP/2 не будут обрабатывать эти потоки, и поэтому можно использовать второй вариант атаки, почти сразу принимая и обрабатывая новый поток после ответа на предыдущий поток.
RFC определяет процесс корректного закрытия соединения, который включает в себя сначала отправку информационного сообщения GOAWAY, не устанавливающего ограничения на открытие новых потоков, а затем отправку туда и обратно другого сообщения, запрещающего открытие дополнительных потоков.
Однако описанный процесс обычно не реализуется так, чтобы обеспечить защиту от вредоносных клиентов. Эта мера делает соединение уязвимым для атак Rapid Reset на слишком долгое время, и ее не следует использовать для смягчения, поскольку она не останавливает входящие запросы. Вместо этого следует настроить GOAWAY для немедленного ограничения создания потока.
Меры по смягчению последствий этого вектора атаки могут принимать различные формы, но в основном они сосредоточены на отслеживании статистики соединений и использовании различных сигналов и бизнес-логики для определения того, насколько полезно каждое соединение. Например, если соединение имеет более 100 запросов, причем более 50% из них отменены, то тут необходимо принять меры по снижению угрозы, которые могут варьироваться от принудительных кадров GOAWAY до немедленного закрытия TCP-соединения.
Чтобы защититься от второго варианта атаки (без отмены потоков), серверам HTTP/2 необходимо закрывать соединения, которые превышают ограничение одновременного потока. Это может произойти либо сразу, либо после небольшого количества повторных правонарушений.
Ряд сервисов Google и клиентов Cloud недавно подверглись новой DDoS-атаке на основе HTTP/2, пик которой пришелся на август. Атаки были значительно масштабнее, чем любые ранее зарегистрированные DDoS-атаки на уровне приложений (Layer 7 согласно уровням модели OSI), причем самая крупная атака превысила 398 миллионов запросов в секунду .
Атаки были остановлены на границе сети глобальной инфраструктурой балансировки нагрузки Google и не привели к каким-либо сбоям в работе. Хотя воздействие было минимальным, группа реагирования на DDoS-атаки Google рассмотрела их и добавила дополнительные средства защиты для дальнейшего смягчения подобных атак.
В этой статье мы объясним методологию атак уровня 7 за последние несколько лет, что изменилось в новых атаках, что сделало их более масштабными, а также эффективные стратегии смягчения подобного типа атак.
Статья написана с точки зрения архитектуры обратного прокси-сервера, в которой HTTP-запрос завершается обратным прокси-сервером, пересылающим запросы другим службам. Те же концепции применимы к HTTP-серверам, интегрированным в сервер приложений, но с несколько иными соображениями, которые потенциально могут привести к различным стратегиям снижения риска.
Введение в HTTP/2 для защиты от DDoS
С конца 2021 года большинство DDoS-атак уровня 7 были основаны на HTTP/2, как по количеству атак, так и по пиковой частоте запросов. Основной целью разработки HTTP/2 была эффективность, и функции, которые делают HTTP/2 более эффективным для приложений, также могут использоваться для повышения эффективности DDoS-атак.Мультиплексирование потоков
HTTP/2 использует «потоки», двунаправленные абстракции, используемые для передачи различных сообщений или «кадров» между конечными точками. Мультиплексирование потоков — это основная функция HTTP/2, которая позволяет более эффективно использовать каждое TCP-соединение. Потоки мультиплексируются таким образом, что их можно отслеживать с обеих сторон соединения, используя только одно соединение уровня 4 (транспортный уровень). Мультиплексирование потоков позволяет клиентам иметь несколько текущих запросов без управления несколькими отдельными соединениями.Одним из основных ограничений при организации DoS-атаки уровня 7 является количество одновременных транспортных соединений. Каждое соединение требует затрат, включая память операционной системы для записей сокетов и буферов, время процессора для подтверждения TLS-рукопожатия, а также то, что для каждого соединения требуется уникальный набор из четырёх элементов (four-tuple) – комбинация IP-адресов (отправитель и получатель) и пара портов (отправитель и получатель). Ограничение количества уникальных four-tuple наборов влияет на то, сколько одновременных соединений может быть установлено между двумя IP-адресами.
В версии HTTP/1.1 запросы обрабатываются по очереди: сервер получает запрос, обрабатывает его, отправляет ответ, и только после этого переходит к следующему запросу. Это значит, что скорость отправки запросов через одно соединение ограничивается временем, необходимым для обработки каждого запроса и временем передачи данных через сеть. Хотя есть технология «конвейерной обработки» в HTTP/1.1, которая может ускорить обработку запросов, она не широко используется в обычных клиентских приложениях.
С помощью HTTP/2 клиент может открывать несколько одновременных потоков в одном TCP-соединении, причем каждый поток соответствует одному HTTP-запросу.
Максимальное количество одновременных открытых потоков теоретически контролируется сервером, но на практике клиенты могут открывать 100 потоков на один запрос, и серверы обрабатывают эти запросы параллельно. Важно отметить, что лимиты сервера не могут быть изменены в одностороннем порядке.
Например, клиент может открыть 100 потоков и отправить запрос по каждому из них за один проход; прокси-сервер будет читать и обрабатывать каждый поток последовательно, но запросы к внутренним серверам снова можно распараллелить. Затем клиент может открывать новые потоки по мере получения ответов на предыдущие. Это обеспечивает эффективную пропускную способность для одного соединения, равную 100 запросам за один проход, с константами времени прохождения туда и обратно, аналогичными запросам HTTP/1.1. Обычно это приводит к почти 100-кратному увеличению использования каждого соединения.
Атака HTTP/2 Rapid Reset
Протокол HTTP/2 позволяет клиентам указывать серверу, что предыдущий поток следует отменить, отправив кадр RST_STREAM. Протокол не требует от клиента и сервера каким-либо образом согласовывать отмену, клиент может сделать это в одностороннем порядке. Клиент также может предположить, что отмена вступит в силу немедленно, когда сервер получит кадр RST_STREAM, прежде чем будут обработаны любые другие данные из этого TCP-соединения.Атака называется Rapid Reset, поскольку она основана на способности конечной точки отправить кадр RST_STREAM сразу после отправки кадра запроса, что заставляет другую конечную точку начать работу, а затем быстро сбрасывает запрос. Запрос отменяется, но соединение HTTP/2 остается открытым.
Шаблон запроса и ответа HTTP/1.1 и HTTP/2
Атака HTTP/2 Rapid Reset достаточно проста: клиент открывает большое количество потоков одновременно, как и в стандартной атаке HTTP/2, но вместо того, чтобы ждать ответа на каждый поток запроса от сервера или прокси, клиент немедленно отменяет каждый запрос.
Возможность быстрого сброса потоков позволяет каждому соединению иметь неопределенное количество запросов в процессе. Явно отменяя запросы, злоумышленник никогда не превышает ограничение на количество одновременных открытых потоков. Количество текущих запросов больше не зависит от времени приема-передачи (round-trip time, RTT), а только от доступной пропускной способности сети.
В типичной реализации сервера HTTP/2 серверу по-прежнему придется выполнять значительный объем работы для отмененных запросов, например выделять новые структуры данных потока, анализировать запрос и выполнять распаковку заголовка, а также сопоставлять URL-адрес с ресурсом. Для реализаций обратного прокси-сервера запрос может быть передан на внутренний сервер до обработки кадра RST_STREAM. С другой стороны, клиент практически не платил за отправку запросов. Это создает полезную асимметрию затрат между сервером и клиентом.
Еще одно преимущество, которое получает злоумышленник, заключается в том, что явная отмена запросов сразу после создания означает, что обратный прокси-сервер не будет отправлять ответ ни на один из запросов. Отмена запросов до записи ответа уменьшает пропускную способность нисходящей линии связи (сервер/прокси-сервер для злоумышленника).
Варианты атаки HTTP/2 Rapid Reset
В течение нескольких недель после первых DDoS-атак было обнаружено несколько вариантов атак Rapid Reset. Они не так эффективны, как первоначальная версия, но все же могут быть более эффективными, чем стандартные DDoS-атаки HTTP/2.Первый вариант не отменяет потоки моментально, а открывает сразу пакет потоков, ждет некоторое время, затем отменяет потоки и сразу открывает еще один большой пакет новых потоков. Такая атака может обойти средства защиты, основанные только на скорости входящих кадров RST_STREAM (например, разрешать не более 100 RST_STREAM в секунду для соединения перед его закрытием). Подобные атаки не позволяют максимизировать использование соединения, но все же имеют некоторую эффективность по сравнению со стандартными DDoS-атаками HTTP/2.
Второй вариант полностью отказывается от отмены потоков и вместо этого пытается открыть больше одновременных потоков, чем заявлено сервером. Преимущество подхода по сравнению со стандартной DDoS-атакой HTTP/2 заключается в том, что клиент может постоянно поддерживать поток запросов полным.
Спецификация предполагает, что попытка открыть слишком много потоков должна аннулировать только те потоки, которые превысили лимит, а не всё соединение. Отметим, что большинство серверов HTTP/2 не будут обрабатывать эти потоки, и поэтому можно использовать второй вариант атаки, почти сразу принимая и обрабатывая новый поток после ответа на предыдущий поток.
Многогранный подход к смягчению последствий
Простая блокировка отдельных запросов не защитит от атак Rapid Reset. Поэтому при обнаружении злоупотреблений необходимо закрыть TCP-соединение. HTTP/2 обеспечивает встроенную поддержку закрытия соединений с использованием типа кадра GOAWAY.RFC определяет процесс корректного закрытия соединения, который включает в себя сначала отправку информационного сообщения GOAWAY, не устанавливающего ограничения на открытие новых потоков, а затем отправку туда и обратно другого сообщения, запрещающего открытие дополнительных потоков.
Однако описанный процесс обычно не реализуется так, чтобы обеспечить защиту от вредоносных клиентов. Эта мера делает соединение уязвимым для атак Rapid Reset на слишком долгое время, и ее не следует использовать для смягчения, поскольку она не останавливает входящие запросы. Вместо этого следует настроить GOAWAY для немедленного ограничения создания потока.
Меры по смягчению последствий этого вектора атаки могут принимать различные формы, но в основном они сосредоточены на отслеживании статистики соединений и использовании различных сигналов и бизнес-логики для определения того, насколько полезно каждое соединение. Например, если соединение имеет более 100 запросов, причем более 50% из них отменены, то тут необходимо принять меры по снижению угрозы, которые могут варьироваться от принудительных кадров GOAWAY до немедленного закрытия TCP-соединения.
Чтобы защититься от второго варианта атаки (без отмены потоков), серверам HTTP/2 необходимо закрывать соединения, которые превышают ограничение одновременного потока. Это может произойти либо сразу, либо после небольшого количества повторных правонарушений.
