CALCETINES
SOCKS es un protocolo de red que permite que las aplicaciones cliente-servidor utilicen de forma transparente los servicios de un firewall . SOCKS es la abreviatura del término en inglés " sockets " y " Secured Over Credential-based Kerberos ".
Las aplicaciones de red protegidas detrás del firewall que deseen acceder a servidores externos deben conectarse a través de un servidor proxy tipo SOCKS. Dicho servidor decide sobre la elegibilidad del cliente para acceder al servidor externo y transmite su solicitud al servidor. SOCKS también se puede usar a la inversa, lo que permite que las aplicaciones externas se conecten a servidores detrás del firewall.
El protocolo fue desarrollado originalmente por David Koblas , uno de los administradores de sistemas de la compañía MIPS . En el año de la adquisición de MIPS por Silicon Graphics , en 1992, Koblas presentó un documento sobre SOCKS en una conferencia de seguridad de Usenix , y SOCKS se convirtió efectivamente en un protocolo público. El protocolo ha sido mejorado en la versión 4 por Ying-Da Lee de la empresa NEC .
La versión 4a, "no oficial", agrega soporte para servidores de resolución de nombres a SOCKS.
La versión actual 5 del protocolo, especificada en RFC 1928 , amplía la versión anterior al agregar la capacidad de transmitir UDP , permite la autenticación, la resolución de nombres de dominio por parte del propio servidor SOCKS e IPv6 .
La arquitectura y la aplicación cliente de referencia son propiedad de Permeo Technologies.
Según el modelo OSI , el protocolo SOCKS es una capa intermedia entre la capa de aplicación y la capa de transporte.
Servidores SOCKS
Lista de software del servidor SOCKS:
Clientes de SOCKS
Hay programas disponibles para socksify otras aplicaciones, lo que permite que cualquier software con capacidades de red utilice SOCKS, incluso si no está diseñado para admitir SOCKS.
Lista de clientes de SOCKS
| Cliente |
Licencia |
Versión |
Fecha de creación |
Plataforma |
Versión del protocolo
|
|---|
| ProxyCap |
Shareware |
5.26 |
03/2007 |
Windows , Mac OS X
|
v4, v5, HTTPS, túnel SSH, HTTP
|
| socat |
GLP |
1,6 |
03/2007 |
POSIX |
túnel multi-opcional
|
| WideCap |
Shareware |
1.4 |
12/2007 |
Ventanas |
v4, v5, HTTPS
|
| Proxificar |
Shareware |
3,21 |
02/2007 |
Windows , Mac OS X
|
v4, v5, HTTPS, HTTP
|
| Cliente de túnel HTTP |
Freeware |
4.4.400 |
01/2007 |
Ventanas |
v4, v5, HTTP
|
| calcetines |
GLP |
1,6 |
10/2006 |
* BSD, Mac OS X
|
v4, v5
|
| conectar |
GLP |
1,95 |
08/2006 |
Ventanas , POSIX |
v4, v5, HTTPS
|
| nylon |
Cláusula 3-BSD |
1.2.1 |
07/2006 |
OpenBSD |
v4, v5
|
| cadenas de proxy |
GLP |
3.1 |
05/2006 |
POSIX (fuente) |
v4, v5, HTTPS
|
| FreeCap |
GLP |
3,18 |
02/2006 |
Ventanas |
v4, v5, HTTPS
|
| Cliente Dante |
BSD / Universidad Carnegie Mellon
|
1.1.19 |
01/2006 |
POSIX |
v4, v5, HTTP
|
| Túnel |
Shareware |
1.4 |
06/2005 |
Ventanas |
Túnel SSH
|
| Biblioteca de GNet |
GLP |
2.0.7 |
02/2005 |
POSIX (fuente) |
v4, v5
|
| CALCETINES Colibrí |
Freeware |
8.0 |
10/2003 |
Ventanas |
v4, v5
|
| calcetines |
GLP |
1.8 |
10/2002 |
POSIX (fuente) |
v4, v5
|
| Gorila Kernel Socks |
GLP |
0.0.4 |
1/2005 |
POSIX (fuente) |
v5
|
CALCETINES v4
Una conexión SOCKS normal consiste en intercambiar las siguientes tramas TCP:
Del cliente a los servidores de SOCKS
- campo 1: Versión de protocolo, 1 byte , 0x04 para esta versión
- campo 2: byte de comando, 1 byte:
- 0x01 = establecer una tubería TCP / IP
- 0x02 = establecer una coincidencia de puerto TCP
- campo 3: número de puerto, (en 2 bytes, big endian )
- campo 4: dirección IPv4 (en 4 bytes)
- campo 5: cadena de autenticación de usuario ( ascii , longitud variable, terminada por un carácter NULL 0x00)
Luego del servidor al cliente
- campo 1: constante 0x0, 1 byte
- campo 2: byte de estado:
- 0x5a = solicitud aceptada
- 0x5b = solicitud rechazada o error
- 0x5c = solicitud fallida porque el cliente no inició el demonio identd (o el servidor no puede acceder a identd)
- 0x5d = la solicitud falló porque el servicio de identificación del cliente no autenticó la cadena enviada en la solicitud.
- campo 3: 2 bytes, ignorado
- campo 4: 4 bytes, ignorado
Ejemplo:
Aquí está la solicitud SOCKS que permite conectar un cliente Fred a la dirección 66.102.7.99:80, en este ejemplo el servidor responde con un "OK":
- Cliente: 0x04 | 0x01 | 0x00 0x50 | 0x42 0x66 0x07 0x63 | 0x46 0x72 0x65 0x64 0x00
- El último campo contiene la cadena "Fred \ 0" en ASCII
- Respuesta del servidor SOCKS: 0x00 | 0x5a | 0xDE 0xAD | 0xBE 0xEF 0xFF 0xFF
- Los dos últimos campos contienen valores arbitrarios, que el protocolo solicita ignorar.
A partir de este punto, todos los datos enviados en este flujo TCP se transferirán en el puerto 80 a la dirección 66.102.7.99
El valor 0x02 ("bind") para el segundo campo de la solicitud permite la apertura de conexiones entrantes para protocolos como FTP en modo activo.
CALCETINES v4a
SOCKS 4a es una extensión simple del protocolo SOCKS 4 que permite a un cliente que no puede resolver el nombre de dominio del host de destino incluirlo en su solicitud.
El cliente debe establecer los primeros tres bytes de la dirección IP de destino en NULL y el último byte en un valor que no sea NULL (esto corresponde a una dirección IP de tipo 0.0.0.x, con x un valor diferente a 0, que no es una dirección válida y, por lo tanto, nunca podría haberse utilizado si el cliente hubiera podido resolver el nombre de dominio). Luego, el cliente debe enviar el nombre de dominio de destino después del byte NULL que termina el nombre de usuario y terminarlo con otro byte NULL. Esto se usa de la misma manera para las solicitudes de "conexión" y "vinculación".
Una conexión SOCKS con una solicitud de resolución de nombre de dominio se ve así:
De cliente a servidor
- campo 1: Versión del protocolo, 1 byte, 0x04 para esta versión
- campo 2: byte de comando, 1 byte:
- 0x01 = establecer una tubería TCP / IP
- 0x02 = establecer una coincidencia de puerto TCP
- campo 3: número de puerto, (en 2 bytes, big endian)
- campo 4: dirección IPv4 (en 4 bytes) deliberadamente inválida, los primeros bytes deben ser 0x00 y el último debe ser diferente de 0x00
- campo 5: cadena de autenticación de usuario (ascii, longitud variable, terminada por un NULL)
- campo 6: nombre de dominio del host a contactar (ascii, longitud variable, terminado por un NULL)
Luego del servidor al cliente
- campo 1: constante 0x0
- campo 2: byte de estado:
- 0x5a = solicitud aceptada
- 0x5b = solicitud rechazada o error
- 0x5c = solicitud fallida porque el cliente no inició el demonio identd (o el servidor no puede acceder a identd)
- 0x5d = la solicitud falló porque el servicio de identificación del cliente no autenticó la cadena enviada en la solicitud.
- campo 3: número de puerto, 2 bytes
- campo 4: dirección IPv4, 4 bytes
Un servidor que admita el protocolo 4a debe examinar la dirección IP de destino en la solicitud. Si es una dirección 0.0.0.x con una x distinta de cero, el servidor debe leer el nombre de dominio especificado por el cliente en el paquete. A continuación, debe resolver él mismo el nombre de dominio y establecer la conexión, si es posible.
CALCETINES v5
SOCKS v5 es una extensión de SOCKS v4 que ofrece más posibilidades de autenticación y compatibilidad con UDP. El apretón de manos inicial consta del siguiente procedimiento:
- El cliente inicia sesión y envía un anuncio que incluye una lista de métodos de autenticación que admite.
- El servidor elige uno de estos métodos o envía un error si ninguno de los métodos es aceptable.
- A continuación, se intercambian varios mensajes de acuerdo con el método de autenticación elegido.
- Una vez autenticado, el cliente envía una solicitud de conexión similar pero diferente al protocolo SOCKS v4.
- El servidor responde de manera similar a SOCKS v4.
Los métodos de autenticación admitidos se enumeran de la siguiente manera:
- 0x00: sin autenticación
- 0x01 - GSSAPI
- 0x02 - Nombre de usuario / contraseña
- 0x03-0x7F - Métodos definidos por IANA
- 0x80-0xFE: métodos reservados para uso privado.
La solicitud inicial del cliente al servidor es:
- campo 1: número de versión de SOCKS (0x05 para esta versión), en un byte
- campo 2: número de métodos de autenticación admitidos, en un byte
- campo 3: lista de métodos de autenticación admitidos (un byte por método), de tamaño variable
A continuación, el servidor comunica su elección:
- campo 1: número de versión de SOCKS (0x05 para esta versión), en un byte
- campo 2: método de autenticación elegido, en un byte, o 0xFF si ninguno de los métodos propuestos es adecuado
El resto de la autenticación depende del método elegido.
Después de la autenticación, el cliente envía su solicitud de conexión:
- campo 1: número de versión de SOCKS (debe ser 0x05 para esta versión), en un byte
- campo 2: código de comando de un byte:
- 0x01 = establecer una conexión TCP / IP
- 0x02 = configurar una coincidencia de puerto TCP
- 0x03 = asociar un puerto UDP
- campo 3: reservado, debe ser 0x00
- campo 4: tipo de dirección de destino, en un byte:
- 0x01 = dirección IPv4 (el campo de dirección tendrá 4 bytes de longitud)
- 0x03 = nombre de dominio (el campo de dirección será de longitud variable)
- 0x04 = dirección IPv6 (el campo de dirección tendrá 16 bytes de longitud)
- campo 5: dirección de destino, longitud 4 o 16 bytes, o la longitud del nombre de dominio + 1.
- Si el tipo de dirección es 0x03, la dirección consta de un byte que indica la longitud del nombre de dominio seguido del nombre en sí.
- campo 6: número de puerto, en 2 bytes
El servidor transmite su respuesta:
- campo 1: número de versión de SOCKS (debe ser 0x05 para esta versión), en un byte
- campo 2: estado, en un byte:
- 0x00 = solicitud aceptada
- 0x01 = falla
- 0x02 = conexión prohibida
- 0x03 = red inaccesible
- 0x04 = host de destino inalcanzable
- 0x05 = conexión rechazada por el host de destino
- 0x06 = TTL caducado
- 0x07 = comando no admitido / error de protocolo
- 0x08 = tipo de dirección no admitido
- campo 3: reservado, debe ser 0x00
- campo 4: tipo de dirección de asociación en calcetines de proxy, en un byte:
- 0x01 = dirección IPv4 (el campo de dirección tendrá 4 bytes de longitud)
- 0x03 = nombre de dominio (el campo de dirección será de longitud variable)
- 0x04 = dirección IPv6 (el campo de dirección tendrá 16 bytes de longitud)
- campo 5: dirección de asociación en calcetines de proxy, longitud 4 o 16 bytes, o la longitud del nombre de dominio + 1.
- Si el tipo de dirección es 0x03, la dirección consta de un byte que indica la longitud del nombre de dominio seguido del nombre en sí.
- campo 6: número de puerto de asociación en calcetines proxy, en dos bytes
Notas y referencias
-
ftp://ftp.delegate.org/pub/DeleGate/COPYRIGHT
-
http://mindprod.com/jgloss/socksify.html
enlaces externos
-
RFC 3089 - Mecanismo de puerta de enlace IPv6 / IPv4 basado en SOCKS
-
RFC 1961 - Método de autenticación GSS-API para SOCKS versión 5
-
RFC 1929 - Autenticación de nombre de usuario / contraseña para SOCKS V5
-
RFC 1928 - Protocolo SOCKS versión 5