Ein universelles Proxy-Protokoll für TCP und UDP, mit dem interne Hosts sicher über die Firewall kommen und dabei ihre Benutzer authentifizieren - diese Identity-Management-Aufgabe erfüllt das Socks-Protokoll. Der Artikel stellt das Protokoll und eine Implementierung vor.
Während viele Firewall-Admins den direkten Webzugang vom internen ins externe Netz erlauben, sind sie bei anderen Diensten wie FTP oder SMTP restriktiver. Ihr gutes Argument: Eine Firewall muss übersichtlich und leicht kontrollierbar sein, daher dürfen die Regeln nur wenige Dienste und Ports durchlassen. Noch mehr Kontrolle erlauben Application Level Gateways: Diese ALGs sind meist als Proxy implementiert (Abbildung 1a). Allerdings braucht jeder Dienst seinen eigenen Proxy.
Einen Mittelweg zwischen Stateful-Paketfilter und ALG beschreitet das Socks-Protokoll ([2], RFC 1928, Abbildung 1b). Implementiert ist es zum Beispiel im Dante-Paket[1]. Mit der generischen Socks-Proxy-Technik behält die Firewall die Kontrolle über jede Applikation, sie trennt die Netze auf Transportebene und stellt den Clients einen festen Anfrage-Port bereit (meist 1080).
Im Socks-Request teilt der Client dem Proxy den gewünschten Zielserver und Dienst mit (etwa HTTP, SMTP oder FTP). Der Socks-Proxy (auch Socks-Server genannt) authentifiziert den Client und autorisiert seinen Zugriff, baut stellvertretend die Verbindung zum Zielserver auf und reicht alle Sende- und Empfangsdaten durch.
Üblicherweise müssen die Client-Applikationen Socks-Support integriert haben, um den Proxy zu nutzen, da Socks in den Protokollablauf eingreift. Es funktioniert aber auch mit einem Wrapper, der mit »LD_PRELOAD«-Technik in fertig kompilierte Programme die Socks-Unterstützung nachträglich einfügt. Der Wrapper implementiert dazu eine angepasste Socket-Bibliothek.
Der Kunstname Socks leitet sich von Socket ab, der ursprüngliche Arbeitsname lautete SOCK-et-S. Es existieren zwei Hauptversionen: Socks v4 und v5. Beide Protokolle schieben sich im OSI-Modell zwischen Transport- und Anwendungsschicht. Version 4 beschränkt sich darauf, Verbindungsanfragen zu verarbeiten, Proxy-Regeln umzusetzen und Anwendungsdaten weiterzureichen. Sie verzichtet auf jede Authentifizierung und funktioniert ausschließlich über TCP. Socks 5 ergänzt starke Authentifikationsmechanismen sowie den Umgang mit UDP.
In einem typischen Socks-Szenario will der Client zum Beispiel den HTTP-Dienst eines Servers im externen Netz nutzen. Der Ablauf ist in Abbildung 2 dargestellt, das Datenformat in Abbildung 3 und der Inhalt der Felder in Tabelle 1. Zunächst öffnet der Client eine TCP-Verbindung zum Socks-Proxy, per Default auf Port 1080. Im Negotiation-Paket schlägt er einige Authentifikationsmethoden vor; deren Anzahl steht in »NMETHODS«, die Methoden im Feld »METHODS«.
Akzeptiert der Proxy diese Anfrage (Schritt 2 in Abbildung 2), dann teilt er dem Client per Server-Negotiation-Paket die gewünschte Authentifizierungsmethode mit (»METHODS« mit genau einem Eintrag). Anschließend authentifiziert sich der Client (Schritt 3). Der genaue Ablauf in diesem Schritt hängt von der gewählten Methode ab.
Der Client teilt danach dem Proxy in einer Request-Nachricht mit, welchen Dienst er in Anspruch nehmen will (die Zieladresse in »DST.ADDR« und den Zielport in »DST.PORT«). Der Socks-Proxy evaluiert diese Anfrage anhand der Identität des Clients sowie der Zieladresse, dabei berücksichtigt er Firewall-typisch eine Zugriffskontrollliste. Bei verbotenen Zugriffen bricht der Socks-Proxy die Verbindung zum Client ab. Andernfalls antwortet er mit einem oder mehreren Server-Reply-Paketen.
Socks-Anfragen und -Antworten können Adressen verschiedenen Typs enthalten. Das Protokoll erlaubt IPv4- und IPv6-Nummern ebenso wie Domain-Namen. Letztere befreien den Client davon, DNS-Anfragen stellen zu müssen. Je nach Art des Client-Request, also abhängig vom »CMD«-Wert (siehe Abbildung 2 und Tabelle 1), sind die Adressenangaben in der Socks-Server-Antwort verschieden zu verstehen. In der Antwort auf ein »CONNECT« enthalten »BND.PORT« und »BND.ADDR« die Socks-Server-Adresse, von der aus der Proxy den Zielserver erreicht hat.
Die »BND.ADDR«-Adresse wird sich in der Regel von der Adresse des Socks-Servers unterscheiden, an die sich der Client gewandt hat. Diese Konstellation ist unter dem Namen Muli Homed Socks Server bekannt und typisch für eine Socks-Firewall, die zwei Netze verbindet. Nach einem erfolgreichen Connect-Kommando kommunizieren Client und Zielserver transparent über den Proxy; Socks leitet alle Daten weiter.
Abbildung 1a: Ist sie als Application Level Gateway implementiert, trennt die Firewall internes und externes Netz auf Applikationsebene. Allerdings braucht sie für jedes Protokoll einen eigenen Proxy.
Abbildung 1b: Anders als ein ALG arbeitet Socks als generischer Proxy. Er nimmt auf Port 1080 Verbindungen für beliebige Applikationsprotokolle entgegen, authentifiziert den Client und autorisiert den Transfer.
Alle Rezensionen aus dem Linux-Magazin
Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...
