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 टाढाबाट समाधान भयो कि भएन अभिलेख गर्नुहोस्; ती चार तथ्य नै प्रमाणित दायरा र आशाको दायराबीचको फरक हुन्।