راهنمای جامع مقابله با حملات DDoS: از تشخیص تا دفاع چندلایه

وقتی سروری زیر حملهٔ منع سرویس قرار می‌گیرد، اولین پرسش معمولاً این است که چرا محافظت ما نتوانست از پس این حجم برآید. پاسخ را باید در مسیر ترافیک جستجو کرد، نه فقط روی خود سرور. در این راهنما، مکان استقرار سامانه‌های محافظت، انواع حمله، و گام‌های مقابله با آن‌ها را بررسی می‌کنیم.

در یک نگاه

• محافظت DDoS از شبکهٔ بالادست آغاز می‌شود و روی خود سرور کامل می‌شود.
• حمله دو راه برای زمین زدن سرویس دارد: اشباع لینک یا تمام کردن منابع سرور.
• آنتی دیداس، فایروال، و CDN نقش‌های متفاوتی دارند و جای هم را نمی‌گیرند.
• داشتن برنامهٔ مکتوب در روز حمله مهم‌تر از ظرفیت بزرگ است.

حمله DDoS دقیقاً چه چیزی را از کار می‌اندازد؟

در حملهٔ منع سرویس توزیع‌شده، هزاران دستگاه آلوده همزمان به یک هدف ترافیک می‌فرستند، اما نتیجه همیشه یک شکل نیست. شناخت نوع شکست، انتخاب راهکار را ساده می‌کند:

• بسته‌ها هرگز به فایروال و وب سرور نمی‌رسند، زیرا ظرفیت پورت پیش از آن پر شده است. در این حالت، سرور سالم و حتی بی‌بار است، اما هیچ‌کس آن را نمی‌بیند.
• لینک جا دارد، اما تعداد اتصال‌ها، حافظه، یا پردازنده به سقف می‌رسد. نشانه‌اش بالا رفتن CPU، پر شدن جدول اتصال‌ها، و کندی سرویس برای کاربران واقعی است.
• حملهٔ ترکیبی را دست کم نگیرید: یک موج حجمی لینک را پر می‌کند و همزمان موجی دیگر از لایهٔ اپلیکیشن، منابع سرور را می‌خورد. همین دوگانگی است که محافظت چندلایه را اجباری می‌کند.

آنتی دیداس در کدام نقطه از مسیر می‌نشیند؟

سامانهٔ محافظت روی مسیر ترافیک قرار می‌گیرد: بسته‌ها پیش از رسیدن به سرور بررسی می‌شوند، ترافیک عادی عبور می‌کند، و ترافیک حمله دور ریخته می‌شود. سه مدل رایج وجود دارد که هر کدام برای شرایطی ساخته شده‌اند:

• ترافیک با مسیریابی BGP به یک مرکز پاک‌سازی بزرگ هدایت و تمیز به سرور برگردانده می‌شود؛ ظرفیت بالا و مناسب حملات حجمی بزرگ.
• تجهیزات اختصاصی روی لبهٔ شبکهٔ مرکز داده؛ تأخیر کمتر و کنترل دقیق‌تر روی قواعد فیلتر، اما سقف ظرفیت محدودتر از مراکز تخصصی است.
• فایروال، محدودسازی نرخ، و تنظیمات هسته؛ ارزان، سریع، و همیشه لازم، اما در برابر اشباع لینک کاملاً بی‌اثر است.

▍ همیشه فعال یا هنگام نیاز؟

در حالت همیشه فعال، همهٔ ترافیک به طور دائم از فیلتر عبور می‌کند و واکنش به حمله تقریباً بدون تأخیر است. در حالت هنگام نیاز، مسیر پاک‌سازی تنها پس از تشخیص حمله فعال می‌شود؛ تأخیر و هزینهٔ روزهای عادی کمتر است، اما در دقیقه‌های نخست ممکن است بخشی از ترافیک مخرب به سرور برسد. پیش از خرید، بپرسید سرویس شما کدام مدل است و در مدل دوم، تشخیص خودکار چند ثانیه زمان می‌برد.

چهار گام مقابله با حمله

مرکز آموزشی Cloudflare مقابله با DDoS را در چهار گام خلاصه می‌کند و همین چرخه تقریباً در همهٔ راهکارها، از سرویس‌های ابری تا تجهیزات مرکز داده، دیده می‌شود:

• تشخیص: جدا کردن حمله از ترافیک عادی با تکیه بر اعتبار IP، الگوهای شناخته‌شده، و رفتار تاریخی همان سرویس.
• پاسخ: دور ریختن ترافیک مخرب و عبور دادن کاربران واقعی، با قواعد فیلتر، محدودسازی نرخ، یا دیوار آتش کاربردی.
• هدایت: مدیریت حجم و تقسیم آن میان مراکز پاک‌سازی و مسیرهای جایگزین تا هیچ نقطه‌ای تک نقطه شکست نشود.
• یادگیری: ثبت الگوهای تکرارشونده مثل رنج‌های IP مهاجم و سخت‌تر کردن دفاع برای حملهٔ بعدی.

لایه‌های دفاع، از لبهٔ شبکه تا کد اپلیکیشن

▍ یک: ظرفیت پاک‌سازی بالادستی و سه عددی که باید بپرسید

حمله‌های حجمی مثل سیل UDP یا حملهٔ تقویتی DNS تنها جایی مهار می‌شوند که ظرفیت ورودی از حجم حمله بیشتر باشد. در این لایه، سه عدد تعیین‌کننده است:

• ظرفیت پهنای باند بر حسب گیگابیت یا ترابیت بر ثانیه؛ سقف حجمی که بدون اشباع لینک جذب می‌شود.
• توان پردازش بسته بر حسب میلیون بسته بر ثانیه؛ زیرا حملهٔ بسته‌های کوچک با حجم کم می‌تواند تجهیزات را از پا بیندازد.
• زمان تشخیص تا فعال شدن فیلتر؛ در حمله‌های کوتاه، همین چند ثانیه تعیین می‌کند سرویس بالا می‌ماند یا نه.

▍ دو: کنترل مسیر با BGP، از بلاک هل تا FlowSpec

وقتی حمله از ظرفیت پاک‌سازی بزرگ‌تر می‌شود، اپراتور از ابزارهای مسیریابی استفاده می‌کند. ساده‌ترین آن‌ها بلاک هل فعال‌شوندهٔ از راه دور است: سند RFC 7999 کامیونیتی 65535:666 را برای این کار تعریف کرده و توصیه می‌کند پیشوند تا حد امکان دقیق باشد، یعنی /32 در IPv4 یا /128 در IPv6. روش دقیق‌تر BGP Flow Specification است که نسخهٔ روز آن در RFC 8955 منتشر شده؛ با آن، قواعد فیلتر بر پایهٔ IP مبدأ و مقصد، پروتکل، و پورت میان روترها توزیع می‌شود و اقداماتی مثل محدودسازی نرخ یا دور ریختن، فقط روی جریان مخرب اعمال می‌شود.

▍ سه: سخت‌سازی سرور با فایروال، SYN Cookie، و محدودسازی نرخ

(یادآوری: جمله‌بندی را عمیق‌تر تغییر بده و ساختار را بازچینی کن. همهٔ اعداد و تاریخ‌های منبع را عیناً بیاور.)

محافظت از وب‌سایت در برابر حملات DDoS

لایهٔ اپلیکیشن: دیوار آتش کاربردی، کش و توزیع بار

حملات لایهٔ هفتم، مانند سیل درخواست‌های HTTP با حجم کم، می‌توانند وب‌سرور و پایگاه داده را از کار بیندازند. این حملات به سختی توسط شیلدهای لایهٔ شبکه تشخیص داده می‌شوند، زیرا شبیه درخواست‌های کاربر واقعی هستند. در این لایه، دیوار آتش کاربردی، کش صفحات پربازدید و توزیع بار میان چند سرور، نقش کلیدی دارند. تنظیم دقیق و بازبینی مداوم این لایه ضروری است، به ویژه پس از هر تغییر در سایت.

آنتی دیداس، فایروال و CDN: نقش‌های متمایز

این سه ابزار اغلب با هم اشتباه گرفته می‌شوند، در حالی که هر کدام جایگاه مشخصی در مسیر محافظت دارند:

نتیجهٔ واضح است: هیچ‌کدام جایگزین دیگری نیستند. استفاده از فایروال تنها، در برابر حملات حجمی بی‌دفاع است؛ و تنها CDN نیز در صورتی که IP اصلی سرور لو برود، کارایی ندارد.

محدودیت‌های ضروری برای آگاهی

• ظرفیت هر شیلد محدود است و حملات بزرگ‌تر منجر به بلاک هل موقت IP می‌شوند.
• حملات لایهٔ اپلیکیشن، با شیلد شبکه به تنهایی مهار نمی‌شوند.
• فیلترهای سختگیرانه ممکن است کاربران واقعی را نیز مسدود کنند.
• عبور ترافیک از مراکز دوردست، تأخیر را برای کاربران داخلی افزایش می‌دهد.
• محافظت DDoS جایگزین به‌روزرسانی، پیکربندی امن و نسخهٔ پشتیبان نیست.

هفت گام ضروری در روز حمله

داشتن برنامهٔ مکتوب، زمان قطعی را کاهش می‌دهد. این مراحل را تمرین کنید:

• تشخیص نوع حمله: اشباع لینک یا منابع سرور؟
• گزارش دقیق: زمان، الگوی ترافیک، مقصد و نمونهٔ بسته‌ها.
• فعال‌سازی اپراتور: مسیر پاک‌سازی، قواعد فیلتر و بلاک هل موقت.
• سخت‌گیری موقت روی نرخ و محدودسازی مسیرهای سنگین.
• نگهداری لاگ‌ها و نمونه‌های ترافیک برای تشخیص دقیق‌تر.
• جداسازی سرویس‌های حیاتی: صفحهٔ سبک، کش و پیام وضعیت.
• نوشتن گزارش کوتاه و اجرای اصلاحیات در هفتهٔ بعد.

اشتباهات رایج در محافظت DDoS

• خرید ظرفیت بزرگ بدون توجه به پیکربندی و سخت‌سازی سرور.
• بستن پورت‌های مدیریتی بدون راه ورود اضطراری.
• تنظیم محدودسازی نرخ با اعداد پیش‌فرض، بدون در نظر گرفتن رفتار کاربران واقعی.
• اعتماد به CDN بدون توجه به لو رفتن IP اصلی سرور.
• عدم آزمایش محافظت تا زمان حملهٔ واقعی.

پرسش‌های متداول دربارهٔ آنتی دیداس

تفاوت آنتی دیداس با فایروال معمولی چیست؟

فایروال روی لینک سرور تصمیم می‌گیرد، در حالی که آنتی دیداس در شبکهٔ بالادست و با ظرفیت بیشتر، حمله را قبل از رسیدن به سرور پاک‌سازی می‌کند. این دو مکمل یکدیگرند.

دو راه شکست در حملهٔ دیداس چیست؟

اشباع لینک ورودی یا تمام شدن منابع سرور مانند پردازنده، حافظه و تعداد اتصال. هر کدام راهکار متفاوتی نیاز دارند.

حملهٔ انعکاسی چیست و چرا خطرناک است؟

مهاجم درخواستی با IP جعلی می‌فرستد و سرورهای باز پاسخ چندبرابری را به قربانی می‌فرستند. ردیابی سخت‌تر و حجم حمله بیشتر می‌شود، که مهار آن در لایهٔ بالادست ضروری است.

آیا افزایش ظرفیت سرور جایگزین آنتی دیداس است؟

راهنمای جامع مقابله با حملات DDoS

آیا شیلد DDoS تأخیر کاربران را افزایش می‌دهد؟

این مسئله به موقعیت مرکز پاک‌سازی بستگی دارد. اگر مسیر پاک‌سازی نزدیک کاربران شما باشد، تأخیر قابل توجهی ایجاد نمی‌شود. اما اگر ترافیک برای پاک‌سازی به قاره‌ای دیگر هدایت شود، کاربران داخلی ممکن است تأخیر را احساس کنند. بنابراین، قبل از خرید، این موضوع را بررسی کنید و حتی می‌توانید با انجام یک تست ساده، تأثیر آن را ارزیابی کنید.

آیا محدود کردن یک کشور می‌تواند حمله را متوقف کند؟

بلاک جغرافیایی برای وب‌سایت‌های داخلی ممکن است بخشی از ترافیک بی‌ربط را حذف کند، اما راه‌حل کاملی نیست. بات‌نت‌ها جهانی هستند و از سرویس‌های ابری در چندین کشور استفاده می‌کنند. علاوه بر این، ممکن است کاربران واقعی شما نیز مسدود شوند.

چه مواردی را قبل از خرید سرور ضد DDoS باید بررسی کرد؟

ظرفیت شیلد، که به گیگابیت و بهتر است به بسته‌های بر ثانیه نیز اشاره شود، سیاست بلاک هل (شامل آستانه، مدت و زمان بازگشت IP)، پوشش حمله‌های لایه اپلیکیشن، ساعت پاسخ پشتیبانی و تعهدات سطح خدمات، از جمله مواردی هستند که باید به صورت مکتوب درخواست شوند. پاسخ روشن به این پرسش‌ها، تصویر واقعی از سرویس ارائه‌شده را نشان می‌دهد.

نکات کلیدی

• شیلد DDoS، ترافیک حمله را شناسایی، پاک‌سازی و تنها جریان سالم را اجازه عبور می‌دهد.
• این محافظت در چهار مرحله تشخیص، پاسخ، هدایت و یادگیری انجام می‌شود.
• ابزارهایی مانند پاک‌سازی بالادستی، بلاک هل بر اساس RFC 7999 و FlowSpec بر اساس RFC 8955، هر کدام نقش خاصی دارند.
• هیچ لایه‌ای به تنهایی کافی نیست؛ شیلد شبکه حمله‌های حجمی را مهار می‌کند، اما کوکی SYN، فایروال، محدودسازی نرخ و دیوار آتش کاربردی روی سرور، برای مقابله با حمله‌های پروتکلی و لایه اپلیکیشن ضروری هستند.

جمع‌بندی

با درک کامل از آنتی دیداس، می‌توانید تصمیم‌گیری بهتری در انتخاب سرویس مناسب داشته باشید. سه پرسش کلیدی را در قرارداد خود شفاف کنید: ظرفیت شیلد، سیاست بلاک هل و پوشش حمله‌های لایه اپلیکیشن. با پاسخ به این پرسش‌ها، سرویس شما در روزهای حمله آماده خواهد بود.

اگر هنوز پرسشی در ذهن دارید، می‌توانید در بخش نظرات آن را مطرح کنید تا به بررسی آن بپردازیم.