„SOCKS“ – Versionsunterschied
[ungesichtete Version] | [gesichtete Version] |
Keine Bearbeitungszusammenfassung |
|||
(115 dazwischenliegende Versionen von 95 Benutzern werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
{{Dieser Artikel|behandelt das Internet-Protokoll. Zu weiteren Bedeutungen siehe [[Socks]].}} |
|||
Das '''SOCKS Protokoll''' ist ein [[Internet]]-[[Proxy]]-[[Protokoll]], das [[Client-Server-System|Client-Server-Anwendungen]] erlaubt, transparent die Dienste einer [[Firewall]] zu nutzen. SOCKS ist eine Abkürzung für "[[Socket|SOCKetS]]". |
|||
Das '''SOCKS-Protokoll''' ist ein [[Internet]]-[[Netzwerkprotokoll|Protokoll]], das [[Client-Server-System|Client-Server-Anwendungen]] erlaubt, protokollunabhängig und transparent die Dienste eines [[Proxy (Rechnernetz)|Proxyservers]] zu nutzen. SOCKS ist eine Abkürzung für „[[Socket (Software)|SOCKetS]]“. |
|||
[[Clients]] hinter einer Firewall, die eine Verbindung zu einem externen [[Server]] aufbauen wollen, verbinden stattdessen zu einem SOCKS-Proxy. Dieser Proxy-Server überprüft die Berechtigung des Clients, den externen Server zu kontaktieren und leitet die Anfrage an den Server weiter. |
|||
[[Client]]s 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 Corporation|NEC]] entwickelt (SOCKS 4). Die aktuelle Version 5 des Protokolls, wie beschrieben in RFC 1928, erweitert die vorherigen Versionen um Unterstützung für [[User Datagram Protocol|UDP]], [[Authentifizierung]] und [[IPv6]]. |
|||
Das SOCKS-Protokoll wurde ursprünglich von [[NEC Corporation|NEC]] entwickelt (SOCKS-4). Die aktuelle Version 5 des Protokolls, wie beschrieben in <nowiki>RFC 1928</nowiki>,<ref>{{RFC-Internet |RFC=1928 |Titel=SOCKS-Protokoll Version 5 |Datum=}}</ref> erweitert die vorherigen Versionen um Unterstützung für [[User Datagram Protocol|UDP]], [[Authentifizierung]], Namensauflösung am SOCKS-Server und [[IPv6]]. |
|||
Im [[OSI-Modell|OSI-Schichtmodell]] ist es eine Zwischenschicht zwischen der Anwendungsschicht und der Transportschicht. |
|||
Im [[Internetprotokollfamilie#TCP/IP-Referenzmodell|TCP/IP-Modell]] ist es eine Zwischenschicht zwischen der Anwendungsschicht und der Transportschicht. |
|||
== Das SOCKS 4 Protokoll == |
|||
== Das SOCKS-4-Protokoll == |
|||
Eine typische SOCKS 4-Verbindungsanfrage sieht wie folgt aus (Jede Nummer ist ein [[Byte]]): |
|||
=== Anfrage === |
|||
Client: 4 1 0 80 66 102 7 99 |
|||
Eine typische SOCKS-4 Verbindung baut sich, via [[Transmission Control Protocol|TCP]], wie folgt auf: |
|||
Der Client verbindet sich zum Server und sendet solch ein Paket: |
|||
{| class="wikitable" |
|||
|- |
|||
! Länge |
|||
! Beschreibung |
|||
|- |
|||
| 1 Byte |
|||
| Version (für SOCKS4: <code>0x04</code>) |
|||
|- |
|||
| 1 Byte |
|||
| Befehl: |
|||
* <code>0x01</code> = neue [[Transmission Control Protocol/Internet Protocol|TCP/IP]]-Verbindung |
|||
* <code>0x02</code> = bindet einen Port |
|||
|- |
|||
| 2 Bytes |
|||
| Portnummer |
|||
|- |
|||
| 4 Bytes |
|||
| [[IPv4]]-Adresse |
|||
|- |
|||
| unbestimmt |
|||
| User-ID (optional; wenn keine Authentifizierung notwendig, diesen Abschnitt überspringen) |
|||
|- |
|||
| 1 Byte |
|||
| Abschluss mit Null-Byte (<code>0x00</code>) |
|||
|} |
|||
=== Antwort === |
|||
(4 ist die SOCKS-Version, 1 ist die Verbindungsanfrage, 0 80 ist der [[Port (Protokoll)|Port]], 66 102 7 99 die [[IP-Adresse]], zu der der Client verbinden möchte) |
|||
{| class="wikitable" |
|||
|- |
|||
! Länge |
|||
! Beschreibung |
|||
|- |
|||
| 1 Byte |
|||
| Null-Byte (<code>0x00</code>) |
|||
|- |
|||
| 1 Byte |
|||
| Antwortcode: |
|||
* <code>0x5A</code> = Anfrage bewilligt |
|||
* <code>0x5B</code> = Anfrage abgelehnt oder fehlgeschlagen |
|||
* <code>0x5C</code> = Anfrage fehlgeschlagen, da der Client nicht <code>identd</code> ausführt (oder nicht vom Server erreichbar ist) |
|||
* <code>0x5D</code> = Anfrage fehlgeschlagen, da <code>identd</code> die ID nicht bestätigen konnte |
|||
|- |
|||
| 2 Byte |
|||
| Beliebige Daten. |
|||
|- |
|||
| 4 Byte |
|||
| Beliebige Daten. |
|||
|} |
|||
=== Beispiel === |
|||
Server: 0 90 0 80 66 102 7 99 |
|||
Fred möchte sich via SOCKS4 zu der IP <code>66.102.7.99</code> auf Port 80 verbinden. Dafür verbindet er sich via TCP zu dem SOCKS4-Proxy seiner Wahl und sendet folgende Anfrage: |
|||
{| class="wikitable" |
|||
|- |
|||
! Version |
|||
! Kommando |
|||
! Portnummer |
|||
! Adresse |
|||
! User-ID |
|||
! Abschluss |
|||
|- |
|||
| <code>0x04</code> |
|||
| <code>0x01</code> |
|||
| <code>0x00 0x50</code> |
|||
| <code>0x42 0x66 0x07 0x63</code> |
|||
| <code>0x46 0x72 0x65 0x64</code> |
|||
| <code>0x00</code> |
|||
|} |
|||
Bei der User-ID ist "Fred" als Zeichenfolge in [[American Standard Code for Information Interchange|ASCII]] formatiert. |
|||
(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) |
|||
Darauf antwortet der Server mit "OK": |
|||
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. |
|||
{| class="wikitable" |
|||
|- |
|||
! Null-Byte |
|||
! Antwortcode |
|||
! Beliebige Daten |
|||
! Beliebige Daten |
|||
|- |
|||
| <code>0x00</code> |
|||
| <code>0x5A</code> |
|||
| <code>0xXX</code> |
|||
| <code>0xXX</code> |
|||
|} |
|||
<code>0xXX</code> ist hier ein Platzhalter für je ein beliebiges Byte. |
|||
== Das SOCKS 5 Protokoll == |
|||
=== Auswahl der Authentifizierung === |
|||
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) |
|||
Von da an werden alle Daten, die der Client (Fred) an den SOCKS-Proxy schickt, an <code>66.102.7.99</code> weitergeleitet und umgekehrt. |
|||
+----+----------+----------+ |
|||
|VER | NMETHODS | METHODS | |
|||
+----+----------+----------+ |
|||
| 1 | 1 | 1 to 255 | |
|||
+----+----------+----------+ |
|||
== Das SOCKS-5-Protokoll == |
|||
VER wird auf die Version, also 0x05, gesetzt. |
|||
SOCKS-5 unterscheidet sich von SOCKS-4 vor allem durch bessere Authentifizierung, UDP und IPv6-Unterstützung. |
|||
NMETHODS gibt die Anzahl der vorgeschlagenen Authentifizierungsmethoden an. |
|||
METHODS sind dann schließlich die vorgeschlagenen Authentifizierungsmethoden. Es gibt folgende Möglichkeiten: |
|||
Der Aufbau funktioniert nun so: |
|||
{| border="1" |
|||
!Byte |
|||
# Der Client verbindet sich zum Server und begrüßt ihn mit Authentifizierungsmethoden, die er selbst unterstützt. |
|||
!Bedeutung |
|||
# Der Server antwortet mit einer von den vom Client gesendeten Methoden. |
|||
!Erklärung |
|||
# Abhängig von der Methode kann eine Reihe von Paketen versendet werden. |
|||
# Der Client sendet eine Verbindungsanfrage ähnlich wie bei SOCKS-4 |
|||
# Der Server antwortet ähnlich wie bei SOCKS-4 |
|||
{| class="wikitable" |
|||
|+ Authentifizierungsmethoden |
|||
|- |
|- |
||
! Byte |
|||
|0x00 |
|||
! Name |
|||
|NO AUTHENTICATION REQUIRED |
|||
! Erklärung |
|||
|Keine Authentifizierung benötigt |
|||
|- |
|- |
||
| <code>0x00</code> |
|||
|0x01 |
|||
| NO AUTHENTICATION REQUIRED |
|||
|GSSAPI |
|||
| Keine Authentifizierung benötigt |
|||
|GSSAPI, siehe RFC 2743. Genutzt u. a. von Kerberos. |
|||
|- |
|- |
||
| <code>0x01</code> |
|||
|0x02 |
|||
| [[GSSAPI]] |
|||
|USERNAME/PASSWORD |
|||
| GSSAPI, siehe <nowiki>RFC 2743</nowiki>.<ref>{{RFC-Internet |RFC=2743 |Titel=Generic Security Service Application Program Interface Version 2, Update 1 |Datum=2000}}</ref> Genutzt u. a. von [[Kerberos (Protokoll)|Kerberos]]. |
|||
|Authentifizierung mit Benutzername und Password |
|||
|- |
|- |
||
| <code>0x02</code> |
|||
|0x03 bis 0x7F |
|||
| USERNAME/PASSWORD |
|||
|IANA ASSIGNED |
|||
| Authentifizierung mit Benutzername und Passwort, siehe <nowiki>RFC 1929</nowiki><ref>{{RFC-Internet |RFC=1929 |Titel=Benutzername/Passwort-Authentifizierung für SOCKS V5 |Datum=}}</ref> |
|||
|Werden von der [[Internet Assigned Numbers Authority|IANA]] vergeben |
|||
|- |
|- |
||
| <code>0x03</code> bis <code>0x7F</code> |
|||
|0x80 bis 0xFE |
|||
| IANA ASSIGNED |
|||
|RESERVED FOR PRIVATE METHODS |
|||
| Werden von der [[Internet Assigned Numbers Authority|IANA]] vergeben |
|||
|Für nicht öffentliche Methoden reserviert |
|||
|- |
|- |
||
| <code>0x80</code> bis <code>0xFE</code> |
|||
|0xFF |
|||
| |
| RESERVED FOR PRIVATE METHODS |
||
| Für nicht öffentliche Methoden reserviert |
|||
|Keine akzeptable Methode |
|||
|- |
|||
| <code>0xFF</code> |
|||
| NO ACCEPTABLE METHODS |
|||
| Keine akzeptable Methode |
|||
|} |
|} |
||
Der |
Der Client sendet als erstes seine Authentifizierungsmethoden: |
||
{| class="wikitable" |
|||
+----+--------+ |
|||
|- |
|||
|VER | METHOD | |
|||
! Länge |
|||
+----+--------+ |
|||
! Beschreibung |
|||
| 1 | 1 | |
|||
|- |
|||
+----+--------+ |
|||
| 1 Byte |
|||
| Version (für SOCKS-5: <code>0x05</code>) |
|||
|- |
|||
| 1 Byte |
|||
| Anzahl <math>n</math> der unterstützten Authentifizierungsmethoden |
|||
|- |
|||
| <math>n</math> Bytes |
|||
| Byte-Werte der unter 'Authentifizierungsmethoden' genannten Methoden, ein Byte pro Methode |
|||
|} |
|||
Der Server gibt die Auswahl der Methode bekannt |
|||
VER ist die Version, also wieder 0x05 |
|||
METHOD ist die akzeptierte und damit verwendete Methode. 0xFF bedeutet: Keine Methode akzeptabel und der Client muss die Verbindung trennen. |
|||
{| class="wikitable" |
|||
|- |
|||
! Länge |
|||
! Beschreibung |
|||
|- |
|||
| 1 Byte |
|||
| Version (<code>0x05</code>) |
|||
|- |
|||
| 1 Byte |
|||
| Byte-Wert der Authentifizierungsmethode; <code>0xFF</code>, wenn keine akzeptable Methode gefunden. |
|||
|} |
|||
=== Die Verbindungsanfrage === |
=== Die Verbindungsanfrage === |
||
Sie sieht bei SOCKS5 so aus: |
|||
So sieht die Verbindungsanfrage bei SOCKS-5 aus: |
|||
+----+-----+-------+------+----------+----------+ |
|||
|VER | CMD | RSV | ATYP | DST.ADDR | DST.PORT | |
|||
+----+-----+-------+------+----------+----------+ |
|||
| 1 | 1 | X'00' | 1 | Variable | 2 | |
|||
+----+-----+-------+------+----------+----------+ |
|||
{| class="wikitable" |
|||
VER ist wieder die Version, 0x05.<br/> |
|||
|- |
|||
CMD ist der Befehl den der Server ausführen soll: |
|||
! Länge |
|||
* 0x01 Eine [[Transmission Control Protocol|TCP]]-Verbindung aufbauen |
|||
! Beschreibung |
|||
* 0x02 Eine [[Transmission Control Protocol|TCP]]-Verbindung entgegennehmen, d. h. einen Server aufmachen. |
|||
|- |
|||
* 0x03 Eine [[User Datagram Protocol|UDP]]-Weiterleitung einrichten |
|||
| 1 Byte |
|||
RSV ist reserviert und muss 0x00 sein.<br/> |
|||
| Version (für SOCKS-5: <code>0x05</code>) |
|||
ATYP ist der Typ der Zieladresse: |
|||
|- |
|||
* 0x01 für eine IP V4 Adresse |
|||
| 1 Byte |
|||
* 0x03 für einen Domainnamen |
|||
| Befehl: |
|||
* 0x04 für eine IP V6 Adresse |
|||
* <code>0x01</code>: Eine [[Transmission Control Protocol|TCP]]-Verbindung aufbauen |
|||
DST.ADDR ist die Zieladresse.<br/> |
|||
* <code>0x02</code>: Eine [[Transmission Control Protocol|TCP]]-Verbindung entgegennehmen, d. h. einen Server öffnen. |
|||
DST.PORT ist der Zielport. |
|||
* <code>0x03</code>: Eine [[User Datagram Protocol|UDP]]-Weiterleitung einrichten |
|||
|- |
|||
| 1 Byte |
|||
| Reserviert: Muss <code>0x00</code> sein |
|||
|- |
|||
| 1 Byte |
|||
| Adress-Typ (Typ der Zieladresse): |
|||
* <code>0x01</code>: IPv4-Adresse |
|||
* <code>0x03</code>: Domainname |
|||
* <code>0x04</code>: IPv6-Adresse |
|||
|- |
|||
| |
|||
| Abhängig vom gewählten Adress-Typ: |
|||
* IPv4: 4 Bytes |
|||
* Domainname: 1 Byte (Länge der Domain) + Domain |
|||
* IPv6: 16 Bytes |
|||
|- |
|||
| 2 Byte |
|||
| Port in [[Byte-Reihenfolge]] Big-Endian |
|||
|} |
|||
Die Serverantwort sieht so aus: |
|||
Die Antwort des Servers sieht genau so aus. Der einzige Unterschied ist, dass CMD in REP, d. h. Antwort, umbenannt wird. Folgende Werte sind für REP erlaubt: |
|||
{| |
{| class="wikitable" |
||
!Byte |
|||
!Bedeutung |
|||
!Erklärung |
|||
|- |
|- |
||
! Länge |
|||
|0x00 |
|||
! Beschreibung |
|||
|succeeded |
|||
|Verbindung erfolgreich hergestellt |
|||
|- |
|- |
||
| 1 Byte |
|||
|0x01 |
|||
| Version (<code>0x05</code>) |
|||
|general SOCKS server failure |
|||
|Serverfehler |
|||
|- |
|- |
||
| 1 Byte |
|||
|0x02 |
|||
| Antwortcode (siehe Tabelle ''Antwortcodes'') |
|||
|connection not allowed by ruleset |
|||
|Verbindung wegen der Serverkonfiguration nicht erlaubt. |
|||
|- |
|- |
||
| 1 Byte |
|||
|0x03 |
|||
| Reserviert: Muss <code>0x00</code> sein |
|||
|Network unreachable |
|||
|Das Zielnetzwerk ist nicht erreichbar |
|||
|- |
|- |
||
| 1 Byte |
|||
|0x04 |
|||
| Address-Typ: |
|||
|Host unreachable |
|||
* <code>0x01</code>: IPv4-Adresse |
|||
|Der Zielhost ist nicht erreichbar |
|||
* <code>0x03</code>: Domainname |
|||
* <code>0x04</code>: IPv6-Adresse |
|||
|- |
|- |
||
| |
|||
|0x05 |
|||
| Abhängig vom Adress-Typ: |
|||
|Connection refused |
|||
* IPv4: 4 Bytes |
|||
|Verbindung abgelehnt |
|||
* Domainname: 1 Byte (Länge der Domain) + Domain |
|||
* IPv6: 16 Bytes |
|||
|- |
|- |
||
| 2 Byte |
|||
|0x06 |
|||
| Port in [[Byte-Reihenfolge]] Big-Endian |
|||
|[[Time-to-live|TTL]] expired |
|||
|} |
|||
|Zielrechner zu weit entfernt |
|||
{| class="wikitable" |
|||
|+ Antwortcodes |
|||
|- |
|- |
||
! Byte |
|||
|0x07 |
|||
! Name |
|||
|Command not supported |
|||
! Erklärung |
|||
|CMD der Anfrage wird nicht unterstützt |
|||
|- |
|- |
||
| <code>0x00</code> |
|||
|0x08 |
|||
| succeeded |
|||
|Address type not supported |
|||
| Verbindung erfolgreich hergestellt |
|||
|ATYP der Anfrage wird nicht unterstützt |
|||
|- |
|- |
||
| <code>0x01</code> |
|||
|0x09 bis 0xFF |
|||
| general SOCKS server failure |
|||
|unassigned |
|||
| Serverfehler |
|||
|Nicht vergeben |
|||
|- |
|||
| <code>0x02</code> |
|||
| connection not allowed by ruleset |
|||
| Verbindung wegen der Serverkonfiguration nicht erlaubt. |
|||
|- |
|||
| <code>0x03</code> |
|||
| Network unreachable |
|||
| Das Zielnetzwerk ist nicht erreichbar |
|||
|- |
|||
| <code>0x04</code> |
|||
| Host unreachable |
|||
| Der Zielhost ist nicht erreichbar |
|||
|- |
|||
| <code>0x05</code> |
|||
| Connection refused |
|||
| Verbindung abgelehnt |
|||
|- |
|||
| <code>0x06</code> |
|||
| [[Time to Live|TTL]] expired |
|||
| Zielrechner zu weit entfernt |
|||
|- |
|||
| <code>0x07</code> |
|||
| Command not supported |
|||
| Kommando der Anfrage wird nicht unterstützt |
|||
|- |
|||
| <code>0x08</code> |
|||
| Address type not supported |
|||
| ATYP der Anfrage wird nicht unterstützt |
|||
|- |
|||
| <code>0x09</code> bis <code>0xFF</code> |
|||
|colspan="3"| Nicht vergeben |
|||
|} |
|} |
||
== SOCKS-Server == |
== SOCKS-Server == |
||
Liste von SOCKS-Servern: |
Liste von SOCKS-Servern: |
||
* [http://www.delegate.org/ Delegate universaler Proxy-Server, unter anderem Socks-Server, Open Source] |
|||
* [https://mitmproxy.org/ mitmproxy universaler Proxy-Server, unter anderem Socks-Server, Open Source] |
|||
* [http://www.inet.no/dante/ Dante Socks-Server] |
* [http://www.inet.no/dante/ Dante Socks-Server] |
||
* [http://jsocks.sourceforge.net/ Java Socks-Server] |
* [http://jsocks.sourceforge.net/ Java Socks-Server, Open Source] |
||
* [http://www.alhem.net/project/socks4/ Socks4-Server] |
* [http://www.alhem.net/project/socks4/ Socks4-Server] |
||
* [http://digilander.libero.it/matteo.ricchetti/ SS5 Socks-Server] |
|||
* [http://sourceforge.net/projects/mocks mocks] |
* [http://sourceforge.net/projects/mocks mocks] |
||
* [http:// |
* [http://www.coderslagoon.com/home.php#cutesocks CuteSocks] |
||
* [[Secure Shell|SSH als Socks-Server]] |
|||
== SOCKS-Clients == |
== SOCKS-Clients/SOCKS-Wrapper == |
||
Es existieren [[Computerprogramm|Programme]], die es anderen Programmen ermöglichen, externe [[ |
Es existieren [[Computerprogramm|Programme]], die es anderen Programmen ermöglichen, externe [[Netzwerk]]e über SOCKS zu erreichen, ohne dass sie spezielle Unterstützung dafür mitbringen müssen: |
||
Liste von SOCKS-Clients: |
Liste von SOCKS-Clients: |
||
* [http://www.inet.no/dante/ Dante client] |
* [http://www.inet.no/dante/ Dante client] |
||
* [http://www.freecap.ru/eng/ FreeCap] |
* [http://www.freecap.ru/eng/ FreeCap] |
||
* [http://www. |
* [http://www.widecap.com/ WideCap] |
||
* [https://www.opentext.com/products-and-solutions/products/specialty-technologies/connectivity/socks-client/ Open Text SOCKS Client (Nachfolger von „Hummingbird SOCKS“)] |
|||
* [http://proxylabs.netwu.com/ ProxyCap] |
* [http://proxylabs.netwu.com/ ProxyCap] |
||
* [http://www. |
* [http://www.google.com/search?hl=en&q=Sockscap&btnG=Google+Search SocksCap (Google Link)] |
||
* [http://tsocks.sourceforge.net/about.php tsocks] |
* [http://tsocks.sourceforge.net/about.php tsocks] |
||
* [http://www.dest-unreach.org/socat/ socat] |
* [http://www.dest-unreach.org/socat/ socat] |
||
* [https://github.com/darkk/redsocks/ redsocks] |
|||
* [http://proxychains.sourceforge.net/ proxychains] |
|||
* [http://www.proxifier.com/ proxifier] |
|||
* [http://code.google.com/p/badvpn/wiki/tun2socks tun2socks] |
|||
== |
== Spezifikationen == |
||
* RFC 3089 |
* {{RFC-Internet |RFC=3089 |Titel=Ein SOCKS-basierender IPv4/IPv6-Gateway-Mechanismus |Datum=}} |
||
* RFC 1961 |
* {{RFC-Internet |RFC=1961 |Titel=GSS-API-Authentifizierungsmethode für SOCKS V5 |Datum=}} |
||
* RFC 1929 |
* {{RFC-Internet |RFC=1929 |Titel=Benutzername/Passwort-Authentifizierung für SOCKS V5 |Datum=}} |
||
* RFC 1928 |
* {{RFC-Internet |RFC=1928 |Titel=SOCKS-Protokoll Version 5 |Datum=}} |
||
* http://archive.socks.permeo.com/protocol/socks4.protocol – SOCKS-Protokoll Version 4 |
|||
* http://www.socks.permeo.com/AboutSOCKS/SOCKSOverview.asp |
|||
== Einzelnachweise == |
|||
[[Kategorie:IT-Architektur]] |
|||
<references /> |
|||
[[Kategorie:Internet]] |
|||
[[Kategorie:IT-Architektur]] |
|||
[[en:SOCKS]] |
|||
[[Kategorie:Internet-Anwendungsprotokoll]] |
|||
[[it:SOCKS]] |
|||
[[ |
[[Kategorie:Abkürzung]] |
||
[[zh:SOCKS]] |
Aktuelle Version vom 14. Juni 2024, 16:15 Uhr
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,[1] 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 | Quelltext bearbeiten]Anfrage
[Bearbeiten | Quelltext bearbeiten]Eine typische SOCKS-4 Verbindung baut sich, via TCP, wie folgt auf: Der Client verbindet sich zum Server und sendet solch ein Paket:
Länge | Beschreibung |
---|---|
1 Byte | Version (für SOCKS4: 0x04 )
|
1 Byte | Befehl:
|
2 Bytes | Portnummer |
4 Bytes | IPv4-Adresse |
unbestimmt | User-ID (optional; wenn keine Authentifizierung notwendig, diesen Abschnitt überspringen) |
1 Byte | Abschluss mit Null-Byte (0x00 )
|
Antwort
[Bearbeiten | Quelltext bearbeiten]Länge | Beschreibung |
---|---|
1 Byte | Null-Byte (0x00 )
|
1 Byte | Antwortcode:
|
2 Byte | Beliebige Daten. |
4 Byte | Beliebige Daten. |
Beispiel
[Bearbeiten | Quelltext bearbeiten]Fred möchte sich via SOCKS4 zu der IP 66.102.7.99
auf Port 80 verbinden. Dafür verbindet er sich via TCP zu dem SOCKS4-Proxy seiner Wahl und sendet folgende Anfrage:
Version | Kommando | Portnummer | Adresse | User-ID | Abschluss |
---|---|---|---|---|---|
0x04
|
0x01
|
0x00 0x50
|
0x42 0x66 0x07 0x63
|
0x46 0x72 0x65 0x64
|
0x00
|
Bei der User-ID ist "Fred" als Zeichenfolge in ASCII formatiert.
Darauf antwortet der Server mit "OK":
Null-Byte | Antwortcode | Beliebige Daten | Beliebige Daten |
---|---|---|---|
0x00
|
0x5A
|
0xXX
|
0xXX
|
0xXX
ist hier ein Platzhalter für je ein beliebiges Byte.
Von da an werden alle Daten, die der Client (Fred) an den SOCKS-Proxy schickt, an 66.102.7.99
weitergeleitet und umgekehrt.
Das SOCKS-5-Protokoll
[Bearbeiten | Quelltext bearbeiten]SOCKS-5 unterscheidet sich von SOCKS-4 vor allem durch bessere Authentifizierung, UDP und IPv6-Unterstützung.
Der Aufbau funktioniert nun so:
- Der Client verbindet sich zum Server und begrüßt ihn mit Authentifizierungsmethoden, die er selbst unterstützt.
- Der Server antwortet mit einer von den vom Client gesendeten Methoden.
- Abhängig von der Methode kann eine Reihe von Paketen versendet werden.
- Der Client sendet eine Verbindungsanfrage ähnlich wie bei SOCKS-4
- Der Server antwortet ähnlich wie bei SOCKS-4
Byte | Name | Erklärung |
---|---|---|
0x00
|
NO AUTHENTICATION REQUIRED | Keine Authentifizierung benötigt |
0x01
|
GSSAPI | GSSAPI, siehe RFC 2743.[2] Genutzt u. a. von Kerberos. |
0x02
|
USERNAME/PASSWORD | Authentifizierung mit Benutzername und Passwort, siehe RFC 1929[3] |
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 Client sendet als erstes seine Authentifizierungsmethoden:
Länge | Beschreibung |
---|---|
1 Byte | Version (für SOCKS-5: 0x05 )
|
1 Byte | Anzahl der unterstützten Authentifizierungsmethoden |
Bytes | Byte-Werte der unter 'Authentifizierungsmethoden' genannten Methoden, ein Byte pro Methode |
Der Server gibt die Auswahl der Methode bekannt
Länge | Beschreibung |
---|---|
1 Byte | Version (0x05 )
|
1 Byte | Byte-Wert der Authentifizierungsmethode; 0xFF , wenn keine akzeptable Methode gefunden.
|
Die Verbindungsanfrage
[Bearbeiten | Quelltext bearbeiten]So sieht die Verbindungsanfrage bei SOCKS-5 aus:
Länge | Beschreibung |
---|---|
1 Byte | Version (für SOCKS-5: 0x05 )
|
1 Byte | Befehl: |
1 Byte | Reserviert: Muss 0x00 sein
|
1 Byte | Adress-Typ (Typ der Zieladresse):
|
Abhängig vom gewählten Adress-Typ:
| |
2 Byte | Port in Byte-Reihenfolge Big-Endian |
Die Serverantwort sieht so aus:
Länge | Beschreibung |
---|---|
1 Byte | Version (0x05 )
|
1 Byte | Antwortcode (siehe Tabelle Antwortcodes) |
1 Byte | Reserviert: Muss 0x00 sein
|
1 Byte | Address-Typ:
|
Abhängig vom Adress-Typ:
| |
2 Byte | Port in Byte-Reihenfolge Big-Endian |
Byte | Name | 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 | Kommando der Anfrage wird nicht unterstützt | |
0x08
|
Address type not supported | ATYP der Anfrage wird nicht unterstützt | |
0x09 bis 0xFF
|
Nicht vergeben |
SOCKS-Server
[Bearbeiten | Quelltext bearbeiten]Liste von SOCKS-Servern:
- Delegate universaler Proxy-Server, unter anderem Socks-Server, Open Source
- mitmproxy universaler Proxy-Server, unter anderem Socks-Server, Open Source
- Dante Socks-Server
- Java Socks-Server, Open Source
- Socks4-Server
- mocks
- CuteSocks
- SSH als Socks-Server
SOCKS-Clients/SOCKS-Wrapper
[Bearbeiten | Quelltext 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:
- Dante client
- FreeCap
- WideCap
- Open Text SOCKS Client (Nachfolger von „Hummingbird SOCKS“)
- ProxyCap
- SocksCap (Google Link)
- tsocks
- socat
- redsocks
- proxychains
- proxifier
- tun2socks
Spezifikationen
[Bearbeiten | Quelltext bearbeiten]- RFC: – Ein SOCKS-basierender IPv4/IPv6-Gateway-Mechanismus. (englisch).
- RFC: – GSS-API-Authentifizierungsmethode für SOCKS V5. (englisch).
- RFC: – Benutzername/Passwort-Authentifizierung für SOCKS V5. (englisch).
- RFC: – SOCKS-Protokoll Version 5. (englisch).