Ce interceptează ProxyChains și ce lasă în pace
ProxyChains agață apeluri de bibliotecă în programul pe care îl lansează. Verificați acoperirea TCP cu maps, strace și o singură cerere, apoi nu mai presupuneți că DNS sau UDP urmează.
ProxyChains-NG nu creează un tunel. Preîncarcă o bibliotecă ce înlocuiește apelurile libc legate de rețea în interiorul singurului program pe care îl lansează, deci granița este un apel într-un proces, nu o rută pentru întregul dispozitiv. Această distincție decide ce dovedește de fapt un test reușit. Un curl funcțional prin lanț confirmă un singur apel agățat, nu că rezolvarea numelor, UDP sau fiecare proces copil au urmat aceeași cale. Ghidul de mai jos verifică acoperirea în trei pași, apoi enumeră ce nu poate atinge cârligul.
Cum ajunge preîncărcarea la o conexiune
La pornire, lansatorul pune libproxychains în LD_PRELOAD și apoi execută programul țintă. Biblioteca rezolvă simbolurile libc reale și le înlocuiește cu propriile versiuni ale unor funcții precum connect și getaddrinfo. Apelurile care trec prin acele simboluri sunt rescrise către proxy-ul SOCKS sau HTTP din fișierul de configurare. Apelurile care iau altă cale nu întâlnesc niciodată cârligul, motiv pentru care garanția este per apel, nu per mașină.
Participă doar programele legate dinamic, iar binarile setuid sub execuție sigură ignoră complet preîncărcarea. Copiii moștenesc mediul, dar numai atâta timp cât lansatorul îl ține la locul lui.
Confirmați că biblioteca este încărcată în acel proces
Porniți cererea și inspectați procesul viu, nu shell-ul care l-a lansat. Fișierul maps arată fiecare obiect partajat mapat în proces în acel moment.
proxychains4 -q curl -sS --max-time 8 https://example.com/ -o /dev/null &
pgrep -a curl
grep libproxychains /proc/$(pgrep -n curl)/mapsO potrivire confirmă prezența bibliotecii agățate, ceea ce este necesar, dar nu suficient. Un rezultat gol înseamnă de obicei că ați inspectat alt proces, de exemplu un browser care a predat URL-ul unei instanțe pornite înainte de lansator. Verificați cu ldd dacă binarul este legat dinamic înainte de a urmări orice altceva, fiindcă o compilare statică nu poate încărca deloc preîncărcarea. Apoi citiți lista de proxy-uri din configurația pe care lansatorul a folosit-o efectiv, deoarece o cale învechită sau un port închis produc un cârlig funcțional fără un lanț funcțional.
Urmăriți conexiunile care părăsesc procesul
Prezența bibliotecii nu dovedește că fiecare apel a fost rescris, așa că urmăriți apelurile de sistem. Rulați o cerere sub trasor și citiți unde au mers de fapt socket-urile.
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 -uUrma ar trebui să arate doar conexiuni către punctul final de proxy, cu portul potrivit intrării din fișierul de configurare. Dacă adresele de destinație ale site-ului țintă apar direct în urmă, acel apel a ocolit cârligul, și exact aceasta este constatarea pe care o căutați. Comparați numerele de port cu lista de proxy-uri în loc să vă bazați pe numele fișierului, fiindcă o configurație rămasă de la alt proiect este o sursă obișnuită de acces direct silențios. Păstrați urma pentru procesul-verbal de acceptare; durează secunde și închide dezbaterile despre acoperire.
Decideți ce nu poate acoperi cârligul
proiectul proxychains-ng limitează redirecționarea la TCP și avertizează că scripturile, procesele din fundal și modulele încărcate se pot comporta diferit față de programul principal. UDP și ICMP stau în afara mecanismului, așa că tot ce se bazează pe ele are nevoie de propria cale suportată. DNS urmează setarea proxy_dns și comportamentul resolverului aplicației, ceea ce înseamnă că o cerere HTTPS reușită nu vă spune nimic despre rezolvarea numelor. Păstrați și validarea certificatelor acolo unde îi este locul: a ajunge la un server printr-un proxy nu este un motiv să dezactivați verificările de identitate.
Dacă revenirea directă trebuie să fie imposibilă, folosiți o frontieră de aplicare care controlează traficul în sine, cum ar fi un spațiu de nume de rețea, reguli de firewall sau un VPN, și țineți-o separată de cârligul bibliotecii. Cârligul este un instrument de compatibilitate pentru un program anume, nu un kill switch. Notați programul, comanda exactă, portul de proxy văzut în urmă și dacă DNS a fost rezolvat de la distanță; aceste patru fapte sunt diferența dintre un domeniu verificat și unul de speranță.