HTTP/2 Bomb چیست و چگونه FortiWeb 7.6 آن را مدیریت میکند
این مقاله حمله HTTP/2 Bomb با CVE-2026-49975 را تشریح میکند و نشان میدهد FortiWeb 7.6 چگونه با HTTP Protocol Constraints، DoS Protection، Server Policy و مانیتورینگ لاگ میتواند ریسک سرویسهای منتشرشده را کاهش دهد.
خلاصه تخصصی مقاله
این مقاله حمله HTTP/2 Bomb با CVE-2026-49975 را تشریح میکند و نشان میدهد FortiWeb 7.6 چگونه با HTTP Protocol Constraints، DoS Protection، Server Policy و مانیتورینگ لاگ میتواند ریسک سرویسهای منتشرشده را کاهش دهد.
موضوعات اصلی: پشتیبانی شبکه، HTTP، FortiWeb، Backend، Protection، Header
1. HTTP/2 Bomb چیست؟
HTTP/2 Bomb یکحملهResource Exhaustion است که بر مدیریت Header Compression، استریمها و Flow Control در HTTP/2 فشار میآورد. برخلاف حملات حجمی سنتی، هدف اصلی این حمله الزاماً پر کردن پهنای باند نیست؛ بلکه قصد دارد سرور را وادار به تخصیص حافظه و ساختارهای داخلی زیادی برای درخواستهای به ظاهر معتبر کند و در نتیجه آنها را به سرعت آزاد نکند.
در گزارشهای منتشرشده، این حمله با ترکیب الگوی سوءاستفاده از HPACK Header Compression و نگهداری اتصال به سبک Slowloris توضیح داده میشود. نتیجه این ترکیب میتواند مصرف شدید حافظه در وبسرور و از کار افتادن سرویس باشد.
این مقاله براساس FortiWeb 7.6 نوشته شده است و تمرکز آن بر این است که مدیران بدانند FortiWeb در نقش WAF و Reverse Proxy چگونه میتواند ریسک این حمله را با HTTP Protocol Constraints، DoS Protection، کنترل HTTP/2 و تنظیم درست Server Policy کاهش دهد.
نکتهاگر سرویس شما پشت FortiWeb منتشر شده باشد، نقطه دفاعی کلیدی این است که رفتار غیرعادی HTTP/2 در لایه WAF قبل از رسیدن درخواست به Backend کنترل شود. FortiWeb در اینجا صرفاً یک Signature-based WAF نیست؛ بلکه با محدودیتهای پروتکلی و ارزیابی رفتارهای ناسالم HTTP/2 را کنترل میکند.
2. چرا این حمله خطرناک است؟
خطر اصلی HTTP/2 Bomb نسبت بین هزینه مهاجم و هزینه سرور است. مهاجم با داده کم روی شبکه میتواند باعث شود تا سرور حافظه بیشتری برای نگهداری Headerها، استریمها و ساختارهای داخلی اختصاص دهد. اگر این حافظه آزاد نشود یا دیر آزاد شود، سرور به جای پاسخ به کاربران واقعی، مشغول نگهداری کانکشنهای مخرب میشود.
| ویژگی حمله | اثر عملیاتی |
|---|---|
| نیاز کمتر به پهنای باند نسبت به DDoS حجمی | ممکن است با یک Client یا تعداد کمی Client هم اثر جدی ایجاد شود. |
| استفاده از رفتارهای معتبر HTTP/2 | تشخیص آن فقط با نگاه کردن به Payload معمولی وب سختتر است. |
| درگیر کردن HPACK و Flow Control | مصرف Memory، افزایش Latency و اختلال در پاسخدهی سرویس. |
| اثر روی وبسرورهای معروف | ریسک برای سرویسهای عمومی که HTTP/2 را با تنظیمات پیشفرض فعال کردهاند. |
3. ارتباط حمله با HPACK و Flow Control چیست؟
در HTTP/2، برای کاهش حجم Headerها از HPACK استفاده میشود. HPACK به دو سمت ارتباط اجازه میدهد از یک Dynamic Table برای فشردهسازی و ارجاع دوباره به Headerها استفاده کنند. در حالت عادی این قابلیت باعث بهبود Performance میشود؛ اما اگر محدودیتهای مناسب روی Header Table، تعداد Headerها، تعداد Streamها و اندازه Frameها اعمال نشود، همین قابلیت میتواند تبدیل به نقطه فشار شود.
بخش دوم حمله به Flow Control مربوط است. در HTTP/2، Client میتواند با Window Size کوچک یا صفر، ارسال Response از سمت سرور را محدود کند. اگر سرور در این وضعیت منابع را نگه دارد و اتصال هم باز بماند، Memory آزاد نمیشود و فشار روی Backend ادامه پیدا میکند.
هشداراین حمله الزاماً با یک URL خاص، SQL Injection، XSS یا Payload کلاسیک شناسایی نمیشود. نقطه تشخیص، رفتار پروتکل HTTP/2 است؛ بنابراین کنترلهایی مثل HTTP Protocol Constraints، محدودیت Stream و Header، ومانیتورینگMemory بسیار مهم هستند.
4. FortiWeb در این سناریو کجای مسیر قرار میگیرد؟
در بهترین سناریو، FortiWeb باید در حالت Reverse Proxy جلوی Backend قرار بگیرد؛ یعنی Client به FortiWeb وصل شود و FortiWeb بعد از بررسی امنیتی، درخواست را به Server Pool ارسال کند. در این حالت FortiWeb میتواند قبل از رسیدن ترافیک به وبسرور، بخشی از رفتار ناسالم HTTP/2 را کنترل کند.
Client → FortiWeb Server Policy → Server Pool → Backend Web Server
اگر FortiWeb فقط بهصورت محدود و بدون Web Protection Profile مناسب استفاده شود، ممکن است صرفاً نقش انتشار سرویس را داشته باشد و از همه قابلیتهای کنترلی آن استفاده نشود. برای حمله HTTP/2 Bomb، باید Server Policy به یک Web Protection Profile وصل باشد که در آن HTTP Protocol Constraints و DoS Protection بهدرستی تنظیم شدهاند.
5. راهکار FortiWeb 7.6 برای کاهش ریسک HTTP/2 Bomb
راهکار FortiWeb برای این سناریو چند لایه کنترلی است. مهمترین بخش، کنترل رفتار HTTP/2 از طریق HTTP Protocol Constraints است. در کنار آن DoS Protection، محدودسازی Rate، مانیتورینگ لاگ و Hardening سمت Backend هم لازم است.
| لایه دفاعی | قابلیت FortiWeb | اثر روی ریسک HTTP/2 Bomb |
|---|---|---|
| کنترل پروتکل | HTTP Protocol Constraints | محدود کردن Header Compression Table، Streams، Frame Size و Header List Size. |
| کنترل حجم و نرخ درخواست | HTTP Access Limit / HTTP Flood / DoS Protection | کاهش فشار ناشی از درخواستهای زیاد یا اتصالهای مشکوک. |
| کنترل مسیر انتشار | Server Policy و Server Pool | قرار گرفتن FortiWeb قبل از Backend و جلوگیری از رسیدن رفتار مخرب به وبسرور. |
| کنترل نسخه پروتکل | Service و تنظیمات HTTP/HTTPS | غیرفعال کردن HTTP/2 در مسیرهایی که واقعاً به آن نیاز ندارند. |
| مانیتورینگ | Attack Log، Traffic Log، Event Log و FortiAnalyzer | تشخیص افزایش خطا، Deny، مصرف منابع یا رفتار غیرعادی Clientها. |
پیشنهاد عملیاتیدر فاز اول، این Constraintها را روی یک Policy تستی یا روی سرویس کمریسک با Action برابر Alert فعال کنید. بعد از بررسی Attack Log و اطمینان از نبود False Positive، برای سرویسهای حساس Action را به Alert & Deny تغییر دهید.
نمونه تنظیم پیشنهادی برای شروع
مقادیر زیر نسخه قطعی برای همه سازمانها نیستند؛ اما بهعنوان نقطه شروع برای سرویسهای عمومی میتوانند در تست اولیه بررسی شوند. اگر برنامه Header یا Cookie سنگین دارد، قبل از Deny باید رفتار واقعی کاربران بررسی شود.
| مورد | نقطه شروع پیشنهادی | توضیح |
|---|---|---|
| Header Compression Table Size | 4096 تا 8192 | برای کاهش سطح سوءاستفاده از HPACK، بیدلیل بالا تنظیم نشود. |
| Number of Concurrent Streams | 50 تا 100 | برای API و Login میتواند پایینتر باشد؛ برای سرویسهای پرترافیک باید تست شود. |
| Initial Window Size | Default یا پایینتر بر اساس تست | افزایش این مقدار معمولاً برای امنیت بهتر نیست و باید دلیل فنی داشته باشد. |
| Frame Size | Default | در حالت عادی افزایش داده نشود. |
| Header List Size | 16384 تا 65536 | به حجم Cookie و Header برنامه بستگی دارد. |
| HTTP/2 Max Requests | 500 تا 1000 | برای اتصالهای طولانی و پرتعداد، مقدار متناسب با سرویس تعیین شود. |
7. DoS Protection و Rate Limiting در FortiWeb
HTTP Protocol Constraints لایه اصلی کنترل رفتار HTTP/2 است، اما برای کاهش فشار کلی روی سرویس، DoS Protection هم باید بررسی شود. FortiWeb در بخش DoS Protection میتواند HTTP Flood، HTTP Access Limit، TCP Flood و سیاستهای مرتبط با Malicious IP را اعمال کند. این قابلیتها بهتنهایی جایگزین Patch و کنترل HTTP/2 نیستند، اما میتوانند شدت اثر حمله یا رفتارهای مشابه را کاهش دهند.
DoS Protection → HTTP Flood
DoS Protection → HTTP Access Limit
DoS Protection → TCP Flood
DoS Protection → Exception Policy
هشداربرای سرویسهای پرترافیک، DoS Protection را بدون Baseline فعال نکنید. اول نرخ طبیعی درخواستها، تعداد Connectionها، رفتار APIها، Botهای مجاز و IPهای مانیتورینگ را مشخص کنید؛ بعد Threshold را تنظیم کنید.
8. سناریوهای پیشنهادی برای پیادهسازی
سناریوی اول: سرویس عمومی با Backend nginx یا Apache
در این سناریو FortiWeb باید بهعنوان Reverse Proxy جلوی Backend قرار بگیرد. HTTP/2 روی سمت Client فقط در صورتی فعال باشد که واقعاً نیاز دارید. سمت Backend بهتر است Patch شود و اگر نیاز فنی وجود ندارد، ارتباط FortiWeb تا Backend روی HTTP/1.1 نگه داشته شود.
- HTTP Protocol Constraints برای HTTP/2 فعال شود.
- Header Compression Table Size و Concurrent Streams محدود شود.
- Action ابتدا Alert و بعد از تست Alert & Deny شود.
- Backend Patch شود یا در صورت نبود Patch، HTTP/2 سمت Backend غیرفعال شود.
سناریوی دوم: API Gateway با Header و Cookie زیاد
در APIها، کاهش بیش از حد Header List Size یا Concurrent Streams ممکن است باعث False Positive شود. در این حالت باید از Traffic Log و Attack Log برای پیدا کردن الگوی واقعی Headerها استفاده شود.
- روی مسیرهای Login و Token Endpoint محدودیت سختگیرانهتر اعمال شود.
- برای APIهای داخلی با Client مشخص، IP Allow List یا Client Certificate بررسی شود.
- برای APIهای عمومی، Rate Limit و HTTP Access Limit فعال شود.
سناریوی سوم: سامانهای که HTTP/2 نیاز ندارد
اگر برنامه شما با HTTP/1.1 بدون مشکل کار میکند و HTTP/2 مزیت عملیاتی مشخصی برای آن ندارد، سادهترین کاهش ریسک این است که HTTP/2 را در مسیر انتشار سرویس غیرفعال کنید. این کار مخصوصاً برای سرویسهای قدیمی، سامانههای داخلی و برنامههایی که Header پیچیده ندارند منطقی است.
9. چکلیست بررسی و پیادهسازی
| مورد | وضعیت مطلوب |
|---|---|
| شناسایی سرویسهای HTTP/2 | تمام Server Policyهایی که HTTP/2 روی آنها فعال است مشخص شده باشند. |
| Patch Backend | nginx، Apache، IIS، Envoy یا Reverse Proxy پشت FortiWeb به نسخه امنتر بهروزرسانی شده باشد. |
| HTTP Protocol Constraints | برای Server Policyهای حساس، Constraint مناسب HTTP/2 فعال و به Web Protection Profile متصل شده باشد. |
| Action | ابتدا Alert، سپس بعد از بررسی False Positive روی Alert & Deny تنظیم شود. |
| DoS Protection | HTTP Flood و HTTP Access Limit با Baseline واقعی سرویس تنظیم شده باشند. |
| Backend Protocol | اگر HTTP/2 سمت Backend نیاز نیست، ارتباط FortiWeb تا Backend با HTTP/1.1 بررسی شود. |
| مانیتورینگ Memory | مصرف Memory و وضعیت Processهای Backend و FortiWeb مانیتور شود. |
| لاگ و FortiAnalyzer | Attack Log، Traffic Log و Event Log به FortiAnalyzer ارسال و قابل جستجو باشند. |
10. Best Practice
- HTTP/2 را فقط برای سرویسهایی فعال نگه دارید که واقعاً به آن نیاز دارند.
- FortiWeb را در مسیر Reverse Proxy قرار دهید تا قبل از Backend بتواند رفتار HTTP/2 را کنترل کند.
- برای سرویسهای حساس، HTTP Protocol Constraints جداگانه بسازید و آن را با Profile عمومی همه سرویسها یکی نکنید.
- برای تغییرات سختگیرانه، اول از Alert شروع کنید و بعد از بررسی لاگها Deny را فعال کنید.
- Patch کردن Backend را فراموش نکنید؛ WAF باید لایه دفاعی باشد، نه جایگزین اصلاح آسیبپذیری.
- اگر سرویس پشت CDN یا Load Balancer است، بررسی کنید FortiWeb دقیقاً کدام نسخه HTTP را از Client و به Backend استفاده میکند.
- برای IPهای مانیتورینگ و تست داخلی، Exception را فقط در صورت نیاز و با محدودیت دقیق تعریف کنید.
برای ارزیابی پایداری، امنیت و نگهداری این زیرساخت، راهنمایپشتیبانی شبکهرا نیز مطالعه کنید.