حملات DoS و DDoS دسترس‌پذیری سرویس را هدف می‌گیرند. DoS مخفف Denial of Service یا منع سرویس است؛ حرف اول DDoS به Distributed، یعنی توزیع‌شده، اشاره دارد. این دو را نباید صرفاً با «کند» و «سریع» یا میزان قطعی ثابتی تعریف کرد.
تفاوت حملات DoS و DDoS
DDoS نوع توزیع‌شدهٔ منع سرویس است که ترافیک یا فعالیت مخرب از منابع متعدد به هدف می‌رسد. بات‌نت یکی از سازوکارهای رایج آن است. در عمل، فقط شمارش چند IP در لاگ برای تشخیص منشأ و نوع حمله کافی نیست.
هدف اصلی اختلال دسترسی است؛ این به معنی نفوذ قطعی به حساب مدیر نیست. البته یک رخداد می‌تواند هم‌زمان چند هدف داشته باشد، پس عادی‌شدن سرعت به‌تنهایی سلامت همهٔ بخش‌های سایت را ثابت نمی‌کند.
سه دستهٔ مهم برای انتخاب دفاع
- حجمی: ظرفیت مسیر شبکه یا پهنای باند را تحت فشار می‌گذارد.
- پروتکلی: منابع پردازش ارتباط و وضعیت اتصال را هدف می‌گیرد.
- لایهٔ کاربرد: درخواست‌هایی مانند HTTP می‌توانند پردازش پرهزینهٔ برنامه را درگیر کنند.
توضیح Cloudflare دربارهٔ DDoS این تفاوت لایه‌ها را نشان می‌دهد. همهٔ حمله‌ها نیازمند حجم عظیم داده نیستند؛ هزینهٔ پاسخ‌گویی هر درخواست نیز اهمیت دارد. همچنین هر Flood الزاماً همان الگوی اتصال نیمه‌تمام نیست.
کندی سایت همیشه حمله نیست
کمبود منابع، پرس‌وجوی کند، خطای نسخهٔ تازه یا افزایش واقعی بازدید هم می‌تواند سایت را مختل کند. مثلاً پس از ارسال خبرنامه، رشد مراجعه به یک محصول طبیعی است؛ اما نیاز به بررسی دارد که درخواست‌ها چه رفتاری دارند و کدام منبع اشباع شده است.
زمان شروع، نرخ درخواست، خطاهای پاسخ، مصرف پردازنده و حافظه، وضعیت شبکه و مسیرهای پربازدید را کنار هم ثبت کنید. آمار CDN و مبدأ ممکن است یکسان نباشد، چون بخشی از درخواست‌ها در لبه پاسخ می‌گیرد یا مسدود می‌شود.
واکنش متناسب با مشکل
اگر لینک شبکه اشباع است، قاعدهٔ داخل برنامه پس از رسیدن ترافیک به سرور مسئله را حل نمی‌کند؛ هماهنگی با میزبان و دفاع بالادستی لازم می‌شود. برای فشار روی مسیر خاص برنامه، محدودسازی متناسب، کش امن محتوای عمومی و اصلاح پردازش پرهزینه می‌تواند مفید باشد.
فایروال و سرویس کاهش DDoS یک ابزار واحد با پوشش یکسان نیستند. برای نمونه، مستند AWS نقش فایروال وب را از سرویس حفاظت DDoS جدا می‌کند. پوشش سرویس خریداری‌شده، پروتکل و مسیر واقعی ترافیک را بررسی کنید؛ نام تجاری به‌تنهایی کافی نیست.
کارهایی که نتیجه را بدتر می‌کنند
مسدودکردن گستردهٔ کشورها یا IPهای مشترک بدون شواهد می‌تواند مشتری واقعی را حذف کند. کش عمومی پاسخ خصوصی نیز راه‌حل امنی برای بار بالا نیست. آزمون فشار را فقط در محدودهٔ مجاز و با هماهنگی میزبان انجام دهید، نه وسط رخداد و بدون سقف مشخص.
پس از مهار، مسیرهای مهم ورود، خرید و API را بررسی کنید. قاعدهٔ موقت باید مسئول، زمان بازبینی و دلیل روشن داشته باشد. میزان اثر، خطای مسدودسازی و گلوگاه باقی‌مانده را ثبت کنید تا رخداد بعدی با همان حدس‌ها مدیریت نشود.
مطالعهٔ مرتبط
بازبینی فنی: ۱۳ آبان ۱۴۰۵. تاریخ انتشار اولیه و نشانی قبلی حفظ شده‌اند.
