stringtranslate.com

MEDIAS

SOCKS es un protocolo de Internet que intercambia paquetes de red entre un cliente y un servidor a través de un servidor proxy . SOCKS5 proporciona autenticación opcional para que solo los usuarios autorizados puedan acceder a un servidor. En la práctica, un servidor SOCKS envía por proxy las conexiones TCP a una dirección IP arbitraria y proporciona un medio para que se reenvíen los paquetes UDP. Un servidor SOCKS acepta conexiones entrantes de clientes en el puerto TCP 1080, como se define en RFC  1928. [1]

Historia

El protocolo fue desarrollado y diseñado originalmente por David Koblas, un administrador de sistemas de MIPS Computer Systems . Después de que Silicon Graphics adquiriera MIPS en 1992, Koblas presentó un artículo sobre SOCKS en el Simposio de Seguridad Usenix de ese año [2] , lo que hizo que SOCKS estuviera disponible para el público. [3] El protocolo fue ampliado a la versión 4 por Ying-Da Lee de NEC .

La arquitectura de referencia SOCKS y el cliente son propiedad de Permeo Technologies , [4] una escisión de NEC . ( Blue Coat Systems compró Permeo Technologies y, a su vez, fue adquirida por Symantec).

El protocolo SOCKS5 fue originalmente un protocolo de seguridad que facilitaba la administración de los cortafuegos y otros productos de seguridad. Fue aprobado por la IETF en 1996 como RFC  1928 (autores: M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas y L. Jones). El protocolo fue desarrollado en colaboración con Aventail Corporation , que comercializa la tecnología fuera de Asia. [5]

Acrónimo

SOCKS se define a veces como un acrónimo de "socket seguro" desde al menos 2001, [6] [7] [8] [9] [10] aunque no se definió originalmente como tal en el RFC del Protocolo SOCKS Versión 5 en 1996 [11] o en el documento del UNIX Security Symposium III en 1992 [2] sino que simplemente se refería a un protocolo proxy específico diseñado para facilitar la comunicación entre clientes y servidores a través de un firewall.

Uso

SOCKS es un estándar de facto para pasarelas a nivel de circuito (pasarelas de nivel 5). [12]

La naturaleza de nivel de circuito/sesión de SOCKS lo convierte en una herramienta versátil para reenviar cualquier tráfico TCP (o UDP desde SOCKS5), creando una interfaz para todo tipo de herramientas de enrutamiento. Se puede utilizar como:

Protocolo

CALCETINES4

Una solicitud de conexión SOCKS4 típica se ve así:

VER
Número de versión de SOCKS, 0x04 para esta versión
Cmd
Código de comando:
  • 0x01 = establecer una conexión de flujo TCP/IP
  • 0x02 = establecer un enlace de puerto TCP/IP
DSTPORT
Número de puerto de 2 bytes (en orden de bytes de red )
DESESTIPAR
Dirección IPv4 , 4 bytes (en orden de bytes de red)
IDENTIFICACIÓN
la cadena de identificación del usuario, longitud variable y terminación nula .
Espana
versión de respuesta, byte nulo
REPS
Código de respuesta
DSTPORT
puerto de destino, significativo si se concede en BIND, de lo contrario ignorar
DSTIP
IP de destino, como se indica arriba: la IP:puerto al que el cliente debe vincularse

Por ejemplo, esta es una solicitud SOCKS4 para conectar a Fred a 66.102.7.99:80 , el servidor responde con un "OK":

A partir de este punto, cualquier dato enviado desde el cliente SOCKS al servidor SOCKS se retransmite a 66.102.7.99, y viceversa.

El campo de comando puede ser 0x01 para "conectar" o 0x02 para "vincular"; el comando "vincular" permite conexiones entrantes para protocolos como FTP activo .

CALCETINES4a

SOCKS4a extiende el protocolo SOCKS4 para permitir que un cliente especifique un nombre de dominio de destino en lugar de una dirección IP; esto resulta útil cuando el propio cliente no puede resolver el nombre de dominio del host de destino en una dirección IP. Fue propuesto por Ying-Da Lee, el autor de SOCKS4. [16]

El cliente debe configurar los primeros tres bytes de DSTIP como NULL y el último byte como un valor distinto de cero. (Esto corresponde a la dirección IP 0.0.0.x, con x distinto de cero, una dirección de destino inadmisible y, por lo tanto, nunca debería ocurrir si el cliente puede resolver el nombre de dominio). Después del byte NULL que termina USERID, el cliente debe enviar el nombre de dominio de destino y terminarlo con otro byte NULL. Esto se utiliza tanto para solicitudes de "conexión" como de "enlace".

Cliente al servidor SOCKS:

CALCETINES4_C
Paquete de protocolo de enlace del cliente SOCKS4 (arriba)
DOMINIO
el nombre de dominio del host para contactar, nulo (0x00) terminado

Del servidor al cliente SOCKS: (igual que SOCKS4)

Un servidor que utilice el protocolo SOCKS4a debe comprobar el DSTIP en el paquete de solicitud . Si representa la dirección 0.0.0.x con x distinto de cero, el servidor debe leer el nombre de dominio que el cliente envía en el paquete. El servidor debe resolver el nombre de dominio y establecer la conexión con el host de destino si puede.

CALCETINES5

El protocolo SOCKS5 se define en RFC  1928. Es una extensión incompatible del protocolo SOCKS4; ofrece más opciones de autenticación y agrega compatibilidad con IPv6 y UDP , este último puede usarse para búsquedas de DNS . El protocolo de enlace inicial consta de lo siguiente:

El saludo inicial del cliente es:

VER
Versión SOCKS (0x05)
NAUTO
Número de métodos de autenticación admitidos, uint8
AUTORIZACIÓN
Métodos de autenticación, se admite 1 byte por método
Los métodos de autenticación admitidos se enumeran de la siguiente manera:
  • 0x00: Sin autenticación
  • 0x01: GSSAPI ( RFC  1961)
  • 0x02: Nombre de usuario/contraseña ( RFC  1929)
  • 0x03–0x7F: métodos asignados por IANA [17]
    • 0x03: Protocolo de autenticación de desafío-apretón de manos
    • 0x04: Sin asignar
    • 0x05: Método de autenticación de desafío-respuesta
    • 0x06: Capa de sockets seguros
    • 0x07: Autenticación NDS
    • 0x08: Marco de autenticación múltiple
    • 0x09: Bloque de parámetros JSON
    • 0x0A–0x7F: Sin asignar
  • 0x80–0xFE: métodos reservados para uso privado
VER
Versión SOCKS (0x05)
CAUTH
método de autenticación elegido, o 0xFF si no se ofrecieron métodos aceptables

La autenticación posterior depende del método. La autenticación con nombre de usuario y contraseña (método 0x02) se describe en RFC  1929:

VER
0x01 para la versión actual de autenticación de nombre de usuario/contraseña
IDLEN, IDENTIFICACIÓN
Longitud del nombre de usuario, uint8; nombre de usuario como cadena de bytes
PWLEN, PW
Longitud de la contraseña, uint8; contraseña como cadena de bytes
VER
0x01 para la versión actual de autenticación de nombre de usuario/contraseña
ESTADO
0x00 éxito, de lo contrario falla, la conexión debe cerrarse

Después de la autenticación, la conexión puede continuar. Primero definimos un tipo de datos de dirección como:

TIPO
Tipo de dirección. Uno de:
  • 0x01: dirección IPv4
  • 0x03: Nombre de dominio
  • 0x04: dirección IPv6
Dirección
Los datos de dirección que se indican a continuación. Según el tipo:
  • 4 bytes para dirección IPv4
  • 1 byte de longitud de nombre seguido de 1 a 255 bytes para el nombre de dominio
  • 16 bytes para dirección IPv6
VER
Versión SOCKS (0x05)
Cmd
Código de comando:
  • 0x01: establecer una conexión de flujo TCP/IP
  • 0x02: establecer un enlace de puerto TCP/IP
  • 0x03: asociar un puerto UDP
virus respiratorio sincitial
reservado, debe ser 0x00
Dirección de área de destino
Dirección de destino, consulte la estructura de dirección más arriba.
DSTPORT
Número de puerto en un orden de bytes de red
VER
Versión SOCKS (0x05)
ESTADO
código de estado:
  • 0x00: solicitud concedida
  • 0x01: fallo general
  • 0x02: conexión no permitida por el conjunto de reglas
  • 0x03: red inaccesible
  • 0x04: host inalcanzable
  • 0x05: conexión rechazada por el host de destino
  • 0x06: TTL expirado
  • 0x07: comando no compatible / error de protocolo
  • 0x08: tipo de dirección no compatible
virus respiratorio sincitial
reservado, debe ser 0x00
BNDADDR
Dirección vinculada al servidor en el formato "dirección SOCKS5" especificado anteriormente
PUERTO BND
Número de puerto vinculado al servidor en un orden de bytes de red

Dado que los clientes pueden utilizar direcciones resueltas o nombres de dominio, existe una convención de cURL para etiquetar la variante de nombre de dominio de SOCKS5 como "socks5h" y la otra simplemente como "socks5". Existe una convención similar entre SOCKS4a y SOCKS4. [18]

Software

Servidores

Implementaciones de servidores proxy SOCKS

Otros programas que proporcionan interfaz de servidor SOCKS

Clientela

El software cliente debe tener soporte nativo de SOCKS para poder conectarse a través de SOCKS.

Navegador

Existen programas que permiten a los usuarios eludir dichas limitaciones:

Calcetines

Los calcetines permiten que las aplicaciones accedan a las redes para utilizar un proxy sin necesidad de admitir ningún protocolo proxy. La forma más común es configurar un adaptador de red virtual y tablas de enrutamiento adecuadas para enviar tráfico a través del adaptador.

Traducción de proxies

Seguridad

Debido a la falta de cifrado en las solicitudes y en el intercambio de paquetes, SOCKS es prácticamente vulnerable a ataques de intermediarios y a escuchas clandestinas de direcciones IP, lo que en consecuencia abre el camino a la censura por parte de los gobiernos.

Referencias

  1. ^ "Registro de números de puerto de protocolo de transporte y nombre de servicio". Autoridad de Números Asignados de Internet . 19 de mayo de 2017 . Consultado el 23 de mayo de 2017 .
  2. ^ ab Koblas, David; Koblas, Michelle R. SOCKS (PDF) . Simposio de seguridad UNIX de USENIX III . Consultado el 16 de noviembre de 2019 .
  3. ^ Darmohray, Tina. "Cortafuegos y cuentos de hadas". ;LOGIN:. Vol 30, no. 1.
  4. ^ Índice de archivo en Wayback Machine
  5. ^ CNET: El ciberespacio desde el espacio exterior
  6. ^ EE. UU. US8984268B2 
  7. ^ EE. UU. US20210058367A1 
  8. ^ EE. UU. US11190374B2 
  9. ^ JP6761452B2 
  10. ^ EE. UU. US11425565B2 
  11. ^ RFC 1928. doi : 10.17487/RFC1928 .
  12. ^ Oppliger, Rolf (2003). "Puertas de enlace a nivel de circuito". Tecnologías de seguridad para la World Wide Web (2.ª ed.). Artech House. ISBN 1580533485. Recuperado el 21 de enero de 2020 .
  13. ^ "Informe sobre el uso de herramientas de elusión en 2010" (PDF) . Centro Berkman para Internet y Sociedad de la Universidad de Harvard. Octubre de 2010.
  14. ^ "Preguntas frecuentes sobre Tor".
  15. ^ "Preguntas frecuentes sobre OpenSSH". Archivado desde el original el 1 de febrero de 2002.
  16. ^ Ying-Da Lee. "SOCKS 4A: Una extensión simple del protocolo SOCKS 4". OpenSSH . Consultado el 3 de abril de 2013 .
  17. ^ IANA.org
  18. ^ "CURLOPT_PROXY". curl.se . Consultado el 20 de enero de 2020 .
  19. ^ "Productos desarrollados por Inferno Nettverk A/S". www.inet.no . Consultado el 20 de marzo de 2021 .
  20. ^ "Easy Net con SOCKS5". shimmercat.com . ShimmerCat. Archivado desde el original el 13 de septiembre de 2018 . Consultado el 20 de abril de 2016 .
  21. ^ "Configuración de un servidor proxy SOCKS en Chrome". www.chromium.org . Consultado el 19 de marzo de 2024 .
  22. ^ Bizjak, Ambroz (20 de enero de 2020). «ambrop72/badvpn: lenguaje de programación NCD, proxy tun2socks, VPN P2P». GitHub . Consultado el 20 de enero de 2020 .
  23. ^ "xjasonlyu/tun2socks: tun2socks - impulsado por la pila TCP/IP de gVisor". GitHub .
  24. ^ "heiher/hev-socks5-tunnel: Un tun2socks de alto rendimiento". GitHub .
  25. ^ Hamsik, Adam (20 de enero de 2020). "proxychains: una herramienta que obliga a cualquier conexión TCP realizada por cualquier aplicación a seguir un proxy como TOR o cualquier otro proxy SOCKS4, SOCKS5 o HTTP(S)". GitHub . Consultado el 20 de enero de 2020 .

Enlaces externos