Abbildung 3: Die Socks-Version 5 arbeitet mit den fünf Paketarten Client Negotiation, Server Negotiation, Client Request, Server Reply und UDP-Request. Die ersten vier benutzt es über TCP, nur der fünfte Pakettyp arbeitet mit UDP. In den Feldern sind ihr Name und ihre Größe angegeben. Tabelle 1 beschreibt den Inhalt.

Abbildung 4: Für den UDP-Paketversand verbindet sich der Client zunächst über TCP mit dem Socks-Proxy. Als Client Request (4) setzt er ein UDP-Associate-Kommando ab, in dem er dem Proxy mitteilt, von wo aus er UDP-Pakete senden wird. Der Proxy antwortet mit einem Relay-Port (hier Y genannt).

01 logoutput: syslog
02 #logoutput: stdout
03 
04 internal: eth0 port = 1080
05 external: eth1
06 #internal: 10.0.0.11 port = 1080
07 #external: 192.168.23.1
08 
09 method: username
10 #method: none
11 #method: rfc931
12 #method: pam
13 
14 user.privileged: proxy
15 user.notprivileged: nobody
16 
17 client pass {
18   from: 10.0.0.3/0 port 1-65535 to: 0.0.0.0/0
19 }
20 
21 client block {
22   from: 0.0.0.0/0 to: 0.0.0.0/0
23   log: connect error
24 }
25 
26 block {
27   from: 0.0.0.0/0 to: 10.0.0.11/0
28   log: connect error
29 }
30 
31 pass {
32   from: 10.0.0.3/0 to: 10.0.0.10/0
33   user: aleitner tkuhn
34 }
35 
36 block {
37   from: 0.0.0.0/0 to: 0.0.0.0/0
38   log: connect error
39 }

Dante

Die BSD-lizenzierte Socks-Client- und -Server-Implementierung Dante[1] unterstützt Socks 4 und 5 sowie das weniger gebräuchliche MSproxy. Ende Januar 2005 ist Version 1.1.15 erschienen. Dante wird von der norwegischen Beratungsfirma Inferno Nettverk A/S entwickelt, die zusätzlich als kostenpflichtige Module Bandbreitenkontrolle und Port- sowie Umleitungsüberwachung anbietet. Für die meisten Aufgaben ist die freie Version völlig ausreichend. Sie arbeitet auch als HTTP-Proxy, implementiert Authentifizierung mit Benutzernamen und Passwort oder per Pluggable Authentication Module und erlaubt Interface-Namen in der Konfigurationsdatei, um DHCP zu unterstützen.

Nach der Installation mit dem üblichen »configure && make && make install« landet die Socks-Server-Konfigurationsdatei in »/etc/sockd.conf« (Listing 1). In Zeile 1 legt eine »logoutput«-Anweisung fest, wohin Dante protokollieren soll (Syslog oder Stdout). Die interne und die externe Netzwerkschnittstelle sind per Interface-Namen angegeben (Zeilen 4 und 5). Das hilft bei DHCP-konfigurierten Rechnern; die Zeilen 6 und 7 zeigen, dass andernfalls auch IP-Adressen genügen. Wichtig: Die interne Schnittstelle benötigt eine Portnummer.

Als Authentifikationsmethoden unterstützt Dante neben der Benutzername-Passwort-Variante (Zeile 9) auch das Ident-Verfahren nach RFC 931 (Zeile 11) und PAM. Je nach Methode braucht der Socks-Server passende Benutzerrechte. Bei Zugriffen auf die Passwortdatei wählt er den privilegierten Benutzer (laut Zeile 14: »proxy«) und begnügt sich bei normalen Aufgaben mit »nobody« (Zeile 15). Im Praxiseinsatz empfiehlt sich ein eigenes Benutzerkonto für die Socks-Software. Ein Chroot-Käfig hält sie von Systemdateien fern und verpasst ihr auf Wunsch eine eigene Passwortdatei.

Gut gefiltert

Filterregeln in der Konfigurationsdatei bestimmen, welcher Client Zugriff auf den Socks-Proxy erhält und wohin er sich verbinden darf. Die Dante-Software arbeitet Filterregeln der Reihe nach ab. Zuerst wertet sie die Regeln mit dem Präfix »client« aus und ermittelt jene Rechner, die auf den Socks-Server zugreifen dürfen (Zeilen 17 bis 24). Die »pass«-Regeln erlauben Zugriffe, während »block« sie abwehrt. Die Zeilen 17 bis 19 gestatten dem Rechner mit der IP-Adresse 10.0.0.3 jeden Zugriff, die Zeilen 21 bis 24 verweigern ihn allen anderen Rechnern. Diese Regeln gelten auf TCP/IP-Ebene, sie haben noch nichts mit dem Socks-Protokoll zu tun.

Abbildung 5: Ein Webbrowser benutzt Socks 5, um sich über den Proxy mit dem Server zu verbinden. Der Netzwerkmonitor Ethereal zerlegt diese Kommunikation in ihre Einzelteile.

Erst die zweite Filterklasse betrachtet den Inhalt der Client-Requests. Diese Regeln bestimmen, welche Anfragen der Proxy erlaubt. In Listing 1 verwirft die »block«-Anweisung in Zeile 26 bis 29 alle Anfragen von Rechnern, die auf 10.0.0.11 zugreifen wollen. Die beiden User »aleitner« und »tkuhn« dürfen von 10.0.0.3 aus Verbindungen zu 10.0.0.10 herstellen (Zeilen 31 bis 34). Alle anderen Anfragen ignoriert der Proxy.

Der Aufruf »/sbin/sockd -d« startet den Socks im Debug-Modus. Dabei schreibt der Proxy wichtige Informationen auf »logoutput«. Abbildung 5 zeigt eine typische Socks-Kommunikation im Netzwerksniffer Ethereal: Das Programm verfolgt detailliert die Kommunikation. Als Testclient eignet sich der Mozilla-Browser. Abbildung 6 zeigt die passende Konfiguration für »Preferences | Advanced | Proxies«: Unter »Manual proxy configuration« ist der Socks-Server auf 10.0.0.11 und Port 1080 festgelegt.

Lehnt der Socks-Proxy eine Verbindung wegen fehlender oder falscher Zugriffsrechte ab, bemerkt der Anwender oft nur die Folgen, ohne etwas über die Ursachen zu erfahren. Beispielsweise gibt der Mozilla-Browser bei Fehlern im zweiten Teil der Filterregeln lediglich die Meldung »The document contains no data« aus, aber keinen Hinweis darauf, dass der Proxy daran schuld ist. Dann hilft ein Blick in die Proxy-Logfiles, bei Syslog-Ausgabe zum Beispiel »/var/log/messages«.