iptables --uid-owner trifft Squids lokale Sockets, nicht LAN-Benutzer
Nutze die Bedeutung von --uid-owner als Ersteller lokaler Sockets, wenn du Squids ausgehenden Datenverkehr beurteilst, und halte weitergeleitete LAN-Pakete getrennt.
Der owner-Match von iptables kann Pakete identifizieren, die von einem lokalen Prozess-Socket erzeugt wurden. Beispielsweise bezieht sich -m owner --uid-owner 1234 auf einen lokalen Socket im Besitz von UID 1234; es identifiziert keinen HTTP-Proxy-Benutzernamen.
Auf einem Rechner mit Squid sind diese Pfade zu unterscheiden:
| Datenverkehr | Relevante Unterscheidung |
|---|---|
| Ein Client verbindet sich mit Squid auf diesem Rechner | Eingehende Verbindung zum Proxy-Listener |
| Squid öffnet eine Zielverbindung | Lokal erzeugter ausgehender Socket |
| Ein LAN-Client leitet direkt über diesen Rechner | Weitergeleiteter Datenverkehr ohne lokal erzeugenden Socket |
Die Erweiterung ist in OUTPUT und POSTROUTING gültig. Weitergeleitete Pakete haben für diesen Match keinen zugehörigen lokalen Socket, daher kann eine FORWARD-Regel den Benutzer des entfernten Rechners nicht ermitteln, indem sie nach Squids UID fragt.
Eine Richtlinie, die Squids eigene ausgehende Sockets erlaubt, deckt also nur einen Teil eines Netzwerkentwurfs ab, der allein auf einem Proxy beruht. Gateway-Weiterleitung, Listener-Zugriff, weitere erlaubte Dienste und das tatsächliche Proxy-Dienstkonto müssen im jeweils passenden Bereich behandelt werden.
Verwende die konfigurierte Laufzeitidentität, statt anzunehmen, Squid liefe als nobody. Mehrere Prozesse können eine UID teilen, daher ist eine UID-basierte Freigabe eine Kontogrenze und kein Beweis dafür, dass ein bestimmtes Programm jede erlaubte Verbindung aufgebaut hat.