Hva ProxyChains fanger opp, og hva det lar være
ProxyChains hekter bibliotekkall i programmet det starter. Bekreft TCP-dekningen med maps, strace og én forespørsel, og slutt å anta at DNS eller UDP følger etter.
ProxyChains-NG lager ingen tunnel. Det forhåndslaster et bibliotek som erstatter nettverksrelaterte libc-kall inne i det ene programmet det starter, så grensen er et kall i en prosess, ikke en rute for hele enheten. Den forskjellen avgjør hva en vellykket test faktisk beviser. En fungerende curl gjennom kjeden bekrefter ett hektet kall, ikke at navneoppslag, UDP eller hver barneprosess fulgte samme vei. Veiledningen nedenfor verifiserer dekningen i tre trinn og lister deretter opp hva hekten ikke kan nå.
Hvordan forhåndslastingen når en tilkobling
Ved oppstart legger starteren libproxychains inn i LD_PRELOAD og kjører deretter målprogrammet. Biblioteket slår opp de ekte libc-symbolene og erstatter dem med egne versjoner av funksjoner som connect og getaddrinfo. Kall som går gjennom disse symbolene, skrives om til SOCKS- eller HTTP-proxyen fra konfigurasjonsfilen. Kall som tar en annen vei, møter aldri hekten, og derfor gjelder garantien per kall og ikke per maskin.
Bare dynamisk lenkede programmer deltar, og setuid-binærfiler under sikker kjøring ignorerer forhåndslastingen helt. Barna arver miljøet, men bare så lenge starteren holder det på plass.
Bekreft at biblioteket er lastet inn i den prosessen
Start forespørselen og undersøk den levende prosessen i stedet for skallet som startet den. Filen maps viser hvert delt objekt som for øyeblikket er mappet inn i prosessen.
proxychains4 -q curl -sS --max-time 8 https://example.com/ -o /dev/null &
pgrep -a curl
grep libproxychains /proc/$(pgrep -n curl)/mapsEt treff bekrefter at det hektede biblioteket er til stede, noe som er nødvendig, men ikke tilstrekkelig. Et tomt resultat betyr vanligvis at du undersøkte en annen prosess, for eksempel en nettleser som ga URL-en videre til en instans som ble startet før starteren. Kontroller med ldd at binærfila er dynamisk lenket før du jager noe annet, fordi et statisk bygg ikke kan laste forhåndslastingen i det hele tatt. Les deretter proxy-listen i konfigurasjonen som starteren faktisk brukte, siden en utdatert sti eller en lukket port gir en fungerende hekt uten en fungerende kjede.
Spor tilkoblingene som forlater prosessen
Bibliotekets tilstedeværelse beviser ikke at hvert kall ble skrevet om, så følg systemkallene. Kjør én forespørsel under sporingen og les hvor socketene faktisk gikk.
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 -uSporet skal bare vise tilkoblinger til ditt proxy-endepunkt, med porten som samsvarer med oppføringen i konfigurasjonsfilen. Hvis destinasjonsadressene til målområdet vises direkte i sporet, betyr det at det kallet omgikk hekten, og det er nettopp funnet du lette etter. Sammenlign portnumrene med proxy-listen i stedet for å stole på filnavnet, fordi en restkonfigurasjon fra et annet prosjekt er en vanlig kilde til stille direkte tilgang. Ta vare på sporet for akseptprotokollen; det tar sekunder og avgjør diskusjoner om dekning.
Avgjør hva hekten ikke kan dekke
proxychains-ng-prosjektet begrenser omdirigering til TCP og advarer om at skript, bakgrunnsprosesser og innlastede moduler kan oppføre seg annerledes enn hovedprogrammet. UDP og ICMP ligger utenfor mekanismen, så alt som er avhengig av dem trenger sin egen støttede vei. DNS følger innstillingen proxy_dns og applikasjonens egen resolveratferd, noe som betyr at én vellykket HTTPS-forespørsel ikke sier deg noe om navneoppslag. Behold også sertifikatvalideringen der den hører hjemme: å nå en server gjennom en proxy er ikke grunn til å slå av identitetskontroller.
Hvis direkte tilbakefall må være umulig, bruk en håndhevelsesgrense som styrer trafikken selv, som et nettverksnavnerom, brannmurregler eller en VPN, og hold den adskilt fra bibliotekhekten. Hekten er et kompatibilitetsverktøy for et navngitt program, ikke en kill switch. Noter programmet, den nøyaktige kommandoen, proxy-porten som ble sett i sporet og om DNS ble løst eksternt; disse fire fakta er forskjellen mellom et verifisert omfang og et håpefullt et.