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.

Verkehrte Welt

Einen »BIND«-Request setzt der Client ab, wenn er selbst eine Verbindung vom Zielserver erwartet. Diese verdrehte Konstellation ist zum Beispiel beim aktiven Modus des FTP-Protokolls üblich. Bei FTP erstellt zunächst in bester Client-Server-Tradition der Client eine Verbindung zum FTP-Server, die so genannte Kontrollverbindung. Für jede zu übermittelnde Datei öffnet aber der Server rückwärts zum Client eine eigene Datenverbindung. Der Client teilt dem Server vorher mit, an welche Adresse und welchen Port er sich wenden soll. Diese Information sendet er über den Kontrollkanal.

Socks ist in der Lage, diese Verbindungen ins interne Netz kontrolliert zu gestatten. Zunächst startet der Client mit einem normalen Connect-Request den Kontrollkanal zum Server. Danach bittet er den Socks-Proxy in einer zweiten Verbindung mit einem Bind-Request darum, einen Port für die hereinkommende Datenverbindung zu öffnen.

Der Proxy antwortet mit zwei Rückmeldungen. In die erste trägt er ein, auf welchem Port und unter welcher Adresse der Socks-Server auf die Verbindung von außen wartet. Das zweite Reply-Paket sendet der Proxy erst, wenn der Zielrechner eine Verbindung zu ihm geöffnet hat. Der Proxy trägt in dieses Antwortpaket die Quelladresse und den Quellport ein, von dem aus sich der Zielrechner mit ihm verbunden hat. Anschließend leitet er alle Daten vom externen Server zum internen Client weiter.

UDP-Relay

Soll Socks als UDP-Proxy arbeiten, dann muss sich der Client zunächst ebenfalls per TCP am Proxy melden und authentifizieren (Abbildung 4). Er verwendet als »CMD« den dritten in Tabelle 1 genannten Wert: »UDP Associate«. Da er die Pakete später tatsächlich per UDP versenden wird, muss er dem Proxy mitteilen, von wo diese Pakete kommen werden. Dazu trägt der Client sich selbst in die Felder »DST.ADDR« und »DST.PORT« als künftigen Absender ein.

Der Proxy öffnet dann einen internen UDP-Relay-Port, über den der Client Pakete nach außen senden darf. Wo sich dieses Relay befindet, erfährt der Client aus der Antwort des Servers auf die UDP-Associate-Frage nach »BND.PORT« und »BND.ADDR«. Dorthin sendet der Client UDP-Pakete, die ins externe Netz gehen sollen. Seine UDP-Pakete verpackt er in einen UDP-Request (Abbildung 3 unten). Das UDP-Relay bleib so lange aktiv, wie der Client die authentifizierte TCP-Verbindung offen hält.

Die gewählte Authentifikationsmethode kann – trotz ihres Namens – auch für Vertraulichkeit und Integrität auf dem Weg zwischen Client und Proxy sorgen. Dazu verkapselt sie die Daten eventuell. Beispielsweise bei SSL/TLS: Nach der Client-Server-Negotiation authentifiziert sich der Client über SSL/TLS. Alle weiteren Daten laufen ebenfalls SSL/TLS-gesichert, Vertraulichkeit und Integrität sind sichergestellt. Damit sind auch mobile, drahtlose Geräte sicher am Socks-Proxy zu betreiben.

Abbildung 2: Beim Verbindungsaufbau über Socks 5 beginnt der Client mit einem Negotiation-Paket an den Socks-Proxy (1). Er authentifiziert sich (3), der Proxy stellt die Verbindung mit dem Zielserver her (6) und leitet dann die Daten zwischen Client und Server weiter (8).