Eludir la inspección profunda de packs: tunelizar el tráfico mediante TLS VPN[

por calpee

En algunos países, los operadores de red emplean técnicas de inspección profunda de paquetes para bloquear ciertos tipos de tráfico. Por ejemplo, el tráfico de la red privada virtual (VPN) se puede analizar y bloquear para evitar que los usuarios envíen paquetes cifrados a través de dichas redes.[

Al observar que HTTPS funciona en todo el mundo (configurado para una gran cantidad de servidores web) y no se puede analizar fácilmente (la carga útil generalmente está encriptada), argumentamos que de la misma manera se pueden organizar los túneles VPN: enmascarando el Tráfico VPN con TLS o su versión anterior – SSL, podemos construir una red confiable y segura. Los paquetes, que se envían a través de dichos túneles, pueden cruzar varios dominios, que tienen varias políticas de seguridad (estrictas y no tan estrictas). A pesar de que el SSH puede usarse potencialmente para construir dicha red, tenemos evidencia de que en ciertos países las conexiones realizadas a través de dichos túneles se analizan estadísticamente: si la utilización de la red por dichos túneles es alta, existen ráfagas o las conexiones son de larga duración, luego, los operadores de red restablecen las conexiones TCP subyacentes.[

Por lo tanto, aquí hacemos un esfuerzo experimental en esta dirección: Primero, describimos diferentes soluciones VPN, que existen en Internet; y, en segundo lugar, describimos nuestro esfuerzo experimental con software basado en Python y Linux, que permite a los usuarios crear túneles VPN utilizando el protocolo TLS y el tráfico de pequeñas oficinas / oficinas en el hogar (SOHO) a través de dichos túneles.[

I. INTRODUCCIÓN[

Las redes privadas virtuales (VPN) son cruciales en la era moderna. Al encapsular y enviar el tráfico del cliente dentro de túneles protegidos, es posible que los usuarios obtengan servicios de red, que de otro modo serían bloqueados por un operador de red. Las soluciones VPN también son útiles cuando se accede a la red de intranet de una empresa. Por ejemplo, los empleados corporativos pueden acceder a la red interna de forma segura estableciendo una conexión VPN y dirigiendo todo el tráfico a través del túnel hacia la red corporativa. De esta forma pueden obtener servicios que de otra manera serían imposibles de obtener del mundo exterior.[

II. ANTECEDENTES[

Existen varias soluciones que se pueden utilizar para crear VPN. Un ejemplo son los protocolos de identidad de host (HIP) [7]. HIP es una solución de capa 3.5 (de hecho, está entre las capas de red y de transporte) y se diseñó inicialmente para dividir la función dual de las direcciones IP: identificador y localizador. Por servirnos de un ejemplo, una compañía llamada Tempered Networks usa el protocolo HIP para crear redes seguras (para obtener muestras, consulte [4]).[

Otra solución es el protocolo Secure Shell (o SSH). SSH es un protocolo de capa de aplicación que proporciona un canal encriptado para redes inseguras. SSH fue diseñado originalmente para proporcionar una línea de comandos remota segura, inicio de sesión y ejecución de comandos [5]. Pero, de hecho, cualquier servicio de red puede protegerse con SSH. Además, SSH da medios para crear túneles VPN entre las redes separadas espacialmente. Lamentablemente, la conexión SSH se puede analizar y bloquear (si estuviera tan popularizada como, por ejemplo, el protocolo TLS, las cosas podrían ser diferentes).[

Como SSH, OpenVPN [6] se ejecuta sobre el protocolo TCP (en verdad, OpenVPN también puede funcionar sobre el protocolo de transporte UDP). Tenemos prueba de que en ciertos países los gobiernos bloquean de manera exitosa OpenVPN. Por supuesto, es más bien difícil detectar estos protocolos, por el hecho de que el tráfico está encapsulado en las conexiones TCP / UDP. Aquí, se necesitan soluciones de inspección profunda de paquetes para bloquear eficazmente dichos túneles.[

Otro protocolo de capa 3 ampliamente utilizado para construir las VPN es el protocolo IPSec. [2]. La asociación de seguridad IPSec se puede detallar a través de claves antes compartidas o a través de protocolos de intercambio de claves de Internet (IKE y también IKEv2) [1]. Debido a que IPsec se ejecuta de forma directa sobre el protocolo IP, se puede detectar de manera fácil sin el uso de sofisticadas soluciones de inspección de packs.[

III. HARDWARE, SOFTWARE Y ARQUITECTURA[

En la Figura 1 mostramos la vista general de la arquitectura. Tenga en cuenta que asumimos que el cuadro de cliente SOHO VPN es un cuadro de Linux separado, no está en la ruta y está dentro de la Intranet.[

Para implementar el cliente y el servidor VPN, hemos utilizado el framework Python y la distribución Ubuntu Linux. La implementación consta de aproximadamente 1.2K líneas de código (LOC) y todas las funciones se realizan en el espacio de usuario. Hemos expuesto la implementación en nuestro repositorio git [3] a fin de que todos puedan emplearlo sin cargo.[

A lo largo de los experimentos, sin embargo, hemos considerado la siguiente configuración. Para el hardware, hemos seleccionado una microinstancia de DigitalOcean. La instancia tenía una CPU de un solo núcleo, 25 GB de almacenaje de datos, 1 GB de memoria de acceso aleatorio y se encontraba situada en Novedosa York, EE. UU. El cliente VPN estaba ubicado en Tashkent, Uzbekistán, y se encontraba girando en un microcontrolador Raspberry PI. Así imitamos el enrutador SOHO. Asimismo hemos usado wget herramienta para medir el rendimiento, y hemos empleado ping utilidad para medir los tiempos de ida y vuelta.[

IV. EVALUACIÓN EXPERIMENTAL[

Hemos efectuado varios ensayos a lo largo de nuestro trabajo. El primer experimento se relacionó con el envío de mensajes de ping al servidor DNS de Google plus y la observación de las diferencias en los tiempos de ida y vuelta (básicamente, hemos comparado los tiempos de ida y vuelta entre el ambiente en el que se encontraba presente el túnel y el ambiente en el que lo logró el túnel no existe).[

Arquitectura del prototipo[

A continuación, nos sentamos a medir el desempeño entre las máquinas locales y recónditas. Básicamente, hemos realizado 50 mediciones para un ambiente, en el que el tráfico iba dentro del túnel y el mismo número de mediciones para el ambiente, en el que el tráfico iba normalmente (o sea, sin cifrar y no encapsulado en packs TLS). Para medir el desempeño, hemos utilizado wget herramienta para descargar el fichero del kernel de Linux1 (1,3 MB) de Internet.[

En la Figura 2 exponemos la distribución de los tiempos de ida y vuelta (RTT). El RTT medio para la conexión VPN fue de 293,7 ms y el RTT medio para ICMP simple fue de 103,3 ms.[

Distribución de RTT[

En la Figura 3 mostramos la distribución del desempeño logrado tanto para túneles protegidos con TLS para conexiones TCP regulares. El valor de rendimiento medio de la conexión VPN fue de 608,7 Kb / s, y el desempeño medio de la conexión TCP fácil fue de 1890,4 Kb / s. Dados estos desenlaces, consideramos que en un caso así el cuello de botella es nuestra implementación. No obstante, creemos que nuestra implementación del túnel VPN es lo suficientemente buena para la mayor parte de las configuraciones de oficinas pequeñas.[

Distribución de rendimientos[

V. POSIBLE EXTENSIÓN[

Más allá de que el túnel estuvo andando a lo largo de múltiples horas sin interrupción y hemos establecido la cubierta de autenticación, todavía hemos visto varios intentos de conexión, aunque sin éxito, del mundo exterior. Para el futuro, planeamos esconder el servidor VPN tras el servidor web, de modo que solo los usuarios que conocen un cierto misterio logren acceder al servidor VPN. La iniciativa es bien simple: en el momento en que el usuario llama mandando peticiones HTTP GET a una página segrega, el servidor web abre un puerto y dirige nuevamente el tráfico del cliente al servidor VPN. Una vez establecida la conexión, el servidor cierra el puerto.[

VI. CONCLUSIONES[

En este breve informe, hemos intentado detallar de qué forma los operadores de red pueden denegar las resoluciones VPN. Argumentamos que el tráfico de VPN aún se puede esconder a los observadores, enmascarando los túneles mediante el protocolo TLS. Nuestros experimentos proponen que este enfoque es útil en el momento en que se precisa un canal seguro, pero los operadores de red están ansiosos por denegar el tráfico de VPN.[

Aunque es bien difícil hacer negocios con esta solución (en un largo plazo, los operadores de red tienen la posibilidad de sencillamente denegar todas las direcciones IP que forman parte a servidores VPN, alojados por una empresa), argumentamos, sin embargo, que las personas tienen la posibilidad de utilizar este software y también implementarlo. en sus propias máquinas en la nube (tienen la posibilidad de sostener en secreto las direcciones IP de los servidores). Así, hay escasas posibilidades de que los operadores de red puedan detectar las direcciones IP de los servidores: (i) el tráfico se va a ver como el tráfico HTTPS habitual (al final, el túnel SSL se usa empleando los puertos HTTPS predeterminados); (ii) es una tarea bastante compleja para los operadores de red escanear todas y cada una de las direcciones IP y hallar aquellas que se usan para enviar tráfico VPN.[

Pusimos el programa predisposición para su descarga en una página de GitHub. Aguardamos que este emprendimiento pueda lograr que Internet sea más liberal en determinados países.[

REFERENCIAS[

[1] Intercambio de claves por Internet. https://en.wikipedia.org/wiki/Internet_Key_Exchange[

[2] IPSec. https://en.wikipedia.org/wiki/IPsec[

[3] Cliente y servidor SOHO VPN. https://github.com/dmitriykuptsov/soho-vpn-over-tls/[

[4] Las redes templadas simplifican la microsegmentación y la conectividad de red segura. https://www.networkworld.com/article/3405853/tempered-networks-simplifies-secure-network-connectivity-and-microsegmentation.html[

[5] DJ Barrett, RE Silverman y RG Byrnes. SSH, Secure Shell: la guía definitiva. O’Reilly Media, Inc., 2005[

[6] M. Feilner. OpenVPN: Creación e integración de redes privadas virtuales: aprenda a hacer VPN seguras con esta fuerte aplicación de código abierto. Packt Publishing, 2006.[

[7] A. Gurtov. Protocolo de identidad de host (HIP): Hacia una Internet móvil inteligente segura. Serie Wiley sobre redes de comunicaciones y sistemas organizados. Wiley, 2008.[

1https://mirrors.edge.kernel.org/pub/linux/kernel/v1.0/linux-1.0.tar.gz[

You may also like