حملات DDoS چیست؟

در یک سرویس آنلاین، Availability به اندازه امنیت و Performance اهمیت دارد. اگر وب‌سایت، API، سامانه پرداخت یا Application شما برای کاربران قابل دسترسی نباشد، حتی بهترین معماری نرم‌افزاری و قوی‌ترین زیرساخت نیز عملاً ارزش خود را از دست می‌دهد.

یکی از مهم‌ترین تهدیدها علیه Availability سرویس‌های اینترنتی، DDoS یا Distributed Denial of Service است؛ حمله‌ای که در آن مهاجم با استفاده از تعداد زیادی منبع، Traffic یا Requestهای مخرب را به سمت یک سرویس هدایت می‌کند تا منابع شبکه، تجهیزات یا Application مصرف شده و کاربران واقعی نتوانند به سرویس دسترسی پیدا کنند.

اما DDoS الزاماً به معنی «ترافیک بسیار زیاد» نیست. بعضی حملات با حجم بسیار بالا انجام می‌شوند و هدفشان اشباع Bandwidth است، در حالی که برخی حملات Application Layer با حجم نسبتاً پایین اما Requestهای پرهزینه می‌توانند CPU، Connection Pool، Database یا سایر منابع Application را تحت فشار قرار دهند.

در این مقاله بررسی می‌کنیم حملات DDoS چیست، چه تفاوتی با DoS دارد، حملات در کدام لایه‌های شبکه رخ می‌دهند، Botnet و Reflection چه نقشی دارند، چگونه DDoS را از افزایش ناگهانی Traffic واقعی تشخیص دهیم و چگونه با استفاده از CDN، WAF، Rate Limiting، Load Balancing، Anycast، Monitoring و طراحی صحیح Origin از زیرساخت محافظت کنیم.

DDoS چیست؟

DDoS مخفف Distributed Denial of Service است و به حمله‌ای گفته می‌شود که در آن منابع متعدد به‌صورت هماهنگ برای ایجاد اختلال در دسترسی به یک سرویس، Server، Network یا Application استفاده می‌شوند.

هدف اصلی DDoS معمولاً کاهش یا از بین بردن Availability است.

در یک حالت ساده می‌توان معماری را این‌گونه تصور کرد:

                 ┌── Source 1
                 ├── Source 2
Internet ────────┼── Source 3
                 ├── Source 4
                 └── ...
                       │
                       ▼
                 Target Service

در یک حمله Distributed، Traffic از یک سیستم واحد نمی‌آید. منابع متعدد می‌توانند باعث شوند تشخیص و فیلتر کردن Traffic مخرب دشوارتر شود.

NIST نیز DDoS را نوعی حمله Denial of Service تعریف می‌کند که از تعداد زیادی Host برای انجام حمله استفاده می‌کند.

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

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

در DoS ممکن است منبع حمله یک سیستم یا تعداد محدودی منبع باشد؛ اما در DDoS، حمله به‌صورت Distributed و از منابع متعدد انجام می‌شود.

بنابراین هر DDoS یک نوع Denial of Service است، اما هر DoS الزاماً DDoS نیست.

چرا DDoS خطرناک است؟

یک سرویس آنلاین منابع محدودی دارد.

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

• Network Bandwidth
• CPU
• RAM
• Concurrent Connections
• Connection Pool
• Thread Pool
• Worker Processes
• Database Connections
• Disk I/O
• Cache Capacity

باشد.

اگر مهاجم بتواند یکی از این منابع را به اندازه کافی مصرف کند، حتی زمانی که خود Server از نظر سخت‌افزاری سالم است، Application می‌تواند برای کاربران واقعی کند یا کاملاً غیرقابل دسترس شود.

DDoS چگونه انجام می‌شود؟

یکی از رایج‌ترین مدل‌ها استفاده از Botnet است.

Botnet شبکه‌ای از دستگاه‌های آلوده یا تحت کنترل مهاجم است که می‌تواند شامل کامپیوترها، Serverها، تجهیزات IoT و سایر دستگاه‌های متصل به اینترنت باشد.

در این مدل، به‌صورت مفهومی:

             Attacker
                 │
                 ▼
              Botnet
        ┌────────┼────────┐
        ▼        ▼        ▼
      Bot 1    Bot 2    Bot 3   ...
        │        │        │
        └────────┼────────┘
                 ▼
              Target

CISA، FBI و MS-ISAC نیز Botnet را یکی از سازوکارهای مهم اجرای حملات DDoS معرفی می‌کنند و اشاره می‌کنند که دستگاه‌های IoT می‌توانند به دلیل ضعف‌های امنیتی یا تنظیمات نامناسب در چنین شبکه‌هایی مورد سوءاستفاده قرار بگیرند.

انواع حملات DDoS

حملات DDoS را می‌توان بر اساس لایه‌ای که هدف قرار می‌دهند به چند دسته اصلی تقسیم کرد.

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

• Volumetric Attacks
• Protocol / Network Attacks
• Application Layer Attacks
• Reflection / Amplification Attacks

در عمل ممکن است یک حمله چند Vector مختلف را هم‌زمان یا پشت سر هم استفاده کند.

۱. حملات Volumetric یا حجمی

در حملات Volumetric هدف اصلی مصرف ظرفیت شبکه و Bandwidth است.

مهاجم تلاش می‌کند حجم بسیار زیادی از Traffic را به سمت Target ارسال کند تا ظرفیت ارتباطی یا تجهیزات شبکه در مسیر اشباع شوند.

Large Traffic Volume
        ↓
Internet Link
        ↓
Firewall / Router
        ↓
Origin

اگر ظرفیت لینک اینترنت شما ۱۰Gbps باشد و Traffic حمله بتواند بسیار بیشتر از ظرفیت قابل دریافت شما شود، حتی یک Server بسیار قدرتمند نیز نمی‌تواند به‌تنهایی مشکل را حل کند.

به همین دلیل مقابله با حملات حجمی معمولاً باید قبل از رسیدن Traffic به Origin انجام شود.

۲. حملات Protocol یا Layer 3/4

این حملات بیشتر روی Network و Transport Layer تمرکز می‌کنند و می‌توانند منابع مربوط به Connection، Firewall، Load Balancer یا سایر تجهیزات شبکه را تحت فشار قرار دهند.

یکی از نمونه‌های شناخته‌شده، SYN Flood است.

SYN Flood چیست؟

TCP برای برقراری Connection از فرآیندی به نام Three-Way Handshake استفاده می‌کند:

Client                  Server

  SYN  ------------------->
       <------------------- SYN-ACK
  ACK  ------------------->

در یک SYN Flood، تعداد زیادی Connection Initiation به سمت سرویس ارسال می‌شود و می‌تواند منابع مربوط به Connection Tracking را تحت فشار قرار دهد.

حملات Network و Protocol می‌توانند به شکل‌های مختلفی انجام شوند و فقط به SYN Flood محدود نیستند. مستندات DDoS نیز طیف وسیعی از حملات L3/L4 مانند SYN، UDP، ICMP و برخی Reflection/Amplification Attackها را در این دسته قرار می‌دهند.

۳. حملات Application Layer یا Layer 7

حملات Layer 7 به جای اینکه صرفاً حجم بزرگی از Packet را ارسال کنند، Application را هدف قرار می‌دهند.

برای مثال یک مهاجم ممکن است تعداد بسیار زیادی HTTP Request به Endpoint خاصی ارسال کند.

Clients / Bots
      │
      │ HTTP Requests
      ▼
   Web Server
      │
      ├── Application
      ├── Cache
      └── Database

مشکل اصلی این است که یک HTTP Request ساده ممکن است در سمت Client بسیار ارزان باشد، اما در سمت Server باعث اجرای چندین عملیات شود:

• Application Processing
• Database Query
• External API Call
• Authentication
• Template Rendering
• Cache Lookup

در نتیجه ممکن است مهاجم با حجم Network نسبتاً پایین، منابع زیادی در Backend مصرف کند.

Cloudflare نیز Application Layer DDoS را به‌عنوان حمله‌ای در Layer 7 توصیف می‌کند که می‌تواند با HTTP/S Requestهای ظاهراً معتبر، منابع Application را تحت فشار قرار دهد.

HTTP Flood چیست؟

HTTP Flood یکی از نمونه‌های شناخته‌شده Application Layer DDoS است که در آن حجم زیادی از HTTP Request به سمت Application ارسال می‌شود.

تشخیص این حملات می‌تواند سخت‌تر از بعضی حملات Network Layer باشد؛ زیرا Requestها ممکن است از نظر ساختار شبیه Traffic واقعی کاربران باشند.

به همین دلیل صرفاً Block کردن Packetهای غیرعادی همیشه کافی نیست و ممکن است نیاز به تحلیل رفتار، Rate Limiting، WAF، Bot Detection و سایر روش‌های Application-aware وجود داشته باشد.

۴. Reflection و Amplification چیست؟

در حملات Reflection مهاجم از سیستم‌ها یا سرویس‌های دیگر برای ارسال Traffic به سمت Target استفاده می‌کند.

در حالت ساده:

Attacker
   │
   │ Request with spoofed source
   ▼
Reflector
   │
   │ Response
   ▼
Target

اگر Response بسیار بزرگ‌تر از Request اولیه باشد، مفهوم Amplification نیز وارد می‌شود.

در این حالت مقدار Traffic ایجادشده در سمت Target می‌تواند نسبت به Traffic ارسال‌شده از سمت مهاجم بسیار بزرگ‌تر باشد.

نمونه‌هایی از Reflection/Amplification در منابع امنیتی شامل DNS، NTP، Memcached و برخی پروتکل‌های دیگر است.

مقایسه انواع DDoS

bps، pps و RPS در DDoS یعنی چه؟

یکی از اشتباهات رایج در تحلیل DDoS این است که فقط به یک عدد مانند Gigabit بر ثانیه توجه کنیم.

bps — Bits per Second

برای سنجش حجم Traffic شبکه استفاده می‌شود.

Gbps / Mbps

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

pps — Packets per Second

تعداد Packetهایی که در هر ثانیه منتقل می‌شوند.

یک حمله می‌تواند Bandwidth خیلی بالایی نداشته باشد اما تعداد Packet بسیار زیادی ایجاد کند و تجهیزات Network را تحت فشار قرار دهد.

RPS — Requests per Second

تعداد Requestهای Application در هر ثانیه است.

در حملات HTTP Flood، RPS معمولاً شاخص مهم‌تری از Gbps است.

برای مثال، یک Endpoint بسیار سنگین ممکن است با تعداد نسبتاً محدودی Request نیز Server را تحت فشار قرار دهد.

آیا بزرگ‌ترین DDoS الزاماً خطرناک‌ترین DDoS است؟

خیر.

شدت DDoS را نمی‌توان فقط با حجم Traffic سنجید.

مثلاً:

Attack A
500 Gbps
Simple Network Flood

Attack B
20,000 RPS
Expensive API Endpoint
        ↓
Database
        ↓
Complex Query

بسته به معماری Target، حمله دوم می‌تواند اثر بیشتری روی Application داشته باشد، حتی اگر حجم Network آن بسیار کمتر باشد.

به همین دلیل دفاع DDoS باید متناسب با Resource مورد هدف طراحی شود.

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

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

• افزایش ناگهانی Traffic
• افزایش شدید Request Rate
• افزایش HTTP 5xx
• افزایش Connectionهای هم‌زمان
• افزایش CPU یا RAM
• افزایش Network Bandwidth
• افزایش Packet Rate
• افزایش Database Connections
• افزایش Response Time
• افزایش Timeout
• افزایش خطاهای Load Balancer
• کاهش Cache Hit Ratio در برخی سناریوها
• عدم دسترسی کاربران واقعی

اما نکته مهم این است که هر افزایش Traffic الزاماً DDoS نیست.

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

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

تشخیص دقیق نیازمند بررسی چند شاخص به‌صورت هم‌زمان است.

برای مثال باید بررسی شود:

• Traffic از چه جغرافیایی می‌آید؟
• چه URLهایی بیشتر درخواست می‌شوند؟
• Request Method چیست؟
• HTTP Status Codeها چگونه تغییر کرده‌اند؟
• User-Agentها چه الگویی دارند؟
• آیا Session و Cookie رفتار طبیعی دارند؟
• آیا Traffic به یک Endpoint خاص متمرکز شده است؟
• آیا الگوی زمانی غیرعادی است؟
• آیا Backend هم‌زمان CPU یا Database Load غیرطبیعی دارد؟

در Application Layer، تشخیص می‌تواند دشوار باشد، زیرا بخشی از Traffic مخرب ممکن است از نظر HTTP شبیه Request واقعی به نظر برسد.

DDoS و Monitoring

بدون Monitoring مناسب، تشخیص DDoS ممکن است زمانی اتفاق بیفتد که کاربران قبلاً با مشکل مواجه شده‌اند.

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

• Network Throughput
• Packets per Second
• HTTP Requests per Second
• Concurrent Connections
• HTTP Status Codes
• Latency
• CPU
• Memory
• Load Average
• Database Connections
• Application Errors
• Firewall Events
• WAF Events

همچنین بهتر است Baseline مربوط به Traffic عادی سیستم مشخص باشد تا Anomalyها سریع‌تر شناسایی شوند.

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

DDoS Mitigation چیست؟

DDoS Mitigation مجموعه اقداماتی است که برای شناسایی، محدود کردن یا حذف Traffic مخرب و حفظ دسترسی کاربران واقعی انجام می‌شود.

Mitigation می‌تواند در نقاط مختلف انجام شود:

Internet
   ↓
Upstream / ISP
   ↓
DDoS Protection
   ↓
CDN / Edge
   ↓
WAF
   ↓
Load Balancer
   ↓
Application

هرچه حمله حجیم‌تر باشد، اهمیت Mitigation در لایه‌های بالاتر شبکه بیشتر می‌شود؛ زیرا اگر لینک اینترنت شما قبل از رسیدن Traffic به Firewall اشباع شود، Firewall داخلی دیگر فرصت زیادی برای دفاع نخواهد داشت.

CDN چگونه به مقابله با DDoS کمک می‌کند؟

CDN می‌تواند یک لایه مهم برای مقابله با DDoS باشد، زیرا Traffic قبل از رسیدن به Origin وارد شبکه Edge می‌شود.

Attackers
    │
    ▼
CDN / Edge Network
    │
    ├── Filter
    ├── Rate Limit
    ├── WAF
    └── DDoS Mitigation
            │
            ▼
          Origin

شبکه‌های بزرگ CDN می‌توانند Traffic را در نقاط مختلف شبکه دریافت و بخشی از آن را قبل از رسیدن به Origin Drop، Rate Limit یا Challenge کنند.

برای آشنایی بیشتر با CDN می‌توانید مقاله CDN چیست؟ را مطالعه کنید.

WAF چگونه به دفاع در برابر DDoS کمک می‌کند؟

WAF یا Web Application Firewall برای تحلیل و کنترل HTTP/HTTPS Traffic در لایه Application طراحی شده است.

در حملات L7، WAF می‌تواند بر اساس Ruleها و ویژگی‌های Request، Traffic مشکوک را محدود یا مسدود کند.

برای مثال می‌توان روی مواردی مانند:

• Path
• HTTP Method
• IP / Network
• Headers
• Request Rate
• Geographic Rules
• Bot Signals

Policy تعریف کرد.

با این حال، WAF به‌تنهایی جایگزین DDoS Protection در سطح Network نیست. برای حملات حجیم، Traffic باید پیش از اشباع لینک و زیرساخت شما کنترل شود.

برای آشنایی بیشتر با WAF، مقاله WAF چیست؟ را بخوانید.

Rate Limiting چیست و چه نقشی در DDoS دارد؟

Rate Limiting به معنی محدود کردن تعداد Request یا Connection در یک بازه زمانی است.

برای مثال می‌توان برای یک Endpoint حساس محدودیت‌هایی بر اساس:

• IP
• User
• API Key
• Session
• Endpoint
• Network

تعریف کرد.

Rate Limiting می‌تواند در برابر برخی Application Layer Attackها بسیار مفید باشد، اما باید با احتیاط تنظیم شود.

اگر Limit بیش از حد سخت‌گیرانه باشد، ممکن است کاربران واقعی نیز Block شوند.

Anycast و DDoS

در شبکه‌های توزیع‌شده، Anycast می‌تواند به پخش Traffic در چند نقطه جغرافیایی کمک کند.

                 Anycast Network
              /       |        \
             /        |         \
           PoP A     PoP B      PoP C
             ↑         ↑          ↑
          Traffic   Traffic    Traffic

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

البته Anycast به‌تنهایی یک DDoS Protection کامل نیست؛ Detection، Filtering و Mitigation نیز باید در کنار آن وجود داشته باشند.

Origin Protection چیست؟

یکی از مهم‌ترین اصول دفاعی این است که Origin Server تا حد امکان مستقیماً در معرض Internet قرار نگیرد.

اگر مهاجم IP واقعی Origin را پیدا کند، ممکن است CDN را دور بزند و Traffic را مستقیماً به Server ارسال کند.

معماری بهتر می‌تواند چنین باشد:

Internet
    ↓
CDN / DDoS Protection
    ↓
WAF
    ↓
Origin Firewall
    ↓
Application

در این حالت Firewall می‌تواند دسترسی به Origin را فقط برای مسیرهای موردنیاز مجاز کند.

این اصل در معماری‌های مدرن DDoS Protection نیز اهمیت زیادی دارد؛ مستندات دفاعی Cloudflare نیز توصیه می‌کنند Origin مستقیماً در معرض Internet قرار نداشته باشد و دسترسی به آن محدود شود.

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

معمولاً خیر.

Firewall برای کنترل Traffic بسیار مهم است، اما اگر حمله آن‌قدر بزرگ باشد که ظرفیت لینک Internet یا تجهیزات قبل از Firewall را اشباع کند، Firewall دیگر نمی‌تواند مشکل اصلی را حل کند.

برای همین معماری DDoS Protection باید لایه‌ای باشد:

Upstream
   ↓
DDoS Protection
   ↓
CDN / Edge
   ↓
WAF
   ↓
Firewall
   ↓
Load Balancer
   ↓
Application

DDoS Scrubbing چیست؟

DDoS Scrubbing

به‌صورت ساده:

Internet Traffic
       ↓
Scrubbing Center
       │
       ├── Malicious → Drop
       │
       └── Legitimate
               ↓
             Origin

این مدل برای سازمان‌هایی که نیاز به محافظت جدی در سطح Network دارند اهمیت زیادی دارد.

DDoS در برابر سرویس‌های API

APIها می‌توانند هدف جذابی برای Application Layer DDoS باشند، زیرا برخی Endpointها عملیات سنگینی انجام می‌دهند.

برای مثال یک Request ممکن است باعث شود:

HTTP Request
     ↓
Authentication
     ↓
Application Logic
     ↓
Database Query
     ↓
External API
     ↓
Response

بنابراین در طراحی API باید Endpointهای پرهزینه شناسایی و برای آن‌ها Rate Limiting، Caching، Authentication و سایر کنترل‌های لازم در نظر گرفته شود.

DDoS و Database

یکی از خطرناک‌ترین سناریوها زمانی رخ می‌دهد که Traffic مخرب به‌صورت مستقیم یا غیرمستقیم باعث افزایش Queryهای Database شود.

DDoS Traffic
     ↓
API
     ↓
Application
     ↓
Database
     ↓
CPU / Connections / I/O Exhaustion

در این شرایط ممکن است Network Traffic خیلی بزرگ نباشد، اما Database به Bottleneck اصلی تبدیل شود.

راهکارهای دفاعی می‌توانند شامل مواردی مانند:

• Rate Limiting
• Caching
• Query Optimization
• Connection Limits
• Queueing
• Circuit Breaker
• Load Shedding

باشند.

Load Shedding چیست؟

Load Shedding

برای مثال:

High Load
   ↓
Classify Requests
   ├── Critical → Allow
   ├── Normal   → Limited
   └── Expensive → Reject

این رویکرد می‌تواند در زمان حمله یا Overload از فروپاشی کامل Application جلوگیری کند.

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

نه لزوماً.

Auto Scaling برای افزایش ظرفیت Application در برابر Load واقعی بسیار مفید است، اما اگر Traffic مخرب باشد، Scale کردن می‌تواند حتی هزینه و مصرف منابع را افزایش دهد.

برای مثال:

DDoS Traffic
     ↓
Load increases
     ↓
Auto Scaling
     ↓
More Servers
     ↓
More Cost
     ↓
DDoS continues

بنابراین Auto Scaling باید در کنار DDoS Protection، Rate Limiting و Traffic Filtering استفاده شود.

آیا افزایش Server باعث حل DDoS می‌شود؟

در بسیاری از موارد خیر.

اگر مشکل در Bandwidth باشد، اضافه کردن CPU و RAM کمکی نمی‌کند.

اگر مشکل در Connection Tracking باشد، اضافه کردن Application Server ممکن است کافی نباشد.

اگر مشکل در Database باشد، اضافه کردن Web Serverها حتی می‌تواند فشار بیشتری ایجاد کند.

بنابراین ابتدا باید مشخص شود کدام Resource در حال Exhaust شدن است.

DDoS و High Availability

High Availability می‌تواند اثر برخی اختلالات را کاهش دهد، اما جایگزین DDoS Protection نیست.

برای مثال اگر سه Application Server داشته باشیم:

             Load Balancer
              /    |    \
             /     |     \
          App 1   App 2   App 3

اگر Traffic مخرب از ظرفیت Load Balancer یا Network بیشتر باشد، وجود سه Server مشکل اصلی را حل نمی‌کند.

بنابراین باید Availability و DDoS Protection را در چند لایه طراحی کرد.

برای طراحی معماری High Availability می‌توانید از خدمات High Availability آلتیمیت کلاد استفاده کنید.

DDoS و Disaster Recovery

DDoS با Disaster Recovery یکی نیست.

Disaster Recovery روی بازیابی سرویس و داده پس از یک اختلال جدی تمرکز دارد، در حالی که DDoS Protection روی جلوگیری یا کاهش اثر یک حمله در زمان وقوع آن تمرکز می‌کند.

با این حال، DDoS باید در سناریوهای Business Continuity و Disaster Recovery نیز در نظر گرفته شود.

برای مطالعه بیشتر:

• Disaster Recovery چیست؟
• خدمات Disaster Recovery
• خدمات Business Continuity

معماری پیشنهادی دفاع در برابر DDoS

برای یک سرویس Production، یک معماری دفاعی می‌تواند به شکل زیر طراحی شود:

                         Internet
                            │
                            ▼
                    DNS / Traffic Routing
                            │
                            ▼
                 CDN / DDoS Protection
                            │
                 ┌──────────┴──────────┐
                 │                     │
                WAF               Rate Limiting
                 │                     │
                 └──────────┬──────────┘
                            ▼
                     Load Balancer
                            │
                     ┌──────┴──────┐
                     ▼             ▼
                  App 1          App 2
                     │             │
                     └──────┬──────┘
                            ▼
                        Database

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

CDN / WAF / LB / App / DB
          │
          ▼
       Metrics
          +
         Logs
          +
        Alerts
          │
          ▼
       NOC / SRE

در زمان وقوع DDoS چه کار کنیم؟

در زمان Incident بهتر است واکنش‌ها بر اساس یک Runbook از قبل آماده‌شده انجام شوند.

مرحله اول: تأیید Incident

ابتدا بررسی کنید آیا مشکل واقعاً DDoS است یا یک افزایش طبیعی Traffic، Bug، Deployment اشتباه یا خرابی زیرساختی.

مرحله دوم: مشخص کردن Layer

باید مشخص شود مشکل در کدام سطح قرار دارد:

• Network
• Transport
• HTTP
• Application
• Database

مرحله سوم: فعال کردن Mitigation

بسته به نوع حمله می‌توان از قابلیت‌هایی مانند:

• DDoS Protection
• WAF Rules
• Rate Limiting
• Traffic Filtering
• Challenge
• Geo Rules
• Origin Protection

استفاده کرد.

مرحله چهارم: محافظت از Origin

اگر Origin مستقیماً قابل دسترسی باشد، باید مسیر حمله به Origin نیز بررسی شود.

مرحله پنجم: Monitoring

بعد از اعمال Mitigation باید بررسی شود که آیا:

• Attack Traffic کاهش یافته است؟
• Users واقعی دوباره سرویس دریافت می‌کنند؟
• CPU و Memory به وضعیت عادی برگشته‌اند؟
• Database سالم است؟
• Error Rate کاهش یافته است؟

بعد از حمله DDoS چه کنیم؟

تمام شدن حمله به معنی پایان Incident نیست.

پس از Incident بهتر است یک Post-Incident Review انجام شود.

موارد زیر را بررسی کنید:

• Attack Vector چه بود؟
• حمله از چه زمانی شروع شد؟
• چه مدت ادامه داشت؟
• Peak Traffic چقدر بود؟
• کدام Resource Bottleneck شد؟
• کدام Rule حمله را Mitigate کرد؟
• آیا کاربران واقعی نیز Block شدند؟
• آیا Origin مستقیماً قابل دسترسی بود؟
• آیا Monitoring به‌موقع Alert داد؟
• آیا Runbook کافی بود؟

نتیجه این بررسی باید به تغییرات واقعی در معماری و Policyهای امنیتی منجر شود.

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

۱. فقط روی Firewall حساب کردن

Firewall داخلی برای بسیاری از سناریوها ضروری است، اما نمی‌تواند Trafficی را که قبل از رسیدن به آن لینک اینترنت را اشباع کرده است، حل کند.

۲. افزایش Server بدون تحلیل

Scale کردن Application بدون شناخت Attack Vector ممکن است فقط هزینه بیشتری ایجاد کند.

۳. Cache کردن همه چیز

Cache می‌تواند فشار را کاهش دهد، اما Cache اشتباه می‌تواند مشکل امنیتی و Consistency ایجاد کند.

۴. باز گذاشتن Origin

اگر مهاجم بتواند CDN را دور بزند و مستقیماً به Origin برسد، بخش مهمی از معماری دفاعی بی‌اثر می‌شود.

۵. Rate Limiting بسیار سخت‌گیرانه

Policy نامناسب ممکن است کاربران واقعی را نیز Block کند.

۶. نداشتن Baseline

اگر ندانید Traffic عادی شما چگونه است، تشخیص Anomaly دشوار خواهد بود.

۷. نداشتن Runbook

زمان حمله، جای آزمون و خطا نیست. فرآیند Incident Response باید از قبل مشخص باشد.

DDoS Protection برای چه کسب‌وکارهایی ضروری‌تر است؟

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

برای مثال:

• فروشگاه‌های اینترنتی
• سرویس‌های پرداخت
• بانکداری و FinTech
• پلتفرم‌های SaaS
• Marketplaceها
• سرویس‌های API
• پلتفرم‌های Media
• سرویس‌های Gaming
• سرویس‌های B2B حیاتی
• زیرساخت‌های عمومی سازمان‌ها

چک‌لیست DDoS Protection

• □ شناسایی دارایی‌های اینترنتی
• □ مشخص کردن Origin Serverها
• □ بررسی ظرفیت Network
• □ استفاده از DDoS Protection متناسب با نیاز
• □ قرار دادن CDN یا Edge در صورت نیاز
• □ فعال‌سازی WAF
• □ طراحی Rate Limiting
• □ محافظت از Origin
• □ بررسی DNS و Routing
• □ Monitoring Network Traffic
• □ Monitoring HTTP Requests
• □ Monitoring CPU و Memory
• □ Monitoring Database
• □ تعریف Alert
• □ آماده‌سازی Incident Runbook
• □ تعریف Contactهای اضطراری ISP / Provider
• □ تست سناریوهای Failover
• □ انجام Post-Incident Review

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

DDoS چیست؟

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

هدف حمله DDoS چیست؟

هدف اصلی معمولاً کاهش Availability و جلوگیری از دسترسی کاربران واقعی به سرویس است.

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

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

Botnet چیست؟

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

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

CDN می‌تواند یکی از لایه‌های مهم DDoS Mitigation باشد، اما میزان حفاظت به معماری و قابلیت‌های Provider بستگی دارد. CDNهای مدرن می‌توانند حملات Network و Application Layer را در Edge شناسایی و Mitigate کنند.

آیا WAF همان DDoS Protection است؟

خیر. WAF بیشتر روی HTTP/HTTPS و Application Layer تمرکز دارد، در حالی که DDoS Protection می‌تواند لایه‌های Network، Transport و Application را پوشش دهد.

آیا Firewall برای مقابله با DDoS کافی است؟

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

آیا Auto Scaling می‌تواند DDoS را حل کند؟

خیر. Auto Scaling ظرفیت Application را افزایش می‌دهد، اما در برابر Traffic مخرب ممکن است فقط باعث مصرف منابع و افزایش هزینه شود.

چگونه بفهمیم Traffic زیاد واقعاً DDoS است؟

باید Traffic Pattern، Request Rate، منابع مصرف‌شده، Endpointهای درگیر، Geography، Status Codeها، Connectionها و رفتار کاربران بررسی شود. افزایش Traffic به‌تنهایی اثبات DDoS نیست.

آیا DDoS به Database هم آسیب می‌زند؟

بله. به‌خصوص در حملات Application Layer، Requestهای زیاد می‌توانند باعث افزایش Query، Connection و مصرف CPU و I/O Database شوند.

آیا DDoS باعث از بین رفتن اطلاعات می‌شود؟

هدف مستقیم DDoS معمولاً ایجاد اختلال در Availability است، نه حذف داده. با این حال، هر Incident امنیتی باید از نظر سایر تهدیدها و پیامدهای جانبی نیز بررسی شود.

جمع‌بندی

DDoS یا Distributed Denial of Service یکی از مهم‌ترین تهدیدها برای Availability سرویس‌های آنلاین است. این حملات می‌توانند از اشباع Bandwidth و Packet Flood گرفته تا حملات پیچیده Application Layer را شامل شوند.

مهم‌ترین نکته این است که DDoS را نباید صرفاً یک «حمله با ترافیک زیاد» در نظر گرفت. حمله ممکن است دقیقاً منبعی را هدف قرار دهد که در معماری شما محدودتر است؛ از Bandwidth و Firewall گرفته تا Connection Pool، CPU، Application Worker یا Database.

به همین دلیل دفاع مؤثر باید چندلایه باشد:

Internet
   ↓
DDoS Protection
   ↓
CDN / Edge
   ↓
WAF
   ↓
Rate Limiting
   ↓
Load Balancer
   ↓
Application
   ↓
Database

        +
   Monitoring
        +
   Alerting
        +
 Incident Response

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

طراحی معماری مقاوم در برابر DDoS با آلتیمیت کلاد

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

آلتیمیت کلاد می‌تواند معماری دفاعی متناسب با زیرساخت شما را طراحی و پیاده‌سازی کند؛ از CDN، Reverse Proxy و WAF تا Monitoring، Load Balancing، High Availability، Security Hardening و معماری Multi-Data Center.

برای تکمیل معماری امنیتی می‌توانید خدمات Security Hardening، خدمات Monitoring، خدمات High Availability و خدمات Scaling آلتیمیت کلاد را نیز بررسی کنید.

همچنین برای درک بهتر لایه‌های مرتبط با DDoS، مطالعه مقالات CDN چیست؟، Reverse Proxy چیست؟ و WAF چیست؟ پیشنهاد می‌شود.

اگر Availability سرویس برای کسب‌وکار شما حیاتی است، معماری DDoS Protection را باید قبل از وقوع Incident طراحی کنید.

درخواست مشاوره و طراحی زیرساخت از آلتیمیت کلاد