En 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. Por ejemplo, permite enviar comunicaciones privadas a través de una red pública (como Internet ) o transmitir un protocolo de red a través de una red incompatible, mediante un proceso llamado encapsulación .
Dado que la tunelización implica reempaquetar los datos de tráfico en un formato diferente, posiblemente con cifrado de serie, puede ocultar la naturaleza del tráfico que pasa a través del túnel.
Los protocolos de tunelización funcionan 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 por capas, como los de la suite OSI o TCP/IP , pero suele incumplir esta estructura cuando utiliza la carga útil para transportar un servicio que normalmente no proporciona la red. Por lo general, el protocolo de entrega opera en un nivel igual o superior dentro del modelo de capas que el protocolo de carga útil.
Usos
Un protocolo de tunelización puede, por ejemplo, permitir que un protocolo externo se ejecute sobre una red que no admite ese protocolo en particular, como por ejemplo ejecutar IPv6 sobre IPv4 .
Otro uso importante es proporcionar servicios que no serían prácticos o seguros si se ofrecieran utilizando únicamente los servicios de red subyacentes, como por ejemplo, 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 del cortafuegos
Los usuarios también pueden usar la tunelización para "saltarse" un cortafuegos, utilizando un protocolo que normalmente bloquearía, pero "envuelto" dentro de un protocolo que el cortafuegos no bloquea, como HTTP . Si la política del cortafuegos no excluye específicamente este tipo de "envoltura", este truco puede funcionar para sortear la política de cortafuegos prevista (o cualquier conjunto de políticas de cortafuegos interconectadas).
Otro método de tunelización basado en HTTP utiliza el método/comando HTTP CONNECT . Un cliente envía el comando HTTP CONNECT a un proxy HTTP. El proxy establece entonces una conexión TCP con un servidor y puerto específicos, y retransmite los datos entre dicho servidor y la conexión del cliente. [ 1 ] Debido a que esto crea una vulnerabilidad de seguridad, los proxies HTTP compatibles con CONNECT suelen restringir el acceso a este método. El proxy permite conexiones únicamente a puertos específicos, como el 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 ] y SMS . [ 5 ]
Descripción general técnica
Como ejemplo de superposición de capas de red, el protocolo GRE ( Generic Routing Encapsulation ), que se ejecuta sobre IP ( protocolo IP número 47), se utiliza a menudo para transportar paquetes IP con direcciones privadas RFC 1918 a través de Internet mediante paquetes de entrega con direcciones IP públicas. En este caso, los protocolos de entrega y de 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 tunelización 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 habilitar el cifrado de datos de las cargas útiles que se transmiten a través de una conexión de red pública (como Internet), proporcionando así la funcionalidad de VPN . IPsec tiene un modo de transporte de extremo a extremo, pero también puede operar en modo túnel a través de una puerta de enlace de seguridad de confianza.
Para comprender una pila de protocolos específica impuesta por el tunelizado, los ingenieros de redes deben comprender tanto la carga útil como los conjuntos de protocolos 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 sobre Ethernet
- GINEBRA
- WireGuard (puerto dinámico UDP)
Problema de colapso de TCP
El tunelizado de una carga útil encapsulada en 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 colapso de TCP , [ 6 ] [ 7 ] razón por la cual el software de red privada virtual (VPN) puede utilizar un protocolo más simple que TCP para la conexión del túnel.
El rendimiento de una conexión TCP-over-TCP puede degradarse debido a que los bucles de control en los TCP interno y externo interfieren destructivamente entre sí. [ 8 ] [ 9 ] Dado que TCP está diseñado para garantizar la entrega de paquetes completa y en orden, el TCP externo enmascara el estado de la conexión para el TCP interno. En el funcionamiento normal de TCP, la pérdida de paquetes se detecta cuando el receptor responde con ACK duplicados a un paquete recibido antes del paquete faltante en la secuencia. En respuesta, el remitente retransmite el paquete perdido y reduce a la mitad la Ventana de Congestión (CWND). En TCP-over-TCP, el TCP externo maneja los paquetes perdidos normalmente a través de la retransmisión y la reducción de CWND. Sin embargo, dado que el TCP interno no ha recibido ninguna información que indique latencia en la conexión, continúa transmitiendo paquetes a la velocidad actualmente gobernada por su CWND.
Debido a que el CWND del TCP interno es mayor que el del TCP externo, el búfer de envío del TCP externo termina por llenarse. A medida que el búfer se llena, los paquetes experimentan retrasos de cola más prolongados y variables antes de la transmisión, lo que aumenta el tiempo de ida y vuelta (RTT) medido del TCP externo y su variabilidad. Esto incrementa su tiempo de espera de retransmisión (RTO). Una vez que el búfer de envío se llena, el proceso del túnel ya no puede reenviar confirmaciones (ACK) del TCP interno, por lo que este deja de recibirlas por completo.
Debido a que el TCP interno ya no recibe confirmaciones (ACK), su tiempo de espera de retorno (RTO) expira, lo que provoca que retransmita el segmento no confirmado más antiguo y duplique su RTO. El RTO del TCP interno crece exponencialmente porque se duplica con cada tiempo de espera, y no se reciben confirmaciones para reiniciarlo.
El resultado de un fallo del protocolo TCP es un TCP externo con un CWND muy reducido, un RTO inflado y un búfer de envío lleno. Esto indica que el TCP interno no puede escribir y que no se envían confirmaciones (ACK) en ninguna dirección.
Túnel Secure Shell
Un túnel Secure Shell (SSH) consiste en un túnel cifrado creado mediante 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 de seguridad de red basado en software, cuyo resultado es un cifrado transparente. [ 10 ]
Por ejemplo, los equipos con Microsoft Windows pueden compartir archivos mediante el protocolo SMB ( Server Message Block ), un protocolo no cifrado. Si se intentara acceder remotamente a un sistema de archivos de Microsoft Windows a través de Internet, alguien que interceptara la conexión podría ver los archivos transferidos. Para acceder de forma segura al sistema de archivos de Windows, 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 utiliza cifrado, el canal SSH cifrado por el que se transmite ofrece seguridad.
Una vez establecida la conexión SSH, el túnel comienza con SSH escuchando en un puerto del host remoto o local. Cualquier conexión que se dirija a él se reenvía a la dirección y puerto especificados desde el host opuesto (remoto o local, como se indicó anteriormente).
El problema de colapso de TCP a menudo no es un problema cuando se utiliza el reenvío de puertos de OpenSSH, porque muchos casos de uso no implican túneles TCP sobre TCP; el colapso 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. [ 11 ] Naturalmente, este envoltorio y desenvoltorio también ocurre en la dirección inversa del túnel bidireccional.
Los túneles SSH proporcionan un medio para sortear los cortafuegos 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 directamente a páginas web de Internet (puerto 80) sin pasar por el filtro proxy de la organización (que proporciona a la organización un medio para monitorizar y controlar lo que el usuario ve a través de la web). Pero es posible que los usuarios no deseen que su tráfico web sea monitorizado o bloqueado por el filtro proxy de la organización. 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 dirigirían su navegador al puerto local en http://localhost/
Algunos clientes SSH admiten el reenvío dinámico de puertos , lo 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 ofrece mayor flexibilidad que la creación de un túnel SSH a un único puerto, como se describió anteriormente. SOCKS libera 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 proxifier para redirigirla al servidor proxy SOCKS local. Algunos proxifiers, 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 capa 3 si ambos extremos tienen habilitadas dichas capacidades. Esto crea interfaces virtuales tun(capa 3, por defecto) o tap(capa 2) en ambos extremos de la conexión. Esto permite el uso normal de la gestión y el enrutamiento de red, y cuando se utiliza en enrutadores, se puede tunelizar el tráfico de toda una subred. Un par de tapinterfaces virtuales funcionan como un cable Ethernet que conecta ambos extremos de la conexión y pueden unirse a puentes del kernel.
Ciberataques basados en túneles
A lo largo de los años, el tunelizado y la encapsulación de datos se han utilizado en muy raras ocasiones con fines maliciosos, para comunicarse de forma maliciosa fuera de una red protegida.
En este contexto, los túneles conocidos involucran protocolos como HTTP , [ 12 ] SSH , [ 13 ] DNS , [ 3 ] [ 14 ] MQTT . [ 4 ]
Véase también
Referencias
- ↑ "Actualización a TLS dentro de HTTP/1.1" . RFC 2817. 2000. Consultado el 20 de marzo de 2013 .
- ↑ "Nota de vulnerabilidad VU#150227: Las configuraciones predeterminadas del proxy HTTP permiten conexiones TCP arbitrarias" . US-CERT . 17 de mayo de 2002. Consultado el 10 de mayo de 2007 .
- ^ 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.
- 1 2 Vaccari, I., Narteni, S., Aiello, M., Mongelli, M., & Cambiaso, E. (2021). Explotación de protocolos de Internet de las cosas para actividades maliciosas de exfiltración de datos. IEEE Access, 9, 104261-104280.
- ↑ Narteni, S., Vaccari, I., Mongelli, M., Aiello, M., & 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.
- ↑ Titz, Olaf (23 de abril de 2001). "Por qué TCP sobre TCP es una mala idea" . Archivado del original el 3 de enero de 2022. Consultado el 3 de enero de 2023 .
- ↑ Honda, Osamu; Ohsaki, Hiroyuki; Imase, Makoto; Ishizuka, Mika; Murayama, Junichi (octubre de 2005). "Understanding TCP over TCP: effects of TCP tunneling on end-to-end throughput and latency". En Atiquzzaman, Mohammed; Balandin, Sergey I (eds.). Performance, Quality of Service, and Control of Next-Generation Communication and Sensor Networks III . Vol. 6011. Bibcode : 2005SPIE.6011..138H . CiteSeerX 10.1.1.78.5815 . doi : 10.1117/12.630496 . S2CID 8945952 .
- ↑ Pérez, PJ (26 de junio de 2025). "TCP sobre TCP es una mala idea" . Archivado del original el 28 de junio de 2025. Recuperado el 13 de febrero de 2026 .
- ↑ Computerphile (15 de abril de 2020). TCP Meltdown - Computerphile . Recuperado el 15 de febrero de 2026 a través de YouTube.
- ↑ Barrett, Daniel J.; Barrett, Daniel J.; Silverman, Richard E.; Silverman, Richard (2001). SSH, el shell seguro: la guía definitiva . O'Reilly Media, Inc. ISBN 978-0-596-00011-0.
- ↑ Kaminsky, Dan (13 de junio de 2003). "Re: ¿Extensiones para redes largas y anchas?" . openssh-unix-dev@mindrot.org (Lista de correo).
El código de reenvío TCP también es bastante rápido. Para responder de antemano a una pregunta, ssh desencapsula y vuelve a encapsular TCP, por lo que no tienes los problemas clásicos de TCP sobre TCP.
- ↑ Pack, DJ, Streilein, W., Webster, S., & Cunningham, R. (2002). Detección de actividades de tunelización HTTP. MASSACHUSETTS INST OF TECH LEXINGTON LINCOLN LAB.
- ↑ Dang, F., Li, Z., Liu, Y., Zhai, E., Chen, QA, Xu, T., ... & Yang, J. (2019, junio). Comprensión de 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).
- ↑ Aiello, M., Mongelli, M., Cambiaso, E., & 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.
Enlaces externos
- Solución de tunelización y reenvío distribuido PortFusion 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 túneles HTTP y UDP en Windows.
- Proyecto VpnHood: implementación gratuita de código abierto de una VPN mediante redirección de sockets.
- Protocolos de tunelización
- protocolos de red
- Ingeniería de ciberseguridad