Hardening de hosts y CIS Benchmark
Qué es endurecer un host, por qué reduce la superficie de ataque y cómo usar el CIS Benchmark y los servicios de AWS para hacerlo en una EC2.
Una EC2 recién lanzada viene configurada para funcionar, no para resistir: trae servicios activos que no vas a usar, permite login con contraseña y confía en los valores por defecto. EndurecerhardeningProceso de reducir la superficie de ataque de un sistema quitando lo innecesario y configurando de forma segura lo que queda. (hardening) un host es llevarlo de ese estado a una configuración mínima y segura. La idea es sencilla y rinde mucho: cuanto menos ofreces, menos puede atacar nadie. Es reducir la superficie de ataque aplicada al sistema operativo, y la base de cualquier host de la app de referencia, Citas.
Qué es endurecer y por qué#
Cada servicio escuchando, cada puerto abierto, cada usuario con shell y cada paquete instalado es una oportunidad para un atacante: algo que puede tener un CVE, una credencial débil o una mala configuración. Endurecer consiste en quitar lo que no necesitas y configurar de forma segura lo que queda. No sustituye a la detección ni a la respuesta —ninguna configuración elimina el riesgo—, pero es la prevención más barata que existe: trabajo de una vez que cierra clases enteras de ataque.
Paso 1 de 6Superficie expuesta
Una EC2 recién creada escucha en más puertos de los que necesita. Internet puede sondear telnet, FTP, la base de datos y SSH: cada uno es una oportunidad.
El CIS Benchmark como guía#
No tienes que inventar qué endurecer. Los CIS BenchmarksCIS BenchmarkGuías de configuración segura, consensuadas por la comunidad, con recomendaciones concretas y niveles de perfil para sistemas, servicios y nubes. son guías de configuración segura, consensuadas por la comunidad, para más de 25 familias de productos —incluidas Amazon Linux, Ubuntu y RHEL—. Cada recomendación trae el riesgo que mitiga, cómo auditarla y cómo remediarla, lo que los hace perfectos para automatizar.
Se organizan en perfiles, y elegir el nivel adecuado es parte del trabajo:
- Level 1: una base práctica que reduce la superficie de ataque sin apenas impacto en el funcionamiento ni el rendimiento. Es el punto de partida razonable para casi cualquier host.
- Level 2: defense in depth para entornos donde la seguridad es crítica (datos regulados, sistemas expuestos). Endurece más, pero puede afectar a la funcionalidad, así que se aplica con cuidado y pruebas.
El antiguo Level 3 se sustituyó por un perfil STIG, alineado con las guías del Departamento de Defensa de EE. UU. Para Citas, Level 1 en toda la flota y Level 2 en los hosts que tocan PII es un reparto sensato.
Medidas clave en una EC2#
Estas son las medidas con mejor relación esfuerzo/impacto para un host en AWS. El explainer las recorre; aquí van con detalle.
-
Usuario no root y mínimo privilegio
Nada de operar como root. Un usuario por servicio sin shell, tareas administrativas vía
sudoacotado, y binarios setuid al mínimo (ver permisos y procesos). -
SSH endurecido —o retirado
Sin login de root, sin contraseñas y solo claves. Y, mejor aún, sin SSH: que el acceso pase por SSM (más abajo).
-
Parches automáticos
Las actualizaciones de seguridad no deben esperar a un humano.
dnf-automaticounattended-upgradesen el host, o AWS Systems Manager Patch Manager para orquestarlo en toda la flota con ventanas de mantenimiento. -
Servicios y puertos mínimos
Desinstala lo que no uses y comprueba qué escucha (
ss -tulpn). Cada puerto cerrado es superficie que desaparece. -
Firewall local
Una segunda capa además del security group:
nftables/firewallden el host deniega por defecto y abre solo lo imprescindible. -
auditd y envío de logs
Auditoría del kernel activa y logs saliendo del host a CloudWatch Logs, para detección e investigación.
-
Cifrado de discos
Volúmenes EBS cifrados con KMS (actívalo por defecto en la cuenta y región). Protege los datos en reposo y los snapshots.
-
Baseline inmutable
No endurezcas a mano cada instancia: construye una golden AMI ya endurecida y reemplaza, no parchees en caliente (infraestructura inmutable).
SSH: de por defecto a endurecido#
El acceso remoto es el punto más atacado de un host expuesto. Compara la configuración por defecto con una endurecida:
sshd por defecto
sshd endurecido
PermitRootLogin yesPasswordAuthentication yesPubkeyAuthentication yes# login de root permitido, contraseñas aceptadas:# un barrido de fuerza bruta solo necesita tiempoPermitRootLogin noPasswordAuthentication noPubkeyAuthentication yesKbdInteractiveAuthentication noAllowGroups ssh-users# solo claves, nunca root, y solo un grupo concretoSin contraseñas no hay nada que adivinar por fuerza bruta, y sin root el atacante tendría que comprometer primero una cuenta concreta y después escalar. Recuerda recargar el servicio tras el cambio (systemctl reload sshd) y no cerrarte fuera: prueba la nueva sesión antes de salir de la actual.
Integración con AWS#
El hardening en la nube no es solo configurar el SO: es apoyarse en servicios gestionados que eliminan clases enteras de riesgo.
SSM Session Manager en vez de SSH#
La mejor forma de asegurar el puerto 22 es no tenerlo abierto. Con AWS Systems Manager Session Manager administras la instancia sin abrir puertos de entrada, sin bastión y sin gestionar claves SSH. El agente SSM (preinstalado en Amazon Linux) sale hacia AWS; tú abres una sesión desde la consola o la CLI, y el acceso se controla con políticas IAM, no con claves repartidas.
# Abrir una shell en la instancia sin SSH, sin puerto 22, sin clave$ aws ssm start-session --target i-0a1b2c3d4e5f67890Las ventajas de seguridad son concretas:
- Sin puertos de entrada: cierras el 22 en el security group; no hay superficie SSH que sondear.
- Control centralizado por IAM: concedes y revocas acceso en un solo sitio, con permisos temporales (p. ej. solo durante una guardia).
- Registro de sesiones: cada sesión y los comandos ejecutados pueden guardarse en S3 o CloudWatch Logs (cifrables con KMS), y las llamadas a la API quedan en CloudTrail. Trazabilidad que SSH plano no te da.
- Sin IP pública: con VPC endpoints (AWS PrivateLink) la instancia ni siquiera necesita salida a Internet.
auditoría de CVEs y cumplimiento#
- Amazon Inspector escanea de forma continua las EC2 (y las imágenes de contenedor en ECR) en busca de CVEs y de exposición de red, priorizando por severidad. Es tu vigilancia de vulnerabilidades sin agentes que mantener.
- Security Hub comprueba la desviación frente a estándares como el CIS AWS Foundations Benchmark, de modo que el endurecimiento de la cuenta se mide solo.
- Systems Manager Patch Manager y State Manager aplican parches y mantienen la configuración deseada en toda la flota.
Errores habituales#
- Endurecer a mano cada instancia. No escala y diverge enseguida. Hornea una golden AMI y reemplaza instancias en vez de parchear en caliente.
- Confiar solo en el security group. Es necesario, pero un firewall local y puertos cerrados en el host son la segunda capa que contiene un error de red.
- Aplicar CIS Level 2 en producción sin probar. Puede romper la aplicación. Nivel adecuado, pruebas en staging y excepciones documentadas.
- Dejar SSH abierto “por si acaso”. Si tienes SSM, el 22 abierto es superficie pura. Ciérralo.
Tu turno
Endurece un host de tu laboratorio con un mini-baseline
Sobre una EC2 o VM tuya de laboratorio, nunca producción ajena:
- Inventaría la superficie:
ss -tulpn(qué escucha) y los paquetes instalados. ¿Qué podrías quitar sin romper nada? - Endurece
sshd_configcon las cuatro líneas de la comparación, recarga el servicio y verifica que puedes entrar antes de cerrar la sesión actual. - Si es una EC2, prueba
aws ssm start-sessiony después cierra el puerto 22 en el security group. ¿Sigues teniendo acceso? - Descarga el CIS Benchmark de tu distribución y aplica tres recomendaciones de Level 1. Anota qué auditaba cada una.
Documenta tu baseline: qué cambiaste, qué excepciones te permitiste y por qué.
Reto
¿Por qué SSM Session Manager se considera más seguro que SSH con clave para administrar una EC2?
▸Mostrar solución
Porque elimina la superficie y centraliza el control. No abres el puerto 22 (nada que sondear ni atacar por fuerza bruta), no gestionas ni repartes claves SSH, el acceso se concede y revoca con políticas IAM desde un solo sitio (incluido acceso temporal), y cada sesión y comando queda registrado en CloudWatch/S3 y las llamadas en CloudTrail. SSH con clave es sólido, pero deja el puerto abierto, las claves por gestionar y menos trazabilidad.
Reto
¿Qué diferencia hay entre el CIS Level 1 y el Level 2, y cuándo elegirías cada uno?
▸Mostrar solución
Level 1 es una base práctica que reduce la superficie sin apenas impacto en el funcionamiento: el punto de partida para casi cualquier host. Level 2 es defense in depth para entornos donde la seguridad es crítica; endurece más pero puede afectar a la funcionalidad, así que requiere pruebas. Elegirías Level 1 de forma general y Level 2 en los hosts que manejan datos sensibles o están muy expuestos, aplicándolo con cuidado.
En resumen#
- Endurecer es reducir la superficie de ataque del host: quitar lo innecesario y configurar de forma segura lo que queda. Es prevención barata, no un sustituto de la detección.
- El CIS Benchmark te da el qué y el cómo; empieza por Level 1 y reserva Level 2 para hosts críticos, siempre con pruebas.
- Medidas clave en una EC2: usuario no root, SSH endurecido, parches automáticos, puertos mínimos, firewall local, auditd, EBS cifrado con KMS y una golden AMI inmutable.
- En AWS, SSM Session Manager sustituye a SSH sin abrir puertos, con control por IAM y registro de sesiones; Inspector vigila CVEs y Security Hub mide la desviación frente a CIS.
- Endurecer es una pata de la defensa en profundidad: combínalo siempre con detección y respuesta.