Cómo configurar el reenvío de puertos dinámicos SSH en Linux

Muchas organizaciones utilizan servidores de tolva accesibles Secure Shell (SSH) para acceder a sistemas críticos. Los administradores primero se conectan a un servidor de salto mediante SSH, opcionalmente a través de una VPN, antes de conectarse al sistema de destino. Este método generalmente funciona bien siempre que el administrador se ciña a la administración de la línea de comandos. Se vuelve un poco más complicado cuando un administrador quiere salir del dominio de la línea de comandos y usar una interfaz web en su lugar.

Veamos el siguiente escenario: Bob es un administrador de sistemas en Securecorp y acaba de recibir una alerta de que un clúster de base de datos que consta de sirius.securecorp.io y orion.securecorp.io funciona mal Para un primer análisis suele utilizar la consola web RHEL8. El firewall no le permite conectarse directamente a este sistema desde su estación de trabajo, pero puede pasar por un servidor de salto llamado bastion.securecorp.io.

El acceso de línea de comando SSH al clúster de base de datos es simple:

[[email protected] ~]$ ssh bastion.securecorp.io
[[email protected] ~]$ ssh sirius.securecorp.io
[[email protected] ~]$
[[email protected] ~]$ ssh bastion.securecorp.io
[[email protected] ~]$ ssh orion.securecorp.io
[[email protected] ~]$

Pero, ¿y si Bob quiere acceder a la consola web de RHEL8 desde sirius.securecorp.io y orion.securecorp.io? Hay varias formas de lograr esto mediante SSH, todas las cuales implican algún tipo de reenvío de puertos.

Advertencia: En algunas organizaciones, las políticas de seguridad no permiten el reenvío de puertos. Para asegurarse de no infringir ninguna regla, consulte a su representante de seguridad de TI.

Índice

Reenvío de puertos SSH

Usando SSH, Bob abre un túnel TCP para ambos sistemas, apuntando al puerto de la consola web (9090) para sirius.securecorp.io y puerto 9091 para orion.securecorp.io.

[[email protected] ~]$ ssh -L 9090:sirius.securecorp.io:9090 bastion.securecorp.io
[[email protected] ~]$
[[email protected] ~]$ ssh -L 9091:orion.securecorp.io:9090 bastion.securecorp.io
[[email protected] ~]$

Bob ahora puede apuntar el navegador de su estación de trabajo local a https: // servidor local: 9090 para acceder a la consola web para sirius.securecorp.io, y https: // servidor local: 9091 para acceder a la consola web para orion.securecorp.io.

Este enfoque puede funcionar bien en algunos casos, pero tiene sus limitaciones:

  • Validación del certificado TLS: el navegador local no está satisfecho porque en la mayoría de los casos el nombre común del certificado no coincide con el nombre del host en la barra de direcciones (localhost), por lo que la validación del certificado falla.
  • Redirecciones: cuando el sitio web al que está accediendo lo redirige a otra URL, la conexión falla porque el reenvío de puertos solo es válido para ese servidor web. Esta situación puede ser problemática cuando se utiliza el inicio de sesión único (SSO), por ejemplo.

Inicie un navegador en el servidor de salto

Bob también iniciaría un navegador como Firefox en el servidor de salto y lo mostraría localmente en su estación de trabajo. SSH proporciona una función llamada reenvío X, que se puede utilizar en esta situación.

[[email protected] ~]$ ssh -X bastion.securecorp.io
[[email protected] ~]$ firefox https://sirius.securecorp.io:9090 &
[[email protected] ~]$ firefox https://orion.securecorp.io:9090 &

Con este método, el proceso del navegador se ejecuta en el servidor de salto y las conexiones a las consolas web de sirius.securecorp.io y orion.securecorp.io están permitidos. En la estación de trabajo de Bob solo se produce la representación de la ventana del navegador.

Si bien este enfoque resuelve algunos problemas simples de reenvío de puertos SSH, también tiene limitaciones:

  • Rendimiento: este método generalmente funciona bastante mal ya que la salida de gráficos debe transferirse desde el servidor de salto a la estación de trabajo a través de la red, lo cual es muy ineficiente.
  • Requisito previo: se debe instalar un navegador como Firefox en el servidor de salto y se debe ejecutar un servidor X en la estación de trabajo.

Ingrese el reenvío de puerto dinámico

Después de explorar los dos enfoques anteriores y conocer sus inconvenientes, sería genial tener una tercera opción, que nos brinda lo mejor de ambos mundos:

  • Se puede utilizar el navegador de la estación de trabajo.
  • La conectividad y la resolución de nombres DNS deben ser las mismas que en el servidor de salto.

Para lograr esto, SSH proporciona una característica llamada, que explota la CALCETINES protocolo. En esta configuración, SSH actúa como un proxy SOCKS, retransmitiendo todo el tráfico relevante a través de la conexión SSH. Para que esto suceda, el cliente (en nuestro ejemplo, este es el navegador) debe ser compatible con SOCKS.

Bob puede iniciar una sesión SSH con reenvío de puerto dinámico de la siguiente manera:

[[email protected] ~]$ ssh -D 1080 bastion.securecorp.io
[[email protected] ~]$

Después de eso, el navegador de la estación de trabajo de Bob debe ser compatible con SOCKS. La configuración de Firefox se puede lograr así:

  • Apunte el navegador a sobre: ​​preferencias.
  • En el General pestaña, desplácese hacia abajo y haga clic en Ajustes ... en el Configuración de red sección.
  • En el Configuración de conexión ventana, elige Configuración manual de proxy, especificar para CALCETINES anfitrión, para Puerto y seleccione CALCETINES v5.
  • En la misma ventana, seleccione Proxy DNS al usar SOCKS v5.
Configurar SOCKS5 en Firefox

Bob ahora puede apuntar el navegador a https://sirius.securecorp.io:9090 y https://orion.securecorp.io:9090 analizar los problemas de rendimiento de sus dos servidores de bases de datos utilizando la consola web RHEL8. También puede acceder a todos los demás recursos internos como si el navegador se estuviera ejecutando en bastion.securecorp.io.

Notar: El puerto 1080 es el puerto registrado en la IANA para SOCKS, pero la conexión puede usar cualquier otro puerto. Los números en el SSH y la configuración del navegador deben coincidir.

Personalmente, me ha resultado útil crear un perfil de navegador separado para que no haya necesidad de cambiar constantemente entre configuraciones de proxy. Se puede crear un nuevo perfil pasando el -P ir firefox comando, lanzando el Administrador de perfiles. Llamé a mi perfil Salto. Después de crear un nuevo perfil, se crea una configuración vacía. En este perfil, apliqué la configuración descrita anteriormente y dejé intacto mi perfil predeterminado.

Configuración de perfil en Firefox

Después de crear el perfil, se puede iniciar Firefox con el siguiente comando:

[[email protected] ~]$ firefox -P Jump

Otro consejo útil es crear una configuración específica de host para el reenvío dinámico de puertos en su ~/.ssh/config archivar. Por ejemplo:

[[email protected] ~]$ cat ~/.ssh/config
Host bastion
  Hostname bastion.securecorp.io
  User bob
  DynamicForward 1080

Conclusión

Hay muchas formas de conectarse a sistemas internos utilizando un servidor de salto y las posibilidades descritas anteriormente no son exhaustivas. Sin embargo, en mi experiencia, SSH le brinda un conjunto de herramientas muy poderoso, que en la mayoría de los casos está disponible y listo para usar sin demasiados obstáculos. El reenvío de puertos dinámico es una de esas herramientas y me ha ayudado a ser más productivo en situaciones específicas, así que pruébelo usted mismo.

Artículos de interés

Subir