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 દૂરથી ઉકેલાયો કે નહીં તે નોંધો; એ ચાર તથ્યો ચકાસાયેલા વ્યાપ અને આશાભર્યા વ્યાપ વચ્ચેનો ફરક છે.