Ինչ է որսում ProxyChains-ը և ինչ է թողնում անվնաս

ProxyChains-NG-ը թունել չի ստեղծում։ Այն նախաբեռնում է գրադարան, որը փոխարինում է ցանցային libc կանչերը այն մեկ ծրագրի ներսում, որը գործարկում է, ուստի սահմանը գործընթացի մեջ կանչն է, ոչ թե ամբողջ սարքի երթուղին։ Այդ տարբերությունն է որոշում, թե ինչ է իրականում ապացուցում հաջող թեստը։ Շղթայով աշխատող curl-ը հաստատում է մեկ կեռիկավորված կանչ, այլ ոչ թե այն, որ անվան լուծումը, UDP-ն կամ յուրաքանչյուր զավակ գործընթաց նույն ուղին է գնացել։ Ստորև ուղեցույցը երեք քայլով ստուգում է ծածկույթը, ապա թվարկում է, թե ինչին կեռիկը չի հասնում։

Ինչպես է նախաբեռնումը հասնում կապի

Մեկնարկի պահին գործարկիչը libproxychains-ը դնում է LD_PRELOAD-ի մեջ և ապա կատարում թիրախ ծրագիրը։ Գրադարանը լուծում է իրական libc սիմվոլները և փոխարինում դրանք իր սեփական տարբերակներով այնպիսի ֆունկցիաների, ինչպիսիք են connect-ը և getaddrinfo-ը։ Այդ սիմվոլներով անցնող կանչերը վերագրվում են կազմաձևի ֆայլի SOCKS կամ HTTP փոխանորդին։ Այլ ուղի վերցնող կանչերը երբեք չեն հանդիպում կեռիկին, և դրա համար էլ երաշխիքը յուրաքանչյուր կանչի համար է, ոչ թե ամբողջ մեքենայի։

Մասնակցում են միայն դինամիկ կերպով կապված ծրագրերը, իսկ անվտանգ կատարման տակ գտնվող setuid բինարները լիովին անտեսում են նախաբեռնումը։ Զավակները ժառանգում են միջավայրը, բայց միայն այնքան ժամանակ, քանի դեռ գործարկիչը պահում է այն տեղում։

Համոզվեք, որ գրադարանը բեռնված է այդ գործընթացում

Սկսեք հարցումը և ուսումնասիրեք կենդանի գործընթացը, ոչ թե այն գործարկած shell-ը։ 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 հարցում ոչինչ չի ասում անվան լուծման մասին։ Վկայագրերի ստուգումը նույնպես թողեք իր տեղում. փոխանորդով սերվերին հասնելը պատճառ չէ անջատելու ինքնության ստուգումները։

Եթե ուղղակի հետընկնումը պետք է անհնար լինի, օգտագործեք պարտադրման սահման, որը կառավարում է հենց երթևեկությունը, օրինակ՝ ցանցային անվանատարածք, firewall-ի կանոններ կամ VPN, և պահեք այն առանձին գրադարանի կեռիկից։ Կեռիկը համատեղելիության գործիք է նշված ծրագրի համար, ոչ թե kill switch։ Գրանցեք ծրագիրը, ճշգրիտ հրամանը, հետքում տեսած փոխանորդի պորտը և այն, թե արդյոք DNS-ը լուծվել է հեռավորորեն. այդ չորս փաստերն են տարբերությունը ստուգված շրջանակի և հույսով լցված շրջանակի միջև։