proxychains er der stadig, når du har fjernet præfikset
Følg en uventet indlæst proxy-wrapper gennem LD_PRELOAD-arv, og skel mellem fremtidige processtart og biblioteker, der allerede er indlæst.
Du fjerner proxychains fra en kommando, starter den igen og ser stadig wrapperens opstartsmeddelelse. Kontroller startmiljøet, før du leder efter en indstilling i programmet.
På Linux beder LD_PRELOAD den dynamiske linker om at indlæse angivne delte objekter før almindelige biblioteker. Proxy-wrappere kan bruge den mekanisme til at opfange understøttede netværkskald. Hvis nogen har eksporteret variablen i et shell, kan senere underordnede programmer arve den, selv når deres kommandolinjer ikke indeholder noget wrapper-præfiks.
En første skrivebeskyttet kontrol i det shell er:
printf '%s\n' "$LD_PRELOAD"
Se efter et proxy-wrapper-bibliotek, men bevar muligheden for, at variablen også oplister andre bevidst indlæste biblioteker. Blindt at fjerne hver post kan forstyrre et andet værktøj.
Skift starter, og genstart derefter programmet
Ryd den utilsigtede proxy-forudindlæsning fra det miljø, der starter det berørte program. Hvis en opstartsfil eller starter eksporterer den, skal du rette den kilde også. Ved Bash-start følger du rækkefølgen af opstartsfiler. Et nyt barn af et rent shell er en anden sag end et barn af en gammel terminal eller IDE, der stadig holder variablen.
At fjerne en miljøvariabel aflæser ikke et bibliotek fra en proces, der allerede er startet med den. En kørende applikation kan derfor beholde wrapperen, indtil den genstartes ad den rettede startvej.
Hvis variablen mangler, skal du undersøge andre konfigurerede forudindlæsningskilder som /etc/ld.so.preload og den faktiske starter. Mekanismen har grænser: statiske kørende filer, direkte systemkald og begrænsninger for sikker kørsel kan opføre sig anderledes. Med sudo er wrapperens rækkefølge vigtig. En arvet forudindlæsning forklarer uventet opfangning; det er ikke bevis for, at al netværkstrafik bruger proxyen.