protocolo calcetines5. Servidor proxy universal. Recibir conexiones entrantes

Al trabajar con un proxy, es muy importante elegir tipo correcto proxy para sus tareas a evitar posibles problemas y lograr tus objetivos. Los más utilizados son los proxies HTTP y los proxies Socks5. Las diferencias entre ellos radican en el grado de anonimato, el protocolo utilizado, el método de transmisión de datos utilizado cuando se trabaja como proxy, así como en algunos funciones adicionales. Veamos cada tipo de proxy por separado.

Características del proxy HTTP

Comencemos con el proxy HTTP. Durante su trabajo, utilizan el protocolo HTTP, que está destinado a visitar sitios, descargar y transferir archivos y cuando trabajan con algunos programas que utilizan este protocolo para conectarse a través de un proxy. Las solicitudes realizadas cuando se trabaja con servidores proxy HTTP no se envían directamente, sino que utilizan el servidor proxy como intermediario, enviando solicitudes en su nombre.

El almacenamiento en caché también está disponible en el protocolo proxy HTTP, que acelera la carga de páginas mediante el uso de archivos guardados, además de monitorear y filtrar el tráfico de red, establecer límites de velocidad, bloquear recursos no deseados, recopilar estadísticas guardando registros, etc.

Los representantes de este protocolo difieren en el grado de anonimato. Destacan los siguientes: tipos HTTP Proxy de anonimato:

Proxy transparentes que no enmascaran la dirección IP real y tampoco ocultan el hecho de que se utiliza un servidor proxy para acceder al recurso. Estos proxies rara vez se utilizan, principalmente para redirigir al usuario a otro servidor proxy.

Proxy anónimo. Transmiten información que utilizan servidores proxy; sin embargo, su dirección IP se enmascara y se reemplaza con otra dirección IP, lo que proporciona un nivel confiable de seguridad.

Representantes de élite. Ocultan el uso de proxies y también enmascaran de forma fiable la dirección IP, lo que los convierte en los más seguros entre los proxies HTTP. El servidor al que intenta acceder asumirá que su conexión es directa, sin utilizar un servidor proxy.

También debemos destacar los proxies HTTPS que utilizan el protocolo SSL. Son un subconjunto del protocolo HTTP que utiliza una conexión segura. El tráfico de red transmitido por estos servidores proxy está cifrado de forma segura, lo que garantiza nivel más alto anonimato. Como regla general, estos proxies se utilizan para garantizar la seguridad de las redes bancarias, en organizaciones comerciales para crear redes corporativas seguras y en otras conexiones que requieren seguridad. Otras características son las mismas que las del protocolo HTTP.

Características del proxy Socks5

Otro protocolo popular entre los usuarios es Socks5. Los servidores proxy que trabajan con este protocolo son inicialmente anónimos porque permiten tráfico de red V forma pura sin exponer los encabezados HTTP. Por lo tanto, el servidor al que intentas acceder no sabrá que estás utilizando un servidor proxy ni recibirá tu dirección IP.

Proxy Socks5, admite lo siguiente protocolos de red: HTTP, HTTPS, FTP y sus características: almacenamiento en caché, conexión SSL,autenticación. Además, los proxies del protocolo Socks5 utilizan conexiones UDP y TPC, lo que amplía su ámbito de aplicación y los convierte en los servidores proxy más funcionales de los modernos. Inicialmente, el protocolo Socks5 estaba destinado a funcionar con software. Por este motivo, la mayoría de los programas admiten este protocolo para conectarse a través de un proxy. Los servidores proxy de Socks5 también tienen una característica interesante que le permite crear cadenas de servidores proxy, lo cual es útil para resolver ciertos problemas al trabajar en Internet.

Si compara los proxies HTTP y Socks5, es preferible utilizar este último. Como son más anónimos, apoyan más características y también trabajar con cualquier sitio y programa que admita la conexión a través de un proxy. Puede visitar nuestro sitio web realizando un pedido en su cuenta personal.

Buen día, queridos amigos, conocidos, lectores, admiradores y otras personas. En este artículo, como comprenderá por el título, hablaremos sobre lo que es MEDIAS servidor y por qué es necesario.

Por supuesto, esta información será más útil para las personas interesadas que para el usuario medio, pero, en principio, el conocimiento de estas cosas también puede serle útil... porque quién sabe cómo será la vida.

Descripción general y detallada de CALCETINES

Es un protocolo que permite que las aplicaciones de red se comuniquen a través de cortafuegos, bloqueando conexión directa. En este caso se utiliza un servidor intermedio especial, al que se permite el acceso a ambos clientes.

Transmite los datos recibidos del primer cliente al segundo y viceversa. A diferencia de, a través de MEDIAS un proxy puede permitir cualquier tráfico (digamos, ). Además MEDIAS transmite datos “limpios” sin añadir nada extra, por lo que es más difícil de detectar.

EN la vida cotidiana MEDIAS El proxy se utiliza con mayor frecuencia para acceder a sitios prohibidos. En esta situación, resulta que estás accediendo al servidor y no a una dirección de Internet prohibida, por lo que la conexión no está bloqueada.

La segunda razón por la que puedes utilizar estos servidores es por el anonimato, es decir, para ocultarte. En este caso, no eres tú quien establece la conexión con el servidor remoto de Internet, sino MEDIAS proxy, por lo que es poco probable que el servidor final reciba información sobre usted y su computadora.

Epílogo

Así son las cosas. Espero que ahora comprendas al menos aproximadamente qué es en general y por qué puede ser necesario en general.

Acerca de cómo trabajar específicamente con MEDIAS y otros representantes para ocultar sus IP se escribirá en un artículo aparte, a menos, por supuesto, que alguien lo necesite y esté interesado en él.

Como siempre, si tiene alguna pregunta, idea, adición, etc., bienvenido a comentar este material.

SOCKS, abreviatura de "SOCKetS" (sockets, sockets), está diseñado para permitir que las aplicaciones cliente/servidor en los dominios TCP y UDP utilicen servicios de firewall de manera conveniente y segura. Permite a los usuarios eludir el firewall de una organización y obtener acceso a recursos ubicados en Internet. SOCKS es un “intermediario de capa de aplicación”: interactúa con herramientas de red comunes (como Telnet y el navegador Netscape) y con servidor central(servidor proxy) establece comunicaciones con otras computadoras centrales en nombre de su computadora.

SOCKS fue desarrollado hace muchos años por Dave Koblas de SGI y hoy el código está disponible de forma gratuita en línea. Desde su lanzamiento inicial, este código ha pasado por varias modificaciones importantes, pero cada una de ellas se distribuyó de forma totalmente gratuita. La versión 4 de SOCKS aborda el problema del cruce inseguro del firewall por parte de aplicaciones cliente/servidor basadas en protocolo TCP, incluidos Telnet, FTP y protocolos de información populares como HTTP, Wide Area Information Server (WAIS) y GOPHER. SOCKS versión 5, RFC 1928, es una extensión adicional de SOCKS versión 4. Incluye UDP, amplía el marco general para permitir potentes esquemas de autenticación generalizada y amplía el sistema de direccionamiento para incluir nombres de dominio y direcciones IP v6.

Actualmente se propone crear un mecanismo para controlar los mensajes IP multicast entrantes y salientes que pasan a través del firewall. Esto se logra definiendo extensiones a los existentes. protocolo calcetines V.5, que crea la base para la transición del firewall autenticado mediante el tráfico de usuarios de unidifusión TCP y UDP. Sin embargo, debido al hecho de que el soporte UDP en versión actual SOCKS V.5 tiene problemas de escalabilidad y otras deficiencias (y definitivamente debería resolverse antes de pasar a la multidifusión), las extensiones se definen de dos maneras: cómo extensiones básicas UDP y como extensiones de multidifusión UDP.

El funcionamiento de SOCKS es reemplazar las llamadas estándar al sistema de red en la aplicación de sus versiones especiales. Estas nuevas llamadas al sistema establecen comunicación con el servidor proxy SOCKS (que es configurado por el usuario en la aplicación o archivo del sistema configuración) conectándose a un puerto conocido (normalmente el puerto 1080/TCP). Después de establecer una conexión con el servidor SOCKS, la aplicación envía al servidor el nombre de la máquina y el número de puerto al que el usuario desea conectarse. servidor de calcetines realmente establece una conexión con el control remoto computadora central y luego transfiere datos de forma transparente entre la aplicación y la máquina remota. En este caso, el usuario ni siquiera sospecha que hay un servidor SOCKS en el canal de comunicación.

La dificultad con el uso de SOCKS es que alguien tiene que hacer el trabajo de reemplazar las llamadas al sistema de red con versiones de SOCKS (este proceso generalmente se denomina "SOCKS-ificación" de la aplicación). Afortunadamente, la mayoría de las veces aplicaciones de red(Telnet, FTP, finger, whois) ya están compatibles con SOCKS y muchos proveedores incluyen soporte SOCKS en sus aplicaciones comerciales. Además, SOCKS V.5 incluye estas rutinas en su biblioteca compartida: en algunos sistemas (como máquinas Solaris), puede SOCKS automáticamente su aplicación colocando la biblioteca compartida SOCKS delante de “libc compartida” en la cadena de búsqueda de su biblioteca ( variable de entorno LD__LIBRARY_PATH en sistemas Solaris).

Hace un tiempo quise probar a implementar un servidor proxy para mis propias necesidades, y que pudiera usarse en el futuro, y además que su tamaño fuera mínimo. La opción natural para mí era la implementación mediante ensamblador. El programa resultó ser pequeño, conveniente y en el futuro lo usé con mucha frecuencia. Pero ahora, después de años, me gustaría mostrar implementación más simple un protocolo, SOCKS4. Este protocolo fue creado para que los clientes ubicados en red local para cortafuegos podría contactar red externa. Al mismo tiempo, en este caso, es posible controlar las solicitudes de los clientes :) Lo primero que necesita al implementar es leer la documentación con una descripción. de este protocolo, ya que queremos que nuestro protocolo sea entendido por programas estándar, sin “socavar con un archivo”. Entonces, la documentación:

Ahora, armados con una descripción, comencemos. El trabajo de un servidor proxy es aceptar una solicitud de un cliente en un formato determinado, generar un socket y conectarlo a la dirección solicitada por el cliente, y luego garantizar el intercambio de datos entre dos sockets hasta que el servidor los cierre. o cliente. Comencemos la implementación.

Macros y estructuras de datos utilizadas en el programa.

Creemos un archivo de inclusión, incluye.inc. EN este archivo colocamos los estándar, en escribiendo ventanas Programa macros + estructuras para trabajar con SOCKS4. Aquí no daré todas las macros, solo daré la descripción y funcionalidad necesaria para solucionar el problema principal, todo lo demás lo encontrarás en el archivo adjunto con códigos fuente.
; SOCKS4: la estructura utilizada por el cliente al solicitar una conexión; al servidor especificado (DSTIP)/puerto (DSTPORT) CONNECT_SOCK4 Struc VN Db?

¿CD Db?
DESTPORT Dw ?
DSTIP ¿Dd? NULO DB? CONNECT_SOCK4 finaliza; SOCKS4: respuesta del servidor proxy sobre la conexión. RESPONSE_SOCK4 Estructura VN Db?¿CD Db?
DESTPORT Dw?
* Y la tercera etapa final es el envío de datos entre el socket del cliente y el socket creado y conectado por nosotros a la dirección solicitada.

Implementación de la primera etapa, inicialización del programa:

; El procedimiento principal es el procedimiento de inicio para el programa WinMain Proc LOCAL ThreadId, hServSock:DWORD LOCAL hostname :BYTE LOCAL _wsa:WSADATA LOCAL _our:sockaddr_in; Al iniciar la biblioteca para trabajar con sockets, utilizamos la funcionalidad de la versión 1.1; solicitémoslo como mínimo invoque WSAStartup, 0101h, ADDR _wsa .if eax == 0 ; Tomamos nuestra dirección, preparamos una estructura para inicializar el socket del servidor invoke gethostname, ADDR hostname, 256 invoke gethostbyname, ADDR hostname .if eax == 0 invoke inet_addr, ADDR hostname .else mov eax, mov eax, mov eax, .endif mov _our.sin_addr, eax invoca inet_ntoa, eax mov _our.sin_family, AF_INET mov _our.sin_addr.S_un.S_addr, INADDR_ANY xor eax, eax; Ingrese el puerto en el que queremos escuchar los mensajes entrantes mov ax, SOCKS_PORT invoke htons, eax mov _our.sin_port, ax invoke socket, AF_INET, SOCK_STREAM, 0 .if eax != INVALID_SOCKET ; Guarde el socket del servidor creado mov hServSock, eax; Vinculamos el socket del servidor a nuestra dirección y el puerto requerido invocamos bind, hServSock, ADDR _our, TAMAÑO DE sockaddr_in .if eax != SOCKET_ERROR @@: ; Iniciar el socket para esperar invocar escuchar, hServSock, SOMAXCONN .repeat; Ha llegado un cliente, recibimos un socket con la invocación del cliente entrante aceptar, hServSock, NULL, NULL .hasta eax != INVALID_SOCKET ; Cree un hilo en el que se procesará el cliente actual xchg eax, ebx invoke CreateThread, NULL, NULL, ADDR socketThread, ebx, NULL, ADDR ThreadId; Dejamos a la espera de que los clientes jmp @B .endif .endif invoquen closesocket, hServSock .endif invoquen ExitProcess, 0 WinMain Endp
Este es nuestro primer procedimiento, intenté comentar el código tanto como sea posible para que usted pueda resolverlo, pero si algo aún no está claro, comuníquese conmigo o con MSDN. Básicamente, todo el código está escrito utilizando la sintaxis MASM y WinAPI. El resultado de la función anterior debería ser un enchufe que funcione en uno de direcciones de red tu auto ( dirección local, o una dirección externa si tiene una IP real) + según la conexión del cliente, la función crea un hilo separado que se utiliza para trabajar con el cliente entrante. Ahora sigamos adelante...

Segunda etapa, análisis de la solicitud del cliente.

En el segundo paso, todo lo que hay que hacer es aceptar una estructura CONNECT_SOCK4, crear un socket, intentar conectarlo y enviar una respuesta al cliente. Implementación:

SocketThread Proc sock:DWORD LOCAL lpMem, _csock, ThreadId, dAmount:DWORD LOCAL Remote:sockaddr_in LOCAL wrFds, rdFds:fd_set LOCAL hResp:RESPONSE_SOCK4; Preparándose para leer datos del socket, invoque FdZero, ADDR rdFds invoque FdSet, sock, ADDR rdFds invoque select, NULL, ADDR rdFds, NULL, NULL, NULL; Obtenemos el tamaño de los datos en espera de ser leídos. Invoque ioctlsocket, sock, FIONREAD, ADDR dAmount; Reservamos memoria para datos mov lpMem, @Result(LocalAlloc, LMEM_FIXED o LMEM_ZEROINIT, dAmount); Leer datos de solicitud desde la invocación del socket recv, sock, lpMem, dAmount, 0; La solicitud llegó lea edi, hResp mov esi, lpMem; Esi contiene una solicitud de usuario. Manejamos (aquí) sólo la versión SOCKS4, ; SOCKS5 puede, en principio, procesarse aquí, pero eso vendrá más adelante... Supongamos Esi: Ptr CONNECT_SOCK4 Supongamos Edi: Ptr RESPONSE_SOCK4 .if .VN == 4 ; Implementación del protocolo SOX 4 .if .CD == 1 invocar socket, AF_INET, SOCK_STREAM, 0 .if eax != INVALID_SOCKET mov _csock, eax ; tomamos los datos anfitrión remoto, con el que el cliente quiere conectarse mov Remote.sin_family, AF_INET mov ax, .DSTPORT mov Remote.sin_port, ax mov eax, .DSTIP mov Remote.sin_addr, eax mov cx, .DSTPORT mov edx, .DSTIP ; Edi contiene la respuesta al usuario mov .VN, 0 mov .DSTPORT, cx mov .DSTIP, edx ; Estamos tratando de conectarnos con servidor remoto invocar connect, _csock, ADDR Remoto, TAMAÑO DE Remoto .if !eax ; Estamos preparando una respuesta que hemos conectado mov .CD, 90 ; Enviamos al cliente una respuesta que contiene el resultado del intento de conexión invoke send, sock, ADDR hResp, SIZEOF RESPONSE_SOCK4, 0 ; Formamos una estructura con información del servidor y; enchufes de clientes conectados; - aquí por servidor me refiero al socket conectado al cliente; quién envió la solicitud; - por cliente me refiero a un socket conectado al servidor; cuyos datos fueron solicitados por el cliente mov ebx, @Result(LocalAlloc, LMEM_FIXED o LMEM_ZEROINIT, SIZEOF THREAD_DATA) Suponga Ebx: Ptr THREAD_DATA mov eax, _csock mov .Server, eax mov eax, sock mov .Client, eax Suponga Ebx: Nada; Iniciamos el hilo de procesamiento del socket (leyendo del cliente y transmitiendo al socket del servidor) invocamos CreateThread, NULL, NULL, ADDR ClientSock, ebx, NULL, ADDR ThreadId .else; Si la conexión falla, cierre el socket del cliente e invoque closesocket, _csock; Decimos que hubo un error de conexión mov , 91 ; Enviamos al cliente una respuesta que contiene el resultado del intento de conexión invoke send, sock, ADDR hResp, SIZEOF RESPONSE_SOCK4, 0 .endif .endif .endif .endif Supongamos Edi: Nada Supongamos Esi: Nada; Liberando la memoria asignada para la solicitud invocar LocalFree, lpMem ret socketThread Endp
El resultado de este procedimiento es un socket conectado, así como un hilo creado que implementa el intercambio de datos entre dos sockets. Es sencillo. Sólo hay que aclarar que aquí se utilizan varios puntos de direccionamiento dentro de las estructuras que se introdujeron en MASM para facilitar la vida del programador. Primer punto, la macro “Asumir”.
La línea Assume Esi: Ptr CONNECT_SOCK4 le dice al compilador que este registro (Esi) contiene la dirección de la estructura CONNECT_SOCK4, lo que simplifica aún más el acceso a las variables dentro de esta estructura. Supongamos Esi: Nada cancela la vinculación. Para comprenderlo mejor, podría ser más fácil si enumero algunas opciones de direcciones:
Supongamos que Esi:Ptr CONNECT_SOCK4 mov al, .VN; Colocamos en AL el valor del byte de la estructura variable VN mov al, .CD ; Coloque la variable CD mov ax en AL. .DSTPORT ; Coloque la variable DSTPORT en AX Supongamos Esi: Nada
o
mov al, ; Coloque el valor del byte de la variable VN en AL mov al,; Coloque la variable CD mov ax, ; Coloque la variable DSTPORT en AX
o
mov al, byte ptr; Coloque la variable VN en AL mov al, byte ptr; Coloque la variable CD en AL mov ax, palabra ptr; Coloque la variable DSTPORT en AX

Creo que para usted es obvio, al igual que para mí, que es más rápido, más conveniente y más claro utilizar la primera opción. Aunque, si es necesario hacer referencia a una variable de la estructura, la segunda opción tiene derecho a existir. Creo que es mejor utilizar la tercera opción en los casos en que los datos de la dirección no estén estructurados. Pero, como sabes, cada lobo de Tambov tiene su propio sabor y color. Utilice el método que le resulte más cómodo.
Un punto más que vale la pena aclarar. Macro de resultados. Esta macro se escribió para que pueda llamar a una función WinAPI en una línea y escribir el resultado de la ejecución en un registro o memoria. Entonces la línea:
mov lpMem, @Result(LocalAlloc, LMEM_FIXED o LMEM_ZEROINIT, dAmount)
Primero hace una llamada como esta:
invocar LocalAlloc, LMEM_FIXED o LMEM_ZEROINIT, dAmount
y después de la ejecución esta llamada el resultado de la ejecución (Eax) se almacena en la variable lpMem. En este caso particular, se asignará memoria y se escribirá en la variable la dirección en la que se encuentra el área asignada para nosotros.

Etapa tres, transferencia de datos

Así, se han completado las dos etapas más difíciles. Llegó el cliente, lo conectamos al servidor remoto y llegó el momento del trabajo “mono” más simple. Transfiere datos entre dos sockets. Hagámoslo rápida y fácilmente:
; Una secuencia que lee desde el socket del cliente y lo envía al socket del servidor.... ClientSock Proc Param:DWORD LOCAL sserver, sclient:DWORD LOCAL rdFds:fd_set LOCAL dAmount, lpBuf: DWORD; En Param tenemos información sobre los sockets del servidor y del cliente; transferir a variables locales mov ebx, Param Suponer Ebx: Ptr THREAD_DATA mov eax, .Server mov sserver, eax mov eax, .Client mov sclient, eax Suponer Ebx: Nada; No olvide liberar memoria, invocar LocalFree, Param @@: invocar FdZero, ADDR rdFds invocar FdSet, sserver, ADDR rdFds invocar FdSet, sclient, ADDR rdFds invocar select, NULL, ADDR rdFds, NULL, NULL, NULL; Compruebe si hay datos para leer.if eax == SOCKET_ERROR || eax == 0 ; Sin datos: salga de jmp @F .endif; ¿Hay datos del servidor que deban pasarse al cliente? invocar FdIsSet, sserver, ADDR rdFds .if eax; Obtenemos el tamaño de los datos en espera de ser leídos, invocamos ioctlsocket, sserver, FIONREAD, ADDR dAmount; Reservar memoria para datos mov lpBuf, @Result(LocalAlloc, LMEM_FIXED o LMEM_ZEROINIT, dAmount) invocar recv, sserver, lpBuf, dAmount, 0 .if eax == SOCKET_ERROR || eax == 0 jmp @F .endif invocar enviar, sclient, lpBuf, eax, 0 invocar LocalFree, lpBuf .endif; ¿Hay datos del cliente para enviar? zócalo del servidor
?
invocar FdIsSet, sclient, ADDR rdFds .if eax; Obtenemos el tamaño de los datos en espera de ser leídos, invocamos ioctlsocket, sclient, FIONREAD, ADDR dAmount; Reservar memoria para datos mov lpBuf, @Result(LocalAlloc, LMEM_FIXED o LMEM_ZEROINIT, dAmount) invocar recv, sclient, lpBuf, dAmount, 0 .if eax == SOCKET_ERROR || eax == 0 jmp @F .endif invocar enviar, sserver, lpBuf, eax, 0 invocar LocalFree, lpBuf .endif; Vamos a un nuevo ciclo jmp @B @@: ; Cerrar los sockets invocar closesocket, sserver invocar closesocket, sclient; Salga del hilo de invocación ExitThread, 0 ClientSock Endp Inicialmente, este procedimiento inicializa las variables internas de la estructura pasada a la secuencia para que su uso sea más cómodo. Luego, en el bucle, se verifica si hay datos para leer de los sockets, luego en dos fragmentos de código (en realidad copiar y pegar, aquí no me molesté en eliminar la función y optimizarla porque es más clara). ) leer desde un socket y enviarlo al segundo.– FireFox. En la configuración de conexión, especificamos que necesita utilizar un servidor proxy SOCKS4. Indicamos su dirección y el puerto en el que se encuentra. Después de eso, guardamos la configuración y disfrutamos de Internet, pasado a través de nuestro proxy, de 3,5 kbytes de tamaño))) Sí, lo aclararé. Para la compilación es necesario tener instalado el paquete