Кратко

  • Клиент открывал поток HTTP/2 и почти сразу отправлял RST_STREAM. Поток освобождал место в лимите одновременности, хотя прокси или приложение могли продолжать уже начатую работу.
  • Эффективная защита стала учитывать накопленное поведение соединения: распознавать аномальный цикл, отправлять GOAWAY или закрывать канал, сохраняя нормальную отмену для обычных клиентов.

Поток закрыт, затраты живы

HTTP/2 мультиплексирует множество запросов в одном соединении. Клиент может отменить ненужный поток с помощью RST_STREAM: это необходимо при переходе на другую страницу, устаревшем поиске или уже полученном ответе. CVE-2023-44487 возникла из сочетания двух штатных возможностей, а не из малоизвестного расширения.

Протокол ограничивает число активных потоков одновременно. Закрытый поток перестаёт занимать место. В Rapid Reset злоумышленник отправлял HEADERS, запускал запрос и тут же сбрасывал поток. Освободившийся слот немедленно использовался снова. Для протокольного автомата запрос закончился; для маршрутизации, распаковки, журналирования, приложения или базы данных работа могла только начинаться.

Настоящий долг не был виден в счётчике открытых потоков. Он состоял из начатой, но ещё не остановленной или не завершённой работы. Одно соединение могло создавать такой долг быстрее, чем система возвращала ресурсы.

Три пика, которые нельзя складывать

Google сообщил об атаке свыше 398 миллионов запросов в секунду. Cloudflare наблюдала пик свыше 201 миллиона запросов в секунду от ботнета примерно из 20 тысяч машин. AWS описала события свыше 155 миллионов запросов в секунду 28 и 29 августа.

Это отдельные наблюдения разных провайдеров, а не части одной суммы. Вместе они показывают смену масштаба: повторное использование соединений и слишком раннее списание работы увеличили отдачу от каждого заражённого устройства.

Публикации также не доказывают одинаковую уязвимость всех реализаций HTTP/2. Различались точки завершения, цепочки прокси, очереди и правила отмены. Урок глобален, а конкретный путь ущерба и исправления остаётся локальным.

Счётчик отвечал не на тот вопрос

Лимит одновременности спрашивает, сколько потоков открыто сейчас. Операционная модель должна спрашивать больше: сколько потоков соединение создало за всё время, сколько мгновенно отменило, какая работа пережила отмену и когда процессор, память и backend действительно освободились.

Опыт Cloudflare с уменьшением MAX_CONCURRENT_STREAMS до 64 показал побочный эффект одномерного решения. Некоторые законные клиенты до получения настроек сервера оптимистично предполагали лимит 100. Серверные сбросы лишних потоков встретились с прежней защитой, считавшей resets, и вызвали ошибки страниц. Компания вернула значение 100.

Лимит одновременности полезен, но не является полной моделью затрат. Мера должна доказать в рабочей среде, что она сохраняет обычную отмену и не даёт одному соединению бесконечно обновлять долг.

Ответственность переходит к соединению

Google описал быстрое выявление шаблона на уровне соединения с последующим GOAWAY или закрытием канала. Cloudflare добавила обнаружение клиентских resets и работу над очередями, планированием, отменой и журналированием, а ранняя защита действовала в TLS-прокси. Общий принцип важнее деталей: единичный reset допустим, накопленная последовательность может доказывать злоупотребление.

Закрытие соединения меняет экономику. Атакующий теряет дешёвый канал для постоянного открытия и стирания потоков. Новое подключение требует состояния и снова проходит классификацию. Обычный пользователь сохраняет редкую отмену; отзывается лишь возможность повторять её без предела, оставляя всё больше работы.

Так действует приоритет работающего кода. Протокол задаёт общие состояния, но именно реализация владеет очередями, CPU, памятью и зависимостями. Поэтому она должна иметь локальное право завершить соединение, которое угрожает её ресурсам.

Что определяет стандарт

RFC 9113 описывает состояния потоков, RST_STREAM, GOAWAY и предел одновременности. Она не обещает, что reset мгновенно устранит каждый внутренний эффект. Продолжается ли работа в прокси, сервисе или базе данных, знает только конкретный рабочий путь.

Позднейший индивидуальный Internet-Draft предложил накопительные кредиты потоков, чтобы быстро закрытые потоки всё равно учитывались на протяжении жизни соединения. Диагноз полезен, но документ не является принятым стандартом или консенсусом IETF. Это один вариант конструкции.

Минимальная спецификация должна удерживать совместимую семантику. Локальная реализация должна измерять собственную стоимость и решать, когда сотрудничество стало небезопасным. Смешение уровней либо требует от стандарта управлять невидимыми очередями, либо создаёт грубую защиту, ломающую нормальных клиентов.

Что должно быть в реестре исправлений

Фразы «патч установлен» недостаточно. Оператору нужно знать, где завершается HTTP/2, куда передаётся запрос и где отмена действительно останавливает работу. Обновлённый балансировщик не спасает, если внутренний прокси продолжает бесконечно принимать осиротевшие задачи.

Для каждой точки завершения нужны версия, накопленная скорость потоков, отношение открытий к resets, оставшаяся после reset работа и компонент с правом закрыть соединение. Испытания должны включать законную отмену, а не только атаку. Защита, которая отбрасывает оба вида трафика, не является точной.

Пределы доказательств

Публичные сведения в основном принадлежат крупным провайдерам и описывают их системы. Они подтверждают механизм, заявленные пики и ряд мер, но не измеряют долю уязвимого интернета и не доказывают универсальность одного порога. Отмена сама по себе не становится вредоносной.

Надёжный вывод уже: конец протокольного объекта не гарантирует конца его стоимости. Мультиплексированная система должна относить оставшийся долг к каналу, который его породил.

Источники

  1. Cloudflare, “HTTP/2 Rapid Reset: deconstructing the record-breaking attack”: https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/
  2. Google Cloud, “How it works: The novel HTTP/2 ‘Rapid Reset’ DDoS attack”: https://cloud.google.com/blog/products/identity-security/how-it-works-the-novel-http2-rapid-reset-ddos-attack?hl=en
  3. Google Cloud, “Google mitigated the largest DDoS attack to date”: https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps
  4. AWS Security Blog, “How AWS protects customers from DDoS events”: https://aws.amazon.com/blogs/security/how-aws-protects-customers-from-ddos-events/
  5. AWS Security Bulletin AWS-2023-011: https://aws.amazon.com/security/security-bulletins/AWS-2023-011/
  6. IETF, RFC 9113, “HTTP/2”: https://www.rfc-editor.org/rfc/rfc9113.html
  7. IETF Internet-Draft, “Cumulative Stream Limits for HTTP/2”: https://datatracker.ietf.org/doc/html/draft-thomson-httpbis-h2-stream-limits-00
  8. Heng Lu, “Running-Code Primary”: https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
  9. Heng Lu, “Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption”: https://heng.lu/minimum-initial-specification-localized-future-decision-and-voluntary-adoption-for-internet-coordination-systems/