حملات DDoS چیست و چگونه از سایت در برابر آن محافظت کنیم؟

گاهی یک وب‌سایت بدون آنکه فایل‌هایش حذف شوند، پایگاه‌داده آن هک شود یا رمز عبور مدیر به دست مهاجم بیفتد، عملاً از دسترس خارج می‌شود. کاربران با خطای اتصال روبه‌رو می‌شوند، صفحات با تأخیر زیاد باز می‌شوند، API پاسخ نمی‌دهد و حتی ممکن است سرور زیر بار غیرعادی کاملاً متوقف شود. یکی از مهم‌ترین تهدیدهایی که چنین وضعیتی ایجاد می‌کند، حملات DDoS یا Distributed Denial of Service است.

هدف اصلی حمله DDoS معمولاً سرقت مستقیم اطلاعات نیست؛ مهاجم تلاش می‌کند قابلیت دسترسی به یک سرویس را مختل کند. برای یک فروشگاه اینترنتی، سایت خبری، سامانه مالی، وب‌اپلیکیشن SaaS یا هر کسب‌وکاری که درآمد و اعتبار آن به حضور آنلاین وابسته است، همین از دست رفتن دسترس‌پذیری می‌تواند خسارت قابل توجهی ایجاد کند.

CISA حملات DoS و DDoS را حملاتی می‌داند که با مصرف منابع سیستم یا شبکه، دسترسی کاربران قانونی به وب‌سایت یا برنامه را مختل می‌کنند. راهنمای مشترک CISA، FBI و MS-ISAC نیز تأکید می‌کند که DDoS علاوه بر هزینه‌های عملیاتی می‌تواند هزینه مالی و اعتباری برای سازمان ایجاد کند.

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

نکته مهم‌تر این است که همه حملات DDoS شبیه یکدیگر نیستند. یک حمله ممکن است پهنای باند ارتباطی را اشباع کند، حمله‌ای دیگر ظرفیت Firewall یا Load Balancer را هدف بگیرد و حمله‌ای در لایه Application با درخواست‌هایی ظاهراً عادی، CPU، حافظه، Database Connection یا Workerهای وب‌سرور را مصرف کند.

به همین دلیل برای جلوگیری از حملات DDoS نمی‌توان فقط به افزایش منابع سرور، نصب یک افزونه امنیتی یا مسدودسازی چند IP متکی بود. معماری مقاوم در برابر DDoS معمولاً ترکیبی از CDN، Anycast، WAF، Rate Limiting، Cache، Load Balancing، زیرساخت افزونه‌پذیر، مانیتورینگ، محدودسازی منابع، همکاری با Hosting Provider و برنامه Incident Response است.

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

حمله DDoS چیست؟

DDoS مخفف Distributed Denial of Service و به معنی «محروم‌سازی از سرویس توزیع‌شده» است.

در یک حمله DDoS، هدف این است که یک سرویس، وب‌سایت، شبکه یا برنامه برای کاربران واقعی کند، ناپایدار یا کاملاً غیرقابل دسترس شود.

OWASP حمله Denial of Service را حمله‌ای علیه Availability می‌داند که می‌تواند با ایجاد حجم بالای درخواست، سوءاستفاده از ضعف‌های برنامه یا مصرف منابع باعث کاهش کیفیت سرویس یا توقف کامل آن شود.

تفاوت اصلی DDoS با بسیاری از حملات امنیتی این است که مهاجم الزاماً به دنبال ورود به حساب کاربری یا سرقت Database نیست. در اینجا یکی از سه اصل کلاسیک امنیت اطلاعات یعنی Availability هدف قرار می‌گیرد.

سه اصل معروف CIA عبارت‌اند از:

• Confidentiality یا محرمانگی
• Integrity یا تمامیت اطلاعات
• Availability یا دسترس‌پذیری

در DDoS تمرکز اصلی روی Availability است.

اگر وب‌سایت از نظر محرمانگی و تمامیت کاملاً امن باشد اما کاربران نتوانند به آن دسترسی پیدا کنند، کسب‌وکار همچنان با یک حادثه امنیتی جدی روبه‌رو است.

تفاوت DoS و DDoS چیست؟

DoS و DDoS هدف مشابهی دارند اما نحوه اجرای آن‌ها متفاوت است.

حمله DoS چیست؟

در حمله Denial of Service یا DoS، ترافیک یا درخواست مخرب ممکن است از یک منبع یا تعداد محدودی منبع ایجاد شود.

اگر منبع حمله مشخص باشد، مسدود کردن آن معمولاً ساده‌تر است.

حمله DDoS چیست؟

در Distributed Denial of Service، حمله از تعداد زیادی منبع انجام می‌شود.

این منابع ممکن است از شبکه‌ها، کشورها و IPهای مختلف باشند.

در نتیجه، سیستم دفاعی نمی‌تواند به‌سادگی تمام ترافیک یک IP را Block کند و تصور کند حمله پایان یافته است.

مقیاس و پراکندگی، DDoS را به تهدیدی پیچیده‌تر تبدیل می‌کند.

چرا حملات DDoS خطرناک هستند؟

DDoS می‌تواند بدون دسترسی مستقیم مهاجم به سیستم، یک کسب‌وکار آنلاین را عملاً متوقف کند.

از دسترس خارج شدن سایت

واضح‌ترین نتیجه این است که کاربران نمی‌توانند سایت را باز کنند.

برای فروشگاه اینترنتی، این موضوع مستقیماً می‌تواند به توقف فروش منجر شود.

کند شدن شدید سایت

همیشه حمله باعث Down شدن کامل سایت نمی‌شود.

گاهی پاسخ‌ها از چندصد میلی‌ثانیه به چندین ثانیه افزایش پیدا می‌کنند.

کاربر سایت را «خراب» یا «کند» تلقی می‌کند و احتمال خروج او بالا می‌رود.

اختلال در API

برنامه‌های موبایل و SPAها معمولاً به API وابسته‌اند.

حتی اگر Frontend از CDN قابل بارگذاری باشد، از دسترس خارج شدن API می‌تواند کل سرویس را غیرقابل استفاده کند.

افزایش هزینه زیرساخت

در زیرساخت‌های Cloud، Autoscaling می‌تواند به حفظ Availability کمک کند؛ اما اگر بدون محدودیت طراحی شده باشد، حمله DDoS ممکن است باعث افزایش شدید مصرف منابع و هزینه شود.

بنابراین Scaling باید با Budget Control، Rate Limiting و سیستم‌های ضد DDoS همراه باشد.

آسیب به اعتبار برند

کاربر تفاوت میان حمله DDoS، اختلال سرور و خطای نرم‌افزاری را نمی‌داند.

او فقط می‌بیند سرویس قابل استفاده نیست.

تکرار این وضعیت می‌تواند اعتماد به برند را کاهش دهد.

ایجاد پوشش برای حملات دیگر

گاهی یک موج اختلال شدید می‌تواند توجه تیم فنی را به Availability معطوف کند و بررسی سایر رویدادهای امنیتی دشوارتر شود.

به همین دلیل هنگام Incident نباید فرض کرد تمام رفتار غیرعادی سیستم فقط از DDoS ناشی شده است.

حملات DDoS چگونه کار می‌کنند؟

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

فرض کنید یک سایت در شرایط عادی توانایی پاسخ به ۵۰۰ درخواست در ثانیه را دارد.

اگر ناگهان مقدار درخواست به چند ده هزار درخواست برسد، ممکن است لایه‌های مختلف زیرساخت تحت فشار قرار گیرند.

اما مسئله فقط تعداد درخواست نیست.

یک درخواست ساده برای فایل Cache شده ممکن است منابع بسیار کمی مصرف کند، در حالی که یک درخواست Search پیچیده می‌تواند Query سنگینی روی Database اجرا کند.

بنابراین حمله DDoS می‌تواند از دو راه کلی فشار ایجاد کند:

حجم بسیار زیاد ترافیک یا هزینه بسیار زیاد پردازش هر درخواست.

NIST در راهنمای امنیت Web Services توضیح می‌دهد که ظرفیت سرویس‌ها یکسان نیست؛ یک Endpoint ممکن است هزاران درخواست ساده را تحمل کند، در حالی که عملیات پیچیده با تعداد بسیار کمتری از درخواست‌ها تحت فشار قرار گیرد.

Botnet چیست و چه ارتباطی با DDoS دارد؟

Botnet شبکه‌ای از سیستم‌ها یا دستگاه‌هایی است که تحت کنترل مهاجم قرار گرفته‌اند.

این دستگاه‌ها می‌توانند شامل:

• کامپیوترهای آلوده
• سرورها
• روترها
• دوربین‌های متصل به اینترنت
• دستگاه‌های IoT
• یا سایر تجهیزات آسیب‌پذیر

باشند.

مالک واقعی دستگاه ممکن است حتی نداند سیستم او بخشی از یک Botnet است.

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

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

NIST نیز افزایش مقیاس حملات DDoS و استفاده از منابع توزیع‌شده و زیرساخت‌های پرظرفیت را از عوامل مهم تحول این تهدید معرفی کرده است.

انواع حملات DDoS

برای دفاع صحیح، ابتدا باید مشخص شود کدام بخش از سیستم هدف حمله قرار گرفته است.

OWASP حملات DoS را به‌طور کلی در حوزه‌های Application، Session/Protocol و Network بررسی می‌کند و تأکید دارد هرکدام به دفاع متفاوتی نیاز دارند.

حملات Volumetric چیست؟

Volumetric DDoS تلاش می‌کند پهنای باند در دسترس هدف را مصرف کند.

در این شرایط حتی ممکن است سرور از نظر CPU و RAM کاملاً سالم باشد، اما ارتباط شبکه به دلیل حجم ترافیک اشباع شده باشد.

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

چرا دفاع در داخل سرور کافی نیست؟

اگر پهنای باند قبل از رسیدن ترافیک به سرور اشباع شده باشد، Firewall روی همان سرور نمی‌تواند مشکل را حل کند.

ترافیک باید در نقطه‌ای Upstream و با ظرفیت بالاتر فیلتر شود.

به همین دلیل سرویس‌های Scrubbing، CDNهای بزرگ و همکاری با ISP در دفاع Volumetric اهمیت زیادی دارند.

حملات Protocol یا State Exhaustion چیست؟

این حملات تلاش می‌کنند ظرفیت تجهیزات یا Stack شبکه را مصرف کنند.

هدف ممکن است:

• Firewall
• Load Balancer
• Connection Table
• NAT Table
• Web Server
• یا سایر تجهیزات Stateful

باشد.

در این نوع حمله لزوماً پهنای باند به‌طور کامل اشباع نمی‌شود؛ بلکه ظرفیت نگهداری Connection یا State تمام می‌شود.

در نتیجه کاربران واقعی نمی‌توانند Connection جدید برقرار کنند.

حملات Application Layer DDoS چیست؟

Application Layer Attack یا Layer 7 DDoS مستقیماً برنامه وب را هدف قرار می‌دهد.

این حملات معمولاً از HTTP یا HTTPS استفاده می‌کنند و ممکن است از بیرون بسیار شبیه درخواست کاربران واقعی باشند.

OWASP اشاره می‌کند که حملات لایه Application الزاماً به مصرف پهنای باند بالا نیاز ندارند؛ آن‌ها می‌توانند با فشار عملیاتی روی برنامه، سرویس را غیرقابل استفاده کنند و معمولاً تشخیص آن‌ها دشوارتر است.

چرا Layer 7 خطرناک است؟

فرض کنید صفحه اصلی سایت Cache شده و درخواست آن تقریباً هزینه‌ای ندارد.

اما Endpoint زیر:

جستجوی پیشرفته → چند Query → بررسی دسترسی → ارتباط با سرویس خارجی → تولید خروجی

ممکن است بسیار گران‌تر باشد.

در چنین شرایطی چند صد درخواست سنگین ممکن است اثری بیشتر از هزاران درخواست ساده داشته باشند.

HTTP Flood چیست؟

HTTP Flood اصطلاحی عمومی برای حجم بالای درخواست HTTP یا HTTPS علیه یک سایت یا API است.

درخواست‌ها می‌توانند ظاهراً معتبر باشند.

همین موضوع تشخیص حمله را دشوار می‌کند.

اگر سیستم صرفاً براساس Signature مخرب عمل کند، ممکن است درخواست‌های DDoS Layer 7 چیزی برای Match شدن نداشته باشند.

دفاع در اینجا بیشتر به تحلیل رفتار، Rate Limiting، Cache، WAF و کاهش هزینه Endpointها وابسته است.

Slow HTTP Attack چیست؟

در برخی حملات، مهاجم تلاش می‌کند Connectionها را برای مدت طولانی باز نگه دارد.

به‌جای ارسال سریع مقدار زیادی Data، درخواست‌ها بسیار آهسته یا ناقص ارسال می‌شوند.

هدف این است که Worker یا Connection Slotهای سرور برای مدت طولانی اشغال شوند.

OWASP این دسته را از حملات Application معرفی می‌کند و توصیه می‌کند Minimum Data Rate، Connection Timeout و محدودیت‌های مناسب برای Connectionها تعریف شوند.

حملات Reflection و Amplification چیست؟

در برخی حملات، مهاجم می‌تواند از سرویس‌های دیگر اینترنت برای ارسال ترافیک به قربانی استفاده کند.

در مدل Reflection، درخواست به یک سرویس ثالث فرستاده می‌شود اما پاسخ به سمت قربانی هدایت می‌شود.

در Amplification تلاش می‌شود پاسخ بسیار بزرگ‌تر از درخواست اولیه باشد.

ترکیب این دو می‌تواند حجم قابل توجهی ایجاد کند.

DNS Amplification

DNS یکی از سرویس‌هایی است که در صورت Configuration نامناسب می‌تواند در حملات Amplification مورد سوءاستفاده قرار گیرد.

NIST تأکید می‌کند DNS یکی از اجزایی است که خود می‌تواند هدف DoS باشد و Configuration مناسب DNS برای جلوگیری از برخی حملات اهمیت دارد.

CISA نیز درباره حملات UDP-Based Amplification توصیه می‌کند سرویس‌های غیرضروری غیرفعال شوند، Rate Limiting مناسب اعمال شود و ارائه‌دهندگان شبکه از Source Address Spoofing جلوگیری کنند.

Multi-Vector DDoS چیست؟

مهاجمان الزاماً فقط از یک نوع حمله استفاده نمی‌کنند.

ممکن است هم‌زمان:

• پهنای باند هدف قرار گیرد.
• Connection Table تحت فشار قرار گیرد.
• Endpointهای سنگین Application درخواست زیادی دریافت کنند.

به چنین وضعیتی Multi-Vector Attack گفته می‌شود.

دفاعی که فقط برای یک Vector طراحی شده باشد ممکن است در برابر ترکیب حملات عملکرد مناسبی نداشته باشد.

تفاوت DDoS لایه شبکه و لایه Application

هیچ‌کدام لزوماً «خطرناک‌تر» نیستند؛ اثر واقعی به معماری هدف بستگی دارد.

کدام بخش‌های سایت بیشتر در معرض DDoS هستند؟

هر Endpoint هزینه پردازشی یکسانی ندارد.

شناخت Endpointهای گران‌قیمت بخش مهمی از طراحی ضد DDoS است.

صفحه اصلی

اگر صفحه اصلی Dynamic باشد و برای هر Request چندین Query اجرا کند، می‌تواند تحت فشار قرار گیرد.

Caching مناسب ریسک را به‌شدت کاهش می‌دهد.

صفحه جستجو

Search معمولاً یکی از Endpointهای پرهزینه است.

جستجوی آزاد روی حجم بزرگی از داده‌ها می‌تواند CPU و Database را تحت فشار قرار دهد.

صفحه ورود

Login علاوه بر Database ممکن است از Hashing Password، Session، CAPTCHA، سرویس MFA یا Logging استفاده کند.

به همین دلیل Authentication Endpoint باید Rate Limit مستقل داشته باشد.

ثبت‌نام

Registration ممکن است باعث:

• ایجاد Database Record
• ارسال Email
• ارسال SMS
• Validation خارجی
• ایجاد Profile

شود.

اگر Rate Limit وجود نداشته باشد، مهاجم می‌تواند علاوه بر Availability، هزینه مالی نیز ایجاد کند.

فراموشی رمز عبور

Forgot Password می‌تواند ارسال Email یا SMS ایجاد کند.

این قابلیت باید در برابر Abuse محافظت شود.

آپلود فایل

پردازش تصویر، تبدیل فایل، ساخت Thumbnail، Virus Scan و ذخیره‌سازی همگی منابع مصرف می‌کنند.

OWASP توصیه می‌کند اندازه فایل و حجم Request محدود شود تا ورودی کاربر نتواند منابع سیستم را بدون کنترل مصرف کند.

API

APIهایی که Aggregate Query، Export، Report Generation یا پردازش پیچیده دارند می‌توانند اهداف جذابی برای Application-Level DoS باشند.

هر Endpoint باید براساس Cost واقعی خود محدود شود، نه اینکه یک Rate Limit عمومی برای کل API تعریف شود.

نشانه‌های حمله DDoS به سایت

هر افزایش ترافیکی DDoS نیست.

ممکن است یک کمپین تبلیغاتی موفق، انتشار خبر مهم یا Viral شدن محتوا باعث افزایش طبیعی کاربران شود.

بنابراین تشخیص باید مبتنی بر چند سیگنال باشد.

افزایش ناگهانی Request Rate

اولین نشانه می‌تواند جهش شدید Request Per Second باشد.

اما باید آن را با Baseline عادی سایت مقایسه کرد.

افزایش پهنای باند

در Volumetric Attack ممکن است Network Throughput ناگهان به سقف اتصال برسد.

افزایش CPU و RAM

در Application DDoS ممکن است پهنای باند طبیعی به نظر برسد اما CPU، Memory یا Workerها اشباع شوند.

افزایش Connectionهای هم‌زمان

تعداد غیرعادی Concurrent Connection می‌تواند نشانه حملات Protocol یا Slow Request باشد.

افزایش خطاهای 5xx

وقتی Backend دیگر توان پاسخ‌گویی ندارد، خطاهای 500، 502، 503 و 504 ممکن است افزایش پیدا کنند.

افزایش Latency

گاهی اولین علامت، کند شدن محسوس پاسخ‌هاست.

اگر Response Time به‌تدریج بالا می‌رود، ممکن است Poolها یا منابع داخلی در حال نزدیک شدن به سقف باشند.

ترافیک غیرعادی روی یک Endpoint

اگر ۸۰ درصد Requestهای جدید فقط یک مسیر خاص را هدف قرار دهند، باید آن Endpoint بررسی شود.

تغییر نسبت Cache Hit

اگر مهاجم عمداً URLهای منحصر‌به‌فرد ایجاد کند، ممکن است Cache Hit Ratio کاهش پیدا کند و درخواست‌های بیشتری به Origin برسند.

افزایش Database Connection

در Layer 7 ممکن است Web Server هنوز Connection بپذیرد اما Database Pool به سقف برسد.

بنابراین مانیتورینگ فقط CPU سرور کافی نیست.

چگونه حمله DDoS را از افزایش طبیعی ترافیک تشخیص دهیم؟

این تشخیص همیشه ساده نیست.

یک Flash Crowd واقعی نیز می‌تواند شبیه DDoS باشد.

بهتر است موارد زیر در کنار هم تحلیل شوند:

• الگوی جغرافیایی کاربران
• Session Behavior
• URL Distribution
• نرخ درخواست در هر کاربر
• Cookie Behavior
• User-Agent Distribution
• Cache Hit Rate
• Conversion یا تعامل واقعی
• درخواست‌های تکراری
• زمان‌بندی Requestها

ترافیک انسانی معمولاً رفتار متنوع‌تری دارد.

کاربر صفحات مختلف را می‌بیند، Asset دانلود می‌کند و Session ایجاد می‌کند.

ترافیک خودکار ممکن است یک Pattern بسیار تکراری داشته باشد.

اما Botهای پیشرفته می‌توانند رفتار مشابه مرورگر واقعی ایجاد کنند؛ بنابراین یک Signal به‌تنهایی کافی نیست.

مهم‌ترین روش‌های جلوگیری از حملات DDoS

جلوگیری کامل از ارسال ترافیک مخرب به اینترنت تقریباً ممکن نیست.

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

OWASP تأکید می‌کند دفاع DoS یک راهکار تک‌مرحله‌ای نیست و باید براساس معماری، منابع، نقاط شکست و هزینه‌های سیستم طراحی شود.

استفاده از CDN

Content Delivery Network یکی از مؤثرترین ابزارهای اولیه برای افزایش مقاومت وب‌سایت در برابر DDoS است.

CDN درخواست کاربران را ابتدا در شبکه توزیع‌شده خود دریافت می‌کند.

CDN چه کمکی می‌کند؟

محتوای Static می‌تواند از Cache Edge پاسخ داده شود.

در نتیجه تعداد درخواست‌هایی که به Origin Server می‌رسند کاهش پیدا می‌کند.

شبکه بزرگ CDN همچنین ظرفیت بسیار بیشتری برای جذب Traffic Spike دارد.

OWASP نیز Caching و میزبانی Static Resourceها خارج از Origin را از روش‌های افزایش مقاومت در برابر مصرف پهنای باند معرفی می‌کند.

مخفی کردن Origin Server

اگر مهاجم IP واقعی Origin را بداند، ممکن است CDN را دور بزند و مستقیم سرور را هدف قرار دهد.

بنابراین بهتر است Origin فقط درخواست‌های شبکه CDN، Load Balancer یا Proxy مورد اعتماد را بپذیرد.

این کنترل باید در Firewall یا Security Group اعمال شود.

البته طراحی دقیق آن به زیرساخت و Provider بستگی دارد.

استفاده از WAF

Web Application Firewall در Layer 7 نقش مهمی دارد.

WAF می‌تواند:

• Patternهای غیرعادی را تشخیص دهد.
• Requestهای تکراری را محدود کند.
• Botها را Challenge کند.
• قوانین Endpoint-Specific اجرا کند.
• IP Reputation را بررسی کند.

اما WAF نباید تنها لایه دفاعی باشد.

حمله‌ای که پهنای باند شبکه را قبل از رسیدن به WAF اشباع کند، با WAF داخل سرور حل نمی‌شود.

Rate Limiting

Rate Limiting تعداد درخواست مجاز را در یک بازه زمانی کنترل می‌کند.

این محدودیت می‌تواند براساس:

• IP
• User
• Session
• API Key
• Endpoint
• Device
• یا ترکیب چند سیگنال

اعمال شود.

OWASP Rate Limiting را یکی از مکانیزم‌های کلیدی مقابله با DoS معرفی می‌کند و توصیه می‌کند نرخ عادی ترافیک براساس Logها Baseline شود تا محدودیت‌ها به کاربران واقعی آسیب نزنند.

Rate Limit یکسان برای همه Endpointها اشتباه است

فرض کنید:

GET /logo.png

و

POST /generate-report

هر دو اجازه ۱۰۰ درخواست در دقیقه داشته باشند.

Request اول تقریباً رایگان است اما Request دوم ممکن است پردازش سنگینی ایجاد کند.

بنابراین Rate Limit باید Cost-Aware باشد.

Endpointهای سنگین باید محدودیت سخت‌گیرانه‌تری داشته باشند.

استفاده از Caching

Cache یکی از قدرتمندترین ابزارها در برابر Application DDoS است.

اگر پاسخ یک صفحه یا API قابل Cache باشد، درخواست‌های تکراری نیازی به اجرای کامل Application و Database ندارند.

چه چیزهایی را می‌توان Cache کرد؟

بسته به سایت:

• صفحات عمومی
• تصاویر
• CSS
• JavaScript
• APIهای Read-Only
• Queryهای پرتکرار
• داده‌های نیمه‌ثابت

هر Request که در Edge پاسخ داده شود یک Request کمتر برای Origin است.

Load Balancing

Load Balancer ترافیک را میان چند Server توزیع می‌کند.

این روش ظرفیت و Availability را افزایش می‌دهد.

اما Load Balancer خود نباید Single Point of Failure باشد.

OWASP به جلوگیری از Single Point of Failure، استفاده از Redundancy و طراحی Fault-Tolerant به‌عنوان اصول مهم مقاومت در برابر DoS اشاره می‌کند.

Autoscaling

در Cloud Environment می‌توان با افزایش Load، Instanceهای جدید ایجاد کرد.

Autoscaling برای Traffic Spike طبیعی و بخشی از حملات Application مفید است.

اما Autoscaling بدون کنترل می‌تواند هزینه را به‌شدت افزایش دهد.

بنابراین باید در کنار:

• Rate Limiting
• Maximum Scaling Limit
• Budget Alert
• WAF
• Cache

استفاده شود.

ایجاد Redundancy

اگر کل سایت به یک Web Server، یک Database یا یک DNS Server وابسته باشد، همان بخش تبدیل به Single Point of Failure می‌شود.

Redundancy می‌تواند در سطوح مختلف وجود داشته باشد:

• چند Application Server
• Database Replication
• چند Availability Zone
• DNS مقاوم
• Storage افزونه
• Providerهای ارتباطی متعدد

معماری باید براساس اهمیت سرویس طراحی شود.

استفاده از Anycast

Anycast اجازه می‌دهد یک IP از چند نقطه شبکه Advertise شود و ترافیک به نزدیک‌ترین یا مناسب‌ترین Location هدایت شود.

بسیاری از CDNها و سرویس‌های DDoS Protection از Anycast برای توزیع بار حمله میان نقاط متعدد استفاده می‌کنند.

برای یک سایت کوچک پیاده‌سازی مستقیم Anycast معمولاً منطقی نیست، اما استفاده از Providerهایی که چنین زیرساختی دارند می‌تواند بسیار مؤثر باشد.

DDoS Scrubbing چیست؟

در حملات بزرگ، ترافیک می‌تواند به Scrubbing Center هدایت شود.

در این مراکز Traffic با ظرفیت بسیار بالا تحلیل می‌شود، بخش مخرب حذف شده و Traffic سالم به Origin تحویل داده می‌شود.

این روش به‌خصوص برای Volumetric Attack اهمیت دارد.

OWASP نیز استفاده از Cloud Filtering Service را برای مقابله با حملات حجیم پیشنهاد می‌کند.

محدود کردن Connectionها

برای مقابله با Exhaustion باید سقف‌هایی برای:

• Connection هم‌زمان
• Request Rate
• Connection Lifetime
• Request Size
• Upload Size

وجود داشته باشد.

اگر هر Client بتواند تعداد نامحدودی Connection باز کند، یک ضعف معماری ایجاد می‌شود.

تنظیم Timeout مناسب

Connection نباید بدون دلیل مدت طولانی باز بماند.

Timeoutهای مناسب برای:

• Header
• Request Body
• Backend
• Database
• Upstream API

می‌توانند جلوی اشغال طولانی منابع را بگیرند.

Timeout بیش از حد کوتاه نیز کاربران دارای ارتباط ضعیف را دچار مشکل می‌کند؛ بنابراین باید با داده واقعی تنظیم شود.

محدود کردن Request Size

Request بزرگ می‌تواند Memory و Bandwidth بیشتری مصرف کند.

برای Formها، JSON، XML و Upload باید سقف منطقی تعریف شود.

OWASP برای Web Serviceها نیز محدود کردن Message Size و منابع CPU، Memory، Connection و Process را توصیه می‌کند.

بهینه‌سازی Database

Database معمولاً یکی از اولین Bottleneckهای Layer 7 است.

مواردی مانند:

• Query بدون Index
• N+1 Query
• Search سنگین
• Connection Leak
• Lock طولانی

می‌توانند اثر DDoS را چند برابر کنند.

یک برنامه بهینه ذاتاً مقاومت بیشتری در برابر Traffic Spike دارد.

جلوگیری از عملیات پرهزینه غیرضروری

OWASP توصیه می‌کند عملیات بسیار CPU-Intensive بررسی شوند و Validationهای ارزان‌تر قبل از عملیات گران انجام شوند.

برای مثال، قبل از اجرای پردازش سنگین بهتر است ابتدا بررسی‌های ساده مانند:

Authentication، Size Limit، Format Validation و Rate Limit

انجام شوند.

این اصل باعث می‌شود Request نامعتبر قبل از مصرف منابع اصلی Reject شود.

استفاده از Queue

عملیاتی که لازم نیست فوری انجام شوند می‌توانند به Queue منتقل شوند.

برای مثال:

• ارسال Email
• ساخت Report
• پردازش فایل
• تولید Thumbnail
• Webhook Processing

اگر همه این عملیات در همان Request انجام شوند، تعداد کمی Request می‌تواند Workerها را مشغول کند.

Queue امکان کنترل Concurrency و Backpressure را فراهم می‌کند.

Circuit Breaker

اگر یک سرویس خارجی Down یا کند شود، Application نباید بی‌نهایت منتظر آن بماند.

Circuit Breaker می‌تواند پس از تشخیص Failure، درخواست‌های جدید را موقتاً متوقف کند و اجازه دهد سیستم Graceful Degradation داشته باشد.

OWASP نیز Graceful Degradation و جلوگیری از انتشار Failure میان اجزای سیستم را از اصول طراحی مقاوم در برابر DoS می‌داند.

Graceful Degradation چیست؟

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

برای مثال هنگام Load شدید:

• Search پیشرفته غیرفعال شود.
• Recommendation موقتاً متوقف شود.
• تصاویر با کیفیت پایین‌تر ارائه شوند.
• Report Generation متوقف شود.
• فقط قابلیت‌های اصلی فعال بمانند.

این طراحی می‌تواند Availability سرویس حیاتی را حفظ کند.

حفاظت از DNS

اگر DNS از دسترس خارج شود، حتی سالم‌ترین Origin Server نیز برای بسیاری از کاربران قابل دسترسی نخواهد بود.

بهتر است از DNS Provider مقاوم و توزیع‌شده استفاده شود.

Name Serverها نیز نباید همگی در یک نقطه زیرساختی قرار داشته باشند.

مانیتورینگ مداوم

برای دفاع در برابر DDoS باید وضعیت عادی سایت را بشناسید.

اگر Baseline ندارید، تشخیص حمله دشوار می‌شود.

مهم‌ترین Metrics عبارت‌اند از:

• Request Per Second
• Bandwidth
• Concurrent Connections
• CPU
• RAM
• Load Average
• Response Time
• Error Rate
• Cache Hit Ratio
• Database Connections
• Queue Length
• Origin Request Rate

Thresholdها باید براساس رفتار واقعی سایت تنظیم شوند.

هشدار امنیتی DDoS

Monitoring بدون Alerting کافی نیست.

اگر Traffic پنج برابر شود اما هیچ‌کس متوجه نشود، واکنش دیر خواهد بود.

Alert می‌تواند براساس ترکیب شرایط تعریف شود.

برای مثال افزایش Request Rate همراه با کاهش Cache Hit و افزایش 5xx اهمیت بیشتری نسبت به افزایش Request به‌تنهایی دارد.

ثبت Logهای مناسب

Logها برای تشخیص Vector حمله ضروری هستند.

اما در DDoS باید مراقب بود Logging بیش از حد خودش Bottleneck ایجاد نکند.

اگر میلیون‌ها Request مخرب برای هر Request چندین خط Log روی Disk ایجاد کنند، Storage I/O می‌تواند مشکل جدیدی ایجاد کند.

بنابراین Logging باید ساختاریافته، محدود و قابل Scale باشد.

چگونه از سایت وردپرسی در برابر DDoS محافظت کنیم؟

وردپرس به دلیل محبوبیت بالا معمولاً Traffic Bot زیادی دریافت می‌کند.

دفاع باید هم در سطح WordPress و هم در لایه زیرساخت انجام شود.

استفاده از CDN برای وردپرس

Static Assetها و در صورت امکان صفحات Cacheable باید از Edge ارائه شوند.

هر Request که به PHP و Database نرسد، مصرف منابع Origin را کاهش می‌دهد.

فعال کردن Page Cache

سایت وردپرسی بدون Cache ممکن است برای هر مشاهده صفحه PHP و Database را درگیر کند.

Page Cache می‌تواند حجم زیادی از Requestها را بدون پردازش مجدد پاسخ دهد.

استفاده از Object Cache

Object Cache مانند Redis در سایت‌های پرترافیک می‌تواند بار Database را کاهش دهد.

البته Configuration باید متناسب با سایت انجام شود.

محافظت از wp-login

صفحه ورود باید Rate Limit داشته باشد.

اما DDoS وردپرس فقط Login را هدف قرار نمی‌دهد.

بنابراین محدود کردن wp-login به‌تنهایی دفاع کامل نیست.

بررسی XML-RPC

اگر سایت به XML-RPC نیاز ندارد، می‌توان براساس نیاز واقعی دسترسی به آن را محدود کرد.

اما غیرفعال‌سازی کورکورانه توصیه نمی‌شود؛ برخی Integrationها ممکن است وابسته باشند.

محدود کردن Endpointهای سنگین

افزونه‌هایی که Search، Export، Ajax یا APIهای پردازشی ایجاد می‌کنند باید بررسی شوند.

یکی از رایج‌ترین مشکلات وردپرس این است که یک Plugin Endpoint بدون Cache و بدون Rate Limit در دسترس قرار می‌دهد.

حذف افزونه‌های غیرضروری

هر افزونه می‌تواند Request Handler یا Endpoint جدید ایجاد کند.

حذف Pluginهای بلااستفاده علاوه بر امنیت عمومی، سطح پردازشی و Attack Surface را کاهش می‌دهد.

استفاده از Hosting مناسب

اگر سایت برای کسب‌وکار مهم است، Shared Hosting بسیار محدود ممکن است در برابر Traffic Spike کوچک نیز دچار مشکل شود.

Hosting باید منابع، Network Capacity و DDoS Protection متناسب با ریسک سایت داشته باشد.

آیا افزونه امنیتی وردپرس جلوی DDoS را می‌گیرد؟

به‌تنهایی خیر.

Plugin داخل WordPress زمانی Request را می‌بیند که ترافیک معمولاً به Origin و PHP رسیده است.

اگر حمله پهنای باند را اشباع کند، PHP هرگز فرصت دفاع پیدا نمی‌کند.

افزونه امنیتی می‌تواند در برخی Layer 7 Abuseها کمک کند اما دفاع اصلی DDoS باید در Edge و Network نیز وجود داشته باشد.

آیا WAF به‌تنهایی DDoS را متوقف می‌کند؟

خیر.

WAF به‌خصوص برای Layer 7 بسیار مفید است، اما Volumetric Attack ممکن است ظرفیت شبکه را قبل از WAF محلی اشباع کند.

بهترین طراحی شامل چند لایه است:

Edge Protection → CDN → DDoS Mitigation → WAF → Load Balancer → Application Rate Limit → Backend Protection

آیا افزایش RAM و CPU راه‌حل DDoS است؟

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

اگر مهاجم بتواند Traffic را متناسب با ظرفیت شما افزایش دهد، مسابقه منابع ایجاد می‌شود.

همچنین در Volumetric Attack مشکل ممکن است پهنای باند باشد نه CPU.

Scaling باید همراه با Filtering و Rate Limiting انجام شود.

آیا مسدود کردن IPها کافی است؟

در حملات کوچک ممکن است مفید باشد، اما در DDoS واقعی ترافیک می‌تواند از تعداد بسیار زیادی IP بیاید.

همچنین برخی IPها ممکن است متعلق به کاربران واقعی، Proxyها یا شبکه‌های اشتراکی باشند.

Blocklist دستی نباید هسته اصلی دفاع باشد.

آیا Geo Blocking مفید است؟

اگر کسب‌وکار واقعاً فقط در یک کشور فعالیت دارد، محدودسازی برخی Regionها می‌تواند سطح حمله را کاهش دهد.

اما Geo Blocking باید براساس نیاز کسب‌وکار انجام شود.

IP Geolocation دقیق مطلق نیست و کاربران VPN نیز وجود دارند.

بنابراین این روش مکمل است.

CAPTCHA در برابر DDoS چه نقشی دارد؟

CAPTCHA برای تشخیص بخشی از Botهای Layer 7 می‌تواند مفید باشد.

اما OWASP صراحتاً اشاره می‌کند Puzzleها مانند CAPTCHA برای جلوگیری از سوءاستفاده از Functionها کاربرد دارند ولی راهکار عمومی دفاع در برابر DoS نیستند.

در Volumetric Attack، نمایش CAPTCHA اساساً مشکل پهنای باند را حل نمی‌کند.

برنامه واکنش به حمله DDoS

زمان حمله مناسب تصمیم‌گیری از صفر نیست.

یک سازمان باید از قبل Runbook مشخص داشته باشد.

مشخص کردن مسئول Incident

باید مشخص باشد چه کسی تصمیم‌گیر اصلی است و چه افرادی با Hosting Provider، CDN، ISP و تیم توسعه ارتباط می‌گیرند.

اطلاعات تماس Providerها

CISA توصیه می‌کند سازمان‌ها از قبل برای هماهنگی با Providerهای بالادستی آماده باشند.

شماره و مسیر ارتباط اضطراری نباید هنگام Down شدن سایت تازه جستجو شود.

مشخص کردن دارایی‌های حیاتی

همه قابلیت‌ها اهمیت یکسانی ندارند.

در زمان Crisis ممکن است حفظ Login و Checkout مهم‌تر از Search پیشرفته باشد.

تعریف Emergency Rules

WAF Rules، Rate Limit سخت‌گیرانه‌تر و Challenge Mode بهتر است از قبل آماده باشند.

آماده کردن Status Page

اگر سایت اصلی Down شود، کاربران باید بتوانند وضعیت سرویس را از مسیری مستقل مشاهده کنند.

Status Page بهتر است روی زیرساختی جدا از Origin اصلی باشد.

هنگام حمله DDoS چه کار کنیم؟

در زمان حمله ابتدا باید Vector و Bottleneck مشخص شوند.

اگر پهنای باند اشباع شده، تغییر تنظیمات PHP کمکی نمی‌کند.

اگر Database CPU به ۱۰۰ درصد رسیده اما Network طبیعی است، احتمالاً با Layer 7 روبه‌رو هستیم.

Metrics را بررسی کنید

Network، Application، CDN و Database باید هم‌زمان بررسی شوند.

Provider را درگیر کنید

در حملات بزرگ، Hosting Provider یا DDoS Protection Provider نقش اصلی دارد.

قوانین موقت اعمال کنید

ممکن است لازم باشد برخی Endpointها موقتاً محدود یا غیرفعال شوند.

Cache را افزایش دهید

در صورت امکان TTL محتوا را افزایش دهید تا Origin Load کاهش پیدا کند.

قابلیت‌های غیرضروری را غیرفعال کنید

Graceful Degradation در این مرحله بسیار ارزشمند است.

از تصمیم‌های عجولانه خودداری کنید

Block کردن یک کشور یا تمام کاربران Anonymous ممکن است کسب‌وکار را بیشتر از حمله مختل کند.

هر Rule باید با Metrics ارزیابی شود.

بعد از حمله DDoS چه کارهایی باید انجام شود؟

پایان ترافیک حمله به معنی پایان Incident نیست.

باید Post-Incident Review انجام شود.

بررسی Timeline

مشخص کنید:

• حمله چه زمانی شروع شد؟
• چه زمانی تشخیص داده شد؟
• اولین اقدام چه بود؟
• چه زمانی سرویس پایدار شد؟

این اطلاعات Mean Time to Detect و Mean Time to Recover را مشخص می‌کنند.

شناسایی Bottleneck

کدام بخش ابتدا شکست خورد؟

Bandwidth؟

Load Balancer؟

PHP Worker؟

Database؟

Third-Party API؟

این نقطه باید برای آینده تقویت شود.

بررسی اثربخشی Ruleها

کدام WAF Rule یا Rate Limit مؤثر بود؟

کدام‌یک کاربران واقعی را Block کرد؟

داده واقعی Incident بهترین منبع برای بهبود Config است.

بررسی هزینه

Cloud Cost، Bandwidth، Support و Downtime باید تحلیل شوند.

گاهی هزینه Mitigation دائمی بسیار کمتر از خسارت یک Incident بعدی است.

به‌روزرسانی Runbook

هر حادثه باید Defense Plan را بهتر کند.

اگر Incident بدون تغییر در Runbook تمام شود، بخش مهمی از ارزش آن از دست رفته است.

معماری مقاوم در برابر DDoS چگونه طراحی می‌شود؟

دفاع مؤثر باید از بیرونی‌ترین لایه شبکه تا داخل Application ادامه داشته باشد.

یک مدل مناسب می‌تواند شامل این مسیر باشد:

Internet → Anycast/CDN → DDoS Protection → WAF → Rate Limiting → Load Balancer → Cache → Application → Database

در هر مرحله بخشی از ترافیک مخرب حذف یا کنترل می‌شود.

اگر یک Request غیرضروری بتواند بدون هیچ Filter مستقیماً به Database برسد، معماری در برابر Layer 7 شکننده خواهد بود.

Defense in Depth در DDoS چیست؟

Defense in Depth یعنی شکست یک کنترل باعث شکست کل سیستم نشود.

اگر CDN نتوانست یک Bot را تشخیص دهد، WAF باید فرصت بررسی داشته باشد.

اگر WAF درخواست را عبور داد، Application Rate Limit وجود داشته باشد.

اگر Load افزایش یافت، Autoscaling فعال شود.

اگر Backend Service دچار مشکل شد، Circuit Breaker مانع انتشار Failure شود.

اگر بخشی از سیستم Down شد، Graceful Degradation قابلیت‌های اصلی را حفظ کند.

این زنجیره همان چیزی است که مقاومت واقعی ایجاد می‌کند.

اشتباهات رایج در مقابله با DDoS

اتکا به سرور قوی

سرور قدرتمند مفید است اما هیچ ظرفیت محدودی در برابر Traffic نامحدود تضمین ایجاد نمی‌کند.

خرید پهنای باند بدون Filtering

پهنای باند بیشتر فقط آستانه شکست را جابه‌جا می‌کند.

قرار دادن Firewall فقط روی Origin

اگر لینک Network قبل از Firewall اشباع شود، Firewall نمی‌تواند ترافیک را نجات دهد.

نبود Cache

ارسال تمام Requestها به Application یکی از پرهزینه‌ترین طراحی‌ها برای سایت عمومی است.

Rate Limit بسیار سخت

Rate Limit اشتباه می‌تواند Flash Crowd واقعی را به حمله تبدیل کند و کاربران قانونی را Block کند.

نبود Baseline

بدون دانستن Traffic عادی، تشخیص رفتار غیرعادی دشوار است.

نبود برنامه Incident Response

واکنش دستی و بدون Runbook زمان بازیابی را افزایش می‌دهد.

فراموش کردن DNS

امنیت Origin بدون DNS مقاوم کامل نیست.

Logging بیش از حد

در حمله بزرگ، Log حجیم می‌تواند Disk و Storage Pipeline را دچار مشکل کند.

تست مقاومت سایت در برابر DDoS

تست Availability باید تنها در محیط و زیرساختی انجام شود که مجوز صریح برای آن وجود دارد.

تولید Traffic سنگین علیه سرویس دیگران می‌تواند باعث اختلال واقعی و مسائل حقوقی شود.

برای یک کسب‌وکار، Load Testing کنترل‌شده در Staging یا با هماهنگی Hosting Provider می‌تواند پاسخ دهد:

• ظرفیت عادی سایت چقدر است؟
• اولین Bottleneck چیست؟
• Autoscaling چقدر سریع عمل می‌کند؟
• Rate Limit چه زمانی فعال می‌شود؟
• Cache چه درصدی از Origin Requestها را حذف می‌کند؟
• Database در چه Loadی اشباع می‌شود؟
• Graceful Degradation عمل می‌کند؟
• Alertها به‌موقع فعال می‌شوند؟

هدف Load Test ایجاد اختلال نیست؛ هدف شناخت ظرفیت قبل از حادثه است.

تفاوت Load Testing و DDoS Testing چیست؟

Load Testing معمولاً برای بررسی Performance در شرایط کنترل‌شده انجام می‌شود.

DDoS Simulation علاوه بر Load می‌تواند عملکرد سیستم دفاعی و Filtering را بررسی کند.

هر دو باید با برنامه و مجوز انجام شوند.

Testing بدون هماهنگی ممکن است از دید Provider حمله واقعی تلقی شود.

DDoS و سایت‌های فروشگاهی

فروشگاه اینترنتی یکی از حساس‌ترین اهداف از نظر Availability است.

Down شدن سایت می‌تواند مستقیماً به کاهش فروش منجر شود.

Endpointهای حساس عبارت‌اند از:

• صفحه محصول
• Search
• Cart
• Checkout
• Login
• Payment Callback
• Inventory API

در طراحی دفاعی باید Checkout و Payment Callback بالاترین اولویت Availability را داشته باشند.

حتی اگر Recommendation یا Search موقتاً محدود شود، خرید کاربران موجود باید ادامه پیدا کند.

DDoS و APIها

APIها به دلیل Machine-to-Machine بودن باید Rate Limiting دقیق‌تری داشته باشند.

برای هر Client می‌توان Quota مشخص کرد.

API Key یا User Identity نیز می‌تواند به Rate Limit کمک کند.

اما Public Endpointهایی که Authentication ندارند باید محافظت بیشتری در Edge داشته باشند.

DDoS و سرویس‌های مالی

سامانه‌های مالی علاوه بر Availability با ریسک‌های Regulatory و اعتماد مشتری روبه‌رو هستند.

در چنین سیستم‌هایی Redundancy، Multi-Region، Monitoring و Incident Response اهمیت بیشتری دارند.

همچنین عملیات پرهزینه باید از Endpointهای ساده جدا شوند تا Failure یک Feature کل سیستم را تحت تأثیر قرار ندهد.

آیا DDoS باعث هک شدن سایت می‌شود؟

DDoS به‌خودی‌خود به معنی دسترسی غیرمجاز به اطلاعات نیست.

هدف اصلی Denial of Service مختل کردن Availability است.

بااین‌حال نباید در زمان حمله فرض کرد هیچ فعالیت امنیتی دیگری در جریان نیست.

DDoS می‌تواند هم‌زمان با حملات دیگر رخ دهد.

بنابراین Logهای Authentication، تغییر فایل، Account Activity و سایر Indicators نیز باید بررسی شوند.

آیا HTTPS جلوی DDoS را می‌گیرد؟

خیر.

HTTPS برای محرمانگی و تمامیت ارتباط ضروری است اما جلوی ارسال درخواست زیاد را نمی‌گیرد.

حتی پردازش TLS خود مقداری Resource مصرف می‌کند.

سرویس‌های Edge می‌توانند TLS Termination را خارج از Origin انجام دهند و بار سرور را کاهش دهند.

آیا تغییر IP سرور حمله DDoS را متوقف می‌کند؟

گاهی ممکن است موقتاً مؤثر باشد، اما راهکار پایدار نیست.

اگر IP جدید دوباره افشا شود، حمله بازمی‌گردد.

بهتر است Origin پشت Proxy یا CDN مقاوم قرار گیرد و IP واقعی مستقیماً قابل دسترسی نباشد.

آیا DDoS Protection برای سایت کوچک لازم است؟

سطح دفاع باید متناسب با اهمیت سایت باشد.

یک وبلاگ شخصی و یک فروشگاه با هزاران تراکنش روزانه نیاز یکسانی ندارند.

اما حداقل اقدامات مانند CDN، Cache، Rate Limiting و Hosting مناسب برای بسیاری از سایت‌ها منطقی هستند.

بسیاری از این کنترل‌ها علاوه بر DDoS، Performance سایت را نیز بهتر می‌کنند.

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

• CDN مناسب برای سایت فعال کنید.
• IP واقعی Origin را تا حد امکان از دسترسی مستقیم محافظت کنید.
• از WAF در Edge استفاده کنید.
• Rate Limit برای Endpointهای حساس تعریف کنید.
• محدودیت‌ها را براساس هزینه واقعی Endpoint تنظیم کنید.
• Page Cache و Object Cache مناسب داشته باشید.
• Static Assetها را از Edge ارائه کنید.
• Connection Timeout منطقی تعریف کنید.
• Request و Upload Size را محدود کنید.
• تعداد Connectionهای هم‌زمان را کنترل کنید.
• Queryهای Database را بهینه کنید.
• Endpointهای بسیار پرهزینه را شناسایی کنید.
• از Load Balancing و Redundancy استفاده کنید.
• Single Point of Failureها را حذف کنید.
• Autoscaling را همراه با سقف هزینه تنظیم کنید.
• DNS مقاوم و توزیع‌شده انتخاب کنید.
• Metrics زیرساخت و Application را مانیتور کنید.
• برای Traffic Spike هشدار تعریف کنید.
• اطلاعات تماس اضطراری Hosting و Provider را نگه دارید.
• Runbook مقابله با DDoS تهیه کنید.
• Status Page مستقل داشته باشید.
• به‌صورت دوره‌ای Load Test مجاز انجام دهید.
• پس از هر Incident گزارش و Retrospective تهیه کنید.

سوالات متداول درباره حملات DDoS

حمله DDoS چیست؟

DDoS یا Distributed Denial of Service حمله‌ای است که با استفاده از منابع متعدد تلاش می‌کند ظرفیت شبکه، سرور یا برنامه هدف را مصرف کند و دسترسی کاربران واقعی به سرویس را مختل سازد.

تفاوت DoS و DDoS چیست؟

در DoS معمولاً تعداد منابع حمله محدودتر است، در حالی که DDoS از تعداد زیادی منبع توزیع‌شده استفاده می‌کند. به همین دلیل مسدود کردن منبع حمله در DDoS بسیار دشوارتر است.

آیا DDoS فقط با ترافیک بسیار زیاد انجام می‌شود؟

خیر. حملات Layer 7 ممکن است با تعداد Request کمتر اما پرهزینه، منابع Application یا Database را مصرف کنند.

بهترین روش جلوگیری از DDoS چیست؟

هیچ ابزار واحدی کافی نیست. CDN، WAF، Rate Limiting، Cache، Load Balancing، Redundancy، Monitoring و DDoS Protection باید در قالب یک معماری چندلایه استفاده شوند.

آیا Cloudflare یا CDN مشابه می‌تواند جلوی DDoS را بگیرد؟

سرویس‌های CDN و Edge می‌توانند بخش بزرگی از حملات را جذب یا فیلتر کنند، اما سطح حفاظت به سرویس، Plan، نوع حمله و Configuration بستگی دارد. Backend نیز باید مستقل از CDN کنترل‌های امنیتی خود را داشته باشد.

آیا WAF جلوی DDoS را می‌گیرد؟

WAF برای Application Layer بسیار مفید است اما به‌تنهایی تمام حملات، به‌خصوص حملات Volumetric بزرگ، را متوقف نمی‌کند.

آیا مسدود کردن IP مهاجم کافی است؟

در DDoS معمولاً خیر، زیرا Traffic می‌تواند از هزاران یا میلیون‌ها IP مختلف ارسال شود.

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

افزایش ظرفیت کمک می‌کند اما دفاع کامل نیست. مهاجم ممکن است Traffic را افزایش دهد یا پهنای باند شبکه را هدف بگیرد.

آیا سایت وردپرسی بیشتر در معرض DDoS است؟

هر سایت قابل دسترس از اینترنت می‌تواند هدف DDoS باشد. وردپرس به دلیل محبوبیت زیاد Bot Traffic بیشتری دریافت می‌کند، اما معماری Hosting، Cache، CDN و افزونه‌ها تعیین‌کننده میزان مقاومت واقعی هستند.

آیا افزونه امنیتی وردپرس برای DDoS کافی است؟

خیر. Plugin پس از رسیدن Request به WordPress عمل می‌کند. دفاع در برابر حملات حجیم باید در شبکه یا Edge نیز انجام شود.

آیا CAPTCHA از DDoS جلوگیری می‌کند؟

CAPTCHA می‌تواند بخشی از Botهای Layer 7 را محدود کند، اما راهکار جامع DDoS نیست و حملات پهنای باند را حل نمی‌کند.

چطور بفهمیم سایت تحت DDoS است؟

افزایش ناگهانی Request، پهنای باند، Connectionها، Latency، خطاهای 5xx و مصرف CPU یا Database می‌تواند نشانه باشد. تشخیص دقیق باید با Baseline و تحلیل Logها انجام شود.

هنگام DDoS ابتدا چه کاری انجام دهیم؟

باید مشخص شود Bottleneck در کدام لایه قرار دارد و سپس Provider مربوط، مانند CDN، Hosting یا ISP، درگیر شود. فعال‌سازی Ruleهای اضطراری، Rate Limit و محدود کردن قابلیت‌های غیرضروری نیز می‌تواند به بازیابی سرویس کمک کند.

جمع‌بندی

حملات DDoS یکی از مهم‌ترین تهدیدها علیه دسترس‌پذیری سایت‌ها و سرویس‌های آنلاین هستند. برخلاف بسیاری از حملات که روی سرقت اطلاعات یا تصاحب حساب تمرکز دارند، DDoS تلاش می‌کند با مصرف پهنای باند، Connection، CPU، Memory، Database یا سایر منابع، دسترسی کاربران قانونی به سرویس را مختل کند.

این حملات می‌توانند در چند سطح انجام شوند. حملات Volumetric پهنای باند را هدف می‌گیرند، حملات Protocol ظرفیت تجهیزات و Connectionها را مصرف می‌کنند و حملات Application Layer با درخواست‌هایی که گاهی کاملاً شبیه رفتار کاربران واقعی هستند، Backend را تحت فشار قرار می‌دهند.

همین تنوع باعث می‌شود هیچ ابزار واحدی بتواند به‌تنهایی تمام حملات DDoS را متوقف کند.

افزایش RAM یا CPU به‌تنهایی کافی نیست. مسدود کردن IPها در برابر حملات توزیع‌شده محدودیت دارد. WAF نیز زمانی که ظرفیت Network قبل از رسیدن ترافیک به آن اشباع شده باشد نمی‌تواند مشکل را حل کند.

رویکرد مؤثر، ایجاد یک معماری چندلایه است.

CDN و شبکه Edge باید بخش بزرگی از Traffic را پیش از رسیدن به Origin مدیریت کنند. Cache باید Requestهای تکراری را از Application دور نگه دارد. WAF و Bot Management رفتارهای مشکوک را محدود کنند. Rate Limiting باید Endpointهای پرهزینه را براساس ظرفیت واقعی آن‌ها کنترل کند و Load Balancing، Redundancy و Autoscaling ظرفیت و Availability سیستم را افزایش دهند.

در لایه Application نیز توسعه‌دهنده باید هزینه هر Request را در نظر بگیرد. Queryهای پرهزینه، Uploadهای بدون محدودیت، پردازش‌های هم‌زمان، Connectionهای بدون Timeout و وابستگی‌های خارجی می‌توانند یک Request ساده را به نقطه شروع Resource Exhaustion تبدیل کنند.

OWASP تأکید می‌کند که دفاع در برابر DoS نیازمند شناخت معماری، شناسایی Bottleneckها، حذف Single Point of Failure و طراحی سیستم برای Graceful Degradation است.

برای سایت‌های وردپرسی نیز استفاده از CDN، Page Cache، Object Cache، محافظت از Endpointهای حساس، حذف افزونه‌های غیرضروری و انتخاب Hosting مناسب اهمیت زیادی دارد. یک افزونه امنیتی به‌تنهایی نمی‌تواند جای DDoS Protection در سطح Network و Edge را بگیرد.

Monitoring بخش جدایی‌ناپذیر این دفاع است. مدیر سایت باید بداند Traffic عادی چه الگویی دارد و Metrics مهمی مانند Request Rate، Response Time، Error Rate، CPU، Database Connection و Cache Hit Ratio را زیر نظر داشته باشد.

همچنین سازمان باید پیش از وقوع حمله Runbook مشخصی داشته باشد. مسیر تماس با Hosting Provider و ISP، Ruleهای اضطراری WAF، Endpointهای قابل غیرفعال‌سازی، Status Page و اولویت سرویس‌های حیاتی باید از قبل تعیین شوند.

در نهایت، هدف دفاع DDoS این نیست که هیچ Packet مخربی هرگز به سمت سایت ارسال نشود؛ چنین هدفی در اینترنت واقع‌بینانه نیست. هدف این است که زیرساخت بتواند Traffic مخرب را هرچه زودتر تشخیص دهد، بخش بزرگی از آن را خارج از Origin فیلتر کند، منابع حیاتی را محافظت کند و حتی در شرایط فشار شدید سطح قابل قبولی از سرویس را برای کاربران واقعی حفظ کند.

سایتی که از ابتدا با اصول Defense in Depth، Redundancy، Caching، Rate Limiting، Monitoring و Graceful Degradation طراحی شده باشد، نه‌تنها در برابر DDoS مقاوم‌تر خواهد بود، بلکه در زمان افزایش طبیعی کاربران و Traffic Spikeهای واقعی نیز عملکرد پایدارتر و قابل اعتمادتری خواهد داشت.