SOCKS

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche
Dieser Artikel befasst sich mit dem Internet-Proxy-Protokoll. Für den gleichnamigen Kater siehe Socks.

Das SOCKS-Protokoll ist ein Internet-Protokoll, das Client-Server-Anwendungen erlaubt, protokollunabhängig und transparent die Dienste eines Proxyservers zu nutzen. SOCKS ist eine Abkürzung für „SOCKetS“.

Clients hinter einer Firewall, die eine Verbindung zu einem externen Server aufbauen wollen, verbinden sich stattdessen zu einem SOCKS-Proxy. Dieser Proxyserver überprüft die Berechtigung des Clients, den externen Server zu kontaktieren, und leitet die Anfrage an den Server weiter.

Das SOCKS-Protokoll wurde ursprünglich von NEC entwickelt (SOCKS 4). Die aktuelle Version 5 des Protokolls, wie beschrieben in RFC 1928, erweitert die vorherigen Versionen um Unterstützung für UDP, Authentifizierung, Namensauflösung am SOCKS-Server und IPv6.

Im TCP/IP Modell ist es eine Zwischenschicht zwischen der Anwendungsschicht und der Transportschicht.

Das SOCKS-4-Protokoll[Bearbeiten]

Eine typische SOCKS-4-Verbindungsanfrage sieht wie folgt aus (jede Nummer ist ein Byte):

Client: 4 1 0 80 66 102 7 99 0

(4 ist die SOCKS-Version, 1 ist die Verbindungsanfrage, 0 80 ist der Port, 66 102 7 99 die IP-Adresse, zu der sich der Client verbinden möchte, 0 wenn kein Benutzername verwendet wird)

Server: 0 90 0 80 66 102 7 99

(0 90 bedeutet, dass die Anfrage angenommen wurde, 0 80 ist der Port, 66 102 7 99 die IP-Adresse, zu der die Verbindung aufgebaut wurde)

Danach werden alle Daten, die der Client an den SOCKS-Proxy schickt, an 66.102.7.99 weitergeleitet. Umgekehrt werden alle Daten von 66.102.7.99 an den SOCKS-Proxy gesendet, welcher sie an den Client weiterleitet.

Das SOCKS-5-Protokoll[Bearbeiten]

Auswahl der Authentifizierung[Bearbeiten]

Anders als bei SOCKS 4 wird vor der eigentlichen Verbindungsanfrage eine „version identifier/method selection message“ gesendet. Diese Nachricht enthält verschiedene Authentifizierungsmethoden, die der Client akzeptiert und von denen sich der Server eine zur Verwendung aussucht. Dies sieht so aus (die Zahlen geben die Anzahl der Bytes an):

VER NMETHODS METHODS
1 1 1 to 255

VER wird auf die Version, also 0x05, gesetzt.
NMETHODS gibt die Anzahl der vorgeschlagenen Authentifizierungsmethoden an.
METHODS sind dann schließlich die vorgeschlagenen Authentifizierungsmethoden. Es gibt folgende Möglichkeiten:

Byte Bedeutung Erklärung
0x00 NO AUTHENTICATION REQUIRED Keine Authentifizierung benötigt
0x01 GSSAPI GSSAPI, siehe RFC 2743. Genutzt u. a. von Kerberos.
0x02 USERNAME/PASSWORD Authentifizierung mit Benutzername und Passwort
0x03 bis 0x7F IANA ASSIGNED Werden von der IANA vergeben
0x80 bis 0xFE RESERVED FOR PRIVATE METHODS Für nicht öffentliche Methoden reserviert
0xFF NO ACCEPTABLE METHODS Keine akzeptable Methode

Der Server akzeptiert daraufhin eine der vorgeschlagenen Authentifizierungsmethoden:

VER METHOD
1 1

VER ist die Version, also wieder 0x05.
METHOD ist die akzeptierte und damit verwendete Methode. 0xFF bedeutet: Keine Methode ist akzeptabel und der Client muss die Verbindung trennen.

Die Verbindungsanfrage[Bearbeiten]

Sie sieht bei SOCKS5 so aus:

VER CMD RSV ATYP DST.ADDR DST.PORT
1 1 X'00' 1 Variable 2

VER ist wieder die Version, 0x05.
CMD ist der Befehl, den der Server ausführen soll:

  • 0x01: Eine TCP-Verbindung aufbauen
  • 0x02: Eine TCP-Verbindung entgegennehmen, d. h. einen Server öffnen.
  • 0x03: Eine UDP-Weiterleitung einrichten

RSV ist reserviert und muss 0x00 sein.
ATYP ist der Typ der Zieladresse:

  • 0x01 für eine IPv4-Adresse
  • 0x03 für einen Domainnamen
  • 0x04 für eine IPv6-Adresse

DST.ADDR ist die Zieladresse.

  • 4 Bytes bei ATYP 0x01
  • 1 Byte + Länge der Domain in Bytes (erstes Byte stellt die Länge der Domain dar) bei ATYP 0x03
  • 16 Bytes bei ATYP 0x04

DST.PORT ist der Zielport.

  • Umrechnung der Portnummer in Zahlenbasis 256
  • Erstes Byte = Portnummer / 256 (abrunden auf ganze Zahl (Highbyte))
  • Zweites Byte = Portnummer modulo 256 (Lowbyte)

Die Antwort des Servers sieht genauso aus. Der einzige Unterschied ist, dass CMD in REP (reply), d. h. Antwort, umbenannt wird. Folgende Werte sind für REP erlaubt:

Byte Bedeutung Erklärung
0x00 succeeded Verbindung erfolgreich hergestellt
0x01 general SOCKS server failure Serverfehler
0x02 connection not allowed by ruleset Verbindung wegen der Serverkonfiguration nicht erlaubt.
0x03 Network unreachable Das Zielnetzwerk ist nicht erreichbar
0x04 Host unreachable Der Zielhost ist nicht erreichbar
0x05 Connection refused Verbindung abgelehnt
0x06 TTL expired Zielrechner zu weit entfernt
0x07 Command not supported CMD der Anfrage wird nicht unterstützt
0x08 Address type not supported ATYP der Anfrage wird nicht unterstützt
0x09 bis 0xFF unassigned Nicht vergeben

SOCKS-Server[Bearbeiten]

Liste von SOCKS-Servern:

SOCKS-Clients/SOCKS-Wrapper[Bearbeiten]

Es existieren Programme, die es anderen Programmen ermöglichen, externe Netzwerke über SOCKS zu erreichen, ohne dass sie spezielle Unterstützung dafür mitbringen müssen:

Liste von SOCKS-Clients:

Spezifikationen[Bearbeiten]

  • RFC 3089 – Ein SOCKS-basierender IPv4/IPv6-Gateway-Mechanismus
  • RFC 1961 – GSS-API-Authentifizierungsmethode für SOCKS V5
  • RFC 1929 – Benutzername/Passwort-Authentifizierung für SOCKS V5
  • RFC 1928 – SOCKS-Protokoll Version 5