OpenSSH y Keycloak: por qué la autenticación es el nuevo perímetro
Dos avisos en la misma semana
En los últimos días convivieron dos avisos que, leídos juntos, dicen bastante. Por un lado, INCIBE-CERT alertó sobre una vulnerabilidad crítica en Keycloak que permitía restablecer contraseñas en un producto que lo usa como pieza de autenticación. Por otro, se publicó un fallo en OpenSSH compilado sobre musl que permitía ingresar sin contraseña en ciertas configuraciones. Dos tecnologías distintas, el mismo punto de falla: la capa que decide quién entra.
No son casos exóticos. Keycloak es un estándar de facto para identidad en empresas; OpenSSH está en casi todos los servidores del planeta. Cuando falla la autenticación, no falla una función: falla el perímetro completo.
Por qué auth es el nuevo perímetro
Durante años el perímetro fue la red: firewall, VPN, segmentación. Con el trabajo remoto y los servicios en la nube, el perímetro se mudó al login. Cada aplicación, cada panel, cada API y cada integración tiene su propia puerta, y todas dependen de un puñado de piezas compartidas: el proveedor de identidad, el servidor de claves, la sesión, el token.
Eso concentra el riesgo. Un error en el proveedor de identidad no afecta a un sistema: afecta a todos los que confían en él. Y como casi nadie audita la cadena completa, el fallo se descubre cuando alguien lo explota.
El detalle que se pasa por alto
La vulnerabilidad de Keycloak no era un bypass genérico: permitía restablecer contraseñas en un escenario específico. Ese nivel de detalle es el que hace la diferencia entre "actualizamos cuando podamos" y "actualizamos hoy". La mayoría de los incidentes reales no vienen de un zero-day espectacular, sino de una configuración concreta que nadie revisó.
Las cinco preguntas que hay que poder responder
- ¿Qué proveedor de identidad usás y en qué versión? Si la respuesta es "el que vino con la plataforma", ya perdiste el control.
- ¿Quién se entera de un aviso de seguridad? Suscribirse a los avisos del proveedor y del CERT correspondiente no es opcional.
- ¿Cuánto tardás en aplicar un parche crítico? Si la respuesta se mide en semanas, el proceso no existe.
- ¿Tenés segundo factor en los accesos administrativos? Sin 2FA en el panel y en el servidor, una contraseña filtrada es acceso total.
- ¿Qué pasa si el proveedor de identidad se cae? Un plan de continuidad que no contempla el login es un plan incompleto.
El error de tratar la seguridad como un producto
Comprar un WAF, contratar un escaneo y firmar un pentest anual no es un programa de seguridad: es una foto. La seguridad que funciona es un proceso con responsables, inventario y cadencia. Y en la capa de autenticación, ese proceso tiene tres piezas mínimas:
- Inventario: qué sistemas autentican, contra qué proveedor y con qué versiones.
- Monitoreo: alertas de intentos fallidos, cambios de contraseña masivos y accesos desde ubicaciones imposibles.
- Respuesta: un runbook escrito para rotar credenciales, revocar sesiones y forzar el cambio de claves.
El costo de no tener inventario
Si no sabés cuántos sistemas dependen de tu proveedor de identidad, tampoco sabés el alcance de un incidente. En una pyme con diez aplicaciones internas eso puede significar un día de trabajo; en una empresa con integraciones y APIs, puede significar que un atacante entre por la puerta lateral que nadie recordaba. El inventario no se hace una vez: se actualiza cada vez que alguien suma un servicio, una integración o un panel nuevo.
Qué hacer esta semana, sin presupuesto
- Verificá la versión de tu proveedor de identidad y buscá avisos de seguridad de los últimos seis meses.
- Revisá si el acceso administrativo tiene 2FA y si las sesiones expiran.
- Confirmá que las contraseñas se almacenan con un hash moderno y que el restablecimiento tiene rate limit.
- Revisá los logs de autenticación de los últimos treinta días buscando patrones raros.
- Anotá quién es el responsable técnico de cada pieza de la cadena.
Ninguna de estas tareas requiere comprar nada. Requiere que alguien las haga.
La lección de los dos avisos
Keycloak y OpenSSH no fallaron por ser malos. Fallaron porque son ubicuos, y lo ubicuo se estudia, se prueba y se rompe. La conclusión no es desconfiar de las herramientas estándar: es asumir que van a fallar y tener el proceso para responder antes de que el fallo sea público.
En Codit Digital trabajamos con hardening de servidores, monitoreo y respuesta ante incidentes como parte del soporte continuo. Si querés revisar tu capa de autenticación, podés ver nuestro servicio de soporte continuo, hosting y seguridad o leer el análisis de la explotación activa de PHP2Shell y el RCE sin parche.
El parche no es el final
Aplicar el parche cierra la puerta conocida. Lo que queda abierto es lo que no sabés: cuántas copias del servicio corren, quién tiene acceso y qué configuración quedó vieja. Ese trabajo no genera titulares, pero es el que evita el próximo incidente.
