Redirección de puertos y túneles SSH

Comprometes una máquina y descubres que está conectada a una red interna que tú no puedes alcanzar directamente. Esa máquina es tu pivote: el puente para llegar a lo que hay detrás. El pivoting es la técnica que convierte "tengo una máquina" en "tengo acceso a toda la red", y es lo que separa una intrusión anecdótica de un compromiso serio.

1. El problema: redes segmentadas

Las organizaciones separan sus redes: la DMZ (lo accesible desde fuera) de la red corporativa, y esta de las redes más sensibles (bases de datos, sistemas industriales). Un servidor web de la DMZ puede hablar con la base de datos interna, pero tú, desde Internet, no puedes hablar con esa base de datos. Cuando comprometes el servidor web, heredas su conectividad: él sí ve la red interna. El pivoting consiste en usar su posición de red para que tu tráfico llegue a donde él llega.

La pieza que lo hace posible casi siempre es SSH, porque además de dar shell sabe reenviar puertos a través de la conexión cifrada. Entender sus tres modos de reenvío es el núcleo de este módulo.

2. Reenvío local: -L

El reenvío local abre un puerto en tu máquina que, a través del túnel SSH, sale por el pivote hacia un destino que solo él alcanza. Sintaxis: -L [puerto_local]:[destino]:[puerto_destino].

$ ssh -L 8001:10.13.0.10:80 leo@pivote -N
# ahora http://127.0.0.1:8001 en TU máquina = http://10.13.0.10:80 visto desde el pivote

Es de uno en uno: cada -L conecta un puerto local con un destino concreto. Ideal cuando sabes exactamente a qué servicio interno quieres llegar. La opción -N dice "no ejecutes ningún comando, solo el túnel"; -f lo manda a segundo plano.

3. Reenvío remoto: -R

El reenvío remoto es el inverso: abre un puerto en el pivote (o en la máquina remota) que reenvía hacia un destino que tú alcanzas. Sintaxis: -R [puerto_remoto]:[destino]:[puerto_destino].

$ ssh -R 9001:127.0.0.1:80 usuario@pivote -N
# el puerto 9001 del pivote reenvía a TU 127.0.0.1:80

Se usa sobre todo en dos situaciones: cuando tienes una shell inversa en el objetivo y quieres traer un puerto interno hacia ti, o cuando necesitas exponer un servicio tuyo (un servidor de payloads) a una red interna a la que el objetivo sí llega. Es la herramienta del "hacia dentro no puedo conectar, pero desde dentro sí pueden conectarme".

4. Reenvío dinámico: -D (SOCKS) y proxychains

Los reenvíos -L y -R son de puerto en puerto: tediosos si quieres explorar toda una red. El reenvío dinámico resuelve eso: convierte el túnel en un proxy SOCKS por el que puedes alcanzar cualquier host y puerto que el pivote vea.

$ ssh -D 1080 leo@pivote -N
# 127.0.0.1:1080 es ahora un proxy SOCKS hacia toda la red del pivote

El problema es que la mayoría de herramientas no saben usar un proxy SOCKS. Ahí entra proxychains: intercepta las conexiones de cualquier programa y las fuerza a pasar por el SOCKS. Se configura el proxy en /etc/proxychains4.conf (socks5 127.0.0.1 1080) y se antepone proxychains4 al comando:

$ proxychains4 curl http://10.13.0.40/
proxychains4 nmap -sT -Pn 10.13.0.0/24    # escanear la red interna a través del túnel

La combinación ssh -D + proxychains es la herramienta de pivoting más usada: con un solo túnel tienes acceso a toda la red interna con cualquier herramienta. (Nota: por SOCKS conviene el escaneo TCP connect -sT, porque el SYN puro de nmap no viaja bien por un proxy.)

5. Doble pivote: redes detrás de redes

A veces la red que buscas no la ve el primer pivote, sino un segundo host que solo es accesible desde el primero. Es el doble pivote: encadenas túneles. La forma más limpia es levantar un SOCKS por el primer pivote y, a través de ese SOCKS, abrir un segundo túnel SSH al host intermedio con un reenvío hacia la red profunda:

$ ssh -D 1080 leo@pivote1 -N
proxychains4 ssh -L 8080:10.14.0.30:80 maya@pivote2 -N
curl http://127.0.0.1:8080/    # llega a la red profunda, dos saltos más allá

La otra forma, más corta cuando ambos saltos son SSH, es ProxyJump (-J), que encadena saltos en una sola línea: ssh -J usuario@pivote1 usuario@pivote2. Cada capa de red que atraviesas necesita su propio salto.

6. Cuando no hay SSH: chisel y socat

No siempre tienes credenciales SSH en el pivote. Dos alternativas imprescindibles:

• chisel: crea un túnel (incluido SOCKS) sobre HTTP/WebSocket entre dos binarios que tú despliegas. El caso típico es el reverse: levantas un servidor chisel en tu máquina y el pivote (que sí puede salir hacia ti) se conecta de vuelta, dándote un SOCKS hacia su red. Perfecto cuando solo hay conectividad de salida.
• socat: un "cable" entre dos puntos. Un simple relé socat TCP-LISTEN:9000,fork TCP:10.13.0.20:5000 en el pivote reenvía su puerto 9000 al servicio interno. Menos flexible que SSH pero funciona en cualquier sitio y sirve para reenvíos puntuales.

$ # en tu máquina:   chisel server -p 8000 --reverse
# en el pivote:    chisel client TU_IP:8000 R:socks
# resultado: un SOCKS en tu 127.0.0.1:1080 hacia la red del pivote

7. Metodología de pivoting

1. Al comprometer un host, mira sus interfaces (ip a, ifconfig): ¿está en más de una red?
2. Desde él, descubre qué hay en la red interna (barrido de ping/puertos, tabla ARP, /etc/hosts).
3. Elige el túnel: -L para un objetivo puntual, -D+proxychains para explorar.
4. Si aparece otra red más profunda, repite el proceso desde el nuevo pivote (doble pivote).
5. Documenta el mapa de red y qué túnel te lleva a cada sitio: es fácil perderse con varios saltos.

Autoevaluación

1. ¿Qué "heredas" al comprometer un host que está en varias redes, y por qué es tan valioso?
2. Explica la diferencia entre -L, -R y -D con un caso de uso de cada uno.
3. ¿Por qué ssh -D + proxychains es más cómodo que muchos -L para explorar una red?
4. ¿Por qué al escanear con nmap a través de un SOCKS conviene usar -sT y no el SYN por defecto?
5. Describe cómo alcanzarías una red que el primer pivote no ve pero un segundo host sí.
6. No tienes SSH en el pivote, pero él sí puede conectar hacia ti. ¿Qué herramienta usas y cómo?