ıllı Internet y Tecnologías de la Información (2018)

internet, Hosting, dominios, seo, antivirus, banco de imágenes, páginas web, tiendas online

[Enciclopedia Online Gratuita] Diccionario de Internet y Tecnologías de la Información y la Comunicación (TIC):

ıllı SOCKS wiki: info, historia y vídeos


La información contenida en esta web debe ser considerada como información general, de carácter formativo, educativo o divulgativo, y no puede ser utilizada o interpretada como consejo o diagnótico médico, psicológico o de ningún otro tipo. Es posible que algunos datos mostrados no esten actualizados. Por ello, en caso de duda lo recomentable es consultar a un experto cualificado.


 


 

videos internet

salud  SOCKS 


SOCKS es un protocolo de Internet que deja a las aplicaciones Cliente del servicio-servidor emplear de forma transparente los servicios de un firewall de red. SOCKS es una abreviación de "SOCKetS".


Los clientes del servicio que hay tras un firewall que precisan acceder a los servidores del exterior, pueden conectarse en su sitio a un servidor proxy SOCKS. Tal servidor proxy controla qué usuario puede acceder al servidor externo y pasa la solicitud al servidor. SOCKS puede ser utilizado asimismo de la manera contraria, dejando a los clientes del servicio de fuera del firewall ("clientes del servicio exteriores") conectarse a los servidores de en el firewall (servidores internos).


El protocolo fue desarrollado originalmente por David Koblas, un administrador de MIPS Computer Systems. Una vez que MIPS fuera controlado por Silicon Graphics en mil novecientos noventa y dos, Koblas presentó un artículo sobre SOCKS en el Simposium anual de seguridad Usenix y SOCKS llegó a estar libre en público. El protocolo fue extendido a la versión cuatro por Ying-Da Lee de NEC.


Las extensiones no oficiales SOCKS 4a agregan soporte para nombres DNS para solucionar nombres con el servidor SOCKS. La versión actual cinco del protocolo, RFC mil novecientos veintiocho o bien authenticated firewall traversal, extiende la versión anterior aguantando UDP, autentificación, dejando al servidor SOCKS solucionar nombres de host para el cliente del servicio SOCKS, y también IPv6.


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




Una solicitud de conexión habitual SOCKS cuatro se semeja a algo afín a esto (cada número es un byte):


Cliente al Servidor Socks:

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

Servidor al cliente del servicio de socks:

campo 1: byte nulocampo 2: estado, 1 byte:- 0x5a = solicitud concedida, 0x5b = solicitud rechazada o bien errada, 0x5c = solicitud errada a raíz de que el usuario no está ejecutando identd (o bien no es asequible desde el servidor) 0x5d = solicitud errada debida a que identd de cliente del servicio no pudo confirmar el string de identidad de usuario en la peticióncampo 3: número de puerto con orden de bytes de red, dos bytescampo 4: dirección ip con orden de bytes de red, cuatro bytes

Ejemplo:


Esta es una solicitud socks cuatro para conectar a Fred al sesenta y seis y ciento dos.99:80, el servidor responde 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 mandados desde el usuario socks al servidor socks va a ser retransmitido a sesenta y seis y ciento dos.99 y a la inversa.


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


Protocolo SOCKS 4a


SOCKS 4a es una extensión simple al protocolo SOCKS cuatro que deja a un usuario que no puede solucionar el nombre de dominio de un host destino concretarlo.


El usuario debe asignar los primeros 3 bytes de DSTIP a NULL y el último byte a un valor diferente de cero (Esto corresponde a una dirección IP 0.0.0.x, siendo x diferente de cero, una dirección destino inaceptable y de esta forma no debe suceder jamás si el usuario puede solucionar el nombre del dominio). Siguiendo al byte NULL que acaba USERID, el usuario debe mandar el nombre de dominio destino y lo acaba con otro byte NULL. Esto se utiliza para las dos solicitudes CONNECT y BIND.


Cliente al Servidor Socks:

campo 1: número de versión socks, 1 byte, ha de ser 0x04 para esta versióncampo 2: código de comando, 1 byte:- 0x01 = establece la conexión de stream tcp/ip 0x02 = establece un enlazado(binding) de puerto tcp/ipcampo 3: número de puerto con orden de bytes de red, dos bytescampo 4: dirección IP inválida deliberada, cuatro bytes, los primeros 3 han de ser 0x00 y el último no ha de ser 0x00campo 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 deseamos contactar, longitud variable, terminado con un nulo (0x00)

Servidor a cliente del servicio de socks:

campo 1: byte nulocampo 2: estado, 1 byte:- 0x5a = solicitud concedida, 0x5b = solicitud rechazada o bien errada, 0x5c = solicitud errada a raíz de que el cliente del servicio no está ejecutando identd (o bien no es asequible desde el servidor) 0x5d = solicitud errada debida a que identd de usuario no pudo confirmar el string de identidad de usuario en la peticióncampo 3: número de puerto en el orden de bytes de la red, dos bytescampo 4: dirección ip en el orden de bytes de la red, cuatro bytes

Un servidor que utiliza el protocolo 4A debe revisar el DSTIP en el bulto de solicitud. Si esto representa la dirección 0.0.0.x siendo x diferente de cero, el servidor debe leer en el nombre de dominio que el cliente del servicio manda en el bulto de datos. El servidor debe solucionar el nombre de dominio y efectuar la conexión al host destino si puede.


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

El usuario se conecta y manda un saludo en el que incluye una lista de los métodos de autentificación soportados.El servidor elige uno (o bien manda una contestación de fallo si ninguno de los métodos ofrecidos es admisible).Algunos mensajes pueden pasar ahora entre el cliente del servicio y el servidor en dependencia del procedimiento de autentificación elegido.El cliente del servicio manda una solicitud de conexión afín a SOCKS4.El servidor responde de forma afín a SOCKS4.

Los métodos de autentificación soprtados son numerados como sigue:

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

El saludo inicial desde el usuario es:

campo 1: número de versión socks, ha de ser 0x05 para esta versióncampo 2: número de métodos de autentificación soportados, 1 bytecampo 3: métodos de autentificación, longitud variable, 1-byte por procedimiento soportado

La elección del servidor es comunicada:

campo 1: versión socks, 1 byte, 0x05 para esta versióncampo 2: procedimiento de autentificación elegida, 1 byte, o bien 0xFF cuando no sean ofrecidos métodos admisibles.

La autentificación siguiente es dependiente del procedimiento.


La solicitud de conexión del cliente del servicio es:-

campo 1: número de versión socks, 1 byte, ha de ser 0x05 para esta versióncampo 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 udpcampo 3: reservado, ha de ser 0x00campo 4: género de dirección, 1 byte:- 0x01 = dirección IP V4 (el campo de direcciones tiene una longitud de cuatro bytes) 0x03 = Nombre de dominio (el campo dirección es variable) 0x04 = dirección IP V6 (el campo de direcciones tiene una longitud de dieciseis bytes)campo 5: dirección destino, 4/16 bytes o bien longitud de nombre 1+dominio. Si el género 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, dos bytes

Respuesta del Servidor:-

campo 1: versión de protocolo socks, 1 byte, 0x05 para esta versióncampo 2: estado, 1 byte:- 0x00 = solicitud concedida, 0x01 = fallo general, 0x02 = la conexión no se dejó por el conjunto de reglas(ruleset) 0x03 = red inaccesible 0x04 = host inaccesible 0x05 = conexión rechazada por el host destino 0x06 = TTL expirado 0x07 = comando no soportado/ fallo de protocolo 0x08 = género de dirección no soportadocampo 3: reservado, 0x00campo 4: género de dirección, 1 byte:- 0x01 = dirección IP V4 (el campo de direcciones tiene una longitud de cuatro bytes) 0x03 = Nombre de dominio (el campo dirección es variable) 0x04 = dirección IP V6 (el campo de direcciones tiene una longitud de dieciseis bytes)campo 5: dirección destino, 4/16 bytes o bien longitud de nombre 1+dominio. Si el género 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, dos bytes


  ELIGE TU TEMA DE INTERÉS: 


autoayuda.es   Internet y Tecnologias 





Está aquí: Inicio > [ INTERNET ] > ıllı SOCKS wiki: info, historia y vídeos

Las cookies nos permiten ofrecer nuestros servicios. Al utilizar nuestros servicios, aceptas el uso que hacemos de las cookies. Ver políticas