ProxyChains چه چیزهایی را رهگیری می‌کند و چه چیزهایی را رها می‌گذارد

ProxyChains-NG تونلی ایجاد نمی‌کند. کتابخانه‌ای را از پیش بارگذاری می‌کند که فراخوانی‌های libc مرتبط با شبکه را درون همان برنامه‌ای که اجرا می‌کند جایگزین می‌کند، پس مرز، یک فراخوانی درون یک فرآیند است نه مسیری در سطح کل دستگاه. همین تمایز تعیین می‌کند که یک آزمون موفق واقعاً چه چیزی را اثبات می‌کند. curl کاری‌افتاده از مسیر زنجیره یک فراخوانی قلاب‌شده را تأیید می‌کند، نه اینکه حل نام، UDP یا هر فرآیند فرزند همان مسیر را رفته باشد. راهنمای زیر پوشش را در سه گام بررسی می‌کند و سپس فهرست می‌کند که قلاب به چه چیزهایی نمی‌رسد.

چگونه پیش‌بارگذاری به یک اتصال می‌رسد

هنگام اجرا، راه‌انداز libproxychains را در LD_PRELOAD قرار می‌دهد و سپس برنامه هدف را اجرا می‌کند. کتابخانه نمادهای واقعی libc را حل می‌کند و نسخه‌های خودش از توابعی مانند connect و getaddrinfo را جایگزین می‌کند. فراخوانی‌هایی که از این نمادها می‌گذرند به پروکسی SOCKS یا HTTP از فایل پیکربندی بازنویسی می‌شوند. فراخوانی‌هایی که مسیر دیگری می‌روند هرگز به قلاب نمی‌رسند، و به همین دلیل تضمین به ازای هر فراخوانی است نه به ازای هر دستگاه.

تنها برنامه‌های پویا‌پیوند شرکت می‌کنند، و فایل‌های اجرایی setuid زیر اجرای امن، پیش‌بارگذاری را کاملاً نادیده می‌گیرند. فرزندان محیط را به ارث می‌برند، اما تنها تا زمانی که راه‌انداز آن را سر جایش نگه دارد.

تأیید کنید که کتابخانه در همان فرآیند بارگذاری شده است

درخواست را آغاز کنید و فرآیند زنده را بررسی کنید نه پوسته‌ای که آن را اجرا کرده است. فایل maps هر شیء مشترکی را نشان می‌دهد که در این لحظه در فرآیند نگاشت شده است.

proxychains4 -q curl -sS --max-time 8 https://example.com/ -o /dev/null &
pgrep -a curl
grep libproxychains /proc/$(pgrep -n curl)/maps

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

اتصال‌هایی را که از فرآیند خارج می‌شوند ردیابی کنید

حضور کتابخانه اثبات نمی‌کند که هر فراخوانی بازنویسی شده است، پس فراخوانی‌های سیستم را دنبال کنید. یک درخواست را زیر ردیاب اجرا کنید و بخوانید که سوکت‌ها واقعاً کجا رفتند.

strace -f -e trace=connect -o /tmp/pc.trace proxychains4 -q curl -sS https://example.com/ -o /dev/null
grep -o "sin_port=htons([0-9]*)" /tmp/pc.trace | sort -u

ردیابی باید تنها اتصال به نقطه پایانی پروکسی شما را نشان دهد، با درگاهی که با ورودی فایل پیکربندی مطابقت دارد. اگر نشانی‌های مقصد سایت هدف مستقیماً در ردیابی ظاهر شوند، یعنی آن فراخوانی قلاب را دور زده است، و این همان یافته‌ای است که دنبالش بودید. شماره درگاه‌ها را با فهرست پروکسی مقایسه کنید نه با اعتماد به نام فایل، چون پیکربندی باقی‌مانده از پروژه‌ای دیگر منبع رایج دسترسی مستقیم خاموش است. ردیابی را برای سابقه پذیرش نگه دارید؛ چند ثانیه بیشتر طول نمی‌کشد و بحث‌های مربوط به پوشش را فیصله می‌دهد.

تصمیم بگیرید که قلاب چه چیزی را نمی‌تواند پوشش دهد

پروژه proxychains-ng تغییر مسیر را به TCP محدود می‌کند و هشدار می‌دهد که اسکریپت‌ها، فرآیندهای پس‌زمینه و ماژول‌های بارگذاری‌شده می‌توانند متفاوت از برنامه اصلی رفتار کنند. UDP و ICMP بیرون از این سازوکار هستند، پس هر چیزی که به آن‌ها تکیه کند به مسیر پشتیبانی‌شده خود نیاز دارد. DNS از تنظیم proxy_dns و رفتار خود حل‌کننده برنامه پیروی می‌کند، یعنی یک درخواست HTTPS موفق هیچ چیزی درباره حل نام به شما نمی‌گوید. اعتبارسنجی گواهی را هم جای خودش نگه دارید: رسیدن به یک سرور از طریق پروکسی دلیلی برای خاموش‌کردن بررسی هویت نیست.

اگر باید بازگشت مستقیم ناممکن باشد، از مرز اجرایی استفاده کنید که خود ترافیک را کنترل می‌کند، مانند فضای نام شبکه، قواعد فایروال یا یک VPN، و آن را از قلاب کتابخانه جدا نگه دارید. قلاب ابزار سازگاری برای یک برنامه مشخص است، نه kill switch. برنامه، فرمان دقیق، درگاه پروکسی دیده‌شده در ردیابی و اینکه DNS از راه دور حل شده یا نه را ثبت کنید؛ همین چهار واقعیت تفاوت میان دامنه بررسی‌شده و دامنه امیدوارانه است.