چک‌لیست کامل جلوگیری از حملات دیداس (DDoS)

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

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

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

در شرایطی که وب‌سایت شما ناگهان از دسترس خارج می‌شود، آن‌هم نه به خاطر باگ یا مشکل داخلی، بلکه به‌دلیل هجوم هزاران درخواست همزمان و جعلی، یک حمله ddos یا Distributed Denial-of-Service رخ داده است. در این حمله که شبیه یک ترافیک سنگین ساختگی در خیابانی بن‌بست است، مهاجمان با استفاده از شبکه‌ای از دستگاه‌های آلوده (بات‌نت)، منابع سرور شما (مانند پهنای باند یا CPU) را با درخواست‌های بی‌وقفه اشباع می‌کنند تا کاربران واقعی دیگر نتوانند به آن دسترسی پیدا کنند.

بیشتر بخوانید: برای آشنایی کامل با انواع و لایه‌های مختلف این حملات، مقاله حمله DDoS چیست؟ راهنمای مقابله را مطالعه کنید.

نشانه‌های اصلی حمله DDoS

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

۱- علائم در سطح شبکه

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

• افزایش ناگهانی و شدید ترافیک: ترافیک ورودی به سرور یا شبکه شما بدون هیچ دلیل مشخصی (مانند کمپین تبلیغاتی) چند ده یا چند صد برابر می‌شود.
• بالا رفتن تأخیر شبکه (Latency): زمان پاسخ‌دهی سرور به درخواست‌های ساده (مثل Ping) به‌شکل چشمگیری افزایش می‌یابد و حتی ممکن است با Timeout مواجه شوید.
• اشباع پهنای باند: تمام ظرفیت پهنای باند اینترنت شما توسط ترافیک ورودی مصرف می‌شود.

۲- علائم در سطح اپلیکیشن

اگر حمله از لایه شبکه عبور کند یا مستقیماً لایه ۷ (در بخش‌های بعدی توضیح خواهیم داد) را هدف بگیرد، نشانه‌ها در خود وب‌سایت یا سرویس شما نمایان می‌شوند:

• کُند شدن شدید وب‌سایت یا سرویس: بارگذاری صفحات به‌شدت کند یا کاملاً متوقف می‌شود.
• افزایش خطاهای 5xx: خطاهایی مانند 502 Bad Gateway یا 503 Service Unavailable به‌طور مکرر برای کاربران نمایش داده می‌شود که نشان‌دهنده ناتوانی سرور در پردازش درخواست‌ها است.
• مصرف غیرعادی منابع سرور: پردازنده (CPU) و حافظه (RAM) سرور به مرز ۱۰۰٪ می‌رسند، درحالی‌که بار کاری واقعی روی اپلیکیشن شما چندان زیاد نیست.

چک‌لیست واکنش اضطراری هنگام حمله DDoS

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

در ۱۵ دقیقه اول- شناسایی و واکنش فوری

• فعال‌سازی حالت دفاعی CDN: بلافاصله حالت «Under Attack Mode» یا مشابه آن را در CDN خود (مانند Cloudflare) فعال کنید. استفاده از CDN برای جلوگیری از ddos اولین لایه دفاعی است و بخش بزرگی از ترافیک مخرب را قبل‌از رسیدن به سرور شما فیلتر می‌کند.
• شروع مانیتورینگ ترافیک شبکه: لاگ‌های سرور (وب‌سرور مانند Nginx و Apache) و فایروال را برای پیدا کردن الگوهای مشکوک، IPهای پرتکرار یا نوع خاصی از درخواست‌های غیرعادی بررسی کنید. این کار به شناسایی منبع و نوع حمله کمک شایانی می‌کند.

در ساعت اول- مسدودسازی و محدودیت

• مسدودسازی IPهای مهاجم: IPهایی که در مرحله قبل به‌عنوان مهاجم شناسایی کردید را در سطح فایروال (WAF) یا CDN مسدود کنید.
• اعمال Rate Limiting سخت‌گیرانه: قوانین Rate Limiting را موقتاً سخت‌گیرانه‌تر کنید. فعال سازی rate limit برای محدود کردن درخواست‌ها از یک IP مشخص در یک بازه زمانی، یکی از مؤثرترین روش‌های مقابله با DDoS در سرور است.
• اطلاع‌رسانی به ارائه‌دهنده سرویس: با ارائه‌دهنده خدمات میزبانی (هاستینگ) یا دیتاسنتر خود تماس بگیرید و آن‌ها را از حمله مطلع سازید. آن‌ها ممکن است ابزارهای پیشرفته‌تری در زیرساخت خود برای کمک به رفع حمله دیداس در اختیار داشته باشند.

کارهایی که هرگز نباید انجام دهید

• خاموش کردن سرور: این کار فقط مشکل را موقتاً پنهان می‌کند و به مهاجم سیگنال می‌دهد که حمله‌اش موفق بوده است. به‌محض روشن شدن دوباره، حمله از سر گرفته خواهد شد.
• تغییر DNS بدون برنامه: تغییر ناگهانی رکوردهای DNS بدون داشتن یک زیرساخت آماده (مانند سرور ضد ddos یا CDN امن)، می‌تواند منجر به قطعی طولانی‌تر و پیچیده‌تر شدن فرایند بازیابی شود.

معماری دفاع چندلایه برای جلوگیری از حملات DDoS

لایه دفاعی	نقش در معماری	نوع حمله تحت پوشش	عملکرد کلیدی و مزیت اصلی
شبکه توزیع محتوا (CDN)	سپر لبه شبکه (بیرونی‌ترین لایه)	حملات حجمی (Volumetric) لایه ۳ و ۴	مخفی‌سازی IP اصلی سرور و جذب سیل عظیم ترافیک توسط شبکه‌ای از سرورهای جهانی
فایروال وب (WAF)	بازرس هوشمند ترافیک	حملات پیچیده اپلیکیشن (لایه ۷) و ربات‌ها	تحلیل تک‌تک درخواست‌های HTTP/S، مسدودسازی الگوهای مخرب و جلوگیری از حملات Low and Slow
محدودیت نرخ (Rate Limiting)	کنترل‌گر سرعت ترافیک	حملات Brute-force و مصرف زیاد منابع	محدود کردن تعداد دفعات مجاز برای ارسال درخواست از یک IP به صفحاتی مثل Login و API
فایروال شبکه (Network Firewall)	نگهبان پورت‌ها و دروازه‌ها	حملات سطح شبکه (مانند SYN/UDP Floods)	کاهش سطح حمله (Attack Surface) با مسدود کردن تمام پورت‌های غیرضروری (اصل Default Deny)
لود بالانسر (Load Balancer)	توزیع‌کننده بار ترافیک	حملاتی که هدفشان Overloadکردن یک سرور است	پخش هوشمندانه ترافیک بین چندین سرور برای افزایش ظرفیت تحمل و حفظ پایداری سیستم (HA)

حملات DDoS مدرن، هوشمند و چندوجهی هستند. برخی از آن‌ها با حجم ترافیک بالا زیرساخت شبکه (لایه 3 و 4) را هدف می‌گیرند و برخی دیگر با درخواست‌های پیچیده و به‌ظاهر قانونی، منابع سرور و اپلیکیشن (لایه 7) را به اتمام می‌رسانند. اتکا به یک ابزار دفاعی، یعنی باقی گذاشتن نقاط کور فراوان برای نفوذ مهاجمان.

در این بخش، به سراغ معماری دفاع چندلایه می‌رویم؛ استراتژی‌ای که متخصصان امنیت برای محافظت از سایت در برابر حملات ddos به کار می‌گیرند. ما لایه‌های دفاعی را از بیرونی‌ترین سپر تا هسته مرکزی بررسی می‌کنیم تا ببینیم چطور هر لایه، نوع خاصی از تهدید را خنثی می‌کند.

لایه اول- شبکه توزیع محتوا (CDN)

وقتی صحبت از اولین لایه دفاعی است، منظور دقیقاً جایی است که ترافیک اینترنت قبل‌از رسیدن به سرور شما با آن برخورد می‌کند. یعنی همان نقطه‌ای که یک CDN (Content Delivery Network) قدرتمند، نقش حیاتی خود را ایفا می‌کند.

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

1. جذب و توزیع حجم عظیم ترافیک:

شبکه‌های CDN معتبر (مانند Cloudflare یا Akamai) ظرفیت پهنای باندی دارند که بر حسب ترابیت بر ثانیه (Tbps) اندازه‌گیری می‌شود؛ ظرفیتی که تهیه آن برای یک سازمان به تنهایی تقریباً غیرممکن است. وقتی یک حمله DDoS حجمی (Volumetric Attack) رخ می‌دهد، این شبکه عظیم، فشار حمله را بین ده‌ها یا صدها سرور خود در سراسر دنیا توزیع و آن را جذب می‌کند. در نتیجه، سرور اصلی شما هرگز با آن سیل ترافیک ویرانگر مواجه نخواهد شد.

2. پنهان‌سازی IP اصلی سرور (IP Masking):

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

در عمل، فعال‌سازی یک CDN معتبر، ساده‌ترین و مؤثرترین گام برای محافظت در برابر دیداسِ لایه شبکه است. این لایه، نویزها و ترافیک‌های ناخواسته را در لبه شبکه (Edge) فیلتر می‌کند و اجازه می‌دهد ترافیک تمیزتر و کم‌حجم‌تر به لایه‌های بعدی دفاعی برسد.

لایه دوم- فایروال برنامه وب (WAF)

بسیار خب، CDN توانست حمله حجمی را دفع کند و جلوی رسیدن میلیون‌ها درخواست زامبی به سرور ما را گرفت. اما تکلیف حملات هوشمندانه‌تر چه می‌شود؟ حملاتی که حجم بالایی ندارند اما با ارسال درخواست‌های پیچیده و به‌ظاهر قانونی، اپلیکیشن شما را فلج می‌کنند (حملات لایه 7).

در این لایه است که تنظیم firewall برای ddos یا WAF (Web Application Firewall) مطرح می‌شود. اگر CDN را یک گارد امنیتی در ورودی اصلی یک مجموعه در نظر بگیریم که از ورود جمعیت‌های غیرمجاز جلوگیری می‌کند، WAF نگهبان متخصصی است که تک‌تک افرادی که وارد شده‌اند را بازرسی می‌کند تا مطمئن شود قصد خرابکاری ندارند.

WAF حرفه‌ای بین کاربران و سرور شما قرار می‌گیرد و تمام درخواست‌های HTTP/S را قبل‌از رسیدن به اپلیکیشن، تحلیل و بازرسی می‌کند. وظیفه اصلی آن، شناسایی و مسدودسازی الگوهای مخرب در لایه اپلیکیشن است. در زمینه DDoS، یک WAF به این روش‌ها کمک می‌کند:

• شناسایی حملات Low and Slow: این حملات با ارسال درخواست‌های کند و در تعداد کم، سعی در اشغال کردن منابع سرور (مانند کانکشن‌های دیتابیس) دارند. WAF می‌تواند این الگوهای رفتاری غیرعادی را که از چشم CDN دور می‌مانند شناسایی و مسدود کند.
• مسدودسازی ربات‌های پیچیده: WAF با تحلیل رفتار درخواست‌ها، می‌تواند ربات‌های پیشرفته‌ای که سعی در تقلید رفتار انسان دارند را از کاربران واقعی تشخیص دهد و آن‌ها را بلاک کند.
• امکان تعریف قوانین سفارشی (Custom Rules): قدرت اصلی WAF در انعطاف‌پذیری آن است. شما می‌توانید قوانینی دقیق برای محدود کردن درخواست‌ها تعریف کنید. برای مثال:
  ۱- هیچ آدرس IP حق ندارد در یک دقیقه، بیش‌از ۱۰ بار فرم لاگین را ارسال کند.
  ۲- درخواست‌هایی که به یک URL خاص و سنگین (مثلاً صفحه گزارش‌گیری) ارسال می‌شوند، باید با نرخ کمتری پردازش شوند.

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

لایه سوم- محدودیت نرخ درخواست (Rate Limiting)

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

Rate Limiting یک مکانیزم دفاعی دقیق و جراحی‌گونه است. به‌جای مسدودسازی کلی یک نوع درخواست، تعداد تکرار آن را از یک منبع مشخص (معمولاً یک آدرس IP) در یک بازه زمانی محدود می‌کند. این لایه دفاعی برای محافظت از بخش‌های حساس و پرهزینه اپلیکیشن شما ضروری است، مانند:

• صفحات ورود (Login Pages): جلوگیری از حملات Brute-force که در آن ربات‌ها سعی می‌کنند با آزمون‌وخطای هزاران رمز عبور به حساب‌های کاربری نفوذ کنند.
• API Endpoints: محافظت از APIها در برابر سوءاستفاده و درخواست‌های بیش‌ازحد که می‌تواند به سرعت پایگاه داده یا منابع سرور را به مرز خستگی برساند.
• فرم‌های جستجو یا گزارش‌گیری: این عملیات‌ها معمولاً منابع زیادی مصرف می‌کنند. محدودکردن تعداد اجرای آن‌ها در دقیقه، از فلج شدن سرور جلوگیری می‌کند.

در عمل، ابزارهایی مانند Cloudflare، Nginx یا حتی کدهای نوشته‌شده در سطح اپلیکیشن، این قابلیت را ارائه می‌دهند. برای مثال، در Nginx می‌توان با چند خط کد ساده تعریف کرد که یک IP حق ندارد بیش‌از ۵ بار در دقیقه به wp-login.php درخواست ارسال کند. محدود کردن درخواست‌ها به این شکل، یک روش بسیار مؤثر برای جلوگیری از ddos در nginx و وردپرس است که حملات لایه ۷ را قبل‌از آنکه تأثیرگذار شوند خنثی می‌کند.

لایه چهارم- تنظیم فایروال شبکه

تا اینجا تمام لایه‌های دفاعی ما روی ترافیک وب (HTTP/S) متمرکز بودند. اما زیرساخت شما ده‌ها یا صدها دروازه دیگر به نام پورت دارد. بازگذاشتن پورت‌های غیرضروری مانند این است که تمام درهای پشتی و پنجره‌های یک قلعه را باز بگذارید. فایروال شبکه (Network Firewall) وظیفه‌اش دقیقاً همین است: قفل کردن تمام دروازه‌هایی که به آن‌ها نیازی نیست.

این لایه در سطح سیستم‌عامل (مانند iptables در لینوکس) یا در سطح سخت‌افزار شبکه پیاده‌سازی می‌شود و براساس یک اصل ساده اما حیاتی کار می‌کند: هر چیزی که صراحتاً مجاز نشده، ممنوع است (Default Deny).

تنظیم firewall برای ddos یعنی شما فقط به پورت‌هایی که برای سرویس‌دهی ضروری هستند اجازه فعالیت می‌دهید. برای یک وب‌سرور استاندارد، این پورت‌ها معمولاً عبارت‌اند از:

• پورت 80: برای ترافیک HTTP
• پورت 443: برای ترافیک HTTPS
• پورت 22: برای دسترسی مدیریتی SSH (که آن هم باید به IPهای مشخص محدود شود)

با بستن سایر پورت‌ها (مانند پورت‌های FTP, SMTP, DNS و…) روی سرور، شما سطح حمله (Attack Surface) را به‌شدت کاهش می‌دهید و جلوی طیف وسیعی از حملات DDoS لایه شبکه مانند SYN Floods یا UDP Floods را که این پورت‌های باز را هدف می‌گیرند می‌گیرید. این کار یکی از اولین و اساسی‌ترین قدم‌ها برای جلوگیری از ddos در سرور لینوکس است.

نقش Load Balancer در توزیع هوشمندانه بار

لود بالانسر (Load Balancer) به‌خودی‌خود یک ابزار امنیتی نیست، اما نقش آن در افزایش مقاومت زیرساخت برای جلوگیری از حملات DDoS غیرقابل انکار است. لود بالانسر را مانند یک افسر راهنمایی و رانندگی در یک تقاطع شلوغ درنظر بگیرید. وظیفه او این است که ماشین‌ها را به خیابان‌های خلوت‌تر هدایت کند تا از ایجاد گره ترافیکی جلوگیری شود.

وقتی شما به‌جای یک سرور، از مجموعه‌ای از سرورها (Server Farm) برای میزبانی اپلیکیشن خود استفاده می‌کنید، استفاده از load balancer دو مزیت کلیدی برایتان به ارمغان می‌آورد:

۱- افزایش ظرفیت تحمل ترافیک:

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

۲- حفظ دسترسی‌پذیری (High Availability):

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

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

تنظیمات Nginx برای مقابله با DDoS

Nginx فقط یک وب‌سرور نیست؛ وقتی به‌منظور استفاده از reverse proxy پیکربندی شود به یکی از قدرتمندترین ابزارهای شما برای جلوگیری از DDoS تبدیل می‌شود. با چند دستور ساده، می‌توانید بخش بزرگی از ترافیک مخرب را قبل‌از رسیدن به اپلیکیشن اصلی متوقف کنید. این تنظیمات ساده، به‌ویژه برای حفاظت از زیرساخت ابری حیاتی هستند.

کانفیگ limit_req_zone

این دستور برای درخواست‌های ورودی به یک آدرس خاص (مثلاً صفحه ورود)، محدودیت سرعت اعمال می‌کند. به Nginx می‌گوید که از یک IP مشخص و در یک بازه زمانی معین، چه تعداد درخواست را بپذیرد.

# در بخش http تعریف می‌شود
limit_req_zone $binary_remote_addr zone=login:10m rate=1r/s;

server {
    # ...
    location /login.php {
        limit_req zone=login burst=5 nodelay;
        # ...
    }
}

• zone=login:10m: یک فضای ۱۰ مگابایتی در حافظه برای نگهداری IPها تعریف می‌کند.
• rate=1r/s: به هر IP اجازه ارسال ۱ درخواست در ثانیه را می‌دهد.
• burst=5: به کاربر اجازه می‌دهد تا ۵ درخواست را به‌صورت آنی و پشت سر هم ارسال کند (برای تجربه‌ کاربری بهتر)، اما درخواست ششم وارد صف محدودیت نرخ می‌شود.

کانفیگ limit_conn_zone

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

# در بخش http تعریف می‌شود
limit_conn_zone $binary_remote_addr zone=addr:10m;

server {
    # ...
    location / {
        limit_conn addr 10;
        # ...
    }
}

این کد به سادگی به هر آدرس IP اجازه می‌دهد حداکثر ۱۰ کانکشن همزمان با سرور داشته باشد.

تنظیم keepalive_timeout و client_body_timeout

برخی حملات DDoS (مانند Slowloris) با ارسال اطلاعات به‌صورت بسیار آهسته و قطره‌چکانی، کانکشن‌ها را برای مدت طولانی باز نگه می‌دارند تا تمام ظرفیت سرور را اشغال کنند. تنظیم صحیح Timeoutها این استراتژی را خنثی می‌کند.

• keepalive_timeout 5 5: به سرور می‌گوید که یک کانکشن فعال (keep-alive) را پس‌از ۵ ثانیه عدم فعالیت ببندد.
• client_body_timeout 10: اگر کلاینت در ارسال بدنه درخواست (body) بیش‌از ۱۰ ثانیه تأخیر کند ارتباط قطع می‌شود.

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

ایمن‌سازی وردپرس در برابر حملات DDoS

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

۱- غیرفعال کردن XML-RPC

فایل xmlrpc.php یک رابط قدیمی برای ارتباط اپلیکیشن‌های دیگر با وردپرس بود. امروزه این فایل به‌ندرت استفاده می‌شود اما یکی از اصلی‌ترین نقاط ضعف برای حملات Brute-force و دیداس است. مهاجمان می‌توانند با ارسال یک درخواست به این فایل، صدها دستور را اجرا کنند.

راه حل: ساده‌ترین راه، نصب افزونه‌ای مانند Disable XML-RPC است. همچنین می‌توانید با افزودن کد زیر به فایل .htaccess خود، دسترسی به آن را مسدود کنید:

<Files xmlrpc.php>
order deny,allow
deny from all
</Files>

۲- محدودسازی دسترسی به REST API

REST API وردپرس، برخلاف XML-RPC، بسیار کاربردی و مدرن است اما می‌تواند برای حملات مورد سوءاستفاده قرار گیرد. اگر از آن برای ارتباط با اپلیکیشن‌های خارجی استفاده نمی‌کنید، بهترین کار محدودکردن دسترسی به آن فقط برای کاربران وارد شده (لاگین کرده) است.

راه حل: قطعه کد زیر را به فایل functions.php قالب خود اضافه کنید:

add_filter( 'rest_authentication_errors', function( $result ) {
    if ( ! empty( $result ) ) {
        return $result;
    }
    if ( ! is_user_logged_in() ) {
        return new WP_Error( 'rest_not_logged_in', 'You are not currently logged in.', array( 'status' => 401 ) );
    }
    return $result;
});

۳- استفاده از افزونه‌های امنیتی معتبر

افزونه‌های امنیتی جامعی مانند Wordfence Security یا Sucuri Security، مجموعه‌ای از ابزارهای دفاعی را در اختیار شما قرار می‌دهند. این افزونه‌ها معمولاً شامل موارد زیر هستند:

• فایروال در سطح اپلیکیشن (WAF): درخواست‌های مخرب را قبل‌از رسیدن به وردپرس شناسایی و مسدود می‌کند.
• محدودیت نرخ درخواست (Rate Limiting): تلاش برای ورودهای مکرر یا خزش بیش‌ازحد در سایت را متوقف می‌کند.
• مسدودسازی IPهای مخرب: به‌صورت خودکار IPهای مهاجم را شناسایی و در لیست سیاه قرار می‌دهد.

نصب یکی از این افزونه‌ها از مؤثرترین راهکارهای جلوگیری از دیداس برای هر سایت وردپرسی است.

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

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

معیارهایی که باید زیر نظر داشت

به‌جای غرق شدن در انبوهی از داده‌ها، روی این سه شاخص حیاتی تمرکز کنید:

معیار (Metric)	چرا مهم است؟	نشانه خطر
تعداد درخواست در ثانیه (RPS/QPS)	نشان‌دهنده حجم کلی ترافیک ورودی به سرور است.	افزایش ناگهانی و شدید که با کمپین‌های بازاریابی یا رویدادهای خاص توجیه نمی‌شود.
نرخ خطا (Error Rate)	درصد خطاهای سمت سرور (مانند 500، 502، 503) را نشان می‌دهد.	بالارفتن نرخ خطا معمولاً به معنی این است که سرور زیر فشار زیاد، درحال از دست دادن توانایی پاسخگویی است.
ترافیک براساس موقعیت جغرافیایی	توزیع جغرافیایی کاربران شما را نمایش می‌دهد.	دریافت حجم عظیمی از ترافیک از کشورها یا مناطقی که معمولاً بازدیدکننده‌ای از آنجا ندارید.

تنظیم هشدارهای (Alerts) حیاتی

صرفاً تماشای نمودارها کافی نیست. شما به یک سیستم هشدار خودکار نیاز دارید که در صورت عبور هر یک از این معیارها از یک آستانه مشخص، فوراً به شما اطلاع‌رسانی کند (ازطریق ایمیل، پیامک و…).

یک قانون خوب:  آستانه هشدار را کمی بالاتر از اوج ترافیک عادی خود تنظیم کنید. برای مثال، اگر در حالت عادی حداکثر ۱۰۰ درخواست در ثانیه دارید، می‌توانید یک هشدار برای ۲۰۰ درخواست در ثانیه تنظیم کنید. این کار به شما فرصت می‌دهد تا قبل‌از فلج شدن کامل زیرساخت وارد عمل شوید.

چک‌لیست نهایی امنیت در برابر DDoS

داشتن یک برنامه واکنش سریع، کلید اصلی جلوگیری از حملات DDoS است. زمان طلایی برای جلوگیری از دیداس دقایق اولیه است و اگر از قبل ندانید چه کاری باید انجام دهید، بازی را باخته‌اید. برای حفظ امنیت در برابر ddos، این چک‌لیست سه مرحله‌ای (براساس توصیه‌های امنیتی Cloudflare) را پرینت گرفته و در دسترس تیم فنی خود قرار دهید.

اقدامات پیش‌از حمله (Proactive)

اولین قدم در جلوگیری از حملات دیداس، ایمن‌سازی زیرساخت در روزهای آرامش است:

• فعال‌سازی CDN و WAF: ترافیک را از یک فیلتر جهانی عبور دهید تا IP اصلی سرور مخفی بماند.
• تنظیم Rate Limiting در Nginx/وب‌سرور: محدودیت سرعت و کانکشن را برای صفحات امنیتی (مثل Login و API) اعمال کنید.
• بستن پورت‌های غیرضروری: تمام پورت‌ها (جز ۸۰ و ۴۴۳ برای وب) را در سطح فایروال شبکه ابری مسدود کنید و دسترسی SSH را محدود به IPهای استاتیک شرکت کنید.
• پیکربندی مانیتورینگ: آستانه هشدارهای ترافیک و مصرف CPU را تنظیم کنید تا پیامک/ایمیل قطعی زودتر از موعد ارسال شود.

اقدامات حین حمله (Reactive)

وقتی هشدارها به صدا درآمدند، خونسردی خود را حفظ کنید و مراحل زیر را انجام دهید:

• فعال‌سازی حالت اضطراری: وضعیت “Under Attack Mode” را در CDN خود روشن کنید (مثلاً در کلادفلر) تا چالش‌های JS/Captcha برای همه کاربران فعال شود.
• بررسی سریع لاگ‌ها: با استفاده از دستورات لینوکس (مثل netstat یا بررسی لاگ Nginx)، IPها یا User-Agentهای تکراری و مشکوک را پیدا کنید.
• مسدودسازی الگوهای مخرب: IPها یا کشورهای مهاجم را در فایروال ابری (WAF یا Network Firewall) مسدود کنید (Drop traffic).
• کاهش Timeouts: مقادیر timeout را در وب‌سرور کاهش دهید تا کانکشن‌های کُندِ مهاجمان سریع‌تر بسته شود.

اقدامات پس‌از حمله (Post-Mortem)

پس‌از فروکش کردن طوفان و رفع خطر، کار شما تمام نشده است:

• تحلیل کالبدشکافی (Post-Mortem): بررسی کنید حمله از چه نوعی بود (لایه شبکه یا اپلیکیشن) و کدام بخش سیستم شما ضعیف‌تر عمل کرد.
• بهبود Ruleهای فایروال: الگوهای حمله‌ای که شناسایی کردید را به قوانین دائمی WAF اضافه کنید.
• به‌روزرسانی برنامه واکنش: چک‌لیست فعلی تیم خود را براساس تجربه‌ای که به دست آوردید آپدیت کنید و نقاط ضعف زیرساخت را برطرف سازید.

لزوم طراحی زیرساخت مقاوم به دیداس

حتی بهترین تنظیمات نرم‌افزاری هم روی یک سرور ضعیف و تک‌بعدی کارساز نیستند. برای جلوگیری از حملات DDoS در مقیاس بزرگ، نیازمند معماری شبکه‌ای هستید که از اساس با رویکرد امنیتی طراحی شده باشد. برای همین است که اهمیت جلوگیری از حملات ddos در زیرساخت ابری، با توجه به اینکه حملات دیداس در ایران و چالش‌های مرتبط با حملات دیداس در اینترنت ملی به‌شکل قابل‌توجهی افزایش یافته‌اند، خودش را نشان می‌دهد و داشتن معماری مدرن و امن شرط بقای کسب‌وکار شماست.

اصل تفکیک سرویس‌ها

یکی از بزرگترین اشتباهات معماری سنتی، قرار دادن وب‌سرور، دیتابیس و فایل‌های استاتیک روی یک ماشین فیزیکی واحد است. در اصل تفکیک سرویس‌ها (Service Decoupling) که آمازون در معماری Well-Architected خود بر آن تأکید دارد، شما اجزای سیستم را از هم جدا می‌کنید. به‌این‌ترتیب، اگر وب‌سرور شما هدف یک حمله لایه ۷ قرار گرفت، دیتابیس شما همچنان در امان است و کل سیستم فرو نمی‌ریزد.

اصل مقیاس‌پذیری خودکار

در برابر سیل ترافیک، شما به سدّی نیاز دارید که بتواند ارتفاعش را تغییر دهد! مقیاس‌پذیری خودکار (Auto-Scaling) به سیستم شما اجازه می‌دهد تا با تشخیص افزایش ناگهانی ترافیک، منابع پردازشی (مانند CPU و RAM) یا حتی سرورهای جدید را به‌صورت خودکار به مدار اضافه کند. این قابلیت، شوک اولیه حمله را جذب می‌کند و مانع از دان شدن سایت می‌شود تا شما فرصت کافی برای اعمال قوانین فایروال داشته باشید.

اهمیت زیرساخت انعطاف‌پذیر

پیاده‌سازی تمام این لایه‌های دفاعی و معماری‌های پیشرفته، روی سرورهای سنتی بسیار زمان‌بر و گاهی غیرممکن است. اما اگر بدانید سرور ابری (cloud server) چیست و چطور کار می‌کند، متوجه می‌شوید که در محیط ابری استاندارد، می‌توانید در چند ثانیه منابع خود را ارتقا دهید، سرویس‌ها را تفکیک کنید و فایروال‌های شبکه‌ای را در بالاترین لایه اعمال کنید. برای خرید سرور امن ابری و پیاده‌سازی سریع این معماری، زیرساخت ابری فردوسی به دلایل زیر بهترین نقطه شروع است:

• امکان ایجاد تنظیمات امنیتی در بالاترین لایه‌های فایروال
• افزایش و تغییر منابع سیستم متناسب با نیاز لحظه‌ای و بدون وقفه
• پرداخت هزینه‌های به‌ازای ساعات استفاده از سرور (پرداخت به‌میزان مصرف)
• خودکارسازی فرایندها (کنترل ورودی/خروجی، منابع و…) با کلید api
• نصب خودکار اسکریپت‌هایی مانند داکر یا وردپرس ازطریق بازاریچه ابری
• بهره‌مندی از پردازنده‌های نسل جدید و هارد پرسرعت NVMe
• نسخه دمو و ۱۰۰ هزارتومان اعتبار رایگان برای تست بدون هزینه امکانات
• و کلی امکانات کاربردی و منحصربه‌فرد دیگر!

جمع‌بندی

در این مقاله بررسی کردیم که برای داشتن یک خط دفاعی مستحکم، تکیه بر یک ابزار خاص کافی نیست. جلوگیری از حملات DDoS نیازمند اتخاذ رویکردی چندلایه‌ است؛ مثل مخفی‌کردن آی‌پی اصلی پشت CDN و استفاده از فایروال‌های وب (WAF) یا تنظیمات دقیق در سطح وب‌سرور (مثل Nginx) و در نهایت، استفاده از یک زیرساخت ابری مقیاس‌پذیر. فراموش نکنید که امنیت یک محصول نیست که آن را بخرید، بلکه یک فرایند مستمر است که نیاز به مانیتورینگ، به‌روزرسانی و آمادگی همیشگی دارد.

آیا تابه‌حال سایت یا اپلیکیشن‌تان هدف حملات دیداس قرار گرفته است؟ در آن لحظات بحرانی چه اقدامی انجام دادید و جای خالی کدام لایه امنیتی را بیشتر حس کردید؟ تجربیات یا سؤالات فنی خود را در بخش نظرات همین مقاله با ما و سایر خوانندگان به اشتراک بگذارید تا با هم درباره راهکارهای آن گفتگو کنیم.

منابع:
cloudflare | aws.amazon | cisa gov | docs.aws | nginx | wordpress | sre google | cisa

سؤالات متداول