ProxyChains-NG ei luo tunnelia. Se esilataa kirjaston, joka korvaa verkkoon liittyvät libc-kutsut sen yhden ohjelman sisällä, jonka se käynnistää, joten raja on kutsu prosessissa, ei koko laitteen reitti. Tämä ero ratkaisee, mitä onnistunut testi todella todistaa. Toimiva curl ketjun läpi vahvistaa yhden koukutetun kutsun, ei sitä, että nimien selvitys, UDP tai jokainen lapsiprosessi olisi kulkenut samaa polkua. Alla oleva ohje varmistaa kattavuuden kolmessa vaiheessa ja luettelee sitten, mihin koukku ei yllä.

Miten esilataus pääsee yhteyteen

Käynnistyksessä käynnistin asettaa libproxychains kirjastoon LD_PRELOAD ja suorittaa sitten kohdeohjelman. Kirjasto selvittää todelliset libc-symbolit ja korvaa ne omilla versioillaan funktioista kuten connect ja getaddrinfo. Kutsut, jotka kulkevat näiden symbolien kautta, kirjoitetaan uudelleen määritystiedoston SOCKS- tai HTTP-välityspalvelimelle. Kutsut, jotka ottavat toisen reitin, eivät koskaan kohtaa koukkua, ja siksi takuu on kutsu- eikä konekohtainen.

Vain dynaamisesti linkitetyt ohjelmat osallistuvat, ja turvallisen suorituksen alla olevat setuid-binäärit jättävät esilatauksen kokonaan huomiotta. Lapset perivät ympäristön, mutta vain niin kauan kuin käynnistin pitää sen paikallaan.

Varmista, että kirjasto on ladattu siihen prosessiin

Käynnistä pyyntö ja tarkastele elävää prosessia sen käynnistäneen kuoren sijaan. maps-tiedosto näyttää jokaisen jaetun objektin, joka on tällä hetkellä kuvattu prosessiin.

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

Osuma vahvistaa, että koukutettu kirjasto on läsnä, mikä on välttämätöntä mutta ei riittävää. Tyhjä tulos tarkoittaa yleensä, että tarkastelit toista prosessia, esimerkiksi selainta, joka antoi URL:n ennen käynnistintä alkaneelle instanssille. Tarkista ldd avulla, että binääri on dynaamisesti linkitetty, ennen kuin jahtaat mitään muuta, sillä staattinen koonti ei voi ladata esilatausta lainkaan. Lue sitten välityspalvelinluettelo määrityksestä, jota käynnistin todella käytti, koska vanhentunut polku tai suljettu portti tuottaa toimivan koukun ilman toimivaa ketjua.

Jäljitä yhteydet, jotka lähtevät prosessista

Kirjaston läsnäolo ei todista, että jokainen kutsu kirjoitettiin uudelleen, joten seuraa järjestelmäkutsuja. Aja yksi pyyntö jäljittimen alla ja lue, minne pistokkeet todella menivät.

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äljen pitäisi näyttää yhteydet vain välityspalvelimesi päätepisteeseen, ja portin pitäisi vastata määritystiedoston merkintää. Jos kohdesivuston kohdeosoitteet näkyvät jäljessä suoraan, kyseinen kutsu ohitti koukun, ja juuri se on se löydös, jota etsit. Vertaa porttinumeroita välityspalvelinluetteloon sen sijaan, että luottaisit tiedostonimeen, koska toisesta projektista jäänyt määritys on tavallinen hiljaisen suoran pääsyn lähde. Säilytä jälki hyväksyntämerkinnäksi; se kestää sekunteja ja ratkaisee väittelyt kattavuudesta.

Päätä, mitä koukku ei voi kattaa

proxychains-ng-projekti rajoittaa uudelleenohjauksen TCP:hen ja varoittaa, että skriptit, taustaprosessit ja ladatut moduulit voivat käyttäytyä eri tavoin kuin pääohjelma. UDP ja ICMP ovat mekanismin ulkopuolella, joten kaikki niihin nojaava tarvitsee oman tuetun polkunsa. DNS noudattaa proxy_dns-asetusta ja sovelluksen oman selvittäjän käyttäytymistä, mikä tarkoittaa, että yksi onnistunut HTTPS-pyyntö ei kerro sinulle mitään nimien selvityksestä. Pidä myös varmenteiden vahvistus paikallaan: palvelimeen pääseminen välityspalvelimen kautta ei ole syy kytkeä henkilöllisyyden tarkistuksia pois.

Jos suoran varayhteyden on oltava mahdoton, käytä pakotettua rajaa, joka hallitsee itse liikennettä, kuten verkkonimiavaruutta, palomuurisääntöjä tai VPN:ää, ja pidä se erillään kirjastokoukusta. Koukku on yhteensopivuustyökalu nimetylle ohjelmalle, ei kill switch. Kirjaa ohjelma, tarkka komento, jäljessä nähty välityspalvelinportti ja se, selvitettiinkö DNS etänä; nuo neljä seikkaa ovat ero varmennetun laajuuden ja toiveikkaan laajuuden välillä.

Aiheeseen liittyvät artikkelit