Du entfernst proxychains aus einem Befehl, startest ihn erneut und siehst weiterhin die Startmeldung des Wrappers. Prüfe die Startumgebung, bevor du eine Anwendungseinstellung suchst.

Unter Linux bittet LD_PRELOAD den dynamischen Linker, angegebene Shared Objects vor gewöhnlichen Bibliotheken zu laden. Proxy-Wrapper können diesen Mechanismus nutzen, um unterstützte Netzwerkaufrufe abzufangen. Hat jemand die Variable in einer Shell exportiert, können spätere Kindprozesse sie erben, selbst wenn ihre Befehlszeilen kein Wrapper-Präfix enthalten.

Eine erste reine Leseprüfung in dieser Shell ist:

printf '%s\n' "$LD_PRELOAD"

Suche nach einer Proxy-Wrapper-Bibliothek, aber behalte die Möglichkeit im Blick, dass die Variable auch andere absichtlich geladene Bibliotheken auflistet. Alle Einträge blind zu entfernen kann ein anderes Werkzeug stören.

Ändere den Starter und starte das Programm neu

Entferne das versehentliche Proxy-Preload aus der Umgebung, die das betroffene Programm startet. Wenn eine Startdatei oder ein Starter es exportiert, korrigiere auch diese Quelle. Bei Bash-Starts folge der Reihenfolge der Startdateien. Ein neues Kind einer sauberen Shell ist ein anderer Fall als das Kind eines alten Terminals oder einer IDE, die die Variable noch hält.

Das Aufheben einer Umgebungsvariable entlädt keine Bibliothek aus einem Prozess, der bereits damit gestartet ist. Eine laufende Anwendung kann den Wrapper daher behalten, bis sie über den korrigierten Startweg neu gestartet wird.

Fehlt die Variable, prüfe andere konfigurierte Preload-Quellen wie /etc/ld.so.preload und den tatsächlichen Starter. Der Mechanismus hat Grenzen: statische ausführbare Dateien, direkte Systemaufrufe und Einschränkungen der sicheren Ausführung können sich anders verhalten. Mit sudo ist die Reihenfolge des Wrappers wichtig. Ein geerbtes Preload erklärt unerwartetes Abfangen; es ist kein Beweis, dass jeder Netzwerkverkehr den Proxy nutzt.

Ähnliche Artikel