Kompletten Traffic durch Proxy leiten (Linux)

Hi,

das kann ich nicht bestätigen. Im Betrieb in dem ich arbeite sind Windows und Linux-Clients vorhanden, die beide nur über einen Proxy (Squid) ins Internet kommen. Bei Windows hast du die IE Proxy-Konfiguration. Die wird von einigen Programmen genutzt, wenn diese entweder das .NET Browser Control (baut auf dem IE auf) verwenden oder bei ihren Anfragen den IE-Proxy auslesen und entsprechend setzen (in .NET z.B. WebClient, HttpWebRequest, etc).

Dann gibt es noch (wie unter Linux auch) die Umgebungsariablen HTTP_PROXY und HTTPS_PROXY. Gegebenenfalls ist auch NO_PROXY wichtig, um bestimmte interne URLs vom Proxy auszuschließen. Hast du die gesetzt? Sowohl unter Windows als auch Linux werden diese Variablen von den meisten Programmen berücksichtigt, wenn man sie global setzt (z.B. in der bashrc unter Linux, oder den Benutzer-Systemvariablen von Windows).

Einziger Unterschied ist, dass Linux auch die jeweils klein geschriebenen Varianten (http_proxy, https_proxy, no_proxy) berücksichtigt und einige wenige Applikationen nur damit funktionieren. Das ist ein wenig Tricky, daher würde ich immer beide setzen. Aber sonst nehmen sich Win und Linux da nicht viel: Es kommt schlicht auf die Anwendung an, ob die Umgebungsvariablen bzw. bei Win auch noch der IE-Proxy genutzt werden. Durchaus gibt es noch Applikationen, die nichts davon unterstützen. Manche machen es sich einfach und benutzen nur ihre eigene Proxy-Konfiguration.

Dazu gibt es noch so Programme wie Visual Studio Code, die einfach nicht sauber funktionieren wollen. Beispielsweise hat da das Installieren von Plugins durch unseren Proxy nie funktioniert, an anderen Stellen wurde der Proxy aber genutzt. Obwohl ich den Proxy da in den VS Code eigenen Einstellungen gesetzt hatte. Das ist dann schlichtweg schlampige Entwicklung, das kann dich je nach Anwendung durchaus auch treffen. Müsste es bei VS Code mal wieder testen, der letzte Versuch war irgendwann Anfang des Jahres.

Docker nutzt die HTTP(S)_PROXY Variable auch nicht. Das hat aber weniger mit Schlamperei als viel mehr mit der Struktur zutun: Technisch ist das eine Client-Server Anwendung, bestehend aus dem Daemon und CLI-Client. Wenn du den Proxy setzt, kann deine Docker CLI darauf zugreifen. Aber bei einem docker pull nginx lädt eben nicht der Client dieses Image herunter, sondern leitet das an den Server weiter. Dieser läuft als Dienst, daher musst du hier den Proxy entweder im Server-Dienst (Systemd) oder der JSON Konfigurationsdatei hinterlegen.

Letztendlich sollte dir aber klar sein: So ganz trivial ist es im Alltag nicht, den kompletten Traffic durch einen Proxy zu leiten. Vor allem dann, wenn dieser Proxy den Datenverkehr noch aufbricht (MITM). Spätestens bei TLS bringt so was immer wieder Probleme. Es reicht schon wenn Programme mit Checksummen arbeiten (was ja prinzipiell auch sinnvoll ist, sowohl hinsichtlich Sicherheiet als auch irgendwelchen Transportfehlern, die zu korrupten Daten führen). Sobald das der Fall ist, kannst du nicht nur überall den Proxy hinterlegen, sondern auch gleich euer Zertifikat.

Und dann wirst du immer noch Ausnahmefälle haben, wo das eben nicht funktioniert/vorgesehen ist. Als schneller Workaround hilft dann bestenfalls das komplette Deaktivieren der Zertifikatsverifizierung. Gibt auch Kollegen, die sich den Stress gar nicht erst machen und das pauschal erst mal abschalten. Ist natürlich sicherheitstechnisch ein Fiasko und macht die Transportverschlüsselung auch erheblich zunichte, wenn aufgrund des eigenen MITM Zertifikatsfehler als Normal angesehen werden und keiner mehr darüber nachdenkt. Wenn es bei dir ohnehin schon eng wird, würde ich zumindest von so MITM-Geschichten nach Möglichkeit die Finger lassen.

Lokale Repos/Mirrors

Ein anderer Ansatz wäre, dass du lokale Repositorys aufbaust, die so was wie Pakete oder Images cachen. Das kommt beispielsweise bei Docker in Frage, den Linux-Paketmanagern oder auch NPM, NuGet & co. Am Beispiel von Docker hast du einen Server, der Docker-Images aus dem Netz laden darf. Alle anderen Clients gehen nicht direkt ins Internet, sondern greifen auf diesen Mirror-Server zu. Der kann sich häufig genutzte Images (z.B. Nginx, Apache etc) im Cache vorhalten. Wenn also 5 Leute das Image laden, wird es nur 1x aus dem Internet gezogen.

Die Adresse von dem Server muss natürlich in NO_PROXY wieder bedacht werden, wenn du für andere Programme die Proxy-Variablen dennoch setzt. Aber das hat bei größeren Umgebungen bzw. schlechten Internet-Leitungen den Performance-Vorteil und für dich als Admin hast du damit die Möglichkeit, Docker-Images einigermaßen zu kontrollieren. Das fängt bei Lizenz-Scans an und hört bei Schwachstellen-Prüfungen auf. So toll Docker auch ist, muss man immer bedenken: Wenn der Author ein neues Image pusht, kann das in eurer Umgebung mit Root-Rechten laufen.

Ist keine direkte Lösung für dein Problem und gerade wenn es zeitlich eng wird auch nicht unbedingt sinnvoll sofort umzusetzen. Aber je nachdem wie eure Umgebung so aussieht, ob du da nach dem Projekt auch weiter arbeiten wirst, wäre das für später eine Überlegung wert.