Іноді сайт починає поводитися так, ніби на нього йде сильна 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-лімітів і контролю ресурсів. Це зменшує ризик, що кілька нестандартних з’єднань зможуть покласти сайт або весь сервер.
Залишити відповідь