Kion ProxyChains kaptas kaj kion ĝi lasas trankvila

ProxyChains-NG ne kreas tunelon. Ĝi antaŭŝargas bibliotekon, kiu anstataŭigas retajn libc-vokojn ene de la ununura programo, kiun ĝi lanĉas, do la limo estas voko en procezo, ne itinero por la tuta aparato. Tiu distingo decidas, kion sukcesa testo vere pruvas. Funkcianta curl tra la ĉeno konfirmas unu hokitan vokon, ne tion, ke nomresolvo, UDP aŭ ĉiu infana procezo sekvis la saman vojon. La gvidilo sube kontrolas la kovradon en tri paŝoj kaj poste listigas, kion la hoko ne povas atingi.

Kiel la antaŭŝargo atingas konekton

Ĉe lanĉo la lanĉilo metas libproxychains en LD_PRELOAD kaj poste plenumas la celan programon. La biblioteko solvas la verajn libc-simbolojn kaj anstataŭigas ilin per propraj versioj de funkcioj kiel connect kaj getaddrinfo. Vokoj, kiuj pasas tra tiuj simboloj, estas reskribataj al la SOCKS- aŭ HTTP-prokurilo el la agorda dosiero. Vokoj, kiuj prenas alian vojon, neniam renkontas la hokon, kaj tial la garantio validas por ĉiu voko kaj ne por la tuta maŝino.

Partoprenas nur dinamike ligitaj programoj, kaj setuid-binaroj sub sekura plenumado tute ignoras la antaŭŝargon. La infanoj heredas la medion, sed nur dum la lanĉilo tenas ĝin en loko.

Konfirmu, ke la biblioteko estas ŝargita en tiu procezo

Startigu la peton kaj ekzamenu la vivan procezon anstataŭ la ŝelon, kiu lanĉis ĝin. La dosiero maps montras ĉiun kunhavatan objekton nuntempe mapitan en la procezon.

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

Trafo konfirmas, ke la hokita biblioteko ĉeestas, kio estas necesa sed ne sufiĉa. Malplena rezulto kutime signifas, ke vi ekzamenis alian procezon, ekzemple retumilon, kiu donis la URL-on al kazo startigita antaŭ la lanĉilo. Kontrolu per ldd, ĉu la binaro estas dinamike ligita, antaŭ ol postkuri ion alian, ĉar statika konstruo tute ne povas ŝargi la antaŭŝargon. Poste legu la prokurilan liston en la agordo, kiun la lanĉilo efektive uzis, ĉar eksdata vojo aŭ fermita pordo donas funkciantan hokon sen funkcianta ĉeno.

Spuru la konektojn, kiuj forlasas la procezon

La ĉeesto de la biblioteko ne pruvas, ke ĉiu voko estis reskribita, do sekvu la sistemvokojn. Rulu unu peton sub la spurilo kaj legu, kien la soketoj efektive iris.

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

La spuro devus montri nur konektojn al via prokurila finpunkto, kun pordo kongrua al la ero en la agorda dosiero. Se la celadresoj de la celloko aperas rekte en la spuro, tiu voko evitis la hokon, kaj tio estas ĝuste la trovitaĵo, kiun vi serĉis. Komparu la pordnumerojn kun la prokurila listo anstataŭ fidi la dosiernomon, ĉar restinta agordo el alia projekto estas ofta fonto de silenta rekta aliro. Konservu la spuron por la akcepta protokolo; ĝi daŭras sekundojn kaj finas disputojn pri kovrado.

Decidu, kion la hoko ne povas kovri

La projekto proxychains-ng limigas alidirektadon al TCP kaj avertas, ke skriptoj, fonaj procezoj kaj ŝargitaj moduloj povas konduti alie ol la ĉefa programo. UDP kaj ICMP staras ekster la mekanismo, do ĉio, kio dependas de ili, bezonas sian propran subtenatan vojon. DNS sekvas la agordon proxy_dns kaj la propran konduton de la solvilo de la aplikaĵo, kio signifas, ke unu sukcesa HTTPS-peto diras al vi nenion pri nomresolvo. Teni ankaŭ la atestilan validigon tie, kie ĝi apartenas: atingi servilon tra prokurilo ne estas kaŭzo malŝalti identec-kontrolojn.

Se rekta retrofalo devas esti neebla, uzu devigan limon, kiu regas la trafikon mem, ekzemple retan nomspacon, fajroŝirmilajn regulojn aŭ VPN, kaj tenu ĝin aparte de la biblioteka hoko. La hoko estas kongrueca ilo por nomita programo, ne kill switch. Notu la programon, la precizan komandon, la prokurilan pordon viditan en la spuro kaj ĉu DNS estis solvita malproksime; tiuj kvar faktoj estas la diferenco inter kontrolita amplekso kaj esperplena amplekso.