وقتی Nginx پشت edge باشد، مبدأ اتصال خود edge است. امشب فقط به یک همتای مشخص اجازه می‌دهیم IP کلاینت را اعلام کند؛ این تصمیم روی allowlist و rate limit اثر دارد.

این جلسه بخشی از دورهٔ انجین‌اکس در ۵۰ شب است. قرارداد آزمایشگاه، مسیرها و روال اعمال تغییر در راهنمای دوره آمده است.

محیط: edge مستقل .40، ماژول http_realip موجود؛ firewall فقط پورت لازم را برای این آزمایش به edge باز کند.

اعتماد محدود#

در server backend www:

set_real_ip_from 192.168.57.40;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

کل subnet یا 0.0.0.0/0 را trusted نکن. با recursive، زنجیرهٔ اعلام‌شده تا آدرس غیرمورداعتماد بررسی می‌شود؛ توپولوژی چند پراکسی باید دقیق ثبت شود. $remote_addr پس از پردازش و $realip_remote_addr همتای اولیه را نشان می‌دهند.

قالب لاگ تازه در http بساز و هر دو مقدار را ثبت کن؛ این متغیر دوم به وجود ماژول مربوط وابسته است. credential و query محرمانه را وارد لاگ نکن.

جعل را واقعاً تست کن#

از .21 به مسیر admin با credential درست و هدر X-Forwarded-For: 192.168.57.20 درخواست بده. نباید عبور کند و remote_addr باید .21 بماند. از edge همان اعلام آدرس پذیرفته می‌شود؛ این نشان می‌دهد چرا کنترل edge حیاتی است.

با CA عمومی منتقل‌شده، این فرمان را یک بار روی ۲۱ و یک بار روی ۴۰ اجرا کن؛ رمز labreader را در prompt وارد کن و IP شاخهٔ RHEL را تغییر بده:

curl --cacert ~/nginx-lab/pki/ca.crt --user labreader \
  --resolve www.nginx.test:443:192.168.57.10 \
  -H 'X-Forwarded-For: 192.168.57.20' \
  -D - https://www.nginx.test/admin/

از ۲۱ انتظار رد و از ۴۰ انتظار پذیرش اعلام IP داریم؛ روی ۴۰ گواهی کلاینت لازم نیست چون این سایت هنوز mTLS ندارد. این درخواست کنترل‌شده نشان می‌دهد یک peer trusted می‌تواند آدرس را اعلام کند؛ در مسیر واقعی باید فقط پراکسی کنترل‌شده به آن peer دسترسی داشته باشد. دو IP اولیه و پردازش‌شده را در log کنار هم ببین.

برای اولین edge عمومی، هدر مبدأ مهاجم را overwrite کن:

proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Real-IP $remote_addr;

این نمونه برای مرز اول است؛ افزودن کور $proxy_add_x_forwarded_for به ورودی نامعتبر، زنجیرهٔ جعلی را حفظ می‌کند. framework برنامه نیز باید فقط proxyهای واقعی خودش را بشناسد. backend خصوصی را در طرح نهایی از دسترسی مستقیم عمومی خارج کن.

بازگشت: تنظیم realip را بردار، همتای واقعی را دوباره بررسی و قانون firewall موقت edge را بازبینی کن. rate limit بر پایهٔ remote_addr را بعد از اصلاح اعتماد طراحی کن، وگرنه همهٔ کاربران ممکن است یک bucket edge داشته باشند.

منبع: http_realip .