Hardening de Linux Server: CIS Benchmark Aplicado sin Romper Produccion
Como aplicar el CIS Benchmark en Debian y Ubuntu de produccion validando cada control, midiendo el impacto y manteniendo el SLA sin pasar la noche en rollback.
Aplicar el CIS Benchmark completo de golpe en un servidor Debian 12 que atiende 40 mil requests por minuto es la forma mas rapida de convertir un viernes en un incidente sev 1. En el equipo Basilisk vimos a mas de una empresa correr el playbook ansible-lockdown crudo en produccion y descubrir a las 3 de la madrugada que el control 5.2.16 desactivo el login del usuario que orquestaba el backup de Postgres. Hardening serio no es copiar 380 controles del PDF: es elegir los 60 que valen el riesgo, probar en staging con la misma carga y tener telemetria para saber en cuantos minutos revertis si algo se rompe en cliente.
El punto de partida correcto es separar los controles en cuatro buckets antes de tocar el servidor. Bucket 1: kernel y boot (sysctl, GRUB, modulos), bajo riesgo de romper la app, ganancia alta. Bucket 2: red y firewall (nftables, IPv6, ICMP), riesgo medio si no mapeaste todos los puertos. Bucket 3: autenticacion, PAM y SSH, donde vive la mayoria de los incidentes post-hardening. Bucket 4: auditd, syslog e integridad con AIDE, riesgo operativo casi nulo. Empeza por el 4, despues el 1, despues el 2, y deja SSH y PAM para el final. Si estas rehaciendo SSH, lee Hardening de SSH 2026: Algoritmos, Certificados y Bastion Hosts antes de tocar sshd_config porque los algoritmos cambiaron en 2026.
Para inventariar el estado actual usa openscap-scanner con el profile xccdf_org.ssgproject.content_profile_cis_level2_server del proyecto ComplianceAsCode. En un Ubuntu 24.04 limpio vas a ver entre 110 y 140 controles en fail, eso es esperado. Exporta el HTML, importalo en Jira como una epica por bucket y estima esfuerzo en puntos de riesgo, no en horas. El truco es nunca aplicar una remediation sin leer el rationale: la mitad de las recomendaciones de CIS Level 2 rompen workloads modernos. Desactivar usb-storage tiene sentido en un bastion, no en un host que escribe dumps en un pendrive cifrado para air gap regulatorio.
La capa de kernel da una ganancia enorme con poco riesgo si sabes que estas tuneando. kernel.kptr_restrict=2, kernel.dmesg_restrict=1, kernel.yama.ptrace_scope=2 y fs.protected_hardlinks=1 son gratis. En cambio kernel.unprivileged_userns_clone=0 rompe Docker rootless, Podman, Bubblewrap y cualquier sandbox de aplicacion, asi que si corres contenedores o usas las tecnicas de Sandbox de Aplicaciones en Linux con Bubblewrap, Firejail y Flatpak dejalo en 1 y documenta el desvio formalmente. Para servicios con alto perfil de ataque considera SELinux enforcing con politica targeted custom, como detallamos en SELinux sin Miedo: Politicas Personalizadas para Servicios Criticos con ejemplo para un Nginx expuesto a internet.
La validacion es la parte que nadie hace bien. Levanta un ambiente espejo en LXD o Proxmox con el mismo kernel, la misma glibc y las mismas versiones de servicios, y corre un perfil de carga con k6 o wrk replicando 30 minutos de trafico real capturado por tcpdump. Aplica los controles en lotes de 10, corre la prueba, compara p95 de latencia y tasa de error. Si la regresion supera el 3% aislas por biseccion cual control es el culpable. Tambien corre atomic-red-team con tecnicas mapeadas a MITRE ATT&CK para confirmar que el hardening realmente reduce superficie: la logica es la misma de Adversary Emulation con Caldera y MITRE ATT&CK en Laboratorio Corporativo, pero enfocada en post-explotacion sobre el host endurecido.
Auditd casi siempre se vuelve cuello de botella si copias el ruleset CIS sin pensar. Las reglas default generan entre 8 y 15 mil eventos por minuto en un host promedio, llenan /var/log en 6 horas y hacen que journald empiece a descartar. La receta que usamos en Basilisk es recortar las reglas de execve para usuarios de servicio conocidos (postgres, nginx, app) y dejar monitoreo agresivo solo para uid 0, sudo y shells interactivas. Reenvialo con auditd-plugin a un pipeline Sigma como mostramos en Threat Hunting con Sigma y Elastic: Del Indicador a la Regla de Deteccion, si no estas generando ruido caro sin ninguna deteccion accionable del otro lado.
Para servidores que tocan datos sensibles o que no podes acceder fisicamente, complementa el hardening con cifrado de disco resistente a coercion y backup verificado siguiendo lo que discutimos en Cripto de Disco y Backups: VeraCrypt, LUKS y Estrategia 3-2-1 Resiliente. LUKS2 con Argon2id, clave en TPM2 sellada con PCR0+PCR7 y snapshot cifrado en storage offsite resuelven el caso de robo fisico del datacenter. Combinado con Secure Boot, modulos firmados y GRUB con password (controles CIS 1.4.x), elevas el costo de un ataque presencial a algo que solo vale la pena contra blancos muy especificos.
Takeaway practico: arma una planilla con cada control CIS aplicado, la version del paquete al momento, el resultado de openscap pre y post, y el delta de latencia medido en staging. Corre esa planilla en cada release mayor del SO (Debian point release, LTS upgrade) porque los sysctl cambian de default y auditd suma campos nuevos. Hardening no es proyecto, es proceso: si en 6 meses no podes probar via scan automatizado que los 60 controles siguen activos en el host, no tenes hardening, tenes fe.