stringtranslate.com

Protocolo de tunelización

En las redes informáticas , un protocolo de túnel es un protocolo de comunicación que permite el movimiento de datos de una red a otra. Puede, por ejemplo, permitir que las comunicaciones de una red privada se envíen a través de una red pública (como Internet ) o que un protocolo de red se transmita a través de una red incompatible, mediante un proceso llamado encapsulación .

Debido a que la creación de túneles implica reempaquetar los datos de tráfico en una forma diferente, tal vez con cifrado como estándar, puede ocultar la naturaleza del tráfico que pasa a través de un túnel.

El protocolo de tunelización funciona utilizando la porción de datos de un paquete (la carga útil ) para transportar los paquetes que realmente brindan el servicio. El túnel utiliza un modelo de protocolo en capas como los del conjunto de protocolos OSI o TCP/IP , pero normalmente viola las capas cuando se utiliza la carga útil para transportar un servicio que normalmente no proporciona la red. Normalmente, el protocolo de entrega opera a un nivel igual o superior en el modelo en capas que el protocolo de carga útil.

Usos

Un protocolo de tunelización puede, por ejemplo, permitir que un protocolo externo se ejecute en una red que no admite ese protocolo en particular, como ejecutar IPv6 sobre IPv4 .

Otro uso importante es proporcionar servicios que no son prácticos o seguros para ofrecerse utilizando solo los servicios de red subyacentes, como proporcionar una dirección de red corporativa a un usuario remoto cuya dirección de red física no forma parte de la red corporativa.

Eludir la política de firewall

Los usuarios también pueden utilizar el túnel para "escabullirse" a través de un firewall, utilizando un protocolo que el firewall normalmente bloquearía, pero "envuelto" dentro de un protocolo que el firewall no bloquea, como HTTP . Si la política de firewall no excluye específicamente este tipo de "ajustamiento", este truco puede funcionar para eludir la política de firewall prevista (o cualquier conjunto de políticas de firewall entrelazadas).

Otro método de tunelización basado en HTTP utiliza el método/comando HTTP CONNECT . Un cliente emite el comando HTTP CONNECT a un proxy HTTP. Luego, el proxy establece una conexión TCP a un servidor:puerto en particular y transmite datos entre ese servidor:puerto y la conexión del cliente. [1] Debido a que esto crea un agujero de seguridad, los servidores proxy HTTP compatibles con CONNECT comúnmente restringen el acceso al método CONNECT. El proxy permite conexiones solo a puertos específicos, como 443 para HTTPS. [2]

Otros métodos de tunelización capaces de eludir los cortafuegos de la red utilizan diferentes protocolos como DNS , [3] MQTT , [4] SMS . [5]

Resumen técnico

Como ejemplo de capa de red sobre capa de red, la encapsulación de enrutamiento genérico (GRE), un protocolo que se ejecuta sobre IP ( número de protocolo IP 47), a menudo sirve para transportar paquetes IP, con direcciones privadas RFC 1918, a través de Internet utilizando paquetes de entrega con direcciones públicas. Direcciones IP. En este caso, los protocolos de entrega y de carga son los mismos, pero las direcciones de carga son incompatibles con las de la red de entrega.

También es posible establecer una conexión utilizando la capa de enlace de datos. El protocolo de túnel de capa 2 (L2TP) permite la transmisión de tramas entre dos nodos. Un túnel no está cifrado de forma predeterminada: el protocolo TCP/IP elegido determina el nivel de seguridad.

SSH utiliza el puerto 22 para permitir el cifrado de datos de cargas útiles que se transmiten a través de una conexión de red pública (como Internet), proporcionando así funcionalidad VPN . IPsec tiene un modo de transporte de extremo a extremo, pero también puede funcionar en modo túnel a través de una puerta de enlace de seguridad confiable.

Para comprender una pila de protocolos particular impuesta por el túnel, los ingenieros de redes deben comprender tanto la carga útil como los conjuntos de protocolos de entrega.

Protocolos de túneles comunes

Túnel Shell seguro

Un túnel Secure Shell (SSH) consta de un túnel cifrado creado a través de una conexión de protocolo SSH . Los usuarios pueden configurar túneles SSH para transferir tráfico no cifrado a través de una red a través de un canal cifrado . Es un enfoque basado en software para la seguridad de la red y el resultado es un cifrado transparente. [6]

Por ejemplo, las máquinas con Microsoft Windows pueden compartir archivos utilizando el protocolo Server Message Block (SMB), un protocolo no cifrado. Si uno montara un sistema de archivos de Microsoft Windows de forma remota a través de Internet, alguien que husmeara en la conexión podría ver los archivos transferidos. Para montar el sistema de archivos de Windows de forma segura, se puede establecer un túnel SSH que enrute todo el tráfico SMB al servidor de archivos remoto a través de un canal cifrado. Aunque el protocolo SMB en sí no contiene cifrado, el canal SSH cifrado a través del cual viaja ofrece seguridad.

Reenvío de puertos local y remoto con ssh ejecutado en la computadora azul.

Una vez que se ha establecido una conexión SSH, el túnel comienza con SSH escuchando un puerto en el  host remoto o local. Cualquier conexión a él se reenvía a la dirección especificada.  dirección y puerto con origen en el  host opuesto (remoto o local, como anteriormente).

Hacer un túnel de una carga útil que encapsula TCP (como PPP ) a través de una conexión basada en TCP (como el reenvío de puertos de SSH) se conoce como "TCP-sobre-TCP", y hacerlo puede inducir una pérdida dramática en el rendimiento de la transmisión (un problema conocido como "colapso de TCP"), [7] [8], razón por la cual el software de red privada virtual puede utilizar un protocolo más simple que TCP para la conexión del túnel. Sin embargo, esto no suele ser un problema cuando se utiliza el reenvío de puertos de OpenSSH, porque muchos casos de uso no implican un túnel TCP sobre TCP; la fusión se evita porque el cliente OpenSSH procesa la conexión TCP local del lado del cliente para llegar a la carga útil real que se está enviando, y luego envía esa carga útil directamente a través de la propia conexión TCP del túnel al lado del servidor, donde OpenSSH De manera similar, el servidor "desenvuelve" la carga útil para "envolverla" nuevamente y enrutarla a su destino final. [9] Naturalmente, este envolvimiento y desenvolvimiento también se produce en la dirección inversa del túnel bidireccional.

Los túneles SSH proporcionan un medio para eludir los firewalls que prohíben ciertos servicios de Internet, siempre que un sitio permita conexiones salientes. Por ejemplo, una organización puede prohibir que un usuario acceda a páginas web de Internet (puerto 80) directamente sin pasar por el filtro de proxy de la organización (que proporciona a la organización un medio para monitorear y controlar lo que el usuario ve a través de la web). Pero es posible que los usuarios no deseen que el filtro proxy de la organización supervise o bloquee su tráfico web. Si los usuarios pueden conectarse a un servidor SSH externo , pueden crear un túnel SSH para reenviar un puerto determinado en su máquina local al puerto 80 en un servidor web remoto. Para acceder al servidor web remoto, los usuarios deben apuntar su navegador al puerto local en http://localhost/

Algunos clientes SSH admiten el reenvío de puertos dinámico que permite al usuario crear un proxy SOCKS 4/5. En este caso, los usuarios pueden configurar sus aplicaciones para utilizar su servidor proxy SOCKS local. Esto brinda más flexibilidad que crear un túnel SSH a un solo puerto como se describió anteriormente. SOCKS puede liberar al usuario de las limitaciones de conectarse únicamente a un puerto y servidor remotos predefinidos. Si una aplicación no es compatible con SOCKS, se puede utilizar un proxy para redirigir la aplicación al servidor proxy SOCKS local. Algunos proxificadores, como Proxycap, admiten SSH directamente, evitando así la necesidad de un cliente SSH.

En versiones recientes de OpenSSH, incluso se permite crear túneles de capa 2 o 3 si ambos extremos han habilitado dichas capacidades de túnel. Esto crea interfaces virtuales tun(capa 3, predeterminada) o tap(capa 2) en ambos extremos de la conexión. Esto permite utilizar la administración y el enrutamiento de red normales y, cuando se usa en enrutadores, se puede tunelizar el tráfico de una subred completa. Un par de tapinterfaces virtuales funcionan como un cable Ethernet que conecta ambos extremos de la conexión y pueden unirse a puentes del núcleo.

Ciberataques basados ​​en túneles

A lo largo de los años, la tunelización y la encapsulación de datos en general se han adoptado con frecuencia por motivos maliciosos, con el fin de comunicarse maliciosamente fuera de una red protegida.

En este contexto, los túneles conocidos involucran protocolos como HTTP , [10] SSH , [11] DNS , [12] [13] MQTT . [14]

Ver también

Referencias

  1. ^ "Actualización a TLS dentro de HTTP/1.1". RFC 2817 . 2000 . Consultado el 20 de marzo de 2013 .
  2. ^ "Nota de vulnerabilidad VU#150227: las configuraciones predeterminadas del proxy HTTP permiten conexiones TCP arbitrarias". CERT de EE. UU . 2002-05-17 . Consultado el 10 de mayo de 2007 .
  3. ^ Raman, D., Sutter, BD, Coppens, B., Volckaert, S., Bosschere, KD, Danhieux, P. y Buggenhout, EV (noviembre de 2012). Túnel DNS para penetración de red. En Conferencia Internacional sobre Seguridad de la Información y Criptología (págs. 65-77). Springer, Berlín, Heidelberg.
  4. ^ Vaccari, I., Narteni, S., Aiello, M., Mongelli, M. y Cambiaso, E. (2021). Explotación de los protocolos de Internet de las cosas para actividades maliciosas de filtración de datos. Acceso IEEE, 9, 104261-104280.
  5. ^ Narteni, S., Vaccari, I., Mongelli, M., Aiello, M. y Cambiaso, E. (2021). Evaluando la posibilidad de perpetrar ataques de túnel explotando el servicio de mensajes cortos. Revista de servicios de Internet y seguridad de la información, 11, 30-46.
  6. ^ Barrett, Daniel J.; Barrett, Daniel J.; Silverman, Richard E.; Silverman, Richard (2001). SSH, Secure Shell: la guía definitiva. "O'Reilly Media, Inc.". ISBN 978-0-596-00011-0.
  7. ^ Titz, Olaf (23 de abril de 2001). "Por qué TCP sobre TCP es una mala idea". Archivado desde el original el 3 de enero de 2022 . Consultado el 3 de enero de 2023 .
  8. ^ Honda, Osamu; Ohsaki, Hiroyuki; Imase, Makoto; Ishizuka, Mika; Murayama, Junichi (octubre de 2005). "Comprensión de TCP sobre TCP: efectos de la tunelización TCP en el rendimiento y la latencia de un extremo a otro". En Atiquzzaman, Mahoma; Balandin, Sergey I (eds.). Rendimiento, calidad de servicio y control de redes de sensores y comunicaciones de próxima generación III . vol. 6011. Código bibliográfico : 2005SPIE.6011..138H. CiteSeerX 10.1.1.78.5815 . doi : 10.1117/12.630496. S2CID  8945952. 
  9. ^ Kaminsky, Dan (13 de junio de 2003). "Re: ¿Extensiones para redes largas y gruesas?". [email protected] (lista de correo). el código de reenvío TCP también es bastante rápido. Solo para responder previamente a una pregunta, ssh decapsula y vuelve a encapsular TCP, para que no tenga los problemas clásicos de TCP sobre TCP.
  10. ^ Pack, DJ, Streilein, W., Webster, S. y Cunningham, R. (2002). Detección de actividades de túnel HTTP. INSTITUTO DE MASSACHUSETTS DE TECH LEXINGTON LINCOLN LAB.
  11. ^ Dang, F., Li, Z., Liu, Y., Zhai, E., Chen, QA, Xu, T., ... y Yang, J. (junio de 2019). Comprender los ataques sin archivos en dispositivos iot basados ​​en Linux con Honeycloud. En actas de la 17ª Conferencia Internacional Anual sobre Sistemas, Aplicaciones y Servicios Móviles (págs. 482–493).
  12. ^ Raman, D., Sutter, BD, Coppens, B., Volckaert, S., Bosschere, KD, Danhieux, P. y Buggenhout, EV (noviembre de 2012). Túnel DNS para penetración de red. En Conferencia Internacional sobre Seguridad de la Información y Criptología (págs. 65-77). Springer, Berlín, Heidelberg.
  13. ^ Aiello, M., Mongelli, M., Cambiaso, E. y Papaleo, G. (2016). Creación de perfiles de ataques de túnel DNS con PCA e información mutua. Revista Lógica del IGPL, 24(6), 957-970.
  14. ^ Vaccari, I., Narteni, S., Aiello, M., Mongelli, M. y Cambiaso, E. (2021). Explotación de los protocolos de Internet de las cosas para actividades maliciosas de filtración de datos. Acceso IEEE, 9, 104261-104280.

enlaces externos