Kaj ProxyChains prestreže in kaj pusti pri miru

ProxyChains-NG ne ustvari tunela. Prednaloži knjižnico, ki zamenja omrežne klice libc znotraj enega programa, ki ga zažene, zato je meja klic v procesu, ne pot za celo napravo. Ta razlika odloča, kaj uspešen test v resnici dokaže. Delujoč curl skozi verigo potrjuje en prestreženi klic, ne pa, da so razreševanje imen, UDP ali vsak podrejeni proces šli po isti poti. Spodnje navodilo preveri pokritost v treh korakih in nato našteje, česa kljuka ne more doseči.

Kako prednalaganje doseže povezavo

Ob zagonu zaganjalnik vstavi libproxychains v LD_PRELOAD in nato izvede ciljni program. Knjižnica razreši prave simbole libc in jih nadomesti z lastnimi različicami funkcij, kot sta connect in getaddrinfo. Klici, ki gredo skozi te simbole, se prepišejo na proxy SOCKS ali HTTP iz konfiguracijske datoteke. Klici, ki ubirajo drugo pot, nikoli ne srečajo kljuke, zato velja zagotovilo za vsak klic in ne za cel stroj.

Sodelujejo le dinamično povezani programi, setuid binarne datoteke pod varnim izvajanjem pa prednalaganje popolnoma prezrejo. Otroci podedujejo okolje, a le dokler ga zaganjalnik drži na mestu.

Potrdite, da je knjižnica naložena v tem procesu

Začnite zahtevo in pregledajte živi proces, ne lupine, ki ga je zagnala. Datoteka maps prikazuje vsak skupni objekt, ki je trenutno preslikan v proces.

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

Ujemanje potrdi prisotnost zataknjene knjižnice, kar je potrebno, a ne zadostuje. Prazen rezultat običajno pomeni, da ste pregledali drug proces, na primer brskalnik, ki je URL predal primerku, zagnanemu pred zaganjalnikom. Preden se lotite česa drugega, z ldd preverite, ali je binarna datoteka dinamično povezana, saj statična gradnja prednalaganja sploh ne more naložiti. Nato preberite seznam proxyjev v konfiguraciji, ki jo je zaganjalnik dejansko uporabil, ker zastarela pot ali zaprta vrata dajo delujočo kljuko brez delujoče verige.

Sledite povezavam, ki zapustijo proces

Prisotnost knjižnice ne dokazuje, da je bil vsak klic prepisan, zato sledite sistemskim klicem. Zaženite eno zahtevo pod sledilnikom in preberite, kam so vtičnice v resnici šle.

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

Sled naj bi prikazala le povezave do vaše proxy končne točke, vrata pa morajo ustrezati vnosu v konfiguracijski datoteki. Če se naslovi ciljnega mesta pojavijo neposredno v sledi, je tisti klic obšel kljuko, in to je natanko tista ugotovitev, ki ste jo iskali. Primerjajte številke vrat s seznamom proxyjev, namesto da zaupate imenu datoteke, ker je preostala konfiguracija iz drugega projekta pogost vir tihega neposrednega dostopa. Sled shranite za zapisnik o sprejemu; traja sekunde in razreši razprave o pokritosti.

Odločite, česa kljuka ne more pokriti

Projekt proxychains-ng omejuje preusmerjanje na TCP in opozarja, da se lahko skripti, ozadnji procesi in naloženi moduli obnašajo drugače kot glavni program. UDP in ICMP sta zunaj mehanizma, zato vsakdo, ki se nanju zanaša, potrebuje svojo podprto pot. DNS sledi nastavitvi proxy_dns in vedenju lastnega razreševalnika aplikacije, kar pomeni, da ena uspešna zahteva HTTPS ne pove ničesar o razreševanju imen. Pustite tudi preverjanje potrdil tam, kjer mu je mesto: doseči strežnik prek proxyja ni razlog za izklop preverjanja identitete.

Če mora biti neposredni povratek nemogoč, uporabite mejo uveljavljanja, ki nadzoruje sam promet, kot je omrežni imenski prostor, pravila požarnega zidu ali VPN, in jo držite ločeno od knjižnične kljuke. Kljuka je orodje za združljivost določenega programa, ne kill switch. Zapišite program, natančen ukaz, proxy vrata, videna v sledi, in ali je bil DNS razrešen na daljavo; ta štiri dejstva so razlika med preverjenim obsegom in obsegom upanja.