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 दूरून सोडवला गेला का हे नोंदवा; ही चार तथ्येच तपासलेल्या व्याप्ती आणि आशेच्या व्याप्तीतील फरक आहेत।