محتوای آموزشی وبلاگ نت‌آرام
در گزارش سایت، همه بازدیدها با یک آی‌پی ثبت می‌شوند. اگر سایت پشت CDN، لودبالانسر یا پراکسی است، برنامه ممکن است آدرس همان واسطه را به جای آدرس کاربر ببیند. اصلاح این موضوع برای گزارش، محدودیت نرخ و کنترل دسترسی مهم است، اما اعتماد به هر هدر ارسالی کاربر می‌تواند به جعل آی‌پی منجر شود.
ابتدا مسیر واقعی درخواست و واسطه‌های مجاز را روی کاغذ مشخص می‌کنیم، سپس فقط به همان‌ها اعتماد می‌کنیم. نمونه زیر برای Nginx روی سرور مستقل است؛ در هاست اشتراکی تنظیم وب‌سرور معمولاً بر عهده مدیر سرویس است.
۱. مسیر و آدرس واسطه را مشخص کنید
مسیر ممکن است چنین باشد: مرورگر ← CDN ← Nginx ← برنامه. هر نصب متفاوت است. مشخص کنید کدام سامانه مستقیماً به Nginx وصل می‌شود، چه هدری با آی‌پی کاربر می‌فرستد و آیا کاربر می‌تواند سرور مبدأ را مستقیم دور بزند یا نه. فهرست نشانی‌های رسمی پراکسی را از ارائه‌دهنده همان سرویس و برای IPv4 و IPv6 بگیرید.
در سرور، تنظیم و ماژول Nginx را فقط بخوانید:
کد / دستورnginx -V 2>&1
sudo nginx -T
فرمان دوم همه تنظیم‌های مؤثر را چاپ می‌کند و ممکن است مسیرها یا اطلاعات حساس داشته باشد؛ خروجی کامل را عمومی منتشر نکنید. وجود ماژول realip و محل تعریف
server مربوط را بررسی کنید. در بعضی توزیع‌ها ماژول ممکن است به شکل پویا بارگذاری شود و عبارت build به‌تنهایی همه وضعیت را توضیح ندهد.۲. بدانید کدام هدر قابل اعتماد است
X-Forwarded-For می‌تواند زنجیره‌ای از آدرس‌ها داشته باشد، اما کاربر نیز قادر است هدر دلخواه بفرستد. اگر بدون بررسی به اولین مقدار اعتماد کنید، ممکن است کاربر آی‌پی دلخواه در لاگ یا کنترل دسترسی ثبت کند. هدر فقط زمانی قابل استفاده است که اتصال مستقیم از یک پراکسی شناخته‌شده آمده و آن پراکسی مقدارها را مطابق قرارداد امن تنظیم کرده باشد.اگر سایت بدون واسطه مستقیماً به Nginx وصل است، آدرس اتصال مستقیم معمولاً مبنای مناسب‌تری است. تنظیم real IP برای پراکسی خیالی یا اعتماد به
0.0.0.0/0 و همه IPv6ها امنیت را خراب می‌کند.۳. نمونه محدود برای Nginx را با شبکه خود تطبیق دهید
در تنظیم آزمایشی همان
کد / دستورserver، فقط پس از تأیید هدر و شبکه واقعی پراکسی می‌توان از ساختاری شبیه زیر استفاده کرد:set_real_ip_from 192.0.2.0/24;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
192.0.2.0/24 یک شبکه مستندسازی و نمونه است؛ آن را با شبکه‌های دقیق و به‌روز پراکسی مورد اعتماد خود، از جمله IPv6 در صورت نیاز، جایگزین کنید. گزینه recursive در زنجیره، آخرین آدرس غیرقابل‌اعتماد را طبق قواعد ماژول انتخاب می‌کند. اگر ارائه‌دهنده هدر اختصاصی یا پروتکل دیگری دارد، تنظیم را مطابق مستندات همان سرویس بنویسید.پیش از تغییر از فایل تنظیم نسخه پشتیبان داشته باشید و ابتدا در محیط آزمایشی:
کد / دستورsudo nginx -t
فقط پس از موفقیت بررسی نحوی، بازبینی شبکه‌های مجاز و آمادگی بازگشت، تنظیم را با روش استاندارد سرور reload کنید. خطای نحوی یا اعتماد بیش از حد می‌تواند دسترسی، لاگ یا محدودیت نرخ را مختل کند.
۴. آدرس درست را به برنامه منتقل کنید
پس از realip،
کد / دستور$remote_addr در Nginx می‌تواند حاوی آدرس انتخاب‌شده باشد. برای یک معماری ساده که برنامه فقط از Nginx قابل دسترسی است، مدیر می‌تواند هدر ارسالی به برنامه را به‌صورت کنترل‌شده بازنویسی کند:proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Real-IP $remote_addr;
این دو خط باید در
location پراکسی صحیح ادغام شوند و فقط یک الگوی ساده‌اند؛ اگر نیاز به حفظ زنجیره دارید یا پراکسی‌های دیگری بین برنامه و Nginx هستند، سیاست متفاوت و تأییدشده لازم است. برنامه نیز باید فقط آدرس پراکسی واقعاً مورد اعتماد را بپذیرد. اجازه دسترسی مستقیم به پورت برنامه می‌تواند این فرض را بی‌اثر کند.تنظیم IP به تنهایی هدرهای
X-Forwarded-Host و X-Forwarded-Proto را امن نمی‌کند؛ اگر برنامه از آن‌ها استفاده می‌کند، هر کدام باید بر اساس معماری واقعی و با بازنویسی امن بررسی شوند.۵. با درخواست واقعی و هدر جعلی آزمایش کنید
از دو اتصال مجاز، یک درخواست معمولی بفرستید و لاگ را با آی‌پی عمومی شناخته‌شده همان اتصال مقایسه کنید. در محیط آزمایشی، یک درخواست با هدر ساختگی نیز بفرستید:
کد / دستورcurl -I -H 'X-Forwarded-For: 203.0.113.77' 'https://example.com/'
دامنه نمونه را با محیط آزمایشی خود عوض کنید.
203.0.113.77 آدرس مستندسازی است. صرف پاسخ HTTP ثابت نمی‌کند لاگ درست است؛ گزارش Nginx و برنامه را بررسی کنید. اگر کاربر غیرمجاز توانست همین مقدار جعلی را به‌عنوان آی‌پی خود ثبت کند، زنجیره اعتماد هنوز ناامن است. پس از آزمون، تغییر را با سیاست حریم خصوصی و نگهداری لاگ هماهنگ کنید.برای بررسی دیگر خطاهای پراکسی، راهنمای CORS در Express و برای رسیدگی تخصصی مدیریت سرور نت‌آرام را ببینید. شرح گزینه‌ها در مستندات رسمی Nginx آمده است.
برچسب‌ها:
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام