ProxyChains എന്തു പിടിക്കുന്നു, എന്തു വെറുതെ വിടുന്നു
ProxyChains താൻ ആരംഭിക്കുന്ന പ്രോഗ്രാമിലെ ലൈബ്രറി കോളുകൾ പിടിക്കുന്നു. maps, strace, ഒരു അഭ്യർത്ഥന എന്നിവ ഉപയോഗിച്ച് TCP പരിധി പരിശോധിക്കുക, എന്നിട്ട് DNS അല്ലെങ്കിൽ UDP പിന്തുടരുമെന്ന് കരുതുന്നത് നിർത്തുക.
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 വിദൂരത്ത് നിർണ്ണയിച്ചോ എന്നിവ രേഖപ്പെടുത്തുക; ആ നാല് വസ്തുതകളാണ് പരിശോധിച്ച പരിധിയും പ്രതീക്ഷയുടെ പരിധിയും തമ്മിലുള്ള വ്യത്യാസം.