Hvad ProxyChains opsnapper, og hvad det lader være
ProxyChains hooker bibliotekskald i det program, den starter. Bekræft TCP-dækning med maps, strace og én anmodning, og antag så ikke, at DNS eller UDP følger med.
ProxyChains-NG opretter ikke en tunnel. Det forhåndsindlæser et bibliotek, der erstatter netværksrelaterede libc-kald inde i det ene program, det starter, så grænsen er et kald i en proces, ikke en rute for hele enheden. Den forskel afgør, hvad en vellykket test faktisk beviser. En fungerende curl gennem kæden bekræfter ét hooket kald, ikke at navneopløsning, UDP eller enhver underproces fulgte samme vej. Vejledningen nedenfor verificerer dækningen i tre trin og opregner derefter, hvad hooken ikke kan nå.
Sådan når forhåndsindlæsningen en forbindelse
Ved opstart lægger starteren libproxychains ind i LD_PRELOAD og kører derefter målprogrammet. Biblioteket slår de rigtige libc-symboler op og erstatter dem med sine egne versioner af funktioner som connect og getaddrinfo. Kald, der går gennem disse symboler, omskrives til SOCKS- eller HTTP-proxyen fra konfigurationsfilen. Kald, der tager en anden vej, møder aldrig hooken, og derfor gælder garantien pr. kald og ikke pr. maskine.
Kun dynamisk linkede programmer deltager, og setuid-binære filer under sikker udførelse ignorerer forhåndsindlæsningen helt. Børnene arver miljøet, men kun så længe starteren holder det på plads.
Bekræft, at biblioteket er indlæst i den proces
Start anmodningen, og undersøg den levende proces i stedet for det shell, der startede den. Filen maps viser hvert delt objekt, der i øjeblikket er mappet ind i processen.
proxychains4 -q curl -sS --max-time 8 https://example.com/ -o /dev/null &
pgrep -a curl
grep libproxychains /proc/$(pgrep -n curl)/mapsEt match bekræfter, at det hookede bibliotek er til stede, hvilket er nødvendigt men ikke tilstrækkeligt. Et tomt resultat betyder normalt, at du undersøgte en anden proces, for eksempel en browser, der gav URL'en videre til en instans, der blev startet før starteren. Kontroller med ldd, at binæren er dynamisk linket, før du jagter noget andet, fordi et statisk build slet ikke kan indlæse forhåndsindlæsningen. Læs derefter proxy-listen i den konfiguration, starteren faktisk brugte, da en forældet sti eller en lukket port giver en fungerende hook uden en fungerende kæde.
Følg de forbindelser, der forlader processen
Bibliotekets tilstedeværelse beviser ikke, at hvert kald blev omskrevet, så følg systemkaldene. Kør én anmodning under traceren, og læs, hvor sockets faktisk gik hen.
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 bør kun vise forbindelser til dit proxy-endepunkt, med porten der matcher posten i konfigurationsfilen. Hvis destinationsadresserne for målwebstedet vises direkte i sporet, betyder det, at det kald omgik hooken, og det er netop det fund, du ledte efter. Sammenlign portnumrene med proxy-listen i stedet for at stole på filnavnet, fordi en restkonfiguration fra et andet projekt er en almindelig kilde til tavs direkte adgang. Gem sporet til acceptprotokollen; det tager sekunder og afgør diskussioner om dækning.
Afgør, hvad hooken ikke kan dække
proxychains-ng-projektet begrænser omdirigering til TCP og advarer om, at scripts, baggrundsprocesser og indlæste moduler kan opføre sig anderledes end hovedprogrammet. UDP og ICMP ligger uden for mekanismen, så alt, der afhænger af dem, har brug for sin egen understøttede vej. DNS følger indstillingen proxy_dns og applikationens egen resolver-adfærd, hvilket betyder, at én vellykket HTTPS-anmodning intet siger om navneopløsning. Behold også certifikatvalidering, hvor den hører hjemme: at nå en server gennem en proxy er ikke en grund til at slå identitetskontroller fra.
Hvis direkte fallback skal være umuligt, brug en håndhævelsesgrænse, der styrer trafikken selv, som et netværksnavnerum, firewall-regler eller en VPN, og hold den adskilt fra bibliotekshooken. Hooken er et kompatibilitetsværktøj til et navngivet program, ikke en kill switch. Registrer programmet, den præcise kommando, proxy-porten set i sporet og om DNS blev opløst eksternt; de fire fakta er forskellen mellem et verificeret omfang og et håbefuldt et.