El acceso persistente mediante SSH es un vector crítico para el movimiento lateral en cualquier entorno. Con el paso del tiempo, los archivos authorized_keys en los servidores se convierten en cementerios de llaves públicas pertenecientes a ex-empleados, dispositivos antiguos o scripts de automatización obsoletos. Confiar únicamente en la rotación de contraseñas es insuficiente; mantener una higiene estricta de las llaves SSH es fundamental para minimizar la superficie de ataque y garantizar el principio de menor privilegio.
Ejemplo práctico:
Para identificar qué llaves han sido utilizadas recientemente, puedes consultar los logs de autenticación de tu servidor Linux. Ejecuta el siguiente comando para listar las llaves que han sido usadas exitosamente según tus logs:
$ grep "Accepted publickey" /var/log/auth.log | awk '{print $9}' | sort | uniq -c | sort -nrSi gestionas flotas de servidores, audita la antigüedad de los archivos authorized_keys en los directorios de usuario para identificar configuraciones que no han sido modificadas recientemente, lo cual puede indicar llaves abandonadas:
$ find /home -maxdepth 3 -name "authorized_keys" -exec ls -ld {} +Recomendación y mitigación:
- Centralización: Migra hacia soluciones de gestión de identidades (IAM) o herramientas como HashiCorp Vault, que permiten la emisión de certificados SSH de corta duración en lugar de llaves estáticas.
- Configuración: Utiliza la directiva AuthorizedKeysCommand en tu sshd_config para obtener las llaves desde un origen centralizado en tiempo real.
- Automatización: Implementa una tarea programada (cron job) que escanee ~/.ssh/authorized_keys y alerte si se encuentran llaves sin uso registrado en los últimos 60 días.
- Limpieza: Asegúrate de que el proceso de «offboarding» de empleados incluya la revocación inmediata de sus llaves en todos los entornos, no solo el acceso al dominio.
¿Gestionas el acceso SSH mediante llaves estáticas en cada nodo o utilizas una solución centralizada de certificados?
0 comentarios