Reenvío del agente SSH: cuando utilizar un socket no es lo más conveniente
¿Usted de verdad se pondría sandalias con calcetines para andar por una bonita playa de arena blanca? Pues lo mismo ocurre con el reenvío del agente SSH: a veces es mejor abstenerse de usar un socket.
¿Qué es el reenvío del agente SSH?
El reenvío del agente SSH es, en pocas palabras, un mecanismo que proporciona grandes ventajas al administrador de un sistema. Gracias a un agente local, los usuarios pueden conectarse a un servidor remoto al rebotar en un servidor intermedio utilizando su propia clave privada, guardada únicamente en su ordenador.
Pero ¿por qué acceder a un servidor rebotando en otro intermedio?
La respuesta es muy sencilla. Teniendo en cuenta el problema de seguridad que plantean las conexiones externas, es evidente que ningún responsable de TI sensato permitiría conexiones directas a recursos críticos de Internet.
El mecanismo del reenvío del agente SSH permite a los usuarios conectarse fácilmente a un servidor al rebotar en otro intermedio, sin la necesidad de almacenar la clave privada del usuario en este último servidor.
El reenvío del agente SSH puede ser una puerta de entrada de ciberataques.
Volviendo al tema principal, el reenvío del agente SSH presenta una vulnerabilidad al abrirse un socket en el servidor intermedio.
El socket creado mediante el reenvío del agente SSH es una vulnerabilidad muy conocida.
Para que comprendamos el proceso, vamos a ir por partes:
- En primer lugar, un agente se ejecuta en su computadora local. Cabe destacar que este agente tiene acceso a la clave privada para poder manejar el reenvío de la autenticación.
- A continuación, el usuario se conecta al servidor de rebote, especifica que dicha conexión puede usarse para rebotar en otro servidor y utiliza la clave privada para autenticarse.
- Finalmente, el usuario se conecta desde el servidor de rebote al servidor final gracias a la clave privada.
¿Pero qué es lo que vuelve vulnerable al socket? Lo que ocurre es que un usuario maligno autenticado en el sistema de rebote puede desviar fácilmente el socket para así hacerse pasar por el usuario original y conectarse a servidores autorizados.
WALLIX Bastion: la solución ideal para la vulnerabilidad del socket que surge en el reenvío del agente SSH
Ahora vayamos a la práctica.
Pongamos por ejemplo que usted es el responsable de TI de un hospital. Algunos de sus equipos, como escáneres o analizadores, los gestionan proveedores que necesitan un acceso seguro y exclusivo a los mismos. Sin embargo, estos no quieren compartir las claves de autenticación a dichos sistemas críticos. Aún así, usted quiere ser capaz de supervisar y grabar cada acción que estos proveedores llevan a cabo en su equipo, al menos por motivos de conformidad.
WALLIX Bastion es la solución perfecta para este tipo de desafío. Gracias a su solución interna de reenvío de agentes, los proveedores pueden acceder a su equipo desde Internet usando su propia clave y sin necesidad de compartirla con el bastión. Además, el bastión funciona como un proxy inverso rompiendo con el protocolo y sin proporcionar acceso de shell.
Dos pájaros de un tiro: eliminamos el socket y la vulnerabilidad
Asimismo, WALLIX Bastion proporciona un arsenal de auditorías completo para que los administradores de TI puedan echar un ojo (nosotros solemos llamarlo «4 ojos») a qué es lo que está ocurriendo en sus equipos críticos al mismo tiempo que se garantiza la conformidad.
En resumidas cuentas, utilizar un calzado apropiado para la playa es muy sencillo y, además, le puede ahorrar problemas tanto a usted como a su reputación.
¿Quiere obtener más información? ¡Póngase en contacto con nosotros para una demostración gratuita!
