ساعت ۱۱:۲۰ است؛ صفحه فروشگاه باز نمیشود، CPU سرور ۹۵٪ است و پشتیبانی میگوید «احتمالاً DDoS شدهایم». اگر نخستین اقدام تیم Block کردن چند IP یا روشنکردن یک Challenge عمومی باشد، ممکن است کاربران واقعی را حذف کند و علت اصلی—Release خراب، Query سنگین، قطعی درگاه یا حمله مستقیم به Origin—همچنان باقی بماند.
مقابله با حملات DDoS خرید یک دکمه جادویی نیست. باید بدانید کدام Service و Resource در حال Exhaust شدن است، ترافیک مخرب کجا فیلتر میشود، کاربر واقعی چگونه عبور میکند، چه کسی اختیار تغییر دارد و با چه شاهدی میفهمید Mitigation اثر کرده است.
خلاصه اجرایی: ابتدا Service map، SLO و Baseline بسازید؛ Exposureهای DNS/IP/API و Origin را ببندید؛ دفاع L3/L4 را به Edge/Provider و دفاع L7 را به WAF و خود برنامه متصل کنید؛ Rate limit را بر هزینه Endpoint و هویت قابلاعتماد تنظیم کنید؛ Runbook و کانال ارتباط خارج Failure domain داشته باشید؛ و با Drill مجاز، Telemetry و Postmortem اثربخشی را ثابت کنید.
حمله DDoS چیست و چه چیزی نیست؟
DDoS یا Distributed Denial of Service تلاشی توزیعشده برای مصرف ظرفیت شبکه، State پروتکل یا منابع برنامه است تا سرویس برای کاربران مجاز کند یا غیرقابلدسترس شود. DoS میتواند از یک مبدأ و DDoS از مبدأهای متعدد باشد؛ ولی برای Incident commander مهمتر از نام، Resource تحت فشار و نقطه Mitigation است.
DDoS در درجه اول تهدید Availability است. خودش به معنی نفوذ، SQL Injection یا سرقت داده نیست؛ هرچند ممکن است همزمان با حمله دیگری رخ دهد یا تیم را منحرف کند. پس در Incident، نشانههای دسترسی غیرمجاز و تغییر داده را نیز بررسی کنید، اما آنها را بدون شاهد به DDoS نسبت ندهید.
| نوع | Resource هدف | Telemetry کلیدی | محل اصلی دفاع |
|---|---|---|---|
| Volumetric | ظرفیت Link و Transit | bps، پکت Dropشده، Saturation | ISP، Anycast edge و Scrubbing |
| Protocol/State exhaustion | Connection table، Load balancer و TLS | pps، SYN/ACK، Connection state، Handshake | Network edge و Managed L3/L4 protection |
| Application-layer | Worker، CPU، Cache، DB و Dependency | rps، Cost/request، Cache hit، Queue، Error/Latency | WAF، Rate limit، App و معماری Resilience |
| Functional/resource abuse | Search، Export، OTP، Email، Upload یا GraphQL | عملیات/هویت، Complexity، هزینه ثالث | Authorization، Quota، Async job و Cost budget |
راهنمای CISA برای شناخت و پاسخ به DDoS و راهنمای OWASP برای Denial of Service نیز بر لایههای متفاوت حمله و نیاز به دفاع چندلایه تأکید دارند. یک WAF نمیتواند Link اشباعشده پیش از دیتاسنتر را نجات دهد؛ یک سرویس L3/L4 نیز منطق گران Search یا API را بهجای شما نمیشناسد.
پیش از ابزار: Service map و Failure budget بسازید
از دامنه اصلی شروع نکنید؛ از Journey حیاتی شروع کنید. کاربر برای تکمیل خرید، ورود یا مشاهده پرونده از چه زنجیرهای عبور میکند؟
| لایه | نمونه Asset/Dependency | Failure محتمل | مالک |
|---|---|---|---|
| نام و مسیر | Registrar، Authoritative DNS، DNSSEC | DNS unavailable یا تغییر غیرمجاز | Network/Security |
| Edge | CDN، Anycast، DDoS service، WAF | Attack pass-through یا False positive | Platform/Security |
| Origin entry | Load balancer، Reverse proxy، Public IP | Origin bypass یا Connection exhaustion | Infrastructure |
| Application | Web، API، Auth، Search، Export | Worker/CPU/Memory exhaustion | Engineering |
| State | Cache، Queue، DB و Session | Stampede، Lock، Queue saturation | Engineering/Data |
| Third party | درگاه، پیامک، Map، Email و CRM | Quota/Latency/Callback failure | Product/Operations |
| Response | Status page، On-call، Support و Vendor | کانال ارتباط روی همان دامنه از کار بیفتد | Incident commander |
برای هر Journey، SLO و Guardrail تعیین کنید: Availability، p95/p99 latency، Error rate، درصد سفارش موفق، Queue delay و حداکثر هزینه Scaling. ظرفیت Provider بهتنهایی SLO شما نیست؛ ممکن است Edge فعال باشد اما DB، OTP یا درگاه زودتر اشباع شود.
Attack surface inventory
- همه Hostnameها، Public IPها، پورتها و Protocolهای اینترنتی؛
- Origin، پنل مدیریت، API، Webhook، فایل و Media endpoint؛
- رکوردهای DNS-only، History DNS، گواهی، Email header و Git/Config که IP را فاش میکنند؛
- Endpointهای گران مانند Search، Login، OTP، Export، Report، Upload و GraphQL؛
- Dependencyهایی که Quota یا هزینه Per-request دارند؛
- Single point of failure و مسیرهای Failover که همان Exposure را تکرار میکنند.
برای سایت ایرانی، مسیر داخلی و بینالمللی، محل Origin، اپراتور/ISP، WebView درگاه و سرویسهای خارجی را جدا ببینید. اختلال مسیر یا سرویس ثالث ممکن است از دید یک Probe شبیه DDoS باشد. Probe داخل و خارج کشور، User journey و Telemetry Provider را کنار هم قرار دهید.
Baseline: بدون رفتار عادی، «غیرعادی» را نمیشناسید
یک Spike فروش، خزنده جستوجو، Campaign، Cache purge یا Release تازه میتواند ترافیک و CPU را بالا ببرد. Baseline را بر ساعت/روز/فصل، Endpoint، Status، Cache state، ASN/منطقه، User type و Device بسازید.
| سیگنال | چرا مهم است؟ | مقایسه لازم |
|---|---|---|
| bps / pps / connections | فشار Network/Protocol | Edge در برابر Origin و ظرفیت Link |
| rps و Cost/request | حمله کمحجم ممکن است گران باشد | Endpoint، Method، Cache، Auth state |
| HTTP status و Latency | اثر واقعی بر کاربر | Edge/Origin/Dependency و p50/p95/p99 |
| WAF action | Allow/Challenge/Block و False positive | Rule ID، Path و نتیجه کاربر |
| Cache hit ratio | افت Hit فشار را به Origin میبرد | قبل/حین حمله و Cache key |
| CPU/Memory/Pool/Queue/DB | گلوگاه واقعی را نشان میدهد | Utilization، Saturation و Error |
| Business task | سرویس ۲۰۰ ولی خرید شکستخورده است | Browse→Cart→Pay→Verify |
| Cost | Autoscaling و سرویس ثالث ممکن است قبض بسازند | Forecast، سقف و Anomaly |
Log خامِ IP بهتنهایی کافی نیست و داده شخصی/امنیتی محسوب میشود. Retention، دسترسی، Redaction و Export اضطراری را از قبل تعریف کنید. در حمله ممکن است Origin log ناقص یا پرهزینه شود؛ Telemetry لبه، Metric کمحجم و Probe بیرونی باید مستقل بمانند. طراحی این لایه در راهنمای Observability و مانیتورینگ سایت و سنجش بیرونی در راهنمای مانیتورینگ Uptime تشریح شده است.
آیا واقعاً DDoS است؟ تریاژ پنجدقیقهای
- اثر را تأیید کنید: کدام Region/ISP/Journey کند یا قطع است؟ Probe بیرونی و تراکنش مصنوعی چه میگویند؟
- زمان را Correlate کنید: Release، Migration، DNS/TLS change، Campaign، Cache purge یا Incident ثالث رخ داده؟
- لایه را پیدا کنید: Edge چه میبیند و Origin چه میبیند؟ Link، Connection، TLS، HTTP، App یا Dependency اشباع است؟
- Telemetry Provider را بخوانید: Attack flag، Vector، Mitigation state، Dropped traffic و Support case وجود دارد؟
- Severity اعلام کنید: Impact، Scope، Start time، SLO breach، Incident commander و Update cadence را ثبت کنید.
| نشانه | DDoS محتمل | جایگزین محتمل |
|---|---|---|
| Edge traffic بالا، Origin عادی | Mitigation لبه فعال و مؤثر | Campaign Cacheable |
| Edge عادی، Origin CPU بالا | Origin bypass یا L7 کمحجم | Release/Query/Job داخلی |
| فقط یک ISP/منطقه قطع | حمله مسیرمحور ممکن | Routing/DNS/شبکه اپراتور |
| DB/Queue اشباع با rps متوسط | Endpoint پرهزینه | N+۱، Cache stampede یا Dependency slow |
| همه Endpointها ۴۰۳ | Rule دفاعی بیشازحد | WAF misconfiguration |
معماری دفاع لایهای
مدل هدف برای Web معمولاً چنین است:
User → Resilient DNS → Anycast/Edge DDoS → CDN/WAF/Bot control → Load balancer → Origin/App → Cache/Queue/DB/Third party
هر پیکان یک Trust boundary و یک نقطه Saturation است. دفاع خوب Attack traffic را تا حد ممکن دور از Resource کمیاب دفع میکند و برای ترافیک Legitimate مسیر قابلپیشبینی نگه میدارد.
DNS و Registrar
- Registrar و DNS را با MFA، Role حداقلی، Lock و Audit log محافظت کنید.
- Authoritative DNS با ظرفیت و DDoS protection مناسب انتخاب کنید.
- TTL و تغییر Emergency را تمرین کنید؛ TTL پایین دائمی هزینه و بار DNS را بالا میبرد.
- Status page و راه تماس اضطراری را روی Failure domain مستقل نگه دارید.
Edge، Anycast و Scrubbing
حملات حجمی باید پیش از اشباع Link باریک شما دفع شوند. Anycast، ظرفیت توزیعشده و Scrubbing در Provider/ISP این نقش را دارند. راهنمای رسمی AWS برای معماری DDoS-resilient استفاده از سرویسهای Edge، DNS، Load balancing، WAF، Metrics و Runbook را بهصورت لایهای توضیح میدهد. مستند Azure DDoS Protection نیز دفاع شبکه L3/L4 را از WAF لایه ۷ جدا میکند.
CDN همه Protocolها یا Endpointها را خودکار پوشش نمیدهد. مشخص کنید HTTP/S، TCP/UDP، DNS، API، WebSocket و پورتهای غیروب هرکدام کجا محافظت میشوند. راهنمای انتخاب و راهاندازی CDN برای سایت ایرانی مسیر تصمیم Provider، Cache، Purge و Failover را تکمیل میکند.
Origin را واقعاً ببندید
«استفاده از CDN» مساوی «مخفی بودن Origin» نیست. رکورد DNS-only، Subdomain قدیمی، Mail header، Certificate history یا IP قبلی میتواند Origin را آشکار کند. پس:
- در Firewall فقط Rangeهای معتبر Edge و مسیرهای مدیریت لازم را Allow کنید؛
- در صورت امکان از Private connectivity، Tunnel یا mTLS میان Edge و Origin استفاده کنید؛
- Origin certificate و Host validation را فعال کنید؛
- DNS history و همه Hostnameها را Audit و IP فاششده را در صورت امکان Rotation کنید؛
- Direct-to-origin probe مجاز برای تیم عملیات داشته باشید، نه Endpoint عمومی ناشناس.
راهنمای رسمی Cloudflare برای محافظت Origin نیز Proxy رکوردها، بررسی افشای DNS و محدودکردن ورودی Origin را توصیه میکند. Allowlist IP بهتنهایی، بهویژه در برابر Spoofing یا تغییر Range، نیازمند طراحی و نگهداری است.
WAF، Rate limit و Bot control چه نقشی دارند؟
WAF درخواست HTTP را میبیند و برای حمله لایه Application مفید است؛ اما جایگزین دفاع Network نیست. Policy باید از Endpoint، Method، Auth state و هزینه عملیات آگاه باشد. معماری و Rollout قانونها در راهنمای فایروال و WAF سایت عمیقتر آمده است.
Rate limit بر پایه هزینه، نه یک عدد عمومی
قانون «۱۰۰ درخواست در دقیقه برای هر IP» ممکن است دفتر مشترک، NAT اپراتور یا خزنده مجاز را مسدود و بات توزیعشده را عبور دهد. Budget را براساس رفتار Legitimate و Cost endpoint بسازید:
| Endpoint | کلید شمارش | Budget | Action پلهای |
|---|---|---|---|
| صفحه Cacheable | IP/ASN + Fingerprint محافظتشده | نسبتاً بالا | Observe → Challenge → Temporary limit |
| Login/OTP | Account + Device + IP | کم و جدا برای Send/Verify | Delay/Challenge/Quota بدون Lockout قربانی |
| Search | Session/User + Query cost | Complexity budget | Cache، محدودیت Filter، Degrade |
| Export/Report | Authenticated user/tenant | Concurrency و Daily quota | Queue و Asynchronous job |
| GraphQL/API | Token/Client/Operation | Depth/Complexity/Cost | Reject/Throttle و Retry-After |
مستند رسمی Cloudflare برای Rate limiting نیز سناریوهای Endpoint، هویت و Complexity را جدا میکند. از Log/Simulate شروع کنید، False positive را بسنجید، Rule را Canary و Expiry تعیین کنید. Emergency rule بدون TTL/Owner معمولاً ماهها باقی میماند و کاربر سالم را آسیب میزند.
برای API، Rate limit فقط یکی از کنترلهاست؛ Authorization سطح Object/Function، Inventory، Schema validation، Resource bound و Log نیز باید کنار آن باشند. جزئیات پیادهسازی در راهنمای امنیت API و OWASP آمده است.
Challenge و CAPTCHA را کمینه کنید
Challenge میتواند Automation بد را کم کند، اما Cost، Accessibility، Privacy، SEO و کاربر شبکه ضعیف را تحتتأثیر میگذارد. CAPTCHA دفاع Volumetric نیست و حتی ممکن است هزینه Render/Application را بالا ببرد. آن را فقط برای Risk بالاتر و مسیر قابلدسترس جایگزین بهکار ببرید؛ Search bot تأییدشده، Monitoring و Integration شریک را بیدلیل Challenge نکنید.
Geo-blocking و IP blocking؛ کنترلهای موقت و ناقص
منبع IP میتواند توزیعشده، Proxyشده یا Spoofed باشد و کاربر ایرانی ممکن است بهدلیل VPN از منطقه دیگری دیده شود. Geo-block فقط وقتی قابلدفاع است که بازار مجاز، الزام حقوقی و False positive روشن باشد. IP block دستی برای چند مبدأ غالب میتواند زمان بخرد، اما در DDoS گسترده مقیاسپذیر نیست. برای مقابله ریشهای با Source spoofing، کنترلهای شبکه اپراتورها مانند Ingress filtering در BCP ۳۸/۸۴ اهمیت دارند؛ این مسئله صرفاً با Firewall سایت حل نمیشود.
خود برنامه را در برابر Resource exhaustion مقاوم کنید
حمله L7 ممکن است با RPS کم، Query یا Dependency گران را مصرف کند. کنترلهای دفاعی:
- Bounded work: حد Size، Depth، Page size، Upload، Timeout و Complexity؛
- Cache: محتوای عمومی، Negative cache و جلوگیری از Stampede؛
- Queue: Job سنگین Async با Capacity و Backpressure؛
- Bulkhead: Pool جدا برای Login، Checkout، Search و Admin تا یک مسیر همه را نخواباند؛
- Circuit breaker: قطع موقت Dependency خراب با Fallback کنترلشده؛
- Load shedding: رد زودهنگام درخواست کماولویت پیش از مصرف DB؛
- Idempotency: جلوگیری از چندبار اجرا شدن Payment/Order/OTP در Retry؛
- Query budget: Index، Cursor pagination و جلوگیری از N+۱/Unbounded filter؛
- Degraded mode: Read-only catalog، صف سفارش یا غیرفعالسازی Feature غیرحیاتی.
Autoscaling ظرفیت میدهد اما Filter نیست. میتواند حمله را تا DB یا سرویس پیامک تقویت و هزینه ایجاد کند. سقف، Cooldown، Downstream capacity و Cost alert تعیین کنید. Failover منطقهای هم اگر Attack با DNS به مقصد جدید دنبال شود، فقط قربانی را جابهجا میکند؛ Secondary باید همان کنترل و Telemetry را داشته باشد.
سناریوی WordPress و WooCommerce
در WordPress، افزونه امنیتی روی Origin نمیتواند Link اشباعشده را نجات دهد. دفاع را از Edge آغاز کنید و نقاط پرهزینه را بشناسید:
| سطح | کنترل | Acceptance |
|---|---|---|
| Edge | Cache صفحه ناشناس، WAF، Bot و Rate rule | Origin hit و Cache key اندازهگیری شود |
| Origin | فقط Edge، TLS/Host validation و Admin path کنترلشده | Direct public request رد شود |
wp-login.php | Rate/step-up بر Account+IP، MFA مدیر | کاربر NATشده و Recovery قفل نشود |
xmlrpc.php | اگر Integration نیاز ندارد Disable؛ در غیر این صورت Limit | Jetpack/App/Integration قبل از تغییر تست شود |
admin-ajax.php/REST | Route owner، Auth، Nonce، Cache/Quota و Cost | Endpoint عمومی بدون حد وجود نداشته باشد |
| WooCommerce | Cart/Checkout جدا از Cache عمومی، Idempotency و Queue | پرداخت/Callback/Refund با Retry سالم باشد |
| Database | Top query، Pool، Lock و Slow log محدود | حمله Search همه Worker/DB را نگیرد |
تغییر کورکورانه XML-RPC یا REST میتواند Integration را بشکند. هر Rule را با Inventory، Owner، Log mode، Test و Rollback اعمال کنید. اگر Shared hosting دارید، سقف اتصال، سیاست Provider و مسیر Escalation تعیینکنندهاند؛ راهنمای امنیت هاست اشتراکی و زمان مهاجرت برای سنجش این محدودیتهاست.
Runbook مقابله با DDoS
Runbook باید کوتاه، قابلاجرا و خارج از سامانه تحت حمله در دسترس باشد. NIST SP 800-61 Rev.3 Incident response را بخشی از مدیریت ریسک مستمر میداند: آمادگی، تشخیص، پاسخ، بازیابی و یادگیری باید به هم متصل باشند.
۰ تا ۱۵ دقیقه: تأیید و فرماندهی
- Incident ID، Start time، Severity و Incident commander را اعلام کنید.
- اثر واقعی بر Journey/SLO را با Probe و Business metric ثبت کنید.
- Release/Change و Incidentهای Provider/ISP/Dependency را بررسی کنید.
- Edge/Origin/Network/App telemetry را Snapshot و Retention را حفظ کنید.
- Case اضطراری با Hosting/CDN/DDoS provider باز و شماره Escalation ثبت کنید.
۱۵ تا ۳۰ دقیقه: Mitigation کمریسک
- لایه/Vector/Target endpoint را تعیین و Rule ازپیشتأییدشده را فعال کنید.
- Cache و Origin lockdown را بررسی؛ IP/Port دورزننده Edge را ببندید.
- Endpoint پرهزینه را با Rate/Concurrency/Queue یا Degraded mode محافظت کنید.
- Critical path مانند Login/Checkout را از Feature کماهمیت Bulkhead کنید.
- False positive، Latency، Error، Origin load و Business success را همزمان ببینید.
۳۰ تا ۶۰ دقیقه: تثبیت و ارتباط
- اگر کنترل مؤثر نیست، Escalation Provider و Scrubbing/Route ازپیشتوافقشده را اجرا کنید.
- Status page مستقل را با Impact و زمان Update بعدی بهروز کنید؛ درباره Attribution حدس نزنید.
- Support script برای کاربران، سفارش نیمهکاره و پرداخت نامشخص بدهید.
- هر تغییر Rule، Threshold، Owner، زمان و نتیجه را در Timeline ثبت کنید.
- اگر نشانه نفوذ یا تغییر داده هست، Workstream امنیتی جدا باز کنید.
بازیابی و خروج از حالت دفاعی
پس از افت ترافیک فوراً همه کنترلها را خاموش نکنید. Attack ممکن است موجی باشد. Exit criteria تعیین کنید: پایداری SLO برای بازه مشخص، Queue تخلیهشده، Dependency سالم، False positive قابلقبول و تأیید Provider. Emergency ruleها را مرحلهای Rollback و User journey را Smoke test کنید.
Backup از DDoS جلوگیری نمیکند، اما اگر Incident همزمان با خرابی یا تغییر داده باشد Recovery لازم است. RTO/RPO، Restore و ارتباط با DR در راهنمای بازیابی فاجعه و Backup سایت آمده است.
جدول تصمیم Mitigation
| شاهد | اقدام محتمل | ریسک/Guardrail |
|---|---|---|
| Link/pps اشباع پیش از Origin | Provider L3/L4، Anycast و Scrubbing | Route change و پوشش همه IP/Protocol |
| HTTP flood روی صفحات عمومی | Cache، WAF managed rule و adaptive challenge | SEO/Accessibility/False positive |
| Search/GraphQL گران | Cost budget، Depth/Filter limit و Queue | کاربر Power و Partner API |
| Origin bypass | Firewall allow Edge، rotate IP و audit leaks | Webhook/Monitoring/Admin مجاز |
| DB/Pool اشباع | Load shedding، concurrency و Cache | Consistency و Critical writes |
| Region/ISP خاص | Route/Provider escalation و Probe مستقل | اختلال شبکه را حمله فرض نکنید |
| WAF همه را مسدود کرده | Rollback/Scope rule و Allow trusted flow | Attack دوباره عبور نکند |
چگونه سرویس DDoS Protection را ارزیابی کنیم؟
قیمت ماهانه بدون Scope ارزشی ندارد. این پرسشها را مکتوب بپرسید:
| حوزه | پرسش خرید | شاهد پذیرش |
|---|---|---|
| Coverage | کدام Domain/IP/Protocol و L3/L4/L7 پوشش دارد؟ | Asset-to-control matrix |
| Mode | Always-on یا On-demand؟ زمان Route/Mitigation؟ | Runbook و Drill result |
| Origin | Private path/mTLS/Allowlist و IP rotation چگونه است؟ | Direct-origin negative test |
| Detection | Baseline/Threshold/Custom policy و False positive؟ | Metric و Sample incident report |
| Capacity | Clean traffic، Regional limit و Shared capacity چیست؟ | SLA/Architecture، نه شعار «نامحدود» |
| Operations | ۲۴×۷، زبان/کانال، Severity و Escalation؟ | Call tree و response target |
| Telemetry | Real-time log/metric، Retention و API export؟ | Test dashboard و SIEM path |
| Cost | Attack traffic، WAF request، Log، Scale و overage؟ | سناریوی Cost spike و سقف |
| Data/Access | TLS termination، log location، Privacy و تحریم؟ | DPA، Key ownership و continuity plan |
| Exit | DNS/IP/Rule/Log چگونه منتقل میشود؟ | Export و rollback rehearsal |
در ایران، امکان پرداخت و تمدید، احراز هویت، مالکیت Account، دسترسی تیم در زمان Incident، مسیر داخلی/خارجی، پشتیبانی فارسی، Data locality و قابلیت انتقال Ruleها را هم بسنجید. سرویس خارجی قدرتمند که هنگام Incident نتوانید وارد حسابش شوید، Control قابلاتکا نیست. بودجه را بر Loss exposure، RTO، Coverage gap و Evidence ببندید؛ روش کامل در راهنمای بودجه امنیت سایت آمده است.
تست DDoS را ایمن و قانونی انجام دهید
هرگز برای «تست» بدون مجوز مکتوب به سامانه Production یا زیرساخت ثالث ترافیک حمله نفرستید. ممکن است قرارداد Hosting/CDN، قانون یا کاربران دیگر را نقض کند. تست را چندلایه کنید:
- Tabletop: سناریو، تماسها، اختیار Rule، ارتباط و Decision gate را تمرین کنید.
- Configuration test: Origin lockdown، Alert، Rule در Log mode، Status page و Export telemetry را بررسی کنید.
- Load/performance test: ظرفیت Legitimate را در محیط و سقف توافقشده، جدا از شبیهسازی حمله بسنجید.
- Provider-approved simulation: فقط با Partner/Range/Window/Stop condition و مجوز همه مالکان اجرا کنید.
- Game day: Alert تا Escalation، Mitigation، Communication، Recovery و Postmortem را زمانگیری کنید.
هدف «بزرگترین ترافیک» نیست؛ اثبات Control است: آیا Alert رسید؟ آیا On-call پاسخ داد؟ آیا Origin مستقیم بسته بود؟ آیا Checkout سالم ماند؟ آیا Rule Rollback شد؟ مستند Azure نیز Runbook، Telemetry و Simulation مجاز را جزو آمادگی عملیاتی میداند.
Postmortem و شواهد اثربخشی
| پرسش | شاهد |
|---|---|
| چه زمانی Impact آغاز و کشف شد؟ | Probe، SLO، Provider flag و Timeline |
| کدام Resource اول اشباع شد؟ | Network/App/DB/Dependency metrics |
| چه مقدار Attack در Edge دفع شد؟ | Allowed/Challenged/Dropped و Origin delta |
| کاربر واقعی چقدر آسیب دید؟ | Task success، Error، Support و Segment |
| کدام Rule کمک یا آسیب زد؟ | Rule ID، Before/After و False positive |
| هزینه مستقیم/فرصت چه بود؟ | Scale، Egress، Provider، Refund و Contribution |
| چه تغییر سیستمی لازم است؟ | Owner، Deadline، Acceptance و Retest |
Postmortem نباید فقط «IPهای بد را مسدود کردیم» باشد. Root cause اثر کسبوکاری ممکن است Origin exposure، نبود Queue، Rule بدون Owner، Escalation کند یا Status page همدامنه باشد. Action item بدون Owner و Verification بدهی عملیاتی است.
برنامه ۳۰روزه افزایش مقاومت DDoS
- روز ۱ تا ۵: Service/Journey/Public asset/Dependency map، SLO و Contact tree بسازید.
- روز ۶ تا ۱۰: DNS/IP/Port/Origin leak را Audit و Edge coverage را با Provider تطبیق دهید.
- روز ۱۱ تا ۱۵: Baseline و Dashboard برای bps/pps/rps/Cost/Cache/App/Business و Alert چندسیگنالی بسازید.
- روز ۱۶ تا ۲۰: Endpoint cost، WAF/Rate/Quota/Queue/Timeout/Load shedding و Degraded mode را تعریف کنید.
- روز ۲۱ تا ۲۵: Runbook، Severity، Emergency rule، Expiry، Status page و متن ارتباط را آماده کنید.
- روز ۲۶ تا ۳۰: Tabletop و Drill مجاز اجرا، Gapها را اصلاح و Evidence pack را بهروز کنید.
چکلیست مقابله با حملات DDoS
- Journey، SLO، RTO و Loss exposure مشخصاند.
- همه Domain/IP/Port/API/Webhook و Third partyها Inventory شدهاند.
- Coverage دفاع L3/L4 و L7 به تفکیک Asset روشن است.
- Origin فقط از مسیرهای مجاز Edge/Management قابلدسترسی است.
- DNS، Registrar، Account و Rule تغییرات MFA/RBAC/Audit دارند.
- Baseline فصلی و Segmentشده برای Network/App/Business وجود دارد.
- Rate limit بر Endpoint cost و هویت مناسب است، نه IP عمومی تنها.
- WAF rule ابتدا Log/Canary و سپس Block میشود و Expiry دارد.
- Cache، Queue، Bulkhead، Timeout، Circuit breaker و Load shedding بررسی شدهاند.
- Autoscaling سقف هزینه و Downstream guardrail دارد.
- Checkout/OTP/Payment و حالت Retry/Unknown در ایران آزموده شدهاند.
- Probe و Status page خارج Failure domain هستند.
- Runbook، Incident commander، Call tree و Provider case آمادهاند.
- Communication از Attribution تأییدنشده پرهیز میکند.
- Drill فقط با مجوز، Window، Range و Stop condition اجرا میشود.
- Recovery، Rollback rule و Postmortem با Owner/Acceptance تعریف شدهاند.
پرسشهای متداول
آیا CDN بهتنهایی جلوی همه حملات DDoS را میگیرد؟
خیر. Coverage به Provider، Plan، Protocol و معماری بستگی دارد. CDN میتواند HTTP Cacheable و بخشی از ترافیک Edge را جذب کند، اما Origin افشاشده، L3/L4 خارج Coverage، API یا Endpoint گران Application به کنترلهای دیگری نیاز دارند.
هنگام حمله DDoS اول چه کاری انجام دهیم؟
اثر و لایه را با Probe، Edge/Origin telemetry و تغییرات اخیر تأیید کنید؛ Incident commander تعیین و Provider را طبق Runbook درگیر کنید. سپس Mitigation ازپیشتأییدشده را روی Target مشخص فعال و همزمان False positive و موفقیت Journey را بسنجید.
آیا Block کردن IP یا کشور راهحل مؤثری است؟
گاهی کنترل موقت است، نه دفاع کامل. DDoS میتواند توزیعشده یا Proxyشده باشد و NAT/VPN کاربران سالم را پشت همان IP/Region قرار دهد. IP/Geo rule باید Evidence، زمان انقضا، استثنا و پایش False positive داشته باشد.
تفاوت WAF و سرویس DDoS Protection چیست؟
سرویس Network DDoS معمولاً حملات حجمی و Protocol در L3/L4 را پیش از Origin دفع میکند؛ WAF درخواست HTTP لایه ۷ و رفتار Endpoint را میبیند. وبسایت پرریسک معمولاً هر دو، بهعلاوه Resilience داخل برنامه و Runbook عملیاتی میخواهد.
آیا DDoS باعث سرقت اطلاعات میشود؟
DDoS مستقیماً Availability را هدف میگیرد و بهخودیخود اثبات نفوذ یا سرقت داده نیست. اما میتواند همزمان با حمله دیگری رخ دهد. Logهای هویت، تغییر داده و دسترسی غیرعادی را جدا بررسی و در صورت وجود شاهد، Incident امنیتی مستقل مدیریت کنید.
جمعبندی: مقاومت DDoS از خرید Capacity شروع و تمام نمیشود. Service map، Origin بسته، دفاع Edge و Application، Rate limit هزینهمحور، Telemetry مستقل، Runbook تمرینشده و Recovery قابلاثبات باید یک سیستم باشند. هدف نهایی «صفر ترافیک مخرب» نیست؛ حفظ کار حیاتی کاربر با هزینه و ریسک کنترلشده است.
