Protocolo de tunelización
Protocolo de comunicación informática
Conjunto de protocolos de Internet
Capa de aplicación
Capa de transporte
Capa de Internet
Capa de enlace

En las redes informáticas , un protocolo de tunelización 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 encapsulamiento .

Debido a que la tunelización implica reempaquetar los datos de tráfico en un formato diferente, quizás con cifrado como estándar, puede ocultar la naturaleza del tráfico que pasa por un túnel.

El protocolo de tunelización funciona utilizando la parte de datos de un paquete (la carga útil ) para transportar los paquetes que realmente proporcionan el servicio. La tunelización utiliza un modelo de protocolo en capas, como los de la suite de protocolos OSI o TCP/IP , pero normalmente viola la estratificación cuando se utiliza la carga útil para transportar un servicio que normalmente no proporciona la red. Normalmente, el protocolo de entrega funciona 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 en IPv4 .

Otro uso importante es proporcionar servicios que no son prácticos o seguros si se ofrecen 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 es parte de la red corporativa.

Cómo eludir la política del firewall

Los usuarios también pueden utilizar la tunelización 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 del firewall no excluye específicamente este tipo de "envoltura", este truco puede funcionar para eludir la política del firewall prevista (o cualquier conjunto de políticas de firewall interconectadas).

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. A continuación, el proxy establece una conexión TCP con un puerto de servidor en particular y retransmite datos entre ese puerto de servidor y la conexión del cliente. [1] Debido a que esto crea un agujero de seguridad, los proxies HTTP con capacidad CONNECT suelen restringir 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 red utilizan diferentes protocolos como DNS , [3] MQTT , [4] SMS . [5]

Descripción técnica

Como ejemplo de capa de red sobre capa de red, el encapsulamiento de enrutamiento genérico (GRE), un protocolo que se ejecuta sobre IP ( protocolo IP número 47), suele servir para transportar paquetes IP, con direcciones privadas RFC 1918, por Internet utilizando paquetes de entrega con direcciones IP públicas. En este caso, los protocolos de entrega y carga útil son los mismos, pero las direcciones de carga útil son incompatibles con las de la red de entrega.

También es posible establecer una conexión mediante 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 por defecto: el protocolo TCP/IP elegido determina el nivel de seguridad.

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

Para comprender una pila de protocolos particular impuesta por la tunelización, los ingenieros de redes deben comprender tanto los conjuntos de protocolos de carga útil como de entrega.

Protocolos de tunelización comunes

  • IP en IP (protocolo IP 4): IP en IPv4/IPv6
  • SIT/IPv6 (protocolo IP 41): IPv6 en IPv4/IPv6
  • GRE (protocolo IP 47): encapsulación de enrutamiento genérico
  • OpenVPN (puerto UDP 1194)
  • SSTP (puerto TCP 443): Protocolo de tunelización de sockets seguros
  • IPSec (protocolos IP 50 y 51): seguridad del protocolo de Internet
  • L2TP (puerto UDP 1701): Protocolo de tunelización de capa 2
  • L2TPv3 (protocolo IP 115): Protocolo de tunelización de capa 2 versión 3
  • VXLAN (puerto UDP 4789): Red de área local virtual extensible
  • PPTP (puerto TCP 1723 para control, GRE para datos): Protocolo de tunelización punto a punto
  • PPPoE (EtherType 0x8863 para control, 0x8864 para datos): Protocolo punto a punto a través de Ethernet
  • GINEBRA
  • WireGuard (puerto dinámico UDP)

Problema de fusión del TCP

La tunelización de una carga útil que encapsula TCP (como PPP ) sobre 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 drástica en el rendimiento de la transmisión, conocida como el problema de fusión de TCP [6] [7], por lo que el software de red privada virtual (VPN) puede utilizar en su lugar un protocolo más simple que TCP para la conexión del túnel. La fusión de TCP se produce cuando una conexión TCP se apila sobre otra. La capa subyacente puede detectar un problema e intentar compensarlo, y la capa superior sobrecompensa debido a eso, y esta sobrecompensación causa dichos retrasos y un rendimiento de transmisión degradado.

Túnel de Secure Shell

Un túnel Secure Shell (SSH) consiste en 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 mediante un canal cifrado . Se trata de un enfoque basado en software para la seguridad de la red y el resultado es un cifrado transparente. [8]

Por ejemplo, las máquinas Microsoft Windows pueden compartir archivos mediante el protocolo Server Message Block (SMB), un protocolo no cifrado. Si se montara un sistema de archivos Microsoft Windows de forma remota a través de Internet, alguien que espiara la conexión podría ver los archivos transferidos. Para montar el sistema de archivos Windows de forma segura, se puede establecer un túnel SSH que dirija 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 locales y remotos 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 al host especificado.  dirección y puerto de origen del  host opuesto (remoto o local, como anteriormente).

El problema de la fusión de TCP no suele ser un problema cuando se utiliza el reenvío de puertos de OpenSSH, porque muchos casos de uso no implican la tunelización 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 el servidor OpenSSH de manera similar "desenvuelve" la carga útil para "envolverla" nuevamente para enrutarla a su destino final. [9] Naturalmente, este envoltura y desenrollado también ocurre en la dirección inversa del túnel bidireccional.

Los túneles SSH proporcionan un medio para eludir los cortafuegos que prohíben determinados servicios de Internet, siempre que un sitio permita conexiones salientes. Por ejemplo, una organización puede prohibir a un usuario acceder a páginas web de Internet (puerto 80) directamente sin pasar por el filtro proxy de la organización (que proporciona a la organización un medio para supervisar 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 de su máquina local al puerto 80 de un servidor web remoto. Para acceder al servidor web remoto, los usuarios apuntarían 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 que utilicen su servidor proxy SOCKS local. Esto proporciona más flexibilidad que la creación de un túnel SSH a un único 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 admite SOCKS, se puede utilizar un proxy para redirigir la aplicación al servidor proxy SOCKS local. Algunos proxys, como Proxycap, admiten SSH directamente, lo que evita la necesidad de un cliente SSH.

En versiones recientes de OpenSSH, incluso se permite crear túneles de capa 2 o capa 3 si ambos extremos tienen habilitadas dichas capacidades de tunelización. Esto crea interfaces virtuales tun(capa 3, predeterminadas) o tap(capa 2) en ambos extremos de la conexión. Esto permite utilizar la gestión y el enrutamiento de red normales y, cuando se utiliza 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 de kernel.

Ciberataques basados ​​en tunelización

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]

Véase 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". US-CERT . 2002-05-17 . Consultado el 2007-05-10 .
  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 protocolos de Internet de las cosas para actividades de exfiltración de datos malintencionadas. IEEE Access, 9, 104261-104280.
  5. ^ Narteni, S., Vaccari, I., Mongelli, M., Aiello, M. y Cambiaso, E. (2021). Evaluación de la posibilidad de perpetrar ataques de tunelización explotando el servicio de mensajes cortos. Journal of Internet Services and Information Security, 11, 30-46.
  6. ^ 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 .
  7. ^ 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 extremo a extremo". En Atiquzzaman, Mohammed; Balandin, Sergey I (eds.). Rendimiento, calidad de servicio y control de las redes de sensores y comunicaciones de próxima generación III . Vol. 6011. Bibcode :2005SPIE.6011..138H. CiteSeerX 10.1.1.78.5815 . doi :10.1117/12.630496. S2CID  8945952. 
  8. ^ Barrett, Daniel J.; Barrett, Daniel J.; Silverman, Richard E.; Silverman, Richard (2001). SSH, el Secure Shell: La guía definitiva. "O'Reilly Media, Inc." ISBN 978-0-596-00011-0.
  9. ^ Kaminsky, Dan (13 de junio de 2003). "Re: Extensiones para redes largas y pesadas?". [email protected] (lista de correo). El código de reenvío TCP también es bastante rápido. Solo para responder una pregunta de antemano, ssh desencapsula y vuelve a encapsular TCP, por lo que no tienes problemas clásicos de TCP sobre TCP.
  10. ^ Pack, DJ, Streilein, W., Webster, S. y Cunningham, R. (2002). Detección de actividades de tunelización HTTP. MASSACHUSETTS INST OF TECH LEXINGTON LINCOLN LAB.
  11. ^ Dang, F., Li, Z., Liu, Y., Zhai, E., Chen, QA, Xu, T., ... y Yang, J. (junio de 2019). En las Actas de la 17.ª Conferencia internacional anual sobre sistemas, aplicaciones y servicios móviles (pp. 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). Perfilado de ataques de tunelización DNS con PCA e información mutua. Logic Journal of the IGPL, 24(6), 957-970.
  14. ^ Vaccari, I., Narteni, S., Aiello, M., Mongelli, M. y Cambiaso, E. (2021). Explotación de protocolos de Internet de las cosas para actividades de exfiltración de datos malintencionadas. IEEE Access, 9, 104261-104280.
  • PortFusion: solución distribuida de tunelización y proxy de reenvío local, de reenvío inverso/reenvío para todos los protocolos TCP
  • Túnel VPN SSH, consulte la sección REDES PRIVADAS VIRTUALES BASADAS EN SSH
  • Proyecto BarbaTunnel: implementación gratuita de código abierto de HTTP-Tunnel y UDP-Tunnel en Windows
  • Proyecto VpnHood: implementación gratuita de código abierto de una VPN mediante redirección de sockets
Retrieved from "https://en.wikipedia.org/w/index.php?title=Tunneling_protocol&oldid=1247462376"