usocksd - user SOCKS daemon

usocksd ist ein SOCKS5-Server, der speziell im Hinblick auf die Situation im Wohnheimnetz und die Benutzung über ssh erstellt wurde. Im Gegensatz zu dem Standard-SOCKS-Server ist hier vorgesehen, dass jeder Benutzer seinen eigenen Serverprozess startet.

Benutzung

Achtung neu: Das Programm ist auf rzstud*, rz114*, AB-Pool als /usr/segment/bin/usocksd installiert, Manpage in /usr/segment/man/man1.

Start über ssh-usocksd

Im RZ ruft man usocksd mit dem vorgeschalteten Shellscript ~uknf/bin/ssh-usocksd auf. Dieses ermittelt sämtliche notwendigen Parameter. Als Portnummer wird die eigene UID verwendet, als Username der Username auf dem Rechner. usocksd verlangt daraufhin eine Passworteingabe. Hierzu sollte man sich ein Passwort ausdenken, das nichts mit dem Account-Passwort zu tun hat. Dieses SOCKS-Passwort muß man seinem SOCKS-Client mitteilen.

Die bevorzugte Art der Benutzung von usocksd ist also:

  ssh rzstud1 -L1080:localhost:98765 ~uknf/bin/ssh-usocksd

wobei 98765 durch die eigene UID zu ersetzen ist (mit dem Befehl id herauszufinden). Nach der Passworteingabe läßt man es einfach weiterlaufen. Das Programm beendet sich, wenn es EOF auf der Standardeingabe sieht, wenn also z.B. Control-D gedrückt oder das ssh-Fenster geschlossen wird.

ssh-usocksd ist für die Benutzung unter ssh vorgesehen, läuft aber auch beim Aufruf über telnet. Man beachte, was als SOCKS-Server zu konfigurieren ist: geht man über eine ssh-Portumlenkung, dann ist es 127.0.0.1:1080, ansonsten z.B. rzstud1 mit der beim Start von usocksd angezeigten Portnummer.

Start von usocksd direkt

Wenn dieses Script nicht funktioniert oder nicht vorhanden ist (z.B. auf Solaris, leider ist das mit HPUX soweit inkompatibel, daß es sich nicht einfach übernehmen läßt), muß man usocksd selber mit den geeigneten Parametern aufrufen. Dazu muß man sich eine Portnummer aussuchen. Ich empfehle, die eigene UID (mit dem Befehl id zu erfahren) zu verwenden; wenn das jeder tut, gibt es keine Kollisionen.

Außerdem braucht man einen Usernamen und ein Passwort. Zumindest letzeres sollte man sich ausdenken und nicht von existierenden Accounts übernehmen. usocksd prüft nicht Username und Passwort anhand des System-Passwortfiles, sondern fragt diese Parameter beim Start ab und verlangt dann von den SOCKS-Clients, genau die gleichen Parameter anzugeben. Das schützt davor, daß ein User den usocksd eines anderen Users benutzt.

Schließlich muß man noch die Adresse des eigenen Rechners wissen und in der Kommandozeile angeben. Wenn man usocksd über eine ssh-Portumlenkung betreibt, bekommt der Aufruf vom eigenen Rechner aus die folgende Form:

  ssh rzstud1 -L1080:localhost:98765     "~uknf/bin/usocksd -p98765 -Ujoe -alocalhost -u1.2.3.4

wobei "98765" durch die gewählte Portnummer zu ersetzen ist, "joe" durch den gewählten Usernamen und "1.2.3.4" durch die eigene IP-Adresse. Das Programm fragt dann nach dem Passwort. Anschließend kann man wie auf der ssh-Seite beschrieben, seinen Rechner als den eigenen SOCKS-Server benutzen.

usocksd beendet sich, wenn er - nach dem Passwort - EOF auf der Standardeingabe sieht. Bei obigem Beispiel drückt man also einfach Control-D, um ihn zu beenden. Weitere Eingaben werden ignoriert.

Eine andere Möglichkeit ist, das Passwort aus einer Datei zu lesen. Das muß dann so aussehen:

  cat ~/.sockspw - |
  ssh rzstud1 -L1080:localhost:98765     "~uknf/bin/usocksd -p98765 -Ujoe -alocaohost -u1.2.3.4

Man beachte den "dash" nach dem Dateinamen. Damit liest das cat die Standardeingabe und wartet dort auf EOF - das EOF wird dann an den usocksd weitergegeben. Sonst würde er sofort nach dem Start abbrechen, da er gleich EOF sieht.

Das alles für ein bißchen Sicherheit?

Die Frage ist falsch gestellt. Die Sicherheitsprobleme mit unverschlüsselten Verbindungen sind so enorm, daß der zusätzliche Aufwand demgegenüber kaum ins Gewicht fällt. Und immerhin gewinnt man so nahezu transparente weltweite Connectivity mitsamt Verschlüsselung.

Funktionsweise

Den Anlaß, dieses Programm zu schreiben, gab das Problem, daß mit dem regulären socksd keine UDP-Dienste funktionieren, wenn man die SOCKS-Verbindung über ssh abwickelt. Der Grund: Das SOCKS-Protokoll verlangt, daß UDP-Pakete von der gleichen IP-Adresse aus abgeschickt werden, die die SOCKS-Verbindung geöffnet hat. Letzteres tut aber der sshd, während UDP-Pakete vom eigenen Rechner kommen. ssh kann kein UDP umlenken. Daraus folgt im übrigen auch, daß UDP-Pakete nicht verschlüsselt werden.

Deswegen hat usocksd zwei Argumente für seine "Clients" auf der Kommandozeile: der -a-Parameter sagt ihm, von wo die SOCKS-Verbindungen kommen, der -u-Parameter die UDP-Pakete.

Wer Netzdienste benutzt, muß immer identifizierbar sein. Daher hat auch das SOCKS-Protokoll einen Authentikationsmechanismus mit Eingabe von Username und Passwort. usocksd erwartet einen Usernamen als -U-Argument und fragt ein Passwort von der Standardeingabe ab. Diese - im Prinzip total beliebigen - Parameter dienen dann zur Authentikation der SOCKS-Clients. Das bedeutet z.B. unter Un*x, daß man dann diese statt des echten Accountnamens und -passwortes in SOCKS5_USER, SOCKS5_PASSWD ablegt.

Das Programm verlangt die Angabe der Parameter -a, -u, -U. Würde man die weglassen, dann eröffnet man die Möglichkeit, daß andere den eigenen usocksd benutzen können und wird damit für deren Aktionen im Netz verantwortlich bzw. gibt unerlaubterweise anderen Zugriff.

Achtung Benutzer von alten Linux-Versionen

Mit einem unmodifizierten Linux 2.0.x (x<35) laufen UDP-Dienste mit der libsocks5 nicht. Der Grund ist ein Bug im Kernel, den ich während der ersten Tests von usocksd gefunden habe. Abhilfe schafft ein kleiner Patch.