STRUMPOR

SOCKS  är ett nätverksprotokoll på sessionsnivå av OSI-modellen , som låter dig vidarebefordra paket från en klient till en server genom en proxyserver på ett transparent sätt (osynligt för dem) och därmed använda tjänster bakom brandväggar (brandväggar) .

Den senare versionen av SOCKS5 förutsätter autentisering så att endast behöriga användare får åtkomst till servern.

Introduktion

Klienter bakom en brandvägg som behöver komma åt externa servrar kan istället kopplas till en SOCKS proxyserver . En sådan proxyserver hanterar klientens rättigheter att komma åt externa resurser och skickar klientens begäran till den externa servern. SOCKS kan också användas på motsatt sätt och kontrollerar externa klienters rättigheter att ansluta till interna servrar bakom en brandvägg .

Till skillnad från HTTP -proxies överför SOCKS all data från klienten utan att lägga till något från sig själv, det vill säga ur den slutliga serverns synvinkel är data som tas emot av den från SOCKS-proxyn identisk med den data som klienten skulle överföra direkt , utan fullmakt. SOCKS är mer allmänt, det beror inte på specifika protokoll för applikationslagret (lager 7 av OSI-modellen ) och fungerar på nivån för TCP-anslutningar (lager 4 av OSI-modellen ). Å andra sidan cachar HTTP - proxyn data och kan mer noggrant filtrera innehållet i den överförda datan.

Protokollet har utvecklats av MIPS systemadministratör David Koblas . Efter att MIPS blev en del av Silicon Graphics Corporation 1992 höll Koblas ett föredrag om SOCKS på Usenix Security Symposium och SOCKS blev allmänt tillgängliga. Den fjärde versionen av protokollet utvecklades av Ying-Da Lee från NEC .

SOCKS-servrar använder vanligtvis port 1080 [1] .

SOCKS 4-protokoll

SOCKS 4 är utformad för att fungera genom en brandvägg utan autentisering för klient-serverapplikationer som körs över TCP -protokollet , som Telnet , FTP och populära kommunikationsprotokoll som HTTP , WAIS och Gopher . I huvudsak kan en SOCKS-server ses som en brandvägg som stöder SOCKS-protokollet.

En typisk SOCKS 4-förfrågan ser ut så här:

Klientbegäran till SOCKS Server:

Storleken Beskrivning
1 byte SOCKS versionsnummer, 1 byte (bör vara 0x04 för denna version)
1 byte Kommandokod:
  • 0x01 = upprättande av en TCP/IP-anslutning
  • 0x02 = TCP/IP -porttilldelning (bindande)
2 byte Portnummer
4 bytes IP-adress
n+1 byte Användar ID. Sträng med variabel längd avslutas med en NUL-byte (0x00). Fältet är avsett att identifiera användaren (se Ident )

Serversvar på SOCKS-klienten:

Storleken Beskrivning
1 byte NUL-byte
1 byte Svarskod:
  • 0x5a = begäran beviljad
  • 0x5b = begäran nekad eller ogiltig
  • 0x5c = Begäran misslyckades eftersom identd inte körs (eller inte tillgänglig från servern)
  • 0x5d = Begäran misslyckades eftersom klient identd inte kan validera användar-id i begäran
2 byte Godtyckliga data, bör ignoreras
4 bytes Godtyckliga data, bör ignoreras

SOCKS 5 protokoll

SOCKS 5 [2] är ett inkompatibelt tillägg till SOCKS 4-protokollet. Det lägger till stöd för UDP , ger generiska starka autentiseringsscheman och utökar adresseringsmetoder, lägger till stöd för domännamn och IPv6 -adresser . Den initiala kommunikationskonfigurationen består nu av följande:

Autentiseringsmetoderna är numrerade enligt följande:

0x00 Ingen autentisering krävs
0x01 GSSAPI
0x02 RFC 1929 användarnamn/lösenord
0x03-0x7F Reserverad av IANA
0x03 KILLE
0x04 Inte upptagen
0x05 Utmaningssvar (autentisering)
0x06 SSL
0x07 NDS-autentisering
0x08 Ramverk för multifaktorautentisering
0x09 JSON-block med parametrar
0x0A–0x7F Inte upptagen
0x80-0xFE Reserverad för privata användningsmetoder

Inledande hälsning från kunden:

Storleken Beskrivning
1 byte SOCKS versionsnummer (bör vara 0x05 för denna version)
1 byte Antal autentiseringsmetoder som stöds
n byte Autentiseringsmetodnummer, variabel längd, 1 byte för varje metod som stöds

Servern rapporterar sitt val:

Storleken Beskrivning
1 byte SOCKS versionsnummer (bör vara 0x05 för denna version)
1 byte Vald autentiseringsmetod, eller 0xFF om ingen acceptabel metod erbjöds

Efterföljande identifiering beror på den valda metoden.

Kundförfrågan:

Storleken Beskrivning
1 byte SOCKS versionsnummer (bör vara 0x05 för denna version)
1 byte Kommandokod:
  • 0x01 = upprättande av en TCP/IP-anslutning
  • 0x02 = TCP/IP-porttilldelning (bindande)
  • 0x03 = UDP-portassociation
1 byte Reserverad byte, måste vara 0x00
1 byte Adresstyp:
  • 0x01 = IPv4-adress
  • 0x03 = domännamn
  • 0x04 = IPv6-adress
Beror på typ av adress Adresstilldelning:
  • 4 byte för en IPv4-adress
  • Den första byten är längden på namnet, följt av domännamnet utan den avslutande null
  • 16 byte för en IPv6-adress
2 byte Portnummer, i ordning från högt till lågt ( big-endian )

Serversvar:

Storleken Beskrivning
1 byte SOCKS versionsnummer (0x05 för denna version)
1 byte Svarskod:
  • 0x00 = begäran beviljad
  • 0x01 = SOCKS-serverfel
  • 0x02 = Anslutning nekad av regeluppsättning
  • 0x03 = nätverk inte tillgängligt
  • 0x04 = värden kan inte nås
  • 0x05 = anslutning nekad
  • 0x06 = TTL utgång
  • 0x07 = kommandot stöds inte / protokollfel
  • 0x08 = adresstyp stöds inte
1 byte Byte reserverad, måste vara 0x00
1 byte Typ av uppföljningsadress:
  • 0x01 = IPv4-adress
  • 0x03 = domännamn
  • 0x04 = IPv6-adress
Beror på typ av adress Adresstilldelning:
  • 4 byte för en IPv4-adress
  • Den första byten är längden på namnet, följt av domännamnet utan den avslutande null
  • 16 byte för en IPv6-adress
2 byte Portnummer, i ordning från högt till lågt ( big-endian )

Implementeringar

Se även

Anteckningar

  1. ↑ Register för tjänstnamn och portnummer för transportprotokoll . IANA. Tillträdesdatum: 8 januari 2016. Arkiverad från originalet 3 mars 2016.
  2. ↑ Marcus Leech <[email protected]>. SOCKS Protocol version  5 . tools.ietf.org. Hämtad 6 juni 2020. Arkiverad från originalet 18 oktober 2020.

Länkar