Guía visual de túneles SSH y redirección de puertos (2023)

 (ittavern.com)
6 puntos por GN⁺ 2024-09-20 | 1 comentarios | Compartir por WhatsApp

Guía visual sobre túneles SSH y redirección de puertos

  • Resumen: Esta publicación de blog fue escrita para ayudar a entender los túneles SSH y la redirección de puertos. El tema incluye casos de uso, configuración, hosts de salto SSH, redirección de puertos local/remota/dinámica y limitaciones.
Casos de uso

  • Seguridad:

    • Cifrar conexiones inseguras como FTP
    • Acceso a paneles de administración web a través de un túnel SSH (autenticación con clave pública)
    • Reducir la cantidad de puertos expuestos (solo se expone el puerto 22)

  • Resolución de problemas:

    • Evitar firewalls/filtros de contenido
    • Elegir otra ruta

  • Conectividad:

    • Acceder a servidores detrás de NAT
    • Acceder a servidores internos a través de Internet usando un host de salto
    • Exponer un puerto local a Internet
Redirección de puertos
  • Configuración/preparación:
    • Los usuarios locales y remotos necesitan permisos para abrir puertos
    • Los puertos 0-1024 requieren privilegios de root
    • Configurar correctamente el cliente y los firewalls de red
    • Se debe habilitar la redirección de puertos en el servidor SSH: AllowTcpForwarding yes
    • Para redirigir puertos desde otras interfaces, se debe habilitar GatewayPorts yes
Host de salto SSH / túnel SSH

  • Conexión a través de un host de salto:

    ssh -J user@REMOTE-MACHINE:22 -p 22 user@10.99.99.1

  • Uso de varios hosts de salto:

    ssh -J user@REMOTE-MACHINE:22,user@ANOTHER-REMOTE-MACHINE:22 -p 22 user@10.99.99.1
Redirección de puertos local

  • Ejemplo 1:

    ssh -L 10.10.10.1:8001:localhost:8000 user@REMOTE-MACHINE

  • Ejemplo 2:

    ssh -L 8001:10.99.99.1:8000 user@REMOTE-MACHINE
Redirección de puertos remota

  • Ejemplos 1+2:

    ssh -R 8000:localhost:8001 user@REMOTE-MACHINE
ssh -R 8000:10.10.10.2:8001 user@REMOTE-MACHINE

  • Ejemplo 3:

    ssh -R 10.99.99.2:8000:10.10.10.2:8001 user@REMOTE-MACHINE
Redirección de puertos dinámica
  • Uso del protocolo SOCKS: 
    ssh -D 10.10.10.1:5555 user@REMOTE-MACHINE
Túneles SSH TUN/TAP
  • Crear un túnel TCP bidireccional: 
    ssh -w local_tun[:remote_tun]
Ejecutar SSH en segundo plano

  • Ejecución en segundo plano:

    ssh -fN -L 8001:127.0.0.1:8000 user@REMOTE-MACHINE

  • Detener SSH en segundo plano:

    ps -ef | grep ssh
kill <PID>
Mantener la conexión SSH
  • Manejo de timeout:
    • ClientAliveInterval 15
    • ClientAliveCountMax 3
Limitaciones

  • UDP:

    • SSH no soporta UDP porque requiere entrega confiable

  • TCP-over-TCP:

    • El mayor overhead reduce el rendimiento y aumenta la latencia

  • No reemplaza a una VPN:

    • El túnel SSH puede sustituir una VPN, pero en términos de rendimiento una VPN es más adecuada

  • Riesgos potenciales de seguridad:

    • Es recomendable desactivar las funciones que no sean necesarias

Resumen de GN⁺

  • Este artículo explica varios casos de uso y métodos de configuración para túneles SSH y redirección de puertos
  • Los túneles SSH son útiles para proporcionar conexiones seguras y evitar firewalls
  • Sin embargo, no pueden reemplazar por completo a una VPN y tienen limitaciones como la degradación del rendimiento
  • Entre otros proyectos relacionados hay soluciones VPN como OpenVPN

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-09-20
Comentarios de Hacker News

  • En 2024, en lugar de escribir comandos SSH directamente, conviene usar el archivo ~/.ssh/config para configurar LocalForward, RemoteForward y ProxyJump

    • Con una configuración de ejemplo, se puede ahorrar tiempo al transferir datos pasando por varias conexiones SSH intermedias
    • Después de configurarlo, se puede usar SSH, SCP y RSYNC en target-server mediante un alias
    • También se puede hacer port forwarding fácilmente con la configuración de LocalForward y RemoteForward

  • El túnel SSH es esencial en entornos corporativos complejos

    • Debido a tanta burocracia y tiempos de espera, conseguir los permisos de acceso necesarios toma tiempo
    • Si usas el comando ssh -D 8888 someserver y configuras el proxy SOCKS del navegador en localhost:8888, el tráfico del navegador se enruta a través de ese servidor

  • Si quieres acceder por SSH a un servidor Linux o dispositivo IoT que está detrás de un firewall y no tiene IP fija, puedes usar un servicio de túneles

  • La experiencia más compleja de hacking con túneles SSH ocurrió al conectar entre centros de datos

    • Había que mover datos de A a B, y de B a C
    • Combinando rsync, túneles SSH, claves y enrutamiento, se logró mover los datos con éxito
    • En ese momento fue un gran logro, y el recuerdo sigue muy vivo

  • Ojalá hubiera más visualización de redes

    • Especialmente hace falta visualizar el tráfico en conexiones de bajo nivel

  • TCP-over-TCP puede aumentar la sobrecarga, incrementar la latencia y degradar el rendimiento

    • En túneles SSH no suele ser un problema a menos que se use TAP/TUN
    • Sin embargo, al usar varios canales sí puede haber una caída de rendimiento

  • Los túneles SSH son una gran herramienta, pero hoy en día se usan más herramientas con TLS y funciones de proxy inverso integradas

  • sshuttle es una mejor herramienta para túneles

    • Se puede usar como una VPN con el comando sshuttle -r user@host 10.0.0.0/8

  • Hace 15 años empecé a usar túneles SSH para evadir el firewall de la red universitaria

    • Cambiaba el puerto predeterminado a 443 para usarlo
    • Desde entonces lo sigo usando para varios fines, además de saltarme firewalls

  • Me pregunto si SSH en sí tiene una función de redirección

    • Si A intenta conectarse por SSH a B, que B le indique que se conecte a C, y que A se conecte directamente a C de forma transparente
    • Así, B deja de ser parte de la ruta crítica de datos
    • Tengo curiosidad por saber si existe una función así