Ano ang hinaharang ng ProxyChains at ano ang hinahayaan

Hindi gumagawa ng tunnel ang ProxyChains-NG. Preload nito ang isang library na pumapalit sa mga tawag na libc kaugnay ng network sa loob ng isang programang inilulunsad nito, kaya ang hangganan ay isang tawag sa isang proseso, hindi isang ruta para sa buong device. Ang pagkakaibang ito ang nagtatakda kung ano talaga ang pinapatunayan ng matagumpay na pagsubok. Ang gumaganang curl sa pamamagitan ng chain ay nagpapatunay ng isang naharang na tawag, hindi na ang resolusyon ng pangalan, UDP o bawat child process ay sumunod sa parehong landas. Ang gabay sa ibaba ay nagbe-verify ng saklaw sa tatlong hakbang, pagkatapos ay inililista ang hindi kayang maabot ng hook.

Paano naaabot ng preload ang isang koneksyon

Sa pagsisimula, inilalagay ng launcher ang libproxychains sa LD_PRELOAD at pagkatapos ay pinapatakbo ang target na programa. Niresolba ng library ang tunay na mga simbolo ng libc at pinapalitan ang mga ito ng sarili nitong bersyon ng mga function gaya ng connect at getaddrinfo. Ang mga tawag na dumadaan sa mga simbolong iyon ay muling isinusulat patungo sa SOCKS o HTTP proxy mula sa configuration file. Ang mga tawag na ibang landas ang tinatahak ay hindi kailanman nakakasalubong ng hook, kaya ang garantiya ay bawat tawag at hindi bawat makina.

Tanging ang mga programang naka-link nang dynamic ang lumalahok, at ang mga setuid binary sa ilalim ng secure na execution ay ganap na binabalewala ang preload. Namamana ng mga anak ang environment, ngunit hangga't pinapanatili ito ng launcher sa lugar.

Kumpirmahin na nakaload ang library sa prosesong iyon

Simulan ang kahilingan at siyasatin ang buhay na proseso sa halip na ang shell na naglunsad nito. Ipinapakita ng file na maps ang bawat shared object na kasalukuyang naka-map sa proseso.

proxychains4 -q curl -sS --max-time 8 https://example.com/ -o /dev/null &
pgrep -a curl
grep libproxychains /proc/$(pgrep -n curl)/maps

Ang tugma ay nagpapatunay na naroroon ang naharang na library, na kailangan ngunit hindi sapat. Ang walang laman na resulta ay karaniwang nangangahulugan na ibang proseso ang sinisiyasat mo, halimbawa isang browser na nagbigay ng URL sa isang instance na sinimulan bago ang launcher. Suriin gamit ang ldd kung dynamic na naka-link ang binary bago habulin ang anupaman, dahil ang static na build ay hindi kayang mag-load ng preload. Pagkatapos ay basahin ang listahan ng proxy sa configuration na aktwal na ginamit ng launcher, dahil ang lumang path o saradong port ay nagbibigay ng gumaganang hook na walang gumaganang chain.

I-trace ang mga koneksyong lumalabas sa proseso

Ang presensya ng library ay hindi nagpapatunay na ang bawat tawag ay muling isinulat, kaya sundan ang mga system call. Patakbuhin ang isang kahilingan sa ilalim ng tracer at basahin kung saan talaga napunta ang mga socket.

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

Dapat lamang ipakita ng trace ang mga koneksyon patungo sa iyong proxy endpoint, na tumutugma ang port sa entry sa configuration file. Kung ang mga destination address ng target na site ay direktang lumitaw sa trace, nilampasan ng tawag na iyon ang hook, at iyon mismo ang natuklasang hinahanap mo. Ihambing ang mga numero ng port sa listahan ng proxy sa halip na magtiwala sa pangalan ng file, dahil ang natirang configuration mula sa ibang proyekto ay karaniwang pinagmumulan ng tahimik na direktang access. Itago ang trace para sa acceptance record; tumatagal ito ng ilang segundo at nagtatapos ng mga pagtatalo tungkol sa saklaw.

Magpasya kung ano ang hindi kayang saklawin ng hook

proyektong proxychains-ng ay nililimitahan ang redirection sa TCP at nagbabala na ang mga script, background na proseso at naka-load na module ay maaaring kumilos nang iba sa pangunahing programa. Ang UDP at ICMP ay nasa labas ng mekanismo, kaya anumang umaasa sa mga ito ay nangangailangan ng sariling sinusuportahang landas. Sinusunod ng DNS ang setting na proxy_dns at ang pag-uugali ng resolver ng application mismo, na nangangahulugan na ang isang matagumpay na HTTPS na kahilingan ay walang sinasabi tungkol sa resolusyon ng pangalan. Panatilihin din ang validation ng certificate sa tamang lugar: ang maabot ang server sa pamamagitan ng proxy ay hindi dahilan upang patayin ang mga tseke ng pagkakakilanlan.

Kung ang direktang fallback ay dapat na imposible, gumamit ng enforcement boundary na kumokontrol sa trapiko mismo, tulad ng network namespace, firewall rules o VPN, at panatilihin itong hiwalay sa hook ng library. Ang hook ay kasangkapan sa compatibility para sa isang partikular na programa, hindi kill switch. Itala ang programa, ang eksaktong command, ang proxy port na nakita sa trace at kung ang DNS ay naresolba nang remote; ang apat na katotohanang iyon ang pagkakaiba ng isang na-verify na saklaw at isang saklaw ng pag-asa.