learn

کاهش حملات DDoS با Cloudflare و استفاده از Under Attack

راهنمای استفادهٔ هدفمند از حفاظت Cloudflare و حالت اضطراری، با توجه به مسیر ترافیک و اثر بر سرویس واقعی.

کاهش حملات DDoS با Cloudflare فقط با تغییر نیم‌سرور یا روشن‌کردن یک گزینه انجام نمی‌شود. باید ترافیک سرویس مورد نظر از مسیر حفاظت‌شده عبور کند. این راهنما روی وب‌سایت و درخواست‌های HTTP/HTTPS تمرکز دارد؛ حفاظت همهٔ پورت‌های سرور موضوع جداگانه‌ای است.

پیش‌نیاز کاهش حملات DDoS با Cloudflare

ابتدا دامنهٔ درست، وضعیت فعال سرویس و رکورد مربوط به وب‌سایت را بررسی کنید. در حالت Proxied، ترافیک سازگار از شبکهٔ Cloudflare می‌گذرد؛ رکورد DNS only همین مسیر پراکسی را ایجاد نمی‌کند. وضعیت Active دامنه به معنی پراکسی‌بودن همهٔ رکوردها نیست.

اگر دامنه هنوز Pending است، نیم‌سرورهای تخصیص‌یافته، ثبت آن‌ها نزد رجیسترار و پیکربندی DNS را بررسی کنید. صرف انتظار با یک عدد ثابت، جای بررسی خطای تنظیم را نمی‌گیرد. نیم‌سرور نمونهٔ مقاله را روی دامنهٔ خود کپی نکنید.

حفاظت خودکار با حالت اضطراری فرق دارد

طبق مستند حفاظت DDoS کلودفلر، تشخیص و کاهش خودکار حمله در شبکه وجود دارد. Under Attack Mode کنترل اضافه‌ای برای بعضی حملات لایهٔ کاربرد است؛ روشن‌نبودن آن به معنی خاموش‌بودن تمام حفاظت DDoS نیست.

پیش از استفاده، آمار درخواست، مسیر هدف و وضعیت مبدأ را بررسی کنید. اگر مشکل از توقف PHP یا خطای پایگاه داده باشد، اضافه‌کردن صفحهٔ چالش لزوماً علت را رفع نمی‌کند. سرویس درگیر را از خطای ظاهری مرورگر تشخیص دهید.

فعال‌سازی Under Attack در داشبورد

  1. حساب و دامنهٔ هدف را انتخاب کنید.
  2. در صفحهٔ Overview، بخش Quick Actions را پیدا کنید.
  3. Under Attack Mode را برای رخداد مرتبط فعال کنید.
  4. دسترسی کاربر واقعی و مسیرهای مهم سایت را بیازمایید.

راهنمای رسمی Under Attack این حالت را از گزینه‌های آخر هنگام حمله معرفی می‌کند. برای اعمال محدود به بعضی مسیرها، Configuration Rule قابل استفاده است؛ قاعده را مطابق رابط و امکانات همان حساب بسازید، نه تنظیمات تصویری قدیمی.

اثر بر کاربر، API و آمار

بازدیدکننده ممکن است صفحهٔ میانی ببیند و مرورگر باید JavaScript را پشتیبانی کند. این رفتار می‌تواند ابزار آمار و برنامه‌هایی را که انتظار پاسخ عادی دارند تحت تأثیر قرار دهد. برای webhook، ربات مجاز یا API، آزمون جدا لازم است؛ نباید فرض کرد همه مانند مرورگر انسانی عمل می‌کنند.

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

سرور مبدأ را فراموش نکنید

اگر درخواست مستقیم به مبدأ ممکن باشد، مهاجم می‌تواند مسیر پراکسی را دور بزند. راهنمای حفاظت مبدأ روش‌های محدودکردن این مسیر را توضیح می‌دهد. اجرای محدودیت باید با میزبان و با حفظ دسترسی مدیریت و سرویس‌های ضروری انجام شود؛ یک دستور عمومی برای همهٔ سرورها مناسب نیست.

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

مطالعهٔ مرتبط

بازبینی فنی: ۱۳ آبان ۱۴۰۵. تاریخ انتشار اولیه و نشانی قبلی حفظ شده‌اند.

مطالب مرتبط

ارسال نظر

فهرست مطالب