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.
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 soportados 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
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 Archivado el 30 de octubre de 2005 en Wayback Machine.
- Proxifier
- Hummingbird socks
- ProxyCap
- SocksCap
- tsocks
- socat
- connect
- GNet Library
- proxychains
Referencias
- Darmohray, Tina. "Firewalls and fairy tales".;LOGIN:. Vol 30, no. 1.
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