Las claves públicas no son suficientes para la seguridad SSH

Si tu organización utiliza claves públicas SSH, es totalmente posible que ya hayas extraviado una. Hay un archivo en una copia de seguridad o en la computadora de un ex empleado que le otorga al titular acceso a tu infraestructura.  Si compartes claves SSH entre empleados, es probable que solo unas pocas claves sean suficientes para dar a un atacante acceso a todo el sistema. Si no las compartes, es probable que tu equipo haya generado tantas claves que hayas perdido por error al menos una.

Si un atacante puede violar así sea un dispositivo de uno de tus clientes, es probable que haya un archivo known_hosts que enumera cada objetivo al que se puede llegar trivialmente con las claves que la máquina ya contiene.  Si alguien puede comprometer la computadora portátil de un miembro del equipo, podría usar teclas en el dispositivo que carecen de protección con contraseña para llegar a destinos confidenciales.

En caso de que eso suceda, ¿cómo responderías y revocarías la clave SSH perdida? ¿Tienes un registro de las claves que se han generado? ¿Haces rotación de las claves SSH? ¿Cómo se gestiona eso en toda una organización tan consumida con el hecho de servir a los clientes que la seguridad debe ser fácil de adoptar?

Cloudflare Access lanzó el año pasado soporte para conexiones SSH para brindar seguridad zero-trust en la forma en que los equipos se conectan a la infraestructura.  Access se integra con su IdP para brindar seguridad SSO a las conexiones SSH mediante la aplicación de reglas basadas en la identidad cada vez que un usuario intenta conectarse a un recurso final.

Sin embargo, una vez que Access conectó a los usuarios al servidor, todavía tenían que confiar en las claves SSH heredadas para autorizar su cuenta. A partir de hoy, nos complace ayudar a los equipos a eliminar ese requisito y reemplazar las claves SSH estáticas con certificados de corta duración.

En los modelos perimetrales de re tradicional, los equipos aseguran su infraestructura con dos puertas: una red privada y claves SSH.

La red privada requiere que cualquier usuario que intente conectarse a un servidor debe estar en la misma red o en un equivalente similar (como una VPN). Sin embargo, eso implica cierto riesgo. Las redes privadas por defecto confían en que un usuario en la red puede llegar a una máquina. Los administradores deben segmentar proactivamente la red o proteger cada parte de la infraestructura con listas de control para trabajar hacia atrás desde ese valor predeterminado.

Cloudflare Access protege la infraestructura empezando por la otra dirección: no se debe confiar en ningún usuario. En cambio, los usuarios deben demostrar que deben poder acceder a cualquier máquina o destino únicos de forma predeterminada.

Lanzamos soporte para conexiones SSH en Cloudflare Access el año pasado para ayudar a los equipos a abandonar ese modelo de perímetro de red y reemplazarlo por uno que evalúe cada solicitud de identidad de usuario a un servidor. A través de la integración con proveedores de identidad conocidos, esa solución también brinda a los equipos la capacidad de incorporar su flujo de SSO a su flujo de SSH.

Una vez que un usuario está conectado a un servidor a través de SSH, generalmente necesita autorizar su sesión. La máquina que intentan alcanzar tendrá un conjunto de perfiles que consiste en identidades de usuario o rol. Esos perfiles definen qué acciones puede realizar el usuario.

Los procesos SSH hacen que algunas opciones estén disponibles para que el usuario inicie sesión en un perfil. En algunos casos, los usuarios pueden iniciar sesión con una combinación de nombre de usuario y contraseña. Sin embargo, la mayoría de los equipos confían en certificados de clave pública-privada para manejar ese inicio de sesión. Para usar ese flujo, los administradores y usuarios deben seguir los pasos previos.

Antes de la conexión, el usuario generará un certificado y proporcionará la clave pública a un administrador, que luego configurará el servidor para confiar en el certificado y asociarlo con un determinado usuario y conjunto de permisos. El usuario guarda ese certificado en su dispositivo y lo presenta durante esa última milla. Sin embargo, esto deja abiertos todos los problemas que SSO intenta resolver:

• La mayoría de los equipos nunca obligan a los usuarios a rotar los certificados. Si lo necesitan, lo solicitarán una vez al año como máximo. Esto deja credenciales estáticas a la infraestructura central persistente en cientos o miles de dispositivos.

• Los usuarios son responsables de proteger sus certificados en sus dispositivos. Los usuarios también son responsables de las contraseñas, pero las organizaciones pueden aplicar los requisitos y la revocación de forma centralizada.

• La revocación es difícil. Los equipos deben administrar una plataforma CRL u OCSP para garantizar que no se usen certificados perdidos o robados.

Con Cloudflare Access, puedes llevar tus cuentas SSO a la autenticación de usuarios dentro de tu infraestructura. No se requieren claves estáticas.

Para construir esto, recurrimos a tres herramientas que ya teníamos: Cloudflare Access, Argo Tunnel y Workers.

Access es un motor de políticas que combina los datos de los empleados en tu proveedor de identidad (como Okta o AzureAD) con las políticas que creas. Según esas políticas, Access puede limitar el acceso a tus aplicaciones internas a los usuarios que elijas. No es un gran salto para ver cómo se podría utilizar el mismo concepto de política para controlar el acceso a un servidor a través de SSH. Escribes una política y la usamos para decidir cuál de tus empleados debería poder acceder a qué recursos. Luego generamos un certificado de corta duración que les permite acceder a ese recurso solo por el período más breve. Si eliminas un usuario de tu IdP, su acceso a tu infraestructura se eliminará de manera similar, sin problemas.

Para canalizar el tráfico a través de nuestra red, utilizamos otra herramienta Cloudflare existente:  Argo Tunnel. Argo Tunnel cambia el modelo tradicional de conectar un servidor a Internet. Cuando activas nuestro daemon en una máquina, este realiza conexiones salientes a Cloudflare, y todo el tráfico fluye a través de esas conexiones. Esto permite que la máquina sea parte de la red de Cloudflare sin que tenga que exponerla directamente a Internet.

Para casos de uso de HTTP, Argo Tunnel solo necesita ejecutarse en el servidor. En el caso del flujo Access SSH, redirigimos el tráfico SSH mediante proxy a través de Cloudflare ejecutando el cliente Argo Tunnel, cloudflared, tanto en el servidor como en la computadora portátil del usuario final.

Cuando los usuarios se conectan a través de SSH a un recurso asegurado por Access for Infrastructure, usan la herramienta command-line de cloudflared. Cloudflared toma el tráfico SSH vinculado a ese nombre de host y lo reenvía a través de Cloudflare en función de la configuración de SSH. No se requieren enlaces ni capas de comando. cloudflared inicia una ventana del navegador y solicita al usuario que se autentique con sus credenciales de SSO.

Una vez autenticado, Access verifica la identidad del usuario con la política que ha configurado para esa aplicación. Si al usuario se le permite acceder al recurso, Access genera un JSON Web Token (JWT), firmado por Cloudflare y con alcance para el usuario y la aplicación. Access distribuye ese token al dispositivo del usuario a través de cloudflared y la herramienta lo almacena de forma local.

Al igual que el flujo principal de autenticación de Access, la validación de token se construye con un Cloudflare Worker que se ejecuta en cada uno de nuestros centros de datos, lo que lo hace rápido y altamente disponible. Los trabajadores nos permitieron implementar este proxy SSH en todos los 194 centros de datos de Cloudflare, lo que significa que Access for Infrastructure a menudo acelera las sesiones SSH en lugar de ralentizarlas.

Con los certificados de corta duración habilitados, la instancia de Cloudflared que se ejecuta en el cliente da un paso adicional. Cloudflared envía ese token a un punto final de firma de certificado de Cloudflare que crea un certificado efímero. El flujo SSH del usuario envía tanto el token, que se usa para autenticar a través de Access, como el certificado de corta duración, que se usa para autenticar en el servidor. Al igual que el flujo principal de autenticación de Access, la validación de token se construye con un Cloudflare Worker que se ejecuta en cada uno de nuestros centros de datos, lo que lo hace rápido y altamente disponible.

Cuando el servidor recibe la solicitud, valida el certificado de corta duración con esa clave pública y, si es auténtico, autoriza la identidad del usuario a un usuario de Unix que coincida. El certificado, una vez emitido, es válido por 2 minutos, pero la conexión SSH puede durar más una vez que la sesión ha comenzado.

La función SSH de Cloudflare Access es completamente transparente para el usuario final y no requiere ningún comando SSH, capa o indicador. En cambio, Access requiere que los miembros de su equipo tomen un par de pasos únicos para comenzar:

1. Instalar el daemon cloudflared

El mismo software liviano que se ejecuta en el servidor de destino se usa para redireccionar mediante proxy conexiones SSH desde los dispositivos de los miembros de tu equipo a través de Cloudflare.  Los usuarios pueden instalarlo con gestores de paquetes populares como brew o en el enlace disponible aquí.  Alternativamente, el software es de código abierto y puede ser construido y distribuido por tus administradores.

2. Imprimir la actualización de configuración SSH y guardarla

Una vez que un usuario final ha instalado Cloudflared, debe ejecutar un comando para generar nuevas líneas para agregar a su archivo de configuración SSH:

cloudflared access ssh-config --hostname vm.example.com --short-lived-cert

El campo --hostname contendrá el nombre de host o el subdominio comodín del recurso protegido detrás de Access.  Una vez ejecutado, cloudflared imprimirá los siguientes detalles de configuración:

Host vm.example.com
    ProxyCommand bash -c '/usr/local/bin/cloudflared access ssh-gen --hostname %h; ssh -tt %r@cfpipe-vm.example.com >&2 <&1'
    
Host cfpipe-vm.example.com
    HostName vm.example.com
    ProxyCommand /usr/local/bin/cloudflared access ssh --hostname %h
    IdentityFile ~/.cloudflared/vm.example.com-cf_key
    CertificateFile ~/.cloudflared/vm.example.com-cf_key-cert.pup

Los usuarios deben anexar esa salida a su archivo de configuración SSH. Una vez guardados, pueden conectarse a través de SSH al recurso protegido. Access les pedirá que se autentiquen con sus credenciales de SSO en el navegador, de la misma manera que inician sesión en cualquier otra herramienta basada en el navegador.  Si ya tienen una sesión de navegador activa con sus credenciales, sencillamente verán una página sin ningún problema.

En su terminal, cloudflared establecerá la sesión y emitirá el certificado de cliente que corresponde a su identidad.

Con certificados de corta duración, Access puede convertirse en una única puerta de enlace integrada con SSO para su equipo e infraestructura en cualquier entorno.  Los usuarios pueden usar SSH directamente en una máquina determinada y los administradores pueden reemplazar sus jumphosts por completo, eliminando esa sobrecarga.  La función está disponible hoy para todos los clientes de Access. Puedes comenzar siguiendo la documentación disponible aquí.