جدید!
سرور ابری ساعتی فعال شد. ۱۰۰ هزار تومان اعتبار هدیه بگیرید
به اشتراک بگذارید
جدید!
سرور ابری ساعتی فعال شد. ۱۰۰ هزار تومان اعتبار هدیه بگیرید
اگر بپرسید Anti DDoS چیست، پاسخ کوتاه این است: مجموعه‌ای از تجهیزات شبکه، پهنای باند اضافه و قواعد فیلترینگ که ترافیک حمله DDoS (منع سرویس توزیع‌شده) را از ترافیک کاربران واقعی جدا می‌کند تا سرور و لینک ارتباطی آن زیر بار حمله از کار نیفتد. بخش اصلی این محافظت در شبکه بالادستی و دیتاسنتر انجام می‌شود و فایروال خود سرور فقط لایه آخر آن است.
- حملات حجمی می‌توانند لینک ورودی را پیش از رسیدن به فایروال سرور پر کنند
- چند ساعت قطعی سایت، اپلیکیشن یا سرور بازی مستقیماً به فروش و اعتماد کاربران آسیب می‌زند
- هیچ لایه دفاعی به‌تنهایی کافی نیست و محافظت DDoS باید از شبکه تا اپلیکیشن ادامه پیدا کند
- شناخت محدودیت‌ها کمک می‌کند انتظار واقع‌بینانه‌ای از سرویس محافظت داشته باشید
💡 Anti DDoS یعنی سدی پیش از سرور که سیل ترافیک حمله را مهار می‌کند
✅ محافظت واقعی در دیتاسنتر شروع می‌شود و روی سرور با فایروال و Rate Limit کامل می‌شود.
✅ سرور اختصاصی ایران وب‌داده با شیلد DDoS صد گیگابیتی و فایروال سخت‌افزاری تحویل می‌شود
✅ سرور اختصاصی ایران وب‌داده با شیلد DDoS صد گیگابیتی و فایروال سخت‌افزاری تحویل می‌شود
اگر قرار است سروری بخرید که روز حمله سرپا بماند، اول باید بدانید محافظت DDoS دقیقاً چه کاری می‌کند و کجا کم می‌آورد. در ادامه سازوکار آنتی دیداس، لایه‌های دفاعی از دیتاسنتر تا خود سرور، محدودیت‌ها و یک چک‌لیست کاربردی برای انتخاب سرور را مرور می‌کنیم.
🔶 سرور اختصاصی با محافظت DDoS در لایه دیتاسنتر
سرور اختصاصی ایران وب‌داده با شیلد DDoS به ظرفیت ۱۰۰ گیگابیت بر ثانیه، فایروال سخت‌افزاری و امنیت چندلایه تحویل می‌شود. پیش از خرید می‌توانید نیاز امنیتی سرویس خود را با تیم فنی شبانه‌روزی بررسی کنید 👇
Anti DDoS چیست و چطور کار می‌کند؟
در حمله DDoS، شمار زیادی دستگاه آلوده (معمولاً یک بات‌نت) هم‌زمان به یک هدف ترافیک می‌فرستند تا پهنای باند یا منابع آن را تمام کنند. انواع این حمله را در راهنمای حمله DDoS و انواع آن جداگانه توضیح داده‌ایم. سامانه آنتی دیداس در مسیر ترافیک قرار می‌گیرد، الگوی غیرعادی را تشخیص می‌دهد، ترافیک مخرب را دور می‌ریزد و ترافیک سالم را به سرور می‌رساند.
شهری کنار رودخانه را تصور کنید. کیسه‌شن جلوی در خانه در برابر آب‌گرفتگی کوچک مفید است، اما وقتی رودخانه طغیان می‌کند، فقط سدی در بالادست می‌تواند سیل را مهار کند. فایروال روی سرور همان کیسه‌شن است و محافظت در دیتاسنتر همان سد؛ هر دو لازم‌اند، اما در سیل بزرگ، سد تعیین‌کننده است.
🌐 Internet: real users + attack traffic
⬇️
[ Upstream / datacenter edge ]
🔎 detection ➡️ 🧹 scrubbing / filtering
⬇️ clean traffic only
[ Hardware firewall ]
⬇️
🗄️ Dedicated server: firewall, SYN cookies, rate limit۱- چهار مرحله اصلی مقابله با حمله
مرکز آموزشی Cloudflare فرایند مقابله با DDoS را در چهار مرحله توضیح می‌دهد. این تقسیم‌بندی برای سرویس‌های ابری نوشته شده است، اما برای فهم کار بیشتر راهکارهای محافظت DDoS هم به کار می‌آید:
- تشخیص (Detection): جدا کردن حمله واقعی از افزایش ناگهانی بازدید کاربران، با تکیه بر اعتبار IP، الگوهای شناخته‌شده حمله و داده‌های گذشته.
- پاسخ (Response): دور ریختن ترافیک بات‌های مخرب و جذب بقیه ترافیک؛ با قواعد WAF برای حملات لایه ۷ و فیلترینگ برای حملات L3/L4.
- مسیریابی (Routing): مدیریت حجم ترافیک و تقسیم آن به بخش‌های قابل کنترل.
- تطبیق (Adaptation): تحلیل الگوهای تکرارشونده، مثل بلوک‌های IP که بارها در حمله دیده می‌شوند یا سوءاستفاده از یک پروتکل خاص، برای دفاع بهتر در حملات بعدی.
🔸 نکته فنی: چرا فایروال سرور به‌تنهایی کافی نیست؟
در حمله حجمی، مشکل اصلی پر شدن «لوله» است، نه کمبود قواعد فایروال. اگر حجم حمله از ظرفیت پورت سرور بیشتر باشد، لینک پیش از رسیدن بسته‌ها به فایروال اشباع می‌شود و کاربران واقعی هم پشت صف می‌مانند. به همین دلیل دو عدد را باید جدی گرفت: ظرفیت پورت سرور و ظرفیت پاک‌سازی بالادستی. تفاوت پورت‌ها را در مقاله پورت ۱ گیگ یا ۱۰ گیگ ببینید.
۲- حالت همیشه‌فعال و حالت هنگام نیاز
در حالت همیشه‌فعال (Always-on)، همه ترافیک در هر لحظه از فیلتر عبور می‌کند و واکنش به حمله تقریباً بی‌درنگ است. در حالت هنگام نیاز (On-demand)، ترافیک فقط پس از تشخیص حمله به مسیر پاک‌سازی منتقل می‌شود؛ هزینه کمتر است و ترافیک در شرایط عادی تأخیر اضافه ندارد، اما در لحظه‌های اول حمله ممکن است بخشی از ترافیک مخرب به سرور برسد. هنگام خرید سرور آنتی دیداس، بپرسید سرویس از کدام مدل استفاده می‌کند.
لایه‌های محافظت DDoS؛ از شبکه بالادستی تا خود سرور
لایه‌های دفاعی را از بیرونی‌ترین لایه، یعنی شبکه بالادستی، تا خود سرور مرور می‌کنیم. هر لایه نوع خاصی از حمله را بهتر مهار می‌کند و هیچ‌کدام جای بقیه را نمی‌گیرد.
۱- پاک‌سازی ترافیک در دیتاسنتر و شبکه بالادستی
حملات حجمی مثل UDP Flood یا حمله تقویتی DNS (DNS Amplification) فقط جایی مهار می‌شوند که ظرفیت ورودی از حجم حمله بیشتر باشد. تجهیزات محافظت DDoS در لبه شبکه دیتاسنتر یا اپراتور بالادستی، ترافیک را بررسی و پاک‌سازی می‌کنند. در این لایه سه مشخصه را از ارائه‌دهنده بپرسید:
◀️ ظرفیت پهنای باند (Gbps یا Tbps): بیشترین حجم حمله‌ای که بدون اشباع لینک جذب می‌شود.
◀️ ظرفیت پردازش بسته (Mpps): حمله با بسته‌های کوچک می‌تواند با حجمی نه‌چندان زیاد، تجهیزات را با تعداد بسته در ثانیه از پا بیندازد.
◀️ زمان تشخیص و واکنش: فاصله شروع حمله تا فعال شدن فیلتر؛ در حمله‌های کوتاه ممکن است همین فاصله کل مدت حمله باشد.
◀️ ظرفیت پردازش بسته (Mpps): حمله با بسته‌های کوچک می‌تواند با حجمی نه‌چندان زیاد، تجهیزات را با تعداد بسته در ثانیه از پا بیندازد.
◀️ زمان تشخیص و واکنش: فاصله شروع حمله تا فعال شدن فیلتر؛ در حمله‌های کوتاه ممکن است همین فاصله کل مدت حمله باشد.
۲- Blackhole یا RTBH؛ آخرین چاره اپراتور
وقتی حمله از ظرفیت پاک‌سازی بزرگ‌تر باشد، اپراتور ممکن است از Remotely Triggered Blackhole استفاده کند. سند RFC 7999 از IETF، کامیونیتی BGP با مقدار
65535:666 را برای همین کار تعریف کرده است: ترافیکی که مقصدش IP هدف است در شبکه دور ریخته می‌شود تا بقیه شبکه سالم بماند. طبق همین سند، پیشوند Blackhole معمولاً تا حد ممکن دقیق است، یعنی /32 در IPv4 یا /128 در IPv6.⚠️ روی دیگر Blackhole
سازوکار Blackhole بقیه شبکه را نجات می‌دهد، اما تا وقتی فعال است، IP هدف عملاً از دسترس خارج است؛ یعنی مهاجم به خواسته‌اش رسیده است. پس هنگام خرید سرور اختصاصی ضد DDoS بپرسید IP در چه آستانه‌ای و برای چه مدت Blackhole می‌شود و چطور می‌توان آن را زودتر به مدار برگرداند.
۳- BGP FlowSpec؛ فیلتر دقیق در روترها
روش دقیق‌تر، BGP Flow Specification یا FlowSpec است. نسخه فعلی آن در RFC 8955 (دسامبر ۲۰۲۰) منتشر شده و جای RFC 5575 و RFC 7674 را گرفته است؛ قواعد مخصوص IPv6 جداگانه در RFC 8956 آمده‌اند. در این روش، قواعد فیلتر بر اساس IP مبدأ و مقصد، پروتکل و پورت بین روترها توزیع می‌شوند و اقداماتی مثل محدودسازی نرخ یا دور ریختن ترافیک فقط روی جریان‌هایی اعمال می‌شود که با قاعده تطبیق دارند. مقدمه همین سند، مهار حملات DoS و DDoS را از کاربردهای این سازوکار می‌داند.
۴- جلوگیری از حمله DDoS در سطح سرور؛ فایروال، SYN Cookie و Rate Limit
ترافیکی که از لایه‌های بالادستی عبور می‌کند، هنوز ممکن است شامل حملات پروتکلی یا درخواست‌های مخرب باشد. در این لایه، فایروال سرور ورودی‌ها را به پورت‌های لازم محدود می‌کند؛ تفاوت گزینه‌ها را در مقاله فایروال سرور سخت‌افزاری یا نرم‌افزاری بررسی کرده‌ایم. در لینوکس، طبق مستندات کرنل، پارامتر
tcp_syncookies به‌طور پیش‌فرض روی ۱ است؛ یعنی وقتی صف SYN یک سوکت پر شود، کرنل با ارسال SYN Cookie اتصال‌های جدید را بدون نیاز به جای خالی در صف می‌پذیرد و صف پرشده جلوی اتصال کاربران واقعی را نمی‌گیرد. همین مستندات تأکید می‌کند که SYN Cookie فقط سازوکار پشتیبان است و نباید با آن بار سنگین اتصال‌های مشروع را جبران کرد.برای وب‌سرور، محدودسازی نرخ درخواست ابزار ساده و مؤثری است. ماژول
limit_req در Nginx طبق مستندات رسمی، نرخ درخواست را برای هر کلید (مثلاً هر IP) با روش سطل نشتی (Leaky Bucket) محدود می‌کند و درخواست‌های اضافه را به‌طور پیش‌فرض با کد 503 رد می‌کند. بخش Nginx در نمونه زیر همان مثال مستندات است:# check SYN cookies (default 1 = on when SYN queue overflows)
sysctl net.ipv4.tcp_syncookies
# nginx: max 1 request/second per IP, burst up to 5
http {
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
server {
location /search/ { limit_req zone=one burst=5; }
}
}📌 یادآوری: نرخ 1r/s در این مثال فقط برای صفحه جست‌وجو تعریف شده است. عدد را بر اساس رفتار واقعی کاربران سایت خود تنظیم کنید، چون مقدار خیلی سخت‌گیرانه کاربران واقعی را هم پشت در نگه می‌دارد. برای پیکربندی فایروال نرم‌افزاری هم راهنمای کانفیگ فایروال CSF را ببینید؛ فقط در نظر داشته باشید که شرکت ConfigServer در شهریور ۱۴۰۴ (اوت ۲۰۲۵) تعطیل شد و CSF حالا از طریق نسخه‌های متن‌باز جامعه‌محور به‌روز می‌شود.
۵- لایه اپلیکیشن؛ WAF، CDN و توزیع بار
حملات لایه ۷ مثل HTTP Flood با حجم کم هم می‌توانند وب‌سرور و دیتابیس را زمین بزنند و چون شبیه درخواست کاربر واقعی‌اند، شیلدهای لایه شبکه به‌سختی آن‌ها را تشخیص می‌دهند. در این لایه WAF درخواست‌های مشکوک را فیلتر می‌کند، CDN در نقش پراکسی معکوس با کش بخشی از بار را از روی سرور برمی‌دارد و توزیع بار بین چند سرور فشار باقی‌مانده را پخش می‌کند؛ برای توزیع بار، مقاله لود بالانسر چیست را بخوانید. برای وردپرس هم راهنمای دفاع در برابر DDoS وردپرس نکات عملی دارد.
📚 پنج گام NCSC برای آمادگی
مرکز ملی امنیت سایبری بریتانیا (NCSC) در راهنمای آمادگی در برابر حملات منع سرویس، پنج گام را پیشنهاد می‌کند: سرویس خود را بشناسید، دفاع‌های بالادستی ارائه‌دهندگان شبکه‌تان را بشناسید، برای افزایش ظرفیت برنامه داشته باشید، برنامه پاسخ به حادثه بنویسید و دفاع‌ها را به‌طور منظم آزمایش و پایش کنید. به بیان دیگر، آنتی دیداس با خرید یک سرویس تمام نمی‌شود و به برنامه‌ریزی و آزمایش دوره‌ای نیاز دارد.
جدول مقایسه روش‌های محافظت در برابر DDoS
جدول زیر روش‌های اصلی را بر اساس لایه عملکرد، مزیت و محدودیت کنار هم می‌گذارد:
| روش | لایه | مزیت اصلی | محدودیت |
|---|---|---|---|
| پاک‌سازی بالادستی | شبکه (L3/L4) | جذب حملات حجمی بزرگ | محدود به ظرفیت شیلد |
| Blackhole (RFC 7999) | مسیریابی BGP | نجات بقیه شبکه | IP هدف از دسترس خارج می‌شود |
| BGP FlowSpec (RFC 8955) | مسیریابی BGP | فیلتر دقیق جریان مخرب | نیاز به پشتیبانی اپراتور |
| فایروال سخت‌افزاری | شبکه و انتقال | فیلتر پیش از رسیدن به سرور | قواعد باید درست تعریف شوند |
| SYN Cookie و فایروال سرور | سیستم‌عامل | مقاومت در برابر SYN Flood | بی‌اثر در برابر اشباع لینک |
| Rate Limit و WAF | اپلیکیشن (L7) | مهار HTTP Flood | نیاز به تنظیم دقیق |
| CDN یا پراکسی معکوس | اپلیکیشن (L7) | پنهان کردن IP اصلی و کش | فقط برای ترافیک وب |
محدودیت‌های آنتی دیداس و چک‌لیست انتخاب سرور اختصاصی ضد DDoS
هیچ ارائه‌دهنده سرور آنتی دیداسی نمی‌تواند محافظت صددرصدی را تضمین کند. با شناختن محدودیت‌ها، سرویس را درست‌تر انتخاب می‌کنید و برای روز حمله برنامه خواهید داشت.
محدودیت‌هایی که پیش از خرید باید بدانید
❌ ظرفیت هر شیلد محدود است و حمله‌ای بزرگ‌تر از آن ممکن است به Blackhole موقت IP منجر شود.
❌ شیلدهای لایه شبکه، حملات لایه اپلیکیشن را که شبیه ترافیک عادی‌اند، به‌تنهایی مهار نمی‌کنند.
❌ فیلترهای سخت‌گیرانه ممکن است بخشی از کاربران واقعی را هم مسدود کنند (مثبت کاذب).
❌ عبور ترافیک از مراکز پاک‌سازی دوردست، به‌ویژه خارج از کشور، می‌تواند تأخیر را برای کاربران داخلی بیشتر کند.
❌ محافظت DDoS جایگزین به‌روزرسانی، پیکربندی امن و بکاپ نیست؛ حفره نرم‌افزاری را پوشش نمی‌دهد.
❌ شیلدهای لایه شبکه، حملات لایه اپلیکیشن را که شبیه ترافیک عادی‌اند، به‌تنهایی مهار نمی‌کنند.
❌ فیلترهای سخت‌گیرانه ممکن است بخشی از کاربران واقعی را هم مسدود کنند (مثبت کاذب).
❌ عبور ترافیک از مراکز پاک‌سازی دوردست، به‌ویژه خارج از کشور، می‌تواند تأخیر را برای کاربران داخلی بیشتر کند.
❌ محافظت DDoS جایگزین به‌روزرسانی، پیکربندی امن و بکاپ نیست؛ حفره نرم‌افزاری را پوشش نمی‌دهد.
چک‌لیست انتخاب سرور آنتی دیداس
✅ ظرفیت محافظت DDoS به گیگابیت بر ثانیه و در صورت امکان به میلیون بسته بر ثانیه اعلام شده باشد.
✅ مشخص باشد محافظت کدام لایه‌ها را پوشش می‌دهد و ارائه‌دهنده برای لایه اپلیکیشن چه راهکاری پیشنهاد می‌کند.
✅ سیاست Blackhole شفاف باشد: آستانه، مدت و روند بازگشت IP.
✅ فایروال سخت‌افزاری و امکان تعریف قواعد اختصاصی وجود داشته باشد.
✅ پورت سرور و پهنای باند برای ترافیک عادی و اوج بار کافی باشد.
✅ امکان خرید IP اضافه و مشاهده ترافیک در پنل کاربری فراهم باشد.
✅ پشتیبانی شبانه‌روزی و مسیر مشخص برای گزارش حمله وجود داشته باشد.
✅ تعهدات محافظت در قرارداد سطح خدمات روشن باشد؛ نحوه خواندن آن را در مقاله SLA چیست ببینید.
✅ مشخص باشد محافظت کدام لایه‌ها را پوشش می‌دهد و ارائه‌دهنده برای لایه اپلیکیشن چه راهکاری پیشنهاد می‌کند.
✅ سیاست Blackhole شفاف باشد: آستانه، مدت و روند بازگشت IP.
✅ فایروال سخت‌افزاری و امکان تعریف قواعد اختصاصی وجود داشته باشد.
✅ پورت سرور و پهنای باند برای ترافیک عادی و اوج بار کافی باشد.
✅ امکان خرید IP اضافه و مشاهده ترافیک در پنل کاربری فراهم باشد.
✅ پشتیبانی شبانه‌روزی و مسیر مشخص برای گزارش حمله وجود داشته باشد.
✅ تعهدات محافظت در قرارداد سطح خدمات روشن باشد؛ نحوه خواندن آن را در مقاله SLA چیست ببینید.
سناریوی نمونه؛ کندی فروشگاه در شب حراج
یک سناریوی نمونه: فروشگاه اینترنتی در شب حراج کند می‌شود و مدیر سایت گمان می‌کند شیلد DDoS کار نمی‌کند. نمودار ترافیک در پنل نشان می‌دهد حجم ورودی عادی است، اما لاگ وب‌سرور می‌گوید تعداد درخواست‌ها به صفحه جست‌وجو چند برابر شده است؛ یعنی حمله لایه اپلیکیشن است، نه حجمی. شیلد شبکه کار خود را درست انجام داده، اما این نوع حمله باید روی خود سرور مهار شود.
راهکار معمول برای جلوگیری از حمله DDoS در این لایه: بررسی لاگ‌ها برای یافتن نشانه‌های بات، محدودسازی نرخ روی مسیرهای سنگین مثل جست‌وجو، کش صفحات پربازدید و مسدود کردن الگوهای مشخص در فایروال. بعد از حمله هم بهتر است همین مراحل در قالب برنامه پاسخ مکتوب ثبت شود تا دفعه بعد سریع‌تر عمل کنید. اگر کار به قطع کامل سرویس کشید، راهنمای کارهای حیاتی هنگام داون شدن سرور را دنبال کنید.
سرور آنتی دیداس در وب‌داده؛ شیلد ۱۰۰ گیگابیتی و فایروال سخت‌افزاری
ما محافظت DDoS سرور اختصاصی را از لایه دیتاسنتر شروع می‌کنیم تا ترافیک حجمی پیش از رسیدن به سرورتان مهار شود. آنچه به‌طور مشخص دریافت می‌کنید:
✅ محافظت DDoS با شیلد ۱۰۰ گیگابیت بر ثانیه، فایروال سخت‌افزاری و امنیت چندلایه
✅ پورت ۱۰ گیگابیت در شبکه‌ای با آپلینک ۱۰۰ گیگابیت برای ترافیک عادی و اوج بار
✅ مشاهده میزان ترافیک در پنل کاربری و پنل مدیریت سرور با ری‌استارت، کنسول KVM و نصب مجدد سیستم‌عامل
✅ خرید IPv4 اضافه از پنل کاربری و امکان IP Announcement رنج IP اختصاصی شما از طریق BGP با AS وب‌داده
✅ سرور HPE DL360 Gen9 با دو پردازنده Xeon E5-2680 v4، رم 64GB ECC و دیسک 1TB NVMe، با تحویل آنی پس از پرداخت
✅ تیم فنی شبانه‌روزی برای مشاوره پیش از خرید و بررسی پیکربندی‌های سفارشی از طریق تیکت یا تماس
✅ پورت ۱۰ گیگابیت در شبکه‌ای با آپلینک ۱۰۰ گیگابیت برای ترافیک عادی و اوج بار
✅ مشاهده میزان ترافیک در پنل کاربری و پنل مدیریت سرور با ری‌استارت، کنسول KVM و نصب مجدد سیستم‌عامل
✅ خرید IPv4 اضافه از پنل کاربری و امکان IP Announcement رنج IP اختصاصی شما از طریق BGP با AS وب‌داده
✅ سرور HPE DL360 Gen9 با دو پردازنده Xeon E5-2680 v4، رم 64GB ECC و دیسک 1TB NVMe، با تحویل آنی پس از پرداخت
✅ تیم فنی شبانه‌روزی برای مشاوره پیش از خرید و بررسی پیکربندی‌های سفارشی از طریق تیکت یا تماس
⚠️ حدود این محافظت
شیلد ۱۰۰ گیگابیتی برای حملات حجمی لایه شبکه طراحی شده است. حملات لایه اپلیکیشن باید روی خود سرور با Rate Limit، WAF و پیکربندی درست مهار شوند. اگر فرصت یا تخصص این کار را ندارید، از خدمات کانفیگ و مدیریت سرور وب‌داده کمک بگیرید.
برای دیدن مشخصات به‌روز و ثبت سفارش، به صفحه اجاره سرور اختصاصی سر بزنید. اگر هنوز بین مدل‌های سرور مردد هستید، پیش از خرید با تیم فنی ما مشورت کنید.
سوالات متداول درباره سرور آنتی دیداس
Anti DDoS چیست و چه فرقی با فایروال معمولی دارد؟
فایروال معمولی تصمیم می‌گیرد کدام بسته‌ها اجازه عبور دارند، اما خودش پشت لینک سرور است و اگر لینک با ترافیک حمله پر شود، کاری از پیش نمی‌برد. آنتی دیداس در شبکه بالادستی و با ظرفیت بسیار بیشتر، ترافیک حمله را پیش از رسیدن به لینک سرور تشخیص می‌دهد و پاک‌سازی می‌کند. این دو مکمل هم‌اند، نه جایگزین هم.
آیا سرور اختصاصی ضد DDoS در برابر همه حملات مصون است؟
خیر. هر شیلد ظرفیت مشخصی دارد و حمله بزرگ‌تر از آن ممکن است به Blackhole موقت IP منجر شود. حملات لایه اپلیکیشن هم که شبیه درخواست کاربران واقعی‌اند، باید روی خود سرور با Rate Limit و WAF مهار شوند. محافظت DDoS واقعی ترکیبی از شیلد دیتاسنتر، پیکربندی درست سرور و برنامه پاسخ به حادثه است.
محافظت DDoS چند گیگابیتی برای من کافی است؟
به اندازه و حساسیت سرویستان بستگی دارد. طبق گزارش‌های Cloudflare که در راهنمای حمله DDoS به آن‌ها اشاره کرده‌ایم، بیشتر حملات لایه شبکه حجم نسبتاً کمی دارند، اما حملات چندترابیتی هم ثبت شده‌اند. به نظر ما، برای بیشتر سایت‌ها و سرویس‌های داخلی، شیلدی با ظرفیت ده‌ها گیگابیت همراه با پیکربندی درست سرور نقطه شروع منطقی است.
برای جلوگیری از حمله DDoS روی سرور لینوکس چه کارهایی انجام دهم؟
پورت‌های غیرضروری را ببندید، فایروال را فقط برای سرویس‌های لازم باز کنید، مطمئن شوید tcp_syncookies فعال است و روی وب‌سرور محدودسازی نرخ درخواست تنظیم کنید. پنل‌های مدیریتی را در دسترس عموم نگذارید و لاگ‌ها و ترافیک را پایش کنید. این اقدامات جایگزین محافظت DDoS دیتاسنتر نیستند، اما در مهار حملات کوچک و حملات لایه اپلیکیشن کمک زیادی می‌کنند.
منظور از Blackhole شدن IP چیست و چقدر طول می‌کشد؟
یعنی اپراتور برای حفاظت از بقیه شبکه، همه ترافیکی را که مقصدش IP شماست دور می‌ریزد؛ کامیونیتی 65535:666 برای همین کار در RFC 7999 تعریف شده است. در این مدت سرویستان از دسترس خارج است. مدت آن به سیاست ارائه‌دهنده و ادامه حمله بستگی دارد؛ پس پیش از خرید، آستانه و مدت Blackhole را از ارائه‌دهنده بپرسید.
آیا استفاده از CDN برای جلوگیری از حمله DDoS کافی است؟
برای سایت‌ها، CDN یا پراکسی معکوس IP اصلی سرور را پنهان می‌کند و بخشی از ترافیک را در لبه شبکه جذب می‌کند. اما فقط ترافیک وب را پوشش می‌دهد و اگر IP اصلی سرور لو رفته باشد، مهاجم می‌تواند مستقیم به آن حمله کند. سرویس‌هایی مثل سرور بازی یا VoIP هم معمولاً از CDN وب بهره نمی‌برند و به محافظت DDoS در لایه شبکه نیاز دارند.
در روز حمله، اولین کاری که باید انجام دهم چیست؟
ابتدا نوع حمله را مشخص کنید: آیا لینک ورودی پر شده یا منابع سرور مثل CPU و اتصال‌ها؟ سپس با پشتیبانی ارائه‌دهنده تماس بگیرید و زمان شروع و نشانه‌ها را گزارش کنید. هم‌زمان لاگ‌ها را نگه دارید، Rate Limit را سخت‌گیرانه‌تر کنید و در صورت نیاز صفحه‌های سنگین را موقتاً محدود کنید. داشتن برنامه پاسخ مکتوب، این مراحل را سریع‌تر می‌کند.
محافظت DDoS سرور اختصاصی وب‌داده شامل چه چیزهایی است؟
سرورهای اختصاصی ایران وب‌داده با شیلد DDoS به ظرفیت ۱۰۰ گیگابیت بر ثانیه، فایروال سخت‌افزاری و امنیت چندلایه ارائه می‌شوند و ترافیک در پنل کاربری قابل مشاهده است. این محافظت برای حملات حجمی لایه شبکه طراحی شده و حملات لایه اپلیکیشن باید با پیکربندی خود سرور مهار شوند. برای جزئیات نیاز خاص خود، با تیم فنی از طریق تیکت یا تماس مشورت کنید.
جمع‌بندی؛ چرا محافظت DDoS باید چندلایه باشد
حالا می‌دانید Anti DDoS چیست: سدی در بالادست سرور که ترافیک حمله را تشخیص می‌دهد، پاک‌سازی می‌کند و فقط ترافیک سالم را عبور می‌دهد. پاک‌سازی بالادستی حملات حجمی را جذب می‌کند، FlowSpec جریان‌های مخرب را دقیق‌تر در روترها فیلتر می‌کند و Blackhole آخرین چاره‌ای است که بقیه شبکه را نجات می‌دهد اما IP هدف را موقتاً از دسترس خارج می‌کند.
برای جلوگیری از حمله DDoS هیچ لایه‌ای به‌تنهایی کافی نیست: شیلد دیتاسنتر حملات حجمی را مهار می‌کند، اما SYN Cookie، فایروال، Rate Limit و WAF روی سرور لازم‌اند تا حملات پروتکلی و لایه اپلیکیشن هم پاسخ بگیرند. سرور اختصاصی ایران وب‌داده با شیلد ۱۰۰ گیگابیتی، فایروال سخت‌افزاری و پورت ۱۰ گیگابیت، لایه شبکه را پوشش می‌دهد؛ تنظیمات لایه سرور و اپلیکیشن همچنان با خودتان است.
قدم بعدی را پیش از حمله بردارید: چک‌لیست انتخاب سرور آنتی دیداس را با ارائه‌دهنده مرور کنید، سرور را سخت‌سازی کنید و برنامه پاسخ به حادثه را بنویسید. روز حمله فرصتی برای این کارها نمی‌ماند.
اگر درباره انتخاب سرور ضد DDoS یا تنظیم محافظت روی سرور سوالی دارید، در بخش نظرات بپرسید؛ تیم فنی وب‌داده پاسخ می‌دهد.
منابع: IETF RFC 7999: BLACKHOLE Community؛ IETF RFC 8955: Dissemination of Flow Specification Rules؛ Cloudflare Learning Center: What is DDoS mitigation?؛ NCSC (UK): Denial of Service (DoS) guidance؛ Linux Kernel Documentation: IP Sysctl (tcp_syncookies)؛ NGINX Docs: Module ngx_http_limit_req_module
