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 алсаас шийдэгдсэн эсэхийг тэмдэглэнэ үү; эдгээр дөрвөн баримт нь шалгасан хамрах хүрээ ба найдвартай хүрээ хоёрын ялгаа юм.

Холбоотой нийтлэлүүд