SOCKS

SOCKS es un protocolo de Internet que permite a las aplicaciones Cliente-servidor usar de manera transparente los servicios de un firewall de red. SOCKS es una abreviación de "SOCKetS".

Los clientes que hay detrás de un firewall que necesitan acceder a los servidores del exterior, pueden conectarse en su lugar a un servidor proxy SOCKS. Tal servidor proxy controla qué cliente puede acceder al servidor externo y pasa la petición al servidor. SOCKS puede ser usado también de la forma contraria, permitiendo a los clientes de fuera del firewall ("clientes exteriores") conectarse a los servidores de dentro del firewall (servidores internos).

El protocolo fue desarrollado originalmente por David Koblas, un administrador de MIPS Computer Systems. Después de que MIPS fuera controlado por Silicon Graphics en 1992, Koblas presentó un artículo sobre SOCKS en el Simposio anual de seguridad Usenix y SOCKS llegó a estar disponible públicamente.[1] El protocolo fue extendido a la versión 4 por Ying-Da Lee de NEC.

Las extensiones no oficiales SOCKS 4a añaden soporte para nombres DNS para resolver nombres con el servidor SOCKS. La versión actual 5 del protocolo, RFC 1928 o authenticated firewall traversal, extiende la versión previa soportando UDP, autenticación, permitiendo al servidor SOCKS resolver nombres de host para el cliente SOCKS, e IPv6.

De acuerdo con el modelo OSI esto es una capa intermedia entre la capa de aplicación y la capa de transporte.

Protocolo SOCKS4

Una petición de conexión típica SOCKS 4 se parece a algo similar a esto (cada número es un byte):

Cliente al Servidor Socks:

campo 1: número de versión socks, 1 byte, debe ser 0x04 para esta versión
campo 2: código de comando, 1 byte:-
  0x01 = establecer una conexión stream tcp/ip
  0x02 = establecer un enlazado(binding) al puerto tcp/ip
campo 3: número de puerto de orden de byte de red, 2 bytes
campo 4: dirección ip de orden de byte de red, 4 bytes
campo 5: el string de id de usuario, longitud variable, terminado con un nulo (0x00)

Servidor al cliente de socks:

campo 1: byte nulo
campo 2: estado, 1 byte:-
  0x5a = petición concedida, 
  0x5b = petición rechazada o fallida,
  0x5c = petición fallida a causa de que el cliente no está ejecutando identd (o no es alcanzable desde el servidor)
  0x5d = petición fallida debida a que identd de cliente no pudo confirmar el string de identidad de usuario en la petición
campo 3: número de puerto con orden de bytes de red, 2 bytes
campo 4: dirección ip con orden de bytes de red, 4 bytes

Ejemplo:

Esta es una petición socks 4 para conectar a Fred al 66.102.7.99:80, el servidor contesta con un "OK."

  Client: 0x04 | 0x01 | 0x00 0x50 | 0x42 0x66 0x07 0x63 | 0x46 0x72 0x65 0x64 0x00
  Server: 0x00 | 0x5a | 0x00 0x50 | 0x42 0x66 0x07 0x63

Desde este punto cualquiera de los datos enviados desde el cliente socks al servidor socks será retransmitido a 66.102.7.99 y viceversa.

El campo comando puede ser 0x01 para "conectar" o 0x02 para "asociar"(bind). "Asociar" permite conexiones entrantes para protocolos como FTP activo.

protocolo SOCKS 4a

SOCKS 4a es una extensión simple al protocolo SOCKS 4 que permite a un cliente que no puede resolver el nombre de dominio de un host destino especificarlo.

El cliente debe asignar los primeros tres bytes de DSTIP a NULL y el último byte a un valor distinto de cero (Esto corresponde a una dirección IP 0.0.0.x, siendo x distinto de cero, una dirección destino inadmisible y así no debe ocurrir nunca si el cliente puede resolver el nombre del dominio). Siguiendo al byte NULL que termina USERID, el cliente debe enviar el nombre de dominio destino y lo termina con otro byte NULL. Esto se usa para ambas peticiones CONNECT y BIND.

Cliente al Servidor Socks:

campo 1: número de versión socks, 1 byte, debe ser 0x04 para esta versión
campo 2: código de comando, 1 byte:-
  0x01 = establece la conexión de stream tcp/ip
  0x02 = establece un enlazado(binding) de puerto tcp/ip
campo 3: número de puerto con orden de bytes de red, 2 bytes
campo 4: dirección IP inválida deliberada, 4 bytes, los primeros tres deben ser 0x00 y el último no debe ser  0x00
campo 5: el string de id de usuario, longitud variable, terminado con un nulo (0x00)
campo 6: el nombre de dominio del host con el que queremos contactar, longitud variable, terminado con un nulo (0x00)

Servidor a cliente de socks:

campo 1: byte nulo
campo 2: estado, 1 byte:-
  0x5a = petición concedida, 
  0x5b = petición rechazada o fallida,
  0x5c = petición fallida a causa de que el cliente no está ejecutando identd (o no es alcanzable desde el servidor)
  0x5d = petición fallida debida a que identd de cliente no pudo confirmar el string de identidad de usuario en la petición
campo 3: número de puerto en el orden de bytes de la red, 2 bytes
campo 4: dirección ip en el orden de bytes de la red, 4 bytes

Un servidor que usa el protocolo 4A debe comprobar el DSTIP en el paquete de petición. Si esto representa la dirección 0.0.0.x siendo x distinto de cero, el servidor debe leer en el nombre de dominio que el cliente envía en el paquete de datos. El servidor debe resolver el nombre de dominio y realizar la conexión al host destino si puede.

Other Languages
Deutsch: SOCKS
English: SOCKS
français: SOCKS
עברית: SOCKS
italiano: SOCKS
日本語: SOCKS
한국어: SOCKS
latviešu: SOCKS
Nederlands: SOCKS
polski: SOCKS
português: SOCKS
русский: SOCKS
Simple English: SOCKS
українська: SOCKS
中文: SOCKS