توسعهٔ وب و بازیراهنمای کاربردی

محدودکردن ورود در NGINX؛ ابتدا Dry Run، سپس اعمال قانون

محدودیت سنجیدهٔ ورود را در NGINX اضافه کنید، IP پراکسی معتبر را بررسی کنید و پیش از اعمال، نتیجهٔ dry run و ورود کاربران واقعی را بسنجید.

خلاصهٔ کاربردی

آنچه باید بدانید

  • قانون را در مسیر موجود برنامه ادغام کنید.
  • برای تشخیص آدرس کاربر فقط به پراکسی تأییدشده اعتماد کنید.
  • پیش از اعمال حد نمونه، نتیجهٔ dry run را ببینید.

قانون را به برنامهٔ واقعی محدود کنید

این مثال برای مدیری است که پیکربندی NGINX را کنترل می‌کند. روی Apache، LiteSpeed یا کنترل‌پنل تولیدکنندهٔ تنظیمات بدون تغییر قابل‌اجرا نیست. مسیر واقعی ورود را پیدا کنید و پردازش proxy یا FastCGI فعلی آن را حفظ کنید. شروع پیشنهادی ما ثبت ورود عادی، کارکنان پشت آدرس مشترک و کلاینت خودکار معتبر است.

ناحیهٔ مشترک را در بخش http تعریف کنید

مرجع ماژول NGINX، limit_req_zone و محدودیت درخواست را توضیح می‌دهد. عدد زیر نمونهٔ آموزشی است و توصیهٔ یکسان برای همهٔ سایت‌ها نیست. ناحیه را در بخش http موجود اضافه کنید:

limit_req_zone $binary_remote_addr zone=login_per_ip:10m rate=10r/m;

دستورهای زیر را در location فعلیِ مسیر ورود موردنظر ادغام کنید و پردازش برنامه یا منطق احراز هویت را حذف نکنید:

limit_req zone=login_per_ip burst=5 nodelay;
limit_req_dry_run on;
limit_req_status 429;

آدرسی را که می‌شمارید تأیید کنید

پشت CDN یا پراکسی، آدرس دیده‌شده ممکن است متعلق به پراکسی باشد. راهنمای real-IP را دنبال کنید و فقط آدرس پراکسی‌هایی را معتبر بدانید که مدیریت یا صحت آن‌ها را تأیید می‌کنید. پذیرش بی‌قید هدرهای forwarded به مشتری امکان اثرگذاری بر آدرس شمارش‌شده می‌دهد. پیش از تفسیر نرخ درخواست، این موضوع را حل کنید.

ساختار را بررسی و نتیجه را مشاهده کنید

راهنمای مقدماتی NGINX، آزمون ساختار و بارگذاری دوباره را توضیح می‌دهد:

sudo nginx -t
sudo nginx -s reload

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

اعمال قانون باید راه برگشت داشته باشد

پس از بررسی نتایج، limit_req_dry_run را off کنید و ساختار را بررسی و دوباره بارگذاری کنید. ورود عادی و پاسخ موردنظر به درخواست اضافه را بسنجید. اگر کاربر معتبر آسیب دید، تا زمان بررسی به dry run یا تنظیم ذخیره‌شده برگردید. حد مبتنی بر IP فقط یک نشانه است و روی شبکهٔ مشترک اثر دارد. تصمیم، نتیجهٔ آزمون و مسئول را ثبت کنید. حفاظت کلیدها و برنامه‌ریزی دفاع DDoS کنترل‌های مکمل‌اند.

منابع و مطالعهٔ بیشتر

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

  1. NGINX: request rate limiting
  2. NGINX: configuration testing and reload
  3. NGINX: trusted proxy real IP
از مطالعه تا اجرا

برای پروژهٔ خودت تصمیم بگیر.

نیاز وب‌سایت، سرور یا تیم فناوری‌تان را با کیاوا مطرح کنید.

گفتگو با کیاوا