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" [1].

Los clientes que hay detrás de un firewall, los cuales necesitan acceder a los servidores del exterior, pueden conectarse en su lugar a un servidor proxy SOCKS. Tal servidor proxy controla que 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 publicamente.^[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.

La arquitectura de referencia SOCKS y el cliente son poseídos por Permeo Technologies.[2]

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

Contenido 1 protocolo SOCKS4 1.1 protocolo SOCKS 4a 2 protocolo SOCKS 5 3 Servidores SOCKS 4 Clientes SOCKS 5 Referencias 6 Enlaces externos

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 esrá 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. El servidor debe resolver el nombre de dominio y realizar la conexión al host destino si puede.

protocolo SOCKS 5

Una extensión del protocolo SOCKS 4 que ofrece más opciones de autenticación. La negociación(handshake) inicial ahora consiste en lo siguiente:-

 El cliente se conecta y envía un saludo en el cual incluye una lista de los métodos de autenticación soportados.
 El servidor escoge uno (o envía una respuesta de fallo si ninguno de los métodos ofrecidos es aceptable).
 Algunos mensajes pueden pasar ahora entre el cliente y el servidor dependiendo del método de autenticación escogido.
 El cliente envía una petición de conexión similar a  SOCKS4.
 El servidor responde de manera similar a SOCKS4.

Los métodos de autenticación sooprtados son numerados como sigue:-

  0x00 - Sin autenticación
  0x01 - GSSAPI
  0x02 - Nombre de Usuario/Password
  0x03..0x7F - métodos asignados por IANA
  0x80..0xFE - métodos reservados para uso privado

El saludo inicial desde el cliente es:-

campo 1: número de versión socks, debe ser 0x05 para esta versión
campo 2: número de métodos de autenticación soportados, 1 byte
campo 3: métodos de autenticación, longitud variable, 1-byte por método soportado

La elección del servidor es comunicada:-

campo 1: versión socks, 1 byte, 0x05 para esta versión
campo 2: método de autenticación escogida, 1 byte, o 0xFF cuando no sean ofrecidos métodos aceptables.

La autenticación subsiguiente es dependiente del método.

La petición de conexión del cliente es:-

campo 1: número de versión socks, 1 byte, debe ser 0x05 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) de puerto tcp/ip
  0x03 = asociar un puerto udp
campo 3: reservado, debe ser 0x00
campo 4: tipo de dirección, 1 byte:-
  0x01 = dirección IP V4 (el campo de direcciones tiene una longitud de 4 bytes)
  0x03 = Nombre de dominio (el campo dirección es variable)
  0x04 = dirección IP V6 (el campo de direcciones tiene una longitud de 16 bytes)
campo 5: dirección destino, 4/16 bytes o longitud de nombre 1+dominio.
  Si el tipo de dirección es 0x03 entonces la dirección consiste en un byte de longitud seguido del nombre de dominio.
campo 6: número de puerto en el orden de bytes de la red, 2 bytes

Respuesta del Servidor:-

campo 1: versión de protocolo socks, 1 byte, 0x05 para esta versión
campo 2: estado, 1 byte:-
  0x00 = petición concedida, 
  0x01 = fallo general,
  0x02 = la conexión no se permitió por el conjunto de reglas(ruleset)
  0x03 = red inalcanzable
  0x04 = host inalcanzable
  0x05 = conexión rechazada por el host destino
  0x06 = TTL expirado
  0x07 = comando no soportado/ error de protocolo
  0x08 = tipo de dirección no soportado
campo 3: reservado, 0x00
campo 4: tipo de dirección, 1 byte:-
  0x01 = dirección IP V4 (el campo de direcciones tiene una longitud de 4 bytes)
  0x03 = Nombre de dominio (el campo dirección es variable)
  0x04 = dirección IP V6 (el campo de direcciones tiene una longitud de 16 bytes)
campo 5: dirección destino, 4/16 bytes o longitud de nombre 1+dominio.
  Si el tipo de dirección es 0x03 entonces la dirección consiste en un byte de longitud seguido del nombre de dominio.
campo 6: número de puerto en el orden de bytes de la red, 2 bytes

Servidores SOCKS

Lista de programas servidores SOCKS:

• Dante Socks Server
• FreeProxy Incluye un servidor SOCKS. Se ejecuta sobre Windows 98, NT, 2000, XP y Server 2003
• AnalogX Proxy Incluye un servidor SOCKS. Se ejecuta sobre Windows 98, NT, 2000, XP y Server 2003
• Java Socks Server
• Socks4 Server
• SS5 Socks Server
• WinGate
• SSH (OpenSSH sobre Unix/Linux, PuTTY sobre Windows) (using dynamic port forwarding)
• DeleGate
• Antinat
• RunWay Pequeño servidor Socks v5 que corre sobre Iphone 3G / Linux

Clientes SOCKS

Son los programas cliente, los cuales permiten la adaptación de cualquier software para conectarse con redes externas mediante SOCKS.

Lista de clientes SOCKS:

• Dante client
• FreeCap
• Proxifier
• Hummingbird socks
• ProxyCap
• SocksCap
• tsocks
• socat
• connect
• GNet Library
• proxychains

Referencias

Enlaces externos

• RFC 3089 - A SOCKS-based IPv6/IPv4 Gateway Mechanism
• RFC 1961 - GSS-API Authentication Method for SOCKS Version 5
• RFC 1929 - Username/Password Authentication for SOCKS V5
• SOCKS4.Protocol - SOCKS Protocol Version 4
• SOCKS4A.Protocol - SOCKS Protocol Version 4A
• RFC 1928 - SOCKS Protocol Version 5
• RFC 1928 (Español) - Documento traducido al español