proxychains rămâne după ce elimini prefixul

Eliminați proxychains dintr-o comandă, o lansați din nou și vedeți în continuare mesajul de pornire al wrapperului. Verificați mediul de lansare înainte de a căuta o setare în aplicație.

Pe Linux, LD_PRELOAD cere linkerului dinamic să încarce obiectele partajate specificate înaintea bibliotecilor obișnuite. Wrapperii proxy pot folosi acel mecanism pentru a intercepta apelurile de rețea acceptate. Dacă cineva a exportat variabila într-un shell, programele copil ulterioare o pot moșteni chiar și atunci când liniile lor de comandă nu conțin niciun prefix de wrapper.

O primă verificare doar în citire în acel shell este:

printf '%s\n' "$LD_PRELOAD"

Căutați o bibliotecă de wrapper proxy, dar păstrați posibilitatea ca variabila să listeze și alte biblioteci încărcate intenționat. Eliminarea orbească a tuturor intrărilor poate perturba alt instrument.

Schimbați lansatorul, apoi relansați programul

Eliminați preîncărcarea proxy accidentală din mediul care lansează programul afectat. Dacă un fișier de pornire sau un lansator o exportă, corectați și acea sursă. La lansările Bash, urmați ordinea fișierelor de pornire. Un copil nou al unui shell curat este un caz diferit de copilul unui terminal sau IDE vechi care încă ține variabila.

Anularea unei variabile de mediu nu descarcă o bibliotecă dintr-un proces care a pornit deja cu ea. De aceea, o aplicație aflată în rulare poate păstra wrapperul până când este repornită prin calea de lansare corectată.

Dacă variabila lipsește, inspectați alte surse de preîncărcare configurate, cum ar fi /etc/ld.so.preload, și lansatorul real. Mecanismul are limite: executabilele statice, apelurile de sistem directe și restricțiile de execuție sigură se pot comporta diferit. Cu sudo, ordinea wrapperului contează. O preîncărcare moștenită explică o interceptare neașteptată; nu este dovada că tot traficul de rețea folosește proxy-ul.