Hvað ProxyChains grípur og hvað það lætur í friði

ProxyChains-NG býr ekki til göng. Það forhleður bókasafni sem kemur í stað netkerfistengdra libc-kalla inni í því eina forriti sem það ræsir, svo mörkin eru kall í ferli, ekki leið fyrir allt tækið. Þessi greinarmunur ræður því hvað árangursríkt próf sannar í raun. Virkt curl í gegnum keðjuna staðfestir eitt krókt kall, ekki að nafnupplausn, UDP eða hvert undirferli hafi farið sömu leið. Leiðbeiningin hér að neðan staðfestir umröðunina í þremur skrefum og telur síðan upp það sem krókurinn nær ekki til.

Hvernig forhleðslan nær til tengingar

Við ræsingu setur ræsirinn libproxychains í LD_PRELOAD og keyrir síðan markforritið. Bókasafnið leysir hin raunverulegu libc-tákn og kemur í stað þeirra með eigin útgáfum af föllum eins og connect og getaddrinfo. Köll sem fara í gegnum þessi tákn eru endurskrifuð á SOCKS- eða HTTP-proxy úr stillingaskránni. Köll sem fara aðra leið mæta króknum aldrei, og þess vegna gildir tryggingin fyrir hvert kall en ekki hverja vél.

Aðeins forrit sem eru kviktengd taka þátt, og setuid-tvíkóðar undir öruggri keyrslu hunsa forhleðsluna algjörlega. Afkvæmin erfa umhverfið, en aðeins svo lengi sem ræsirinn heldur því á sínum stað.

Staðfestu að bókasafnið sé hlaðið inn í það ferli

Byrjaðu beiðnina og skoðaðu lifandi ferlið í stað skeljarinnar sem ræsti það. Skráin maps sýnir hvern sameiginlegan hlut sem er nú varpað inn í ferlið.

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

Samsvörun staðfestir að krókaða bókasafnið sé til staðar, sem er nauðsynlegt en ekki nægjanlegt. Tóm niðurstaða þýðir venjulega að þú skoðaðir annað ferli, til dæmis vafra sem afhenti slóðina til tilviks sem var ræst áður en ræsirinn. Athugaðu með ldd að tvíkóðinn sé kviktengdur áður en þú eltir eitthvað annað, því stöðluð bygging getur alls ekki hlaðið forhleðslunni. Lestu síðan proxy-listann í þeirri stillingu sem ræsirinn notaði í raun, því úrelt slóð eða lokuð höfn gefur virkan krók án virkrar keðju.

Rekjaðu tengingarnar sem fara út úr ferlinu

Tilvist bókasafnsins sannar ekki að hvert kall hafi verið endurskrifað, svo fylgdu kerfisköllunum. Keyrðu eina beiðni undir reklinum og lestu hvert sokkarnir fóru í raun.

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

Rekið ætti aðeins að sýna tengingar við endapunkt proxy-sins þíns, með höfn sem samsvarar færslunni í stillingaskránni. Ef markmiðsfang slóðarinnar birtast beint í rekinu þýðir það að það kall fór fram hjá króknum, og það er einmitt sú niðurstaða sem þú varst að leita að. Berðu saman hafnarnúmerin við proxy-listann í stað þess að treysta skráarnafninu, því afgangsstilling úr öðru verkefni er algeng uppspretta hljóðlátra beinna aðgangs. Geymdu rekið fyrir samþykkisskráninguna; það tekur sekúndur og leysir deilur um umröðunina.

Ákveddu hvað krókurinn getur ekki náð yfir

proxychains-ng verkefnið takmarkar endurbeiningu við TCP og varar við því að skriftur, bakgrunnsferli og hlaðnar einingar geti hegðað sér öðruvísi en aðalforritið. UDP og ICMP liggja utan fyrirkomulagsins, svo allt sem treystir á þau þarf sína eigin studdu leið. DNS fylgir stillingunni proxy_dns og eigin hegðun leysis forritsins, sem þýðir að ein árangursrík HTTPS-beiðni segir þér ekkert um nafnupplausn. Haltu einnig staðfestingu skírteina þar sem hún á heima: að ná í þjón í gegnum proxy er ekki ástæða til að slökkva á auðkenningarskoðunum.

Ef beint afturhvarf verður að vera ómögulegt, notaðu framfylgdarmörk sem stjórna umferðinni sjálfri, eins og netnafnrými, reglur eldveggs eða VPN, og haltu því aðskildu frá bókasafnskróknum. Krókurinn er samhæfingartæki fyrir tiltekið forrit, ekki kill switch. Skráðu forritið, nákvæma skipunina, proxy-höfnina sem sást í rekinu og hvort DNS var leyst úr fjarlægð; þessar fjórar staðreyndir eru munurinn á staðfestu umfangi og vonandi umfangi.