Hardening de imágenes en cloud
“Hardening” es una de esas palabras que siempre aparece en todo tipo de reuniones pero que nadie tiene claro bien en qué consiste. Amado por unos, odiado por otros, me recuerda a aquella frase sobre el big data:
“El Big data es como el sexo en la adolescencia: todo el mundo habla de ello, nadie sabe realmente cómo hacerlo, todos piensan que los demás lo están haciendo, así que todos dicen que también lo hacen…”
Dan Ariely — Professor of Psychology & Behavioral Economics @ Duke University
Pero realmente… ¿Qué es el hardening?
Hardening es el proceso de fortalecer un sistema para reducir la superficie de exposición y los vectores de ataque mediante distintas herramientas y configuraciones.
El concepto es sencillo pero también genérico. El hardening se puede aplicar a todo sistema informático: aplicaciones, sistemas operativos, redes, bases de datos, plataformas cloud… Pero el tema que hoy nos ocupa es la automatización del hardening de imágenes en sistemas cloud como AWS, Azure o GCP.
¿Qué es CIS Benchmarks?
La entidad con mayor reconocimiento en el área de fortalecimiento de sistemas operativos es el CIS (Center of Internet Security) que dispone de unos controles de seguridad bastante exhaustivos.
Estos controles se dividen en 2 niveles:
- El Nivel 1 (L1) se considera una recomendación básica que puede implementarse con bastante rapidez y está diseñado para que no tenga un gran impacto en el rendimiento. La intención es reducir la superficie de ataque de su organización mientras mantiene las máquinas utilizables y no obstaculiza la funcionalidad del negocio.
- El nivel 2 (L2) está considerado como “defensa en profundidad” y está destinado a entornos en los que la seguridad es primordial. Las recomendaciones asociadas con el perfil de Nivel 2 pueden tener un efecto adverso en su organización si no se implementan apropiadamente o sin el debido cuidado.
En su web, el CIS facilita unos scripts en Python para poner solución a estos distintos controles y así asegurarte de que cumples con su normativa:
También dispone de imágenes hardenizadas en las distintas plataformas cloud, pero con un precio adicional de 15$/mes por máquina, lo cual no es moco de pavo.
Pero ahora que tenemos los scripts… ¿por qué pagar cuando puedes hacértelo tu?
1. Personalizar los scripts de hardening
Los scripts python del CIS presentan un problema: la configuración del sistema operativo de la que parten difiere de la configuracion de las instancias de AWS o Azure y por tanto, si ejecutamos los scripts sin modificar no podremos volver a acceder a nuestras instancias. ⚠️
Así que la primera tarea es detectar qué controles corrompen nuestra instancia y cuales no. Para ello es necesario comprender la lógica de los controles obviando pruebas banales y poniendo esfuerzo en cumplir las que realmente pueden suponer un riesgo, además de conocer el contexto donde los scripts se ejecutarán.
Veamos un ejemplo práctico: La siguiente imagen muestra un control de nivel 1 que indica que el acceso al fichero /etc/motd debe estar restringido al usuario root
Sin embargo, en AWS este fichero no existe y la carpeta /etcúnicamente es editable por el usuario root, por tanto, el test debería pasar correctamente pero no será así porque el fichero no existe y por tanto, el análisis del CIS, al intentar comprobar sus permisos fallará, dando el control como fallido.
¿Merece la pena pringarse para cumplir con este control? Obviamente no.
Una vez excluidos los controles problemáticos, nos creamos nuestros propios scripts para después automatizar la creación de imágenes
2. Verificar el cumplimiento
Conforme afinamos los scripts para que cubran el mayor numero de controles posibles, iremos realizando escaneos para ver el resultado.
Las siguiente imágen muestra un análisis del CIS (L1 y L2) sobre una máquina recien creada en AWS con Ubuntu 16.04, donde vemos que de 412 controles de seguridad, únicamente ha pasado 200.
En cambio, en esta imagen tenemos el análisis del CIS (L1 y L2) sobre una máquina en AWS con Ubuntu 16.04 donde ya hemos ejecutado nuestros scripts y vemos que 357 controles pasan satisfactoriamente.
Como ya mencioné en el punto anterior, llegar a un cumplimiento del 100% es realmente complicado y muy poco práctico, además de un derroche de energía, por ello es importante entender los controles que hemos dejado sin pasar. Una vez satisfechos con el resultado, podemos garantizar el porcentaje de cumplimiento que garantizan dichos scripts, como en la tabla a continuación:
3. Automatizar el proceso
Con los scripts ya ajustados y probados, queda automatizar el flujo para que diariamente realice el proceso de hardening y las nuevas imágenes generadas puedan ser consumidas por otros usuarios, incluso de manera anónima.
En este caso, he realizado el ejemplo para AWS y mediante Github Actions pero cualquier otro CI es bienvenido (Travis, Jenkins, CircleCI…). En la imagen a continuación se observa las 8 fases que conforman el script desarrollado para ello y su ejecución en dicho CI:
- Obtener la imagen más reciente: AWS actualiza diariamente sus imágenes de SO, por lo tanto tenemos que obtener la más reciente pero estable.
- Crear una instancia: Una vez tenemos la imagen, lanzamos una instancia sobre la que ejecutar el script.
- Ejecutar los scripts: Con la instancia funcional, subimos los scripts y los ejecutamos mediante SSH o WinRM.
- Reiniciar: Los scripts requieren de reinicio para que la nueva configuración sea cargada.
- Pruebas: Ya vimos que los scripts podían corromper las imagenes, así que nos aseguramos mediante una batería de pruebas.
- Crear nueva imagen: Confirmado que la instancia funciona correctamente, creamos la imagen a partir de ella.
- Compartir o publicar la nueva imagen: En caso que otras cuentas o regiones deban usarla, deberemos hacerla pública o compartirla con las cuentas interesadas.
Llegados a este punto, ya tenemos imágenes originales de AWS hardenizadas. Ahora podemos servirnos de políticas de IAM o de otros servicios como AWS Service Catalog para facilitar el uso de estas imágenes seguras en lugar de las originales que no son disponen de una configuración tan robusta. Y por supuesto, notificar en el canal adecuado las nuevas imágenes generadas:
La parte difícil llegados a este punto es….
¿Se deberían limitar los permisos de los usuarios para utilizar exclusivamente estas imágenes seguras?
