HTTP/2 Bomb چیست و کنترل آن در FortiWeb

مدت زمان مطالعه:

۴ تیر ۱۴۰۵

HTTP/2 Bomb چیست و FortiWeb 7.6 چطور جلوی آن را می‌گیرد؟

حمله HTTP/2 Bomb با شناسه CVE-2026-49975 یکی از نمونه‌های مهم حملات Denial of Service روی پیاده‌سازی‌های HTTP/2 است. اهمیت این حمله در این است که الزاماً شبیه DDoS حجمی کلاسیک نیست؛ یعنی مهاجم برای ایجاد اختلال جدی، همیشه به Botnet بزرگ یا پهنای باند بسیار بالا نیاز ندارد.

در گزارش‌های منتشرشده توسط Calif و Imperva، این حمله با ترکیب یک الگوی سوءاستفاده از HPACK Header Compression و یک نگه‌داشتن اتصال به سبک Slowloris توضیح داده شده است. نتیجه این ترکیب می‌تواند مصرف شدید Memory در وب‌سرور و از دسترس خارج شدن سرویس باشد.

این مقاله بر اساس FortiWeb 7.6 نوشته شده است و تمرکز آن روی این است که ادمین بداند FortiWeb در نقش WAF و Reverse Proxy چطور می‌تواند ریسک این نوع حمله را با HTTP Protocol Constraints، DoS Protection، کنترل HTTP/2 و تنظیم درست Server Policy کاهش دهد.

مروری بر این مقاله

HTTP/2 Bomb چیست؟
چرا این حمله خطرناک است؟
ارتباط حمله با HPACK و Flow Control چیست؟
FortiWeb در این سناریو کجای مسیر قرار می‌گیرد؟
راهکار FortiWeb 7.6 برای کاهش ریسک HTTP/2 Bomb
تنظیم HTTP Protocol Constraints برای HTTP/2
DoS Protection و Rate Limiting در FortiWeb
سناریوهای پیشنهادی برای پیاده‌سازی
چک‌لیست بررسی و پیاده‌سازی
Best Practice

1. HTTP/2 Bomb چیست؟

HTTP/2 Bomb یک حمله Resource Exhaustion است که روی نحوه مدیریت Header Compression، Streamها و Flow Control در HTTP/2 فشار ایجاد می‌کند. برخلاف حملات حجمی، هدف اصلی این حمله الزاماً پر کردن پهنای باند نیست؛ هدف این است که سرور مجبور شود برای درخواست‌های ظاهراً معتبر، Memory و ساختارهای داخلی زیادی اختصاص دهد و نتواند آن‌ها را سریع آزاد کند.

در گزارش Calif، این حمله روی وب‌سرورهای معروفی مثل nginx، Apache httpd، Microsoft IIS، Envoy و Cloudflare Pingora بررسی شده است. در پایگاه NVD، CVE-2026-49975 برای Apache HTTP Server ثبت شده و ضعف آن به مصرف Memory از طریق درخواست‌های مخرب HTTP نسبت داده شده است.

نکته: اگر سرویس شما پشت FortiWeb منتشر شده باشد، نقطه مهم دفاع این است که قبل از رسیدن درخواست به Backend، رفتار غیرعادی HTTP/2 در لایه WAF کنترل شود. FortiWeb در اینجا فقط Signature-based WAF نیست؛ بلکه می‌تواند با محدودیت‌های پروتکلی، رفتارهای ناسالم HTTP/2 را هم کنترل کند.

2. چرا این حمله خطرناک است؟

خطر اصلی HTTP/2 Bomb در نسبت نامتوازن هزینه مهاجم و هزینه سرور است. مهاجم می‌تواند با داده نسبتاً کم روی Wire، کاری کند که سرور Memory بسیار بیشتری برای نگهداری Header، Stream و ساختارهای داخلی اختصاص دهد. اگر این Memory آزاد نشود یا دیر آزاد شود، سرور به‌جای پاسخ‌دهی به کاربران واقعی، درگیر نگهداری اتصال‌های مخرب می‌شود.

ویژگی حمله	اثر عملیاتی
نیاز کم‌تر به پهنای باند نسبت به 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 Bomb نیست؛ بلکه باید چند لایه کنترلی با هم فعال شوند. مهم‌ترین بخش، کنترل رفتار HTTP/2 از طریق HTTP Protocol Constraints است. در کنار آن، DoS Protection، محدودسازی Rate، مانیتورینگ لاگ و Hardening سمت Backend هم لازم است.

لایه دفاعی	قابلیت FortiWeb	اثر روی ریسک HTTP/2 Bomb
کنترل پروتکل	HTTP Protocol Constraints	محدود کردن Header Compression Table، Streamها، 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ها.

6. تنظیم HTTP Protocol Constraints برای HTTP/2

در FortiWeb 7.6، بخش HTTP/HTTPS Protocol Constraints برای محدود کردن رفتارهای غیرعادی در سطح پروتکل استفاده می‌شود. Fortinet برای HTTP/2 فیلدهایی مثل Header Compression Table Size، Number of Concurrent Streams، Initial Window Size، Frame Size، Header List Size، HTTP/2 Max Requests، HTTP/2 RST Stream و HTTP/2 RST Stream Frequency را مستند کرده است.

مسیر کلی در GUI:

Web Protection → Protocol Constraints → HTTP/HTTPS Protocol Constraints

بعد از ساخت یا ویرایش Constraint، باید آن را داخل Web Protection Profile متصل به Server Policy اعمال کنید:

Policy → Web Protection Profile → HTTP Protocol Constraints

فیلدهای مهم برای مقابله با HTTP/2 Bomb

فیلد	کاربرد	پیشنهاد عملیاتی
Header Compression Table Size	کنترل اندازه Header Compression Table در HTTP/2	برای سرویس‌های عمومی، مقدار را بی‌دلیل بالا نبرید. ابتدا با مقدار محافظه‌کارانه تست کنید و در صورت نیاز افزایش دهید.
Number of Concurrent Streams	کنترل تعداد Streamهای همزمان در یک اتصال HTTP/2	برای Portal، Login و APIهای حساس، عدد پایین‌تر از سرویس‌های عمومی پرترافیک انتخاب شود.
Initial Window Size	کنترل Window اولیه برای Flow Control	افزایش بی‌دلیل این مقدار می‌تواند مصرف منابع را بالا ببرد. قبل از تغییر، رفتار نرم‌افزار بررسی شود.
Frame Size	کنترل حداکثر اندازه Payload در Frameهای HTTP/2	در بیشتر سناریوها نیازی به افزایش مقدار پیش‌فرض نیست.
Header List Size	کنترل اندازه کلی Headerهای پذیرفته‌شده	اگر برنامه Cookieهای بزرگ دارد، قبل از Deny مستقیم، چند روز در حالت Alert بررسی شود.
HTTP/2 Max Requests	کنترل تعداد درخواست‌ها در یک Connection HTTP/2	برای کاهش سوءاستفاده از اتصال‌های طولانی، مقدار منطقی و متناسب با سرویس تنظیم شود.
HTTP/2 RST Stream / RST Stream Frequency	کنترل رفتار غیرعادی مربوط به Reset Stream	برای تشخیص رفتارهای خودکار و غیرعادی روی HTTP/2 مفید است.

پیشنهاد عملیاتی: در فاز اول، این 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 را فقط در صورت نیاز و با محدودیت دقیق تعریف کنید.

مطالب مرتبط

پرسش و پاسخ

آیا Patch کردن Backend همچنان لازم است؟

بله. FortiWeb یک لایه دفاعی مهم است، اما جایگزین Patch کردن وب‌سرور یا Reverse Proxy آسیب‌پذیر نیست. بهترین طراحی، ترکیب Patch، WAF، محدودیت پروتکل و مانیتورینگ است.

آیا DoS Protection جای HTTP Protocol Constraints را می‌گیرد؟

خیر. DoS Protection برای کنترل نرخ و حجم رفتارهای مشکوک مفید است، اما HTTP/2 Bomb به محدودیت‌های خود پروتکل هم مربوط است. هر دو لایه باید با هم بررسی شوند.

اگر برنامه Header یا Cookie بزرگ داشته باشد چه کار کنیم؟

باید Header List Size و Header Value Length را بر اساس رفتار واقعی برنامه تنظیم کنید. سخت‌گیری بیش از حد می‌تواند باعث Block شدن کاربران واقعی شود؛ راحت گیری بیش از حد هم سطح ریسک را بالا می‌برد.

آیا FortiWeb باید HTTP/2 را Terminate کند؟

در سناریوی Reverse Proxy، بهتر است FortiWeb در نقطه‌ای قرار گیرد که بتواند ترافیک HTTP/2 را قبل از Backend ببیند و کنترل کند. اگر FortiWeb فقط ترافیک رمزنگاری‌شده را عبور دهد و امکان بررسی نداشته باشد، قابلیت‌های WAF عملاً محدود می‌شوند.

آیا فقط با خاموش کردن HTTP/2 مشکل حل می‌شود؟

اگر سرویس واقعاً به HTTP/2 نیاز ندارد، غیرفعال کردن آن می‌تواند یک Mitigation سریع باشد. اما اگر به HTTP/2 نیاز دارید، باید محدودیت‌های پروتکلی، Patch Backend و مانیتورینگ را هم انجام دهید.

آیا FortiWeb یک Signature مشخص برای HTTP/2 Bomb دارد؟

ممکن است در آینده Signatureها یا به‌روزرسانی‌های امنیتی جدیدی ارائه شود، اما در این مقاله راهکار اصلی روی کنترل رفتاری و پروتکلی تمرکز دارد. برای این نوع حمله، HTTP Protocol Constraints و DoS Protection اهمیت زیادی دارند.

آیا HTTP/2 Bomb یک DDoS حجمی است؟

خیر. این حمله بیشتر Resource Exhaustion است. یعنی مهاجم تلاش می‌کند با مصرف Memory و نگه داشتن منابع سرور، سرویس را کند یا از دسترس خارج کند. ممکن است حجم ترافیک نسبت به DDoSهای کلاسیک خیلی زیاد نباشد.

امتیاز و دیدگاه کاربران

دیدگاه خود را درباره این مقاله بیان کنید.ثبت دیدگاه

پایگاه دانش