Mida ProxyChains püüab kinni ja mida jätab puutumata

ProxyChains-NG ei loo tunnelit. See eellaadib teegi, mis asendab võrguga seotud libc-kutsed selle ühe programmi sees, mille ta käivitab, seega piiriks on kutse protsessis, mitte kogu seadet hõlmav marsruut. Just see erinevus otsustab, mida edukas test tegelikult tõestab. Töötav curl läbi ahela kinnitab üht haagitud kutset, mitte seda, et nime lahendamine, UDP või iga tütarprotsess läks sama teed. Allolev juhend kontrollib katvust kolme sammuna ja loetleb seejärel, milleni haak ei ulatu.

Kuidas eellaadimine ühenduseni jõuab

Käivitamisel paneb käivitaja libproxychains väärtusesse LD_PRELOAD ja käivitab seejärel sihtprogrammi. Teek lahendab tegelikud libc-sümbolid ja asendab need oma versioonidega funktsioonidest nagu connect ja getaddrinfo. Kutsed, mis läbivad neid sümboleid, kirjutatakse ümber konfiguratsioonifailis olevale SOCKS- või HTTP-proksile. Kutsed, mis lähevad muud teed, ei kohtu haagiga kunagi, mistõttu kehtib garantii kutse, mitte masina kohta.

Osalevad ainult dünaamiliselt lingitud programmid ning turvalise täitmise all olevad setuid-binaarid eiravad eellaadimist täielikult. Lapsprotsessid pärivad keskkonna, kuid ainult seni, kuni käivitaja seda paigal hoiab.

Kinnitage, et teek on selles protsessis laaditud

Alustage päring ja uurige elavat protsessi, mitte shelli, mis selle käivitas. Fail maps näitab iga jagatud objekti, mis on protsessi praegu kaardistatud.

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

Vaste kinnitab, et haagitud teek on olemas, mis on vajalik, kuid mitte piisav. Tühi tulemus tähendab tavaliselt, et uurisite teist protsessi, näiteks brauserit, mis andis URL-i enne käivitajat alanud eksemplarile. Enne millegi muu tagaajamist kontrollige ldd abil, kas binaar on dünaamiliselt lingitud, sest staatiline build ei suuda eellaadimist üldse laadida. Seejärel lugege prokside nimekirja konfiguratsioonis, mida käivitaja tegelikult kasutas, sest aegunud tee või suletud port annab töötava haagi ilma töötava ahelata.

Jälgige ühendusi, mis protsessist väljuvad

Teegi olemasolu ei tõesta, et iga kutse kirjutati ümber, seega jälgige süsteemikutsed. Käivitage üks päring jälgija all ja lugege, kuhu soketid tegelikult läksid.

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

Jälg peaks näitama ühendusi ainult teie proksi lõpp-punktiga, kusjuures port vastab konfiguratsioonifaili kirjele. Kui sihtsaidile suunatud aadressid ilmuvad jäljes otse, tähendab see, et see kutse läks haagist mööda, ja see ongi leid, mida otsisite. Võrrelge pordi numbreid prokside nimekirjaga, selle asemel et usaldada faili nime, sest teisest projektist jäänud konfiguratsioon on tavaline vaikse otsese juurdepääsu allikas. Hoidke jälg vastuvõtuprotokolli jaoks alles; see võtab sekundeid ja lõpetab vaidlused katvuse üle.

Otsustage, mida haak katta ei suuda

proxychains-ng projekt piirab ümbersuunamise TCP-ga ja hoiatab, et skriptid, taustaprotsessid ja laaditud moodulid võivad käituda teisiti kui põhiprogramm. UDP ja ICMP jäävad mehhanismist välja, seega vajab kõik neile toetuv oma toetatud teed. DNS järgib seadet proxy_dns ja rakenduse enda nimeserveri käitumist, mis tähendab, et üks edukas HTTPS-päring ei ütle teile nime lahendamise kohta midagi. Hoidke ka sertifikaatide valideerimine seal, kuhu see kuulub: serverini jõudmine proksi kaudu ei ole põhjus identiteedikontrolle välja lülitada.

Kui otsene tagasilangemine peab olema võimatu, kasutage jõustamispiiri, mis juhib liiklust ennast, näiteks võrgu nimeruum, tulemüüri reeglid või VPN, ja hoidke seda teegihaagist eraldi. Haak on konkreetse programmi ühilduvusvahend, mitte kill switch. Kirjutage üles programm, täpne käsk, jäljes nähtud proksiport ja see, kas DNS lahendati kaugelt; need neli fakti on vahe kontrollitud ulatuse ja lootusliku ulatuse vahel.