Иногда сайт начинает вести себя так, будто на него идет сильная DDoS-атака: страницы открываются медленно, API отвечает с задержкой, в логах появляются ошибки 502 или 503, а процессы веб-сервера резко потребляют больше памяти. Но при этом нет огромного потока запросов, канал не забит, а нагрузка может идти от небольшого количества соединений. Так работает HTTP/2 Bomb. Это DoS-атака на HTTP/2 – протокол, через который сайт или приложение обменивается данными с сервером. Атакующий отправляет сравнительно небольшой объем данных, но заставляет сервер тратить значительно больше памяти на их обработку. В результате веб-сервер или прокси может зависнуть, начать использовать диск вместо оперативной памяти, перезапустить процессы или перестать нормально обслуживать обычных пользователей.
Опасность в том, что HTTP/2 часто включен по умолчанию. Его используют для сайтов на HTTPS, API, CDN, балансировщиков, обратных прокси и входных шлюзов в контейнерной инфраструктуре. Владелец сайта может не настраивать HTTP/2 вручную, но все равно иметь его на входе.
Как работает HTTP/2 Bomb
В HTTP/2 есть механизм сжатия заголовков HPACK. Заголовки – это служебные данные запроса: cookies, host, user-agent, authorization и другие поля. Проще говоря, это дополнительная информация, которую браузер или приложение передает вместе с запросом к серверу.
Чтобы не передавать одинаковую информацию много раз, HTTP/2 может сохранять ее во внутренней таблице и дальше использовать короткие ссылки. В обычной работе это ускоряет обмен данными. Но в атаке эта особенность становится проблемой.
Небольшой запрос после распаковки и внутренней обработки может превратиться для сервера в большое количество объектов в памяти. Если таких потоков много и они долго не завершаются, память не освобождается вовремя.
То есть HTTP/2 Bomb опасен не только размером заголовков. Проблема в том, сколько внутренних структур создает сервер и как долго он их удерживает. Именно поэтому атака может быть незаметной на уровне сетевого трафика, но очень ощутимой для оперативной памяти и стабильности сервиса.
Кто попадает в зону риска
Риск есть у серверов и прокси, которые принимают HTTP/2-соединения и не имеют достаточно жестких ограничений на количество заголовков, cookie-фрагментов и зависших потоков. В зоне внимания – nginx, Apache HTTPD с mod_http2, Microsoft IIS, Envoy, Cloudflare Pingora и другие реализации HTTP/2 в стандартных или устаревших конфигурациях.
Проверять нужно не только основной веб-сервер. Во многих проектах HTTP/2 завершается на CDN, балансировщике, обратном прокси, входном шлюзе Kubernetes или промежуточном сервисном слое. Если именно этот уровень уязвим или неправильно настроен, атака ударит по нему, даже если приложение за ним работает нормально.
В первую очередь стоит проверить:
- VPS и выделенные серверы с nginx или Apache;
- сайты и API с включенным HTTP/2;
- входные шлюзы Kubernetes, Envoy Gateway, service mesh;
- серверы без ограничений на использование памяти;
- инфраструктуру, где один прокси обслуживает много сайтов;
- панели управления, CRM, личные кабинеты и внутренние сервисы.
Главный вопрос простой: какой компонент принимает HTTP/2-запросы из интернета и обновлен ли он до безопасной версии.
Как понять, что проблема может быть в HTTP/2
HTTP/2 Bomb не всегда выглядит как классическая атака. Может не быть тысяч IP-адресов, большого трафика или очевидного всплеска запросов. Чаще это похоже на внезапную утечку памяти.
Типичные признаки:
- быстро растет потребление памяти у nginx, Apache, Envoy или IIS;
- сервер начинает использовать диск как резерв для оперативной памяти;
- увеличивается количество долгих HTTP/2-соединений;
- появляются ошибки 502, 503, 504;
- рабочие процессы веб-сервера перезапускаются или завершаются из-за нехватки памяти;
- в контейнерной инфраструктуре часто перезапускаются отдельные сервисы;
- ответы сайта замедляются, хотя трафик не выглядит аномальным.
Для первичной проверки не нужно запускать эксплойты. Достаточно посмотреть фактические версии пакетов, проверить, включен ли HTTP/2 на HTTPS-входе, и просмотреть лимиты на заголовки, время ожидания соединений и использование памяти.
Как исправить HTTP/2 Bomb
Основной способ защиты – обновить компонент, который принимает HTTP/2. Для nginx нужно проверить возможность обновления до версии 1.29.8 или новее, где появился лимит max_headers. Он ограничивает количество заголовков, которые сервер готов обрабатывать в одном запросе.
Для Apache важно смотреть не только общую версию httpd, но и модуль mod_http2. Именно он отвечает за обработку HTTP/2. Поэтому обновление только части системы может не решить проблему.
Для Envoy нужно проверить релизную ветку и параметры, связанные с количеством и размером заголовков, в частности max_headers_count и лимиты на заголовки запроса. Это особенно важно для Kubernetes и service mesh, где Envoy часто стоит перед приложениями незаметно для владельца сайта.
Если быстро обновиться невозможно, временный вариант – отключить HTTP/2 на уязвимом входе. Для обычного сайта это может быть приемлемым компромиссом. Но если используются gRPC, мобильные приложения или сервисы, которые зависят от HTTP/2, такое решение нужно тестировать осторожно.
Что настроить для профилактики
Обновление закрывает конкретную уязвимость, но сервер все равно должен быть защищен лимитами. HTTP/2 нельзя оставлять без контроля, потому что небольшой запрос на уровне сети может дорого стоить на уровне памяти.
Для профилактики стоит настроить:
- ограничение количества заголовков в запросе;
- лимиты на общий размер заголовков;
- корректный учет cookie-фрагментов;
- время ожидания для неактивных или зависших HTTP/2-потоков;
- ограничение памяти для процессов, контейнеров и отдельных сервисов;
- мониторинг памяти, ошибок 5xx и перезапусков сервисов.
Отдельно стоит проверить цепочку CDN → прокси → веб-сервер → приложение. Защита должна быть на том уровне, где фактически завершается HTTP/2. Если CDN принимает HTTP/2, но дальше передает HTTP/2 на основной сервер, слабое место может оставаться внутри вашей инфраструктуры.
Что сделать владельцу сайта сейчас
Сначала нужно определить, включен ли HTTP/2 и какой именно компонент его обрабатывает. Это может быть nginx, Apache, Envoy, IIS, CDN, балансировщик или входной шлюз. Затем проверить версию этого компонента и наличие обновлений безопасности.
Дальше стоит явно настроить лимиты на заголовки, время ожидания соединений и использование памяти. Для большинства сайтов нет нормальной причины принимать тысячи заголовков в одном запросе или держать потоки открытыми бесконечно.
HTTP/2 Bomb – это не атака, которую можно остановить только более широким каналом или классическим сетевым фильтром. Она бьет по логике обработки запросов внутри сервера. Поэтому реальная защита состоит из трех вещей: обновленного веб-сервера или прокси, жестких HTTP/2-лимитов и контроля ресурсов. Это снижает риск, что несколько нестандартных соединений смогут положить сайт или весь сервер.
Добавить комментарий