حملات DDoS را بشناسید و خنثی کنید؛ این جمله شاید در نگاه اول یک توصیه امنیتی ساده به نظر برسد، اما در واقع خلاصه‌ای است از یکی از پیچیده‌ترین چالش‌هایی که هر مدیر سرور و توسعه‌دهنده وردپرس ممکن است با آن روبه‌رو شود. حمله DDoS (Distributed Denial of Service) یا «انکار سرویس توزیع‌شده»، نوعی حمله سایبری است که در آن مهاجم با استفاده از شبکه‌ای از دستگاه‌های آلوده، حجم عظیمی از درخواست‌های جعلی را به سمت هدف روانه می‌کند تا منابع سرور را اشغال کرده و سرویس را از دسترس کاربران واقعی خارج کند. برخلاف تصور رایج، DDoS فقط برای سایت‌های بزرگ و شرکت‌های فناوری رخ نمی‌دهد؛ آمارها نشان می‌دهد که بیش از ۴۰ درصد حملات DDoS علیه کسب‌وکارهای کوچک و متوسط انجام می‌شود و بسیاری از آن‌ها هرگز در رسانه‌ها بازتاب پیدا نمی‌کنند. در این نوشتار، لایه‌به‌لایه از تعریف و انواع حمله تا راهبردهای دفاعی عملی و پیکربندی سرور و CDN را بررسی می‌کنیم.

خلاصه آنچه در ادامه می‌آید: حمله DDoS با اشغال پهنای باند، منابع پردازشی یا اتصالات شبکه، سرویس را از دسترس خارج می‌کند. این حملات در سه لایه اصلی OSI رخ می‌دهند: لایه شبکه (حجمی)، لایه انتقال (پروتکل) و لایه کاربردی (اپلیکیشن). شناخت علائم اولیه—کندی ناگهانی، افزایش مصرف CPU و پهنای باند، خطاهای ۵۰۳ و ۵۰۴—برای واکنش سریع ضروری است. دفاع مؤثر ترکیبی از CDN، WAF، Rate Limiting، تنظیمات سرور، و برنامه پاسخ به حادثه است. Cloudflare، Sucuri، AWS Shield و Azure DDoS Protection از جمله سرویس‌های تجاری هستند که می‌توانند بخش بزرگی از بار حمله را جذب کنند. در سرور وردپرس، تنظیمات Nginx، محدودسازی درخواست‌ها و غیرفعال‌سازی XML-RPC از گام‌های کلیدی محسوب می‌شوند. در پایان، جدول مقایسه راهکارها و پرسش‌های پرتکرار تصمیم‌گیری را روشن‌تر می‌کند.

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

DDoS چیست و چه تفاوتی با DoS دارد؟

حمله DoS (Denial of Service) یا «انکار سرویس»، نوعی حمله است که در آن یک مهاجم واحد تلاش می‌کند با ارسال درخواست‌های مخرب، سرویس را از دسترس خارج کند. در مقابل، حمله DDoS (Distributed Denial of Service) از شبکه‌ای از دستگاه‌های آلوده—که به آن‌ها «بات‌نت» (Botnet) می‌گویند—برای رسیدن به همان هدف استفاده می‌کند. تفاوت بنیادین این دو در منبع حمله است: در DoS، مهاجم یک نقطه است و می‌توان با بلاک کردن IP آن، حمله را متوقف کرد. اما در DDoS، هزاران یا حتی میلیون‌ها دستگاه از نقاط مختلف جهان در حمله مشارکت دارند و بلاک کردن یک IP هیچ تأثیری ندارد.

بات‌نت‌ها معمولاً از دستگاه‌های اینترنت اشیا (IoT - Internet of Things) آلوده ساخته می‌شوند: دوربین‌های امنیتی، روترهای خانگی، دستگاه‌های ضبط ویدیو و حتی برخی لوازم خانگی هوشمند. این دستگاه‌ها اغلب با رمزهای پیش‌فرض یا نرم‌افزارهای قدیمی کار می‌کنند و به‌سادگی آلوده می‌شوند. مطالعه‌ای نشان داد که بیش از ۵۰ درصد حملات DDoS با استفاده از بات‌نت‌های IoT انجام می‌شود و این رقم در حال رشد است. اگر می‌خواهید درباره امنیت این دستگاه‌ها بیشتر بدانید، نوشتار امنیت در اینترنت اشیا را ببینید.

هدف اصلی DDoS همیشه از کار انداختن دائمی سرویس نیست. در بسیاری از موارد، مهاجمان به دنبال اخاذی، رقابت ناسالم، انحراف توجه از حمله اصلی (Smoke Screen) یا صرفاً ایجاد اختلال موقت هستند. آمارها نشان می‌دهد که حدود ۳۰ درصد حملات DDoS با انگیزه مالی انجام می‌شود و متوسط هزینه هر حمله برای قربانی، بین ۲۰٬۰۰۰ تا ۵۰۰٬۰۰۰ دلار تخمین زده می‌شود. این هزینه شامل از دست رفتن فروش، هزینه بازیابی، خسارت به اعتبار برند و احتمال پرداخت باج است.

DDoS یک مسئله فنی نیست؛ یک مسئله کسب‌وکاری است که خود را در قالب کندی سرور نشان می‌دهد. هر تصمیم دفاعی باید با معیار «چقدر کسب‌وکار را از دست می‌دهیم» سنجیده شود.

برای مطالعه بیشتر درباره مفاهیم پایه امنیت، نوشتار امنیت وب چیست؟ و حملات DDoS را بشناسید و خنثی کنید را توصیه می‌کنم. همچنین برای مطالعه تعریف آکادمیک DDoS می‌توانید به صفحه ویکی‌پدیای آن مراجعه کنید: Denial-of-service attack.

انواع حملات DDoS در لایه‌های OSI

حملات DDoS را می‌توان بر اساس لایه‌ای از مدل OSI (Open Systems Interconnection) که هدف قرار می‌دهند، دسته‌بندی کرد. این دسته‌بندی نه‌تنها برای درک علمی، بلکه برای انتخاب راهکار دفاعی مناسب ضروری است.

حملات حجمی (Volumetric Attacks) - لایه ۳ و ۴

این حملات حجم زیادی از داده را به سمت هدف روانه می‌کنند تا پهنای باند را اشباع کنند. حجم این حملات معمولاً بر حسب گیگابیت بر ثانیه (Gbps) اندازه‌گیری می‌شود. دو نوع رایج آن عبارت‌اند از:

  • UDP Flood: ارسال حجم عظیمی از بسته‌های UDP به پورت‌های تصادفی سرور.
  • ICMP Flood: ارسال درخواست‌های Ping متعدد (Ping of Death) که سرور را مجبور به پاسخ‌دهی می‌کند.
  • DNS Amplification: استفاده از سرورهای DNS باز برای تقویت حجم حمله تا چند برابر. یک درخواست کوچک می‌تواند پاسخی بزرگ‌تر از ۵۰ برابر تولید کند.
  • NTP Amplification: مشابه DNS Amplification اما با پروتکل NTP.

بزرگ‌ترین حمله حجمی ثبت‌شده تاکنون، حمله‌ای با حجم بیش از ۳٫۴۷ ترابیت بر ثانیه در سال ۲۰۲۱ بود که علیه یکی از سرویس‌های ابری انجام شد. این عدد بیش از ۱۰ برابر بزرگ‌ترین حملات چند سال قبل است و نشان می‌دهد که مقیاس این تهدید به‌سرعت در حال رشد است.

حملات پروتکلی (Protocol Attacks) - لایه ۳ و ۴

این حملات به‌جای حجم زیاد، از ضعف‌های پروتکل‌های شبکه برای اشغال منابع سرور یا تجهیزات میانی سوءاستفاده می‌کنند. نمونه‌های معروف:

  • SYN Flood: ارسال حجم بالایی از درخواست‌های SYN بدون تکمیل Handshake سه‌مرحله‌ای TCP. سرور مجبور به نگه‌داشتن اتصالات نیمه‌باز در حافظه می‌شود.
  • Ping of Death: ارسال بسته‌های ICMP غیرمجاز بزرگ که باعث کرش کردن سیستم‌های قدیمی می‌شود.
  • Smurf Attack: استفاده از آدرس IP قربانی به‌عنوان مبدأ ارسال درخواست‌های ICMP Broadcast.
  • Teardrop Attack: ارسال بسته‌های دستکاری‌شده IP برای سوءاستفاده از باگ در تکه‌تکه کردن (Fragmentation).

SYN Flood یکی از پایدارترین و همچنان پرکاربردترین بردارهای حمله است، زیرا هم پیاده‌سازی آن ساده است و هم دفاع در برابر آن، بدون تجهیزات خاص، دشوار. راهکارهای کاهش این حمله شامل فعال‌سازی SYN Cookies در هسته لینوکس و تنظیم Backlog مناسب در وب‌سرور است.

حملات لایه اپلیکیشن (Application Layer Attacks) - لایه ۷

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

  • نیازی به پهنای باند زیادی ندارند؛ حتی چند صد درخواست در ثانیه می‌تواند یک سایت را از کار بیندازد.
  • تشخیص آن‌ها از ترافیک واقعی بسیار دشوار است.
  • بسیاری از فایروال‌های سنتی نمی‌توانند آن‌ها را تشخیص دهند.

نمونه‌های رایج لایه ۷:

  • HTTP Flood: ارسال انبوه درخواست‌های GET یا POST به صفحات پویا.
  • Slowloris: باز نگه‌داشتن اتصالات HTTP با ارسال هدرهای ناقص و بسیار کند. هر اتصال یک Thread یا Process سرور را اشغال می‌کند.
  • RUDY (Are You Dead Yet?): مشابه Slowloris اما با ارسال کند بدنه POST.
  • XML-RPC Flood: سوءاستفاده از پورت XML-RPC در وردپرس برای ارسال پینگ‌بک‌های جعلی.
  • WordPress REST API Flood: ارسال درخواست‌های سنگین به REST API وردپرس.

حملات لایه ۷ معمولاً از نظر حجم داده کوچک اما از نظر اثر مخرب بسیار مؤثرند. مطالعه‌ای روی ۵۰۰ حمله DDoS نشان داد که ۲۷ درصد از حملات مدرن از این نوع هستند و میانگین زمان بیدفاع‌ماندن سایت در برابر آن‌ها، بیش از یک ساعت است. برای مطالعه بیشتر درباره حملات اپلیکیشن، نوشتار حمله تزریق کد چیست و چگونه دفع می‌شود؟ را ببینید.

علائم هشدار: چگونه بفهمیم تحت حمله هستیم؟

تشخیص سریع حمله DDoS، تفاوت میان یک وقفه کوتاه و یک فاجعه طولانی است. علائم زیر معمولاً هم‌زمان ظاهر می‌شوند و باید به آن‌ها توجه کرد:

  • کندی ناگهانی سایت بدون تغییر در کد یا افزونه‌ها.
  • افزایش ناگهانی مصرف CPU و RAM سرور بدون افزایش ترافیک واقعی کاربران.
  • خطاهای ۵۰۳ (Service Unavailable) و ۵۰۴ (Gateway Timeout) در لاگ وب‌سرور.
  • افزایش شدید تعداد اتصالات هم‌زمان در دستور netstat یا ss.
  • خطاهای Timeout در پاسخ‌دهی دیتابیس به دلیل اشغال اتصالات توسط حمله.
  • افزایش ترافیک خروجی از حد معمول در پنل هاست یا CDN.
  • عدم پاسخ‌دهی سایت به کاربران ایرانی یا خارجی به‌طور هم‌زمان.

در سرورهای لینوکس، دستورات زیر می‌توانند در تشخیص اولیه کمک کنند:

# مشاهده اتصالات هم‌زمان به پورت ۸۰ و ۴۴۳
ss -tan 'sport = :http' | awk '{print $1}' | sort | uniq -c

# مشاهده IPهایی با بیشترین اتصال
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n

# بررسی بار پردازنده
top -b -n 1 | head -20

اگر تعداد اتصالات از یک یا چند IP به‌طور غیرعادی بالا باشد و هم‌زمان بار CPU سرور به‌سقف برسد، احتمال حمله DDoS بسیار بالاست. در این مرحله، سرعت واکنش حیاتی است؛ هر دقیقه تأخیر می‌تواند به از دست رفتن کاربران، افت رتبه در گوگل و در موارد شدید، ریست شدن سرور منجر شود.

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

برای مطالعه بیشتر درباره مانیتورینگ و شناسایی رفتار غیرعادی سرور، نوشتار مانیتورینگ سرور چگونه انجام می‌شود؟ راهنمای عملی خوبی است.

بردارهای رایج حمله علیه سایت‌های وردپرسی

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

  • XML-RPC Flood: در وردپرس، فایل xmlrpc.php برای پینگ‌بک و ارتباط با اپلیکیشن‌های موبایل استفاده می‌شود. مهاجم می‌تواند با ارسال درخواست‌های متعدد به این فایل، سرور را اشغال کند. غیرفعال کردن این فایل در صورت عدم نیاز، از مؤثرترین راه‌های کاهش سطح حمله است.
  • wp-login.php Flood: حمله به صفحه ورود با درخواست‌های POST تکراری. این نوع حمله هم می‌تواند به‌عنوان DDoS و هم به‌عنوان Brute Force عمل کند.
  • REST API Flood: درخواست‌های متعدد به /wp-json/wp/v2/posts یا سایر Endpointها. اگر REST API محدود نشود، می‌تواند به‌عنوان یک بردار حمله لایه ۷ عمل کند.
  • Admin-Ajax Flood: فراخوانی مکرر admin-ajax.php که در هر بار بارگذاری، فایل‌های هسته وردپرس و افزونه‌ها را بارگذاری می‌کند. این بردار بسیار خطرناک است زیرا حتی درخواست‌های محدود می‌توانند بار سنگینی ایجاد کنند.
  • Search Flood: ارسال درخواست‌های جستجو با عبارت‌های تصادفی که در هر بار، کوئری سنگینی به دیتابیس ارسال می‌کند.

در یکی از پروژه‌های واقعی، حمله‌ای با نرخ تنها ۲۰۰ درخواست در ثانیه به admin-ajax.php باعث شد سرور با ۸ هسته CPU و ۱۶ گیگابایت RAM به‌طور کامل از کار بیفتد. این نشان می‌دهد که حجم حمله همیشه تعیین‌کننده نیست؛ هدف قرار دادن نقطه ضعف اپلیکیشن، بسیار کارآمدتر از حجم زیاد است.

راهبردهای دفاعی و پیشگیری

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

  1. لایه CDN و Anycast: پخش کردن ترافیک در چندین نقطه جغرافیایی برای جذب حجم حمله.
  2. لایه WAF: تشخیص و مسدودسازی درخواست‌های مخرب بر اساس الگوهای رفتاری.
  3. لایه Rate Limiting: محدودسازی نرخ درخواست‌ها بر اساس IP، User-Agent یا Endpoint.
  4. لایه سرور: تنظیمات هسته لینوکس، Nginx، PHP-FPM و دیتابیس برای مقاوم‌سازی در برابر بار غیرعادی.
  5. لایه برنامه: بهینه‌سازی کد وردپرس، کاهش تعداد افزونه‌ها و استفاده از کش.
  6. لایه انسانی: آموزش تیم، تهیه Runbook پاسخ به حادثه و پایش مستمر.

مطالعه‌ای روی ۱۰۰ سازمان نشان داد که سازمان‌هایی که رویکرد چندلایه برای مقابله با DDoS داشتند، به‌طور میانگین ۷۳ درصد کاهش در زمان قطعی سرویس تجربه کردند. در مقابل، سازمان‌هایی که تنها به یک ابزار تکیه کرده بودند، همچنان آسیب‌پذیر باقی ماندند.

CDN و Cloudflare: خط اول دفاع

CDN (Content Delivery Network) یا «شبکه توزیع محتوا»، یکی از مؤثرترین راه‌ها برای مقابله با DDoS است. CDN محتوای سایت شما را در چندین سرور جغرافیایی توزیع می‌کند و ترافیک را به نزدیک‌ترین سرور هدایت می‌کند. مزیت امنیتی CDN در این است که سرور اصلی شما پشت CDN پنهان می‌شود و مهاجم نمی‌داند کدام IP را هدف بگیرد. اگر حمله‌ای هم رخ دهد، CDN می‌تواند حجم آن را جذب کند و تنها ترافیک سالم را به سرور اصلی برساند.

Cloudflare یکی از محبوب‌ترین سرویس‌های CDN و امنیت سایت است. این سرویس در لایه‌های رایگان و پولی خود، محافظت‌های متنوعی ارائه می‌دهد:

  • DNS Proxied: مخفی کردن IP واقعی سرور در لایه رایگان.
  • Under Attack Mode: نمایش صفحه چالش JavaScript برای کاربران مشکوک.
  • Rate Limiting: محدودسازی تعداد درخواست‌ها از یک IP در بازه زمانی مشخص.
  • Bot Fight Mode: تشخیص و مسدودسازی ربات‌های مخرب.
  • WAF Managed Rules: قوانین آماده برای مسدودسازی حملات رایج مانند SQL Injection و XSS.
  • DDoS Protection: حفاظت خودکار در برابر حملات حجمی و لایه ۷.

برای فعال‌سازی Cloudflare، باید Nameserverهای دامنه را به Cloudflare تغییر دهید و IP سرور اصلی را در تنظیمات مخفی نگه دارید. یک نکته حیاتی این است که هرگز IP اصلی سرور را در هیچ‌جای سایت—حتی در پست‌های تست یا ابزارهای آنلاین—افشا نکنید. در غیر این صورت، مهاجم می‌تواند Cloudflare را دور بزند و مستقیماً سرور را هدف بگیرد. برای مطالعه بیشتر درباره CDN و انتخاب آن، نوشتار CDN چیست و چگونه سرعت سایت را بهبود می‌دهد؟ را ببینید.

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

WAF و فیلتر هوشمند ترافیک

WAF (Web Application Firewall) یک فایروال لایه ۷ است که ترافیک HTTP/HTTPS را بررسی می‌کند و درخواست‌های مخرب را مسدود می‌کند. برخلاف فایروال سنتی که بر اساس IP و پورت عمل می‌کند، WAF محتوای درخواست را تحلیل می‌کند و می‌تواند الگوهای حمله را در پارامترها، هدرها و بدنه درخواست تشخیص دهد.

انواع WAF از نظر محل استقرار:

  • Cloud-based WAF: مانند Cloudflare WAF، Sucuri Firewall و AWS WAF. مزیت آن جذب ترافیک در لبه شبکه و محافظت از سرور اصلی است.
  • Host-based WAF: مانند ModSecurity نصب‌شده روی سرور. نیاز به تنظیم دقیق دارد و بار CPU اضافه می‌کند.
  • WordPress WAF Plugins: مانند Wordfence و iThemes Security. برای سایت‌های کوچک مناسب هستند اما در برابر حملات حجمی کارایی چندانی ندارند.

WAF Cloudflare به‌طور پیش‌فرض دارای مجموعه قوانینی است که حملات رایج—SQL Injection، XSS، Command Injection و Path Traversal—را مسدود می‌کند. در نسخه‌های پولی، می‌توان قوانین سفارشی تعریف کرد و نرخ درخواست‌ها را به‌طور دقیق محدود کرد. اگر در حال انتخاب افزونه امنیتی وردپرس هستید، نوشتار بهترین افزونه‌های امنیتی وردپرس کدامند؟ مقایسه جامعی ارائه می‌دهد.

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

Rate Limiting و محدودسازی درخواست‌ها

Rate Limiting یکی از مؤثرترین و در دسترس‌ترین راه‌ها برای مقابله با حملات لایه ۷ است. این تکنیک، تعداد درخواست‌هایی که یک IP یا کاربر می‌تواند در بازه زمانی مشخص ارسال کند، محدود می‌کند. برای مثال، می‌توانید تنظیم کنید که هر IP حداکثر ۶۰ درخواست در دقیقه به صفحات پویا ارسال کند.

در Nginx، Rate Limiting با دو ماژول limit_req_zone و limit_req پیاده‌سازی می‌شود:

http {
    limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;
    
    server {
        location /wp-login.php {
            limit_req zone=one burst=5 nodelay;
            # سایر تنظیمات
        }
        
        location /wp-json/ {
            limit_req zone=one burst=10 nodelay;
            # سایر تنظیمات
        }
    }
}

در این پیکربندی، هر IP تنها می‌تواند ۱۰ درخواست در ثانیه ارسال کند و حداکثر ۵ درخواست اضافی را در صف نگه دارد. اگر از این حد فراتر رود، پاسخ ۵۰۳ برگردانده می‌شود. این تنظیم به‌تنهایی می‌تواند بسیاری از حملات لایه ۷ سبک را دفع کند.

در Cloudflare، Rate Limiting از طریق پنل کاربری قابل تنظیم است. می‌توانید بر اساس IP، هدر، مسیر URL یا کوکی، قوانین محدودسازی تعریف کنید. نسخه رایگان Cloudflare اجازه یک قانون Rate Limiting را می‌دهد که برای بسیاری از سایت‌های کوچک کافی است. برای سایت‌های بزرگتر، نسخه Pro یا Business توصیه می‌شود.

Rate Limiting در سطح برنامه نیز با افزونه‌های وردپرس مانند Wordfence و Limit Login Attempts قابل پیاده‌سازی است. اما باید توجه داشت که این افزونه‌ها خودشان بخشی از برنامه وردپرس هستند و در صورت حمله لایه ۷ سنگین، ممکن است خودشان تحت فشار قرار بگیرند. بنابراین، Rate Limiting در سطح سرور یا CDN همیشه مؤثرتر و سریع‌تر است.

سخت‌سازی سرور و تنظیمات Nginx

سخت‌سازی سرور یکی از لایه‌های کلیدی دفاع در برابر DDoS است. حتی اگر CDN و WAF داشته باشید، سرور باید به‌گونه‌ای تنظیم شود که در برابر بار غیرعادی مقاوم باشد. در سرورهای لینوکس، تنظیمات زیر در فایل /etc/sysctl.conf توصیه می‌شود:

# فعال‌سازی SYN Cookies برای مقابله با SYN Flood
net.ipv4.tcp_syncookies = 1

# کاهش زمان انتظار برای بستن اتصالات
net.ipv4.tcp_fin_timeout = 15

# افزایش تعداد اتصالات هم‌زمان
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535

# کاهش تعداد درخواست‌های ICMP
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1

# محدودسازی نرخ ارسال SYN
net.ipv4.tcp_syn_retries = 2

در Nginx، تنظیمات زیر می‌توانند به کاهش اثر حمله کمک کنند:

# محدودسازی تعداد اتصالات هم‌زمان از هر IP
limit_conn_zone $binary_remote_addr zone=addr:10m;
limit_conn addr 10;

# محدودسازی اندازه بدنه درخواست
client_max_body_size 10m;
client_body_timeout 10s;
client_header_timeout 10s;

# محدودسازی زمان ارسال پاسخ
send_timeout 10s;

# مخفی کردن نسخه Nginx
server_tokens off;

# غیرفعال‌سازی XML-RPC
location = /xmlrpc.php {
    deny all;
    access_log off;
}

برای PHP-FPM، تنظیم پارامترهای pm.max_children، pm.max_requests و request_terminate_timeout بسیار مهم است. اگر تعداد Child Processها بیش از حد باشد، حمله لایه ۷ می‌تواند حافظه سرور را اشغال کند. اگر کمتر از حد باشد، سایت در ترافیک عادی نیز کند می‌شود. تنظیم دقیق این پارامترها نیازمند پایش مستمر و تنظیم بر اساس بار واقعی است.

برای مطالعه بیشتر درباره بهینه‌سازی سرور برای وردپرس، نوشتار بهینه‌سازی سرور برای وردپرس راهنمای کاملی است. همچنین اگر با VPS کار می‌کنید، نوشتار امنیت VPS چگونه تامین می‌شود؟ را ببینید.

برنامه پاسخ به حادثه و بازیابی

داشتن یک برنامه پاسخ به حادثه (Incident Response Plan) به‌اندازه خود ابزارهای دفاعی مهم است. بدون برنامه، تیم فنی در لحظه حمله سردرگم می‌شود و زمان طلایی واکنش از دست می‌رود. یک برنامه خوب شامل این مراحل است:

  1. شناسایی: تشخیص اینکه حمله در حال وقوع است. این مرحله نیازمند مانیتورینگ مستمر و هشدارهای خودکار است.
  2. مهار: اقدامات فوری برای کاهش اثر حمله، مانند فعال‌سازی Under Attack Mode در Cloudflare، مسدودسازی IPهای مهاجم و افزایش موقت Rate Limiting.
  3. ریشه‌کنی: شناسایی منبع حمله و مسدودسازی آن در لایه‌های مختلف.
  4. بازیابی: بازگرداندن سرویس به حالت عادی و اطمینان از صحت داده‌ها. اگر داده‌ای از دست رفته، از بکاپ بازگردانی شود. اگر با بکاپ‌گیری آشنایی ندارید، نوشتار چگونه از سایت وردپرسی بکاپ بگیریم؟ را ببینید.
  5. درس‌آموزی: تحلیل حادثه و به‌روزرسانی برنامه دفاعی برای جلوگیری از تکرار.

در تیم‌های حرفه‌ای، Runbook یا «کتابچه واکنش» تهیه می‌شود که شامل دستورات دقیق، لینک‌های سریع به پنل‌های مدیریتی و اطلاعات تماس افراد کلیدی است. این کتابچه باید به‌صورت آفلاین نیز در دسترس باشد، زیرا در زمان حمله ممکن است دسترسی به اینترنت یا پنل‌های ابری مختل شود.

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

تفاوت DDoS با Brute Force و حملات لایه اپلیکیشن

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

DDoS در مقابل، هدفش از کار انداختن سرویس است، نه نفوذ. با این حال، این دو می‌توانند ترکیب شوند: مهاجم می‌تواند در حین حمله DDoS، یک حمله Brute Force را نیز اجرا کند تا توجه تیم امنیتی منحرف شود. به همین دلیل، برنامه دفاعی باید همزمان به هر دو نوع حمله پاسخ دهد.

تفاوت دیگر DDoS با حملات لایه اپلیکیشن مانند SQL Injection و XSS در این است که DDoS به دنبال سوءاستفاده از ضعف کد نیست، بلکه از ضعف ظرفیت منابع استفاده می‌کند. یک سایت با کد امن اما ظرفیت محدود، می‌تواند قربانی DDoS شود. برعکس، یک سایت با ظرفیت بالا اما کد ناامن، می‌تواند قربانی تزریق SQL شود. بنابراین، دفاع در برابر DDoS و دفاع در برابر تزریق، دو رویکرد متفاوت اما مکمل هستند. برای مطالعه بیشتر درباره حملات تزریق، نوشتار حملات SQL Injection و راه‌های مقابله و حملات XSS چیست و چگونه جلوگیری کنیم؟ را توصیه می‌کنم.

جدول مقایسه راهکارهای دفاعی

راهکار لایه حمله مزیت اصلی محدودیت
CDN (Cloudflare, Sucuri) حجمی، پروتکلی، اپلیکیشن پنهان‌سازی IP و جذب حجم حمله هزینه در حجم بالا؛ نیاز به تغییر Nameserver
WAF اپلیکیشن مسدودسازی حملات رایج لایه ۷ نیاز به تنظیم دقیق؛ نمی‌تواند حملات حجمی را دفع کند
Rate Limiting اپلیکیشن کنترل نرخ درخواست در سطح سرور تنظیم نادرست می‌تواند کاربران واقعی را مسدود کند
SYN Cookies پروتکلی (SYN Flood) دفاع مؤثر در برابر SYN Flood تنها یک بردار حمله را پوشش می‌دهد
سخت‌سازی سرور همه لایه‌ها افزایش مقاومت کلی سرور نیاز به تخصص و پایش مستمر
افزونه امنیتی وردپرس اپلیکیشن نصب و راه‌اندازی ساده کارایی محدود در حملات حجمی
Cloud DDoS Protection (AWS Shield, Azure) حجمی، پروتکلی ظرفیت بسیار بالا هزینه بالا و مناسب سازمان‌های بزرگ

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

یکی از رایج‌ترین اشتباهات، نادیده‌گرفتن IP واقعی سرور است. اگر IP سرور اصلی شما در جایی عمومی افشا شده باشد—مثلاً در یک پست تست، DNS تاریخی یا ابزارهای آنلاین—مهاجم می‌تواند Cloudflare را دور بزند و مستقیماً سرور را هدف بگیرد. راه‌حل، تغییر IP سرور پس از فعال‌سازی CDN و اطمینان از عدم افشای آن است.

اشتباه دوم، تکیه بر افزونه‌های امنیتی وردپرس به‌عنوان خط اول دفاع است. این افزونه‌ها در لایه برنامه اجرا می‌شوند و در برابر حملات حجمی یا لایه ۷ سنگین، خودشان تحت فشار قرار می‌گیرند و ممکن است از کار بیفتند. افزونه‌ها مکمل CDN و WAF هستند، نه جایگزین آن‌ها.

اشتباه سوم، نادیده‌گرفتن مانیتورینگ است. اگر نتوانید حمله را در دقیقه اول تشخیص دهید، هر دقیقه تأخیر می‌تواند ساعت‌ها زمان بازیابی به همراه داشته باشد. مانیتورینگ مستمر با ابزارهایی مانند UptimeRobot، Pingdom و Netdata از ضروریات هر سایت جدی است.

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

اشتباه پنجم، نبود برنامه پاسخ به حادثه است. اگر تیم شما نداند در زمان حمله چه کاری باید انجام دهد و چه کسی مسئول تصمیم‌گیری است، زمان طلایی واکنش از دست می‌رود. یک Runbook ساده با دستورات آماده، می‌تواند زمان واکنش را چند برابر کاهش دهد.

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

پرسش‌های پرتکرار درباره حملات DDoS

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

حمله DDoS یا «انکار سرویس توزیع‌شده»، نوعی حمله سایبری است که در آن مهاجم با استفاده از شبکه‌ای از دستگاه‌های آلوده (بات‌نت)، حجم عظیمی از درخواست‌های جعلی را به سمت سرور هدف روانه می‌کند. این درخواست‌ها منابع سرور—پهنای باند، پردازنده، حافظه و اتصالات شبکه—را اشغال می‌کنند و سرویس را از دسترس کاربران واقعی خارج می‌سازند.

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

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

چگونه بفهمیم سایت تحت حمله DDoS است؟

علائم رایج شامل کندی ناگهانی سایت، افزایش شدید مصرف CPU و RAM، خطاهای ۵۰۳ و ۵۰۴، افزایش تعداد اتصالات هم‌زمان در سرور، و کندی دیتابیس بدون تغییر در کد یا افزونه‌هاست. مانیتورینگ مستمر و بررسی لاگ وب‌سرور برای تشخیص سریع ضروری است.

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

بله، Cloudflare یکی از مؤثرترین ابزارها در برابر DDoS است. این سرویس با مخفی کردن IP واقعی سرور، توزیع ترافیک در شبکه Anycast و ارائه قوانین WAF و Rate Limiting، می‌تواند بخش بزرگی از حملات را دفع کند. اما نکته حیاتی این است که IP اصلی سرور هرگز افشا نشود.

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

ترکیب چند لایه ضروری است: فعال‌سازی CDN، استفاده از WAF، تنظیم Rate Limiting در Nginx، فعال‌سازی SYN Cookies در هسته لینوکس، غیرفعال‌سازی XML-RPC در صورت عدم نیاز، محدودسازی REST API، سخت‌سازی PHP-FPM و پایش مستمر. هیچ لایه‌ای به‌تنهایی کافی نیست.

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

افزونه‌های امنیتی وردپرس مانند Wordfence و iThemes Security در برابر حملات لایه اپلیکیشن سبک مؤثرند، اما در برابر حملات حجمی و لایه ۷ سنگین کارایی محدودی دارند. این افزونه‌ها مکمل CDN و WAF هستند، نه جایگزین آن‌ها.

هزینه حمله DDoS برای قربانی چقدر است؟

متوسط هزینه هر حمله برای قربانی بین ۲۰٬۰۰۰ تا ۵۰۰٬۰۰۰ دلار تخمین زده می‌شود. این هزینه شامل از دست رفتن فروش، هزینه بازیابی، خسارت به اعتبار برند و در مواردی پرداخت باج است. برای کسب‌وکارهای کوچک، حتی یک حمله چند ساعته می‌تواند حیاتی باشد.

آیا DDoS جرم است؟

بله، در اکثر کشورها حمله DDoS جرم سایبری محسوب می‌شود و مجازات‌های سنگینی دارد. در ایران نیز قانون جرائم رایانه‌ای مصوب ۱۳۸۸، دسترسی غیرمجاز و اخلال در سیستم‌های رایانه‌ای را جرم شناخته و مجازات‌هایی از حبس تا جریمه نقدی برای آن تعیین کرده است.

چه زمانی باید از سرویس‌های DDoS Protection تجاری استفاده کرد؟

اگر سایت شما ترافیک بالا دارد، هدف حملات مکرر است، یا کسب‌وکار شما به‌شدت به دسترس‌پذیری وابسته است، استفاده از سرویس‌های تجاری مانند AWS Shield Advanced، Azure DDoS Protection یا Cloudflare Enterprise توصیه می‌شود. این سرویس‌ها ظرفیت بسیار بالاتری برای جذب حملات بزرگ دارند و پشتیبانی تخصصی ارائه می‌دهند.

آیا محدود کردن دسترسی جغرافیایی به کاهش DDoS کمک می‌کند؟

محدودسازی جغرافیایی می‌تواند مؤثر باشد، به‌ویژه اگر کاربران اصلی سایت شما از یک یا چند کشور خاص هستند. اما باید با احتیاط انجام شود، زیرا ممکن است کاربران واقعی از کشورهای دیگر—مانند مسافران یا کاربران VPN—را نیز مسدود کند. این راهکار باید به‌عنوان یک لایه مکمل، نه راه‌حل اصلی، در نظر گرفته شود.

اگر این مطلب برایتان مفید بود یا تجربه‌ای در مقابله با DDoS در پروژه‌های واقعی دارید، خوشحال می‌شوم آن را در دیدگاه‌ها به اشتراک بگذارید. به‌ویژه اگر راه‌حل جایگزینی برای کاهش اثر حمله یا ترکیب متفاوتی از ابزارهای دفاعی پیدا کرده‌اید که می‌تواند برای خواننده بعدی هم مفید باشد. 🛡️

برای مطالعه بیشتر درباره امنیت وب و حملات سایبری، نوشتار حملات سایبری چیست و چه انواعی دارد؟ و حملات سایبری رایج علیه وردپرس کدامند؟ را توصیه می‌کنم.