نکات کلیدی
- سامانهٔ محافظت روی مسیر ترافیک قرار می گیرد: بسته ها پیش از رسیدن به سرور بررسی می شوند، ترافیک عادی عبور می کند و ترافیک حمله دور ریخته می شود.
- فایروال روی لینک سرور تصمیم می گیرد کدام بسته عبور کند؛ اگر لینک با ترافیک حمله پر شود، فایروال کاری از پیش نمی برد.
- آنتی دیداس در شبکهٔ بالادست و با ظرفیت بسیار بیشتر، حمله را پیش از رسیدن به لینک سرور پاک سازی می کند.
وقتی سروری زیر حملهٔ منع سرویس از دسترس خارج می‌شود، اولین پرسش معمولاً این است که چرا محافظت ما جلوی این حجم را نگرفت. پاسخ را باید در مسیر ترافیک جست‌وجو کرد، نه فقط روی خود سرور. در این راهنما نشان می‌دهیم آنتی دیداس دقیقاً کجا می‌نشیند، هر لایه چه کاری انجام می‌دهد، کدام محدودیت‌ها واقعی‌اند و در روز حمله به چه ترتیبی باید عمل کنید.
در یک نگاه
- ◆ محافظت DDoS از شبکهٔ بالادست آغاز می‌شود و روی خود سرور کامل می‌شود.
- ◆ حمله دو راه برای زمین زدن سرویس دارد: اشباع لینک یا تمام کردن منابع سرور.
- ◆ آنتی دیداس، فایروال و CDN سه نقش متفاوت دارند و جای هم را نمی‌گیرند.
- ◆ در روز حمله، داشتن برنامهٔ مکتوب مهم‌تر از داشتن عدد بزرگ ظرفیت است.
حمله دداس دقیقاً چه چیزی را از کار می‌اندازد؟
در حملهٔ منع سرویس توزیع‌شده، هزاران دستگاه آلوده هم‌زمان به یک هدف ترافیک می‌فرستند، اما نتیجه همیشه یک شکل نیست. شناخت نوع شکست، انتخاب راهکار را ساده می‌کند:
بسته‌ها هرگز به فایروال و وب‌سرور نمی‌رسند، چون ظرفیت پورت پیش از آن پر شده است. در این حالت سرور سالم و حتی بی‌بار است، اما هیچ‌کس آن را نمی‌بیند.
لینک جا دارد، اما تعداد اتصال‌ها، حافظه یا پردازنده به سقف می‌رسد. نشانه‌اش بالا رفتن 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 و محدودسازی نرخ
ترافیکی که از لایه‌های بالادست عبور می‌کند هنوز می‌تواند شامل حملهٔ پروتکلی باشد. اینجا فایروال فقط پورت‌های لازم را باز می‌گذارد، پارامتر tcp_syncookies هنگام پر شدن صف SYN با ارسال کوکی از سرور محافظت می‌کند و روی وب‌سرور محدودسازی نرخ درخواست اعمال می‌شود. ماژول limit_req در Nginx نرخ درخواست را برای هر کلید مثل هر IP با روش سطل نشتی محدود می‌کند و درخواست‌های اضافه را به‌طور پیش‌فرض با کد 503 رد می‌کند:
▍ چهار: لایهٔ اپلیکیشن با دیوار آتش کاربردی، کش و توزیع بار
حمله‌های لایهٔ هفتم مثل سیل درخواست HTTP با حجم کم هم می‌توانند وب‌سرور و دیتابیس را زمین بزنند و چون شبیه درخواست کاربر واقعی‌اند، شیلدهای لایهٔ شبکه به‌سختی تشخیصشان می‌دهند. در این لایه، دیوار آتش کاربردی، کش صفحات پربازدید و توزیع بار میان چند سرور نقش اصلی را دارند؛ همین لایه است که بیشترین تنظیم دقیق را می‌خواهد و باید پس از هر تغییر در سایت بازبینی شود.
آنتی دیداس، فایروال و CDN؛ سه نقش متفاوت
این سه ابزار زیاد با هم اشتباه گرفته می‌شوند، در حالی که هر کدام جای مشخصی در مسیر دارند:
| ابزار | کجا می‌نشیند | چه چیزی را مهار می‌کند | کجا کم می‌آورد |
|---|---|---|---|
| آنتی دیداس | شبکهٔ بالادست و مرکز پاک‌سازی | حمله‌های حجمی و پروتکلی | محدود به ظرفیت اعلام‌شدهٔ شیلد |
| فایروال | روی سرور یا لبهٔ شبکهٔ شما | بستن پورت‌ها و ترافیک ناخواسته | در برابر اشباع لینک بی‌اثر است |
| CDN و دیوار آتش کاربردی | لبهٔ شبکهٔ توزیع‌شده و نزدیک کاربر | حمله‌های لایهٔ اپلیکیشن و پنهان‌کردن IP | تنها ترافیک وب را پوشش می‌دهد |
نتیجهٔ عملی ساده است: هیچ‌کدام جای دیگری را نمی‌گیرد. با فایروال تنها، حملهٔ حجمی سرویس را پایین می‌آورد؛ با CDN تنها، اگر IP اصلی سرور لو برود مهاجم مستقیم به سرور می‌زند.
پنج محدودیتی که باید صادقانه بدانید
✕
ظرفیت هر شیلد یک عدد مشخص است؛ حملهٔ بزرگ‌تر از آن به بلاک‌هل موقت IP منجر می‌شود.
✕
حمله‌های لایهٔ اپلیکیشن، که شبیه ترافیک عادی‌اند، با شیلد شبکه به‌تنهایی مهار نمی‌شوند.
✕
فیلترهای سخت‌گیرانه ممکن است بخشی از کاربران واقعی را هم مسدود کنند.
✕
عبور ترافیک از مراکز پاک‌سازی دوردست می‌تواند تأخیر کاربران داخلی را بیشتر کند.
✕
محافظت DDoS جایگزین به‌روزرسانی، پیکربندی امن و نسخهٔ پشتیبان نیست.
روز حمله: هفت کار به همین ترتیب
داشتن برنامهٔ مکتوب تفاوت بین چند دقیقه و چند ساعت قطعی است. این ترتیب را از پیش تمرین کنید:
۱
در دقیقهٔ صفر نوع حمله را مشخص کنید: لینک ورودی پر شده یا منابع سرور به سقف رسیده؟
۲
گزارش دقیق بدهید: زمان شروع، الگوی ترافیک، مقصد حمله و نمونهٔ بسته‌ها.
۳
اپراتور را وارد کنید: فعال‌سازی مسیر پاک‌سازی، قواعد فیلتر و در آخرین حالت بلاک‌هل موقت.
۴
روی سرور نرخ را موقتاً سخت‌گیرانه‌تر کنید و مسیرهای سنگین مثل جست‌وجو را محدود کنید.
۵
لاگ‌ها و نمونهٔ ترافیک را نگه دارید؛ همین داده‌ها تشخیص دقیق‌تر و دفاع بعدی را می‌سازند.
۶
سرویس حیاتی را جدا کنید: صفحهٔ سبک، کش، حالت تعمیر و پیام وضعیت برای کاربران.
۷
پس از حمله گزارش کوتاهی بنویسید و دو مورد اصلاحی را همان هفته اجرا کنید.
پنج اشتباه رایج در محافظت DDoS
✕
خرید ظرفیت بزرگ و بی‌توجهی به پیکربندی و سخت‌سازی خود سرور.
✕
بستن پورت‌های مدیریتی بدون داشتن راه ورود اضطراری مثل کنسول سرور.
✕
تنظیم محدودسازی نرخ با اعداد پیش‌فرض، بدون سنجش رفتار کاربران واقعی.
✕
گمان اینکه CDN به‌تنهایی کافی است، در حالی که IP اصلی سرور لو رفته است.
✕
آزمایش نکردن محافظت تا لحظهٔ حملهٔ واقعی؛ ظرفیتی که تست نشده، قابل اتکا نیست.
پرسش‌های پرتکرار درباره آنتی دیداس
آنتی دیداس چه فرقی با فایروال معمولی دارد؟
فایروال روی لینک سرور تصمیم می‌گیرد کدام بسته عبور کند؛ اگر لینک با ترافیک حمله پر شود، فایروال کاری از پیش نمی‌برد. آنتی دیداس در شبکهٔ بالادست و با ظرفیت بسیار بیشتر، حمله را پیش از رسیدن به لینک سرور پاک‌سازی می‌کند. این دو مکمل‌اند، نه رقیب.
دو راه شکست در حملهٔ دیداس کدام‌اند؟
یا لینک ورودی اشباع می‌شود و بسته‌ها هرگز به سرور نمی‌رسند، یا منابع سرور مثل پردازنده، حافظه و تعداد اتصال تمام می‌شود. راهکار هر کدام متفاوت است؛ اولی با ظرفیت پاک‌سازی بالادست و دومی با پیکربندی درست سرور مهار می‌شود.
حملهٔ انعکاسی چیست و چرا خطرناک است؟
مهاجم درخواست کوچکی با IP مبدأ جعلی می‌فرستد و سرورهای باز مثل سرویس‌های DNS پاسخ چند برابر را به قربانی می‌فرستند. چون مبدأ واقعی پنهان است، ردیابی سخت‌تر است و حجم حمله با یک موج کوچک چند برابر می‌شود؛ همان چیزی که مهار آن تنها در لایهٔ بالادست ممکن است.
بالا بردن ظرفیت سرور جایگزین آنتی دیداس است؟
نه. ظرفیت بیشتر فقط آستانهٔ تحمل را بالا می‌برد و هزینهٔ ماهانه را زیاد می‌کند، اما لینک همچنان می‌تواند اشباع شود و هیچ فیلتری وجود ندارد که ترافیک مخرب را کنار بگذارد. ظرفیت و پاک‌سازی دو چیز جدا هستند.
شیلد DDoS تأخیر کاربران را بیشتر می‌کند؟
بستگی به موقعیت مرکز پاک‌سازی دارد. اگر مسیر پاک‌سازی نزدیک کاربران شما باشد، افزایش تأخیر ناچیز است؛ اما اگر ترافیک برای پاک‌سازی به قاره‌ای دیگر برود، کاربران داخلی تفاوت را حس می‌کنند. این را پیش از خرید بپرسید و اگر ممکن است با یک تست ساده بسنجید.
آیا با محدود کردن یک کشور می‌توان حمله را مهار کرد؟
بلاک جغرافیایی برای سایت‌های داخلی می‌تواند بخشی از ترافیک بی‌ربط را حذف کند، اما راه‌حل نیست: بات‌نت‌ها جهانی‌اند و از سرویس‌های ابری چند کشور استفاده می‌کنند، ضمن اینکه ممکن است کاربران واقعی شما هم مسدود شوند.
پیش از خرید سرور ضد DDoS چه چیزی را مکتوب بگیریم؟
ظرفیت شیلد به گیگابیت و در صورت امکان بسته بر ثانیه، سیاست بلاک‌هل (آستانه، مدت و بازگشت IP)، پوشش حمله‌های لایهٔ اپلیکیشن، ساعت پاسخ پشتیبانی و تعهدات سطح خدمات. پاسخ روشن این پنج مورد، تصویر واقعی سرویس را نشان می‌دهد.
جمع‌بندی
حالا می‌دانید آنتی دیداس چیست: سدی در بالادست سرور که ترافیک حمله را می‌شناسد، پاک‌سازی می‌کند و فقط جریان سالم را عبور می‌دهد. این محافظت در چهار گام تشخیص، پاسخ، هدایت و یادگیری کار می‌کند و ابزارهایی مثل پاک‌سازی بالادستی، بلاک‌هل بر پایهٔ RFC 7999 و FlowSpec بر پایهٔ RFC 8955 هر کدام جای خود را دارند.
نکتهٔ اصلی این است که هیچ لایه‌ای به‌تنهایی کافی نیست: شیلد شبکه حمله‌های حجمی را مهار می‌کند، اما کوکی SYN، فایروال، محدودسازی نرخ و دیوار آتش کاربردی روی سرور لازم‌اند تا حمله‌های پروتکلی و لایهٔ اپلیکیشن هم پاسخ بگیرند.
سه پرسش را در قرارداد شفاف کنید: ظرفیت شیلد بر حسب گیگابیت و بسته بر ثانیه، سیاست بلاک‌هل و زمان بازگشت IP، و پوشش حمله‌های لایهٔ اپلیکیشن. با پاسخ این سه، سرویس شما در روز حمله غافلگیر نمی‌شود.
اگر پرسشی در این مسیر برایتان ماند، در بخش نظرات بنویسید تا بررسی کنیم.
منابع: IETF RFC 7999 دربارهٔ کامیونیتی بلاک‌هل، IETF RFC 8955 دربارهٔ انتشار قواعد فیلتر، مرکز آموزشی Cloudflare دربارهٔ مراحل مقابله با DDoS، راهنمای منع سرویس سازمان NCSC بریتانیا، مستندات هستهٔ لینوکس برای tcp_syncookies و مستندات ماژول ngx_http_limit_req در Nginx.
کمپین ابتکار نو
کمپین ایده های نو
کمپین آینده روشن
کمپین طراحی مدرن