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 دور سے حل ہوا یا نہیں، درج کریں؛ یہی چار حقائق تصدیق شدہ دائرے اور امید بھرے دائرے کے درمیان فرق ہیں۔