← Volver al blogAvanzado

Hardening de infraestructura: la guía para reducir tu superficie de ataque

Una infraestructura que creció sin gestión de configuración automatizada termina con controles inconsistentes e imposibles de auditar. Aprendé a aplicar CIS Benchmarks con Ansible y mantener el hardening a escala.

10 min de lectura

Introducción al Problema#

El hardening —o bastionado— de infraestructura es el proceso de reducir deliberadamente la superficie de ataque de un sistema: deshabilitar servicios innecesarios, reforzar configuraciones por defecto, limitar privilegios, aplicar controles de auditoría. Es una práctica conocida, documentada, con estándares internacionales. Y sin embargo, en la mayoría de las organizaciones medianas, no se hace sistemáticamente.

El problema no es falta de conocimiento. Es falta de escala y consistencia. El primer servidor se hardeneó con cuidado. El segundo también. Cuando hay veinte, treinta, o cincuenta servidores — muchos creados bajo presión operativa, por distintos administradores, en distintos momentos — la situación se fragmenta. Algunos tienen configuraciones actualizadas, otros tienen configuraciones de hace tres años que nadie revisó, y nadie tiene una vista completa del estado real.

Cada desviación respecto al estándar es un vector de ataque potencial. El hardening manual, sin automatización, no escala. Este artículo explica cómo construir una práctica de hardening sostenible usando CIS Benchmarks como referencia y Ansible como motor de automatización.

Caso Real o Ejemplo Cotidiano#

Una empresa de servicios financieros con 47 servidores Linux y Windows inició un proceso de certificación ISO 27001. Parte del proceso requería demostrar controles de configuración segura sobre todos los activos.

El equipo de IT tardó seis semanas en relevar manualmente el estado de configuración de cada servidor. El resultado fue alarmante: solo 8 de los 47 servidores tenían configuraciones alineadas con los controles mínimos del CIS Benchmark correspondiente. Los restantes 39 tenían alguna combinación de servicios habilitados innecesariamente, usuarios locales con contraseñas que nunca expiran, SSH con autenticación por contraseña en lugar de clave, banners de login ausentes, y parámetros del kernel vulnerables a ataques de red.

Lo más grave: cuatro servidores tenían el servicio de Telnet activo — un protocolo sin cifrado que transmite credenciales en texto plano, considerado obsoleto e inseguro desde hace más de dos décadas.

Ninguno de estos problemas era una vulnerabilidad de software que requiriera un parche. Eran configuraciones incorrectas que habían persistido silenciosamente durante años, invisibles porque nadie las auditaba sistemáticamente.

La solución fue implementar un pipeline de hardening con Ansible + CIS-CAT Pro que hoy ejecuta auditorías automáticas semanales y aplica remediaciones de forma controlada.

Riesgos para la Empresa#

Configuración débil	Impacto técnico	Riesgo de negocio
Servicios innecesarios activos (Telnet, FTP, RPC)	Vectores de acceso adicionales, protocolos inseguros	Compromiso inicial más fácil para el atacante
Usuarios locales sin política de contraseñas	Credenciales que nunca expiran, fáciles de forzar	Movimiento lateral una vez dentro
SSH con autenticación por contraseña	Susceptible a brute-force automatizado	Acceso no autorizado a servidores críticos
Parámetros del kernel sin ajustar	IP forwarding activo, ICMP redirects habilitados	Facilita ataques de red y reconocimiento
Logs de auditoría no configurados	Sin evidencia de accesos ni cambios	Imposibilidad de investigar incidentes
SUID/SGID innecesarios en binarios	Escalación de privilegios local	Atacante con acceso limitado obtiene root

Explicación Técnica Sencilla#

¿Qué es la superficie de ataque? Es el conjunto total de puntos donde un atacante puede intentar ingresar o extraer datos. Cada servicio activo, cada puerto abierto, cada usuario con más privilegios de los necesarios es parte de esa superficie. Hardening es reducirla deliberadamente.

CIS Benchmarks son guías de configuración segura mantenidas por el Center for Internet Security, una organización sin fines de lucro. Existen benchmarks específicos para Debian, Ubuntu, RHEL, Windows Server, Docker, Kubernetes, AWS, y muchos más. Cada benchmark lista controles numerados con niveles de impacto (L1 básico, L2 avanzado) y una justificación técnica para cada uno.

code

Ejemplo — CIS Ubuntu 22.04 Benchmark, control 1.1.1:
"Asegurarse de que cramfs esté deshabilitado"

Rationale: El sistema de archivos cramfs rara vez se usa en producción.
Al cargarse automáticamente como módulo del kernel, puede ser explotado
para montar filesystems maliciosos.

Remediación:
echo "install cramfs /bin/true" >> /etc/modprobe.d/cramfs.conf
modprobe -r cramfs

Ansible es una herramienta de automatización de configuración que permite describir el estado deseado de un sistema en archivos YAML llamados "playbooks". Al ejecutar el playbook, Ansible verifica el estado actual y aplica solo los cambios necesarios para llegar al estado deseado — es idempotente (ejecutarlo diez veces da el mismo resultado que ejecutarlo una).

yaml

# Ejemplo: playbook Ansible para deshabilitar módulos de kernel inseguros
- name: Deshabilitar filesystem cramfs
  copy:
    content: "install cramfs /bin/true\n"
    dest: /etc/modprobe.d/cramfs.conf
    owner: root
    group: root
    mode: '0644'

- name: Configurar parámetros de kernel seguros
  sysctl:
    name: "{{ item.key }}"
    value: "{{ item.value }}"
    sysctl_set: true
    state: present
    reload: true
  loop:
    - { key: "net.ipv4.ip_forward", value: "0" }
    - { key: "net.ipv4.conf.all.accept_redirects", value: "0" }
    - { key: "net.ipv4.tcp_syncookies", value: "1" }

La combinación CIS Benchmarks + Ansible convierte el hardening en configuración como código: versionado, reproducible, auditable, y aplicable a cualquier número de servidores de forma consistente.

Cómo Prevenirlo#

Elegí el CIS Benchmark correcto para cada sistema operativo y versión: CIS publica benchmarks para Ubuntu, Debian, RHEL/CentOS, Windows Server 2019/2022, Amazon Linux, y más. Descargalos desde cisecurity.org. El nivel L1 es el punto de partida práctico para la mayoría de las organizaciones.
Ejecutá una auditoría de línea de base con Lynis o CIS-CAT Pro antes de aplicar cambios: Lynis es open source y corre directamente en el servidor. CIS-CAT Pro (gratuito para miembros CIS) genera reportes HTML detallados alineados al benchmark. Esto te da el gap inicial: qué está bien, qué está mal, qué falta.
bash
```
# Auditoría con Lynis
lynis audit system --no-colors | tee /var/log/lynis-$(date +%Y%m%d).log
```
Construí playbooks Ansible organizados por área de control: No intentes implementar todos los controles a la vez. Empezá por los de mayor impacto: SSH, usuarios locales, servicios activos, parámetros del kernel. Estructurá los playbooks por roles (role ssh, role kernel, role users) para que sean reutilizables.
Aplicá los cambios en un entorno de pruebas antes que en producción: Hardening puede romper cosas si se aplica sin entender el contexto (por ejemplo, deshabilitar IPv6 en un sistema que lo usa). Probá siempre en un entorno equivalente. Usá el modo --check de Ansible para simular cambios sin aplicarlos.
bash
```
ansible-playbook hardening.yml --check --diff -i inventory/production
```
Automatizá auditorías periódicas y alertá sobre desvíos: El estado hardened no es permanente. Cada nuevo paquete instalado, cada cambio de configuración manual, cada actualización del sistema puede introducir desvíos. Programá auditorías automáticas semanales con Lynis o OpenSCAP y generá alertas si el score baja del umbral definido.
Versioná los playbooks en git y aplicá revisión de código: El hardening-as-code debe tratarse como cualquier otro código de infraestructura: pull requests, revisión por al menos otra persona, historial de cambios claro. Esto da trazabilidad cuando un control cambia o se agrega uno nuevo.
Documentá las excepciones con justificación: Habrá controles del benchmark que no podás aplicar por razones de compatibilidad o negocio. Documentá cada excepción explícitamente — qué control, por qué no aplica, qué control compensatorio existe. Las excepciones no documentadas son brechas invisibles.

Herramientas Recomendadas#

Lynis (lynis.io): Auditor de seguridad open source para sistemas Linux/Unix. Corre sin agente, directamente en el servidor, y genera un reporte con score y recomendaciones priorizadas por severidad. No aplica cambios — solo audita. Ideal como herramienta de diagnóstico inicial y para auditorías continuas en CI/CD. Completamente gratuito.

Ansible (ansible.com): Motor de automatización de configuración open source de Red Hat. Sin agente (usa SSH), lenguaje YAML declarativo, enorme biblioteca de módulos para sistemas operativos, servicios en la nube, y aplicaciones. La versión Community es completamente gratuita. Para equipos grandes, Ansible Automation Platform agrega control de acceso, logs, y orquestación visual.

CIS-CAT Pro (cisecurity.org/cis-cat-pro): Herramienta oficial del Center for Internet Security para evaluar cumplimiento de CIS Benchmarks. Genera reportes HTML/XML detallados con el estado de cada control. Gratuito para miembros CIS (la membresía básica es gratuita para organizaciones sin fines de lucro; comercial tiene costo). Excelente para auditorías formales y evidencia de cumplimiento.

OpenSCAP (open-scap.org): Implementación open source del estándar SCAP (Security Content Automation Protocol). Incluye perfiles de seguridad preconfigurados para RHEL, Fedora, Ubuntu, y otros. Se integra con Ansible para auditar y remediar en un mismo pipeline. Muy usado en entornos governamentales y de defensa por su alineación con estándares NIST.

Checklist Final#

Existe un inventario completo de todos los servidores con su sistema operativo y versión
Hay un CIS Benchmark asignado para cada tipo de sistema en el inventario
Se ejecutó una auditoría de línea de base y el score inicial está documentado
Los playbooks de hardening están versionados en git con historial claro
Los playbooks cubren al menos: SSH, usuarios locales, kernel parameters, servicios activos
Los cambios se prueban en un entorno equivalente antes de aplicarse en producción
Las auditorías de cumplimiento se ejecutan de forma automática (semanal o quincenal)
Existe un proceso de alerta si el score de cumplimiento cae por debajo del umbral definido
Las excepciones a controles del benchmark están documentadas con justificación
El acceso SSH usa autenticación por clave, no por contraseña
No hay servicios de protocolos inseguros activos (Telnet, FTP sin TLS, RPC antiguo)
El proceso de hardening está integrado en el pipeline de provisioning de servidores nuevos

CVE / Vulnerabilidades Relacionadas#

En esta categoría, los riesgos principales no son CVEs de software específico sino patrones de configuración débil sistémicamente explotados. Las organizaciones de threat intelligence documentan que más del 60% de los incidentes exitosos involucran al menos una configuración incorrecta que el atacante aprovechó para moverse lateralmente o escalar privilegios, no necesariamente una vulnerabilidad de día cero.

Algunos ejemplos concretos de configuraciones inseguras explotadas activamente:

SSH con autenticación por contraseña expuesto a internet: Los escáneres automatizados intentan millones de combinaciones por hora. Si el servidor acepta contraseñas, es cuestión de tiempo.
Servicios con privilegios de root innecesarios: Si un servicio comprometido corre como root, el atacante ya tiene el control total del sistema sin necesidad de escalar.
cron jobs con permisos de escritura para todos: Un atacante con acceso de usuario no privilegiado puede modificar un script ejecutado por root para obtener escalación de privilegios.
Variables de entorno con credenciales hardcodeadas en /etc/environment o en scripts de inicio: Visibles para cualquier usuario del sistema, sin cifrado.

El hardening sistemático con CIS Benchmarks cubre explícitamente todos estos vectores.

Conclusión y CTA#

El hardening no es un proyecto de un mes — es una práctica continua. La clave para que sea sostenible es la automatización: CIS Benchmarks dan el estándar, Ansible aplica los controles consistentemente a escala, Lynis y OpenSCAP miden el estado real de forma continua. Cuando el hardening está codificado y automatizado, la seguridad de tu infraestructura puede crecer junto con tu infraestructura, no quedarse atrás.

El primer paso es saber dónde estás: ejecutá lynis audit system en tus servidores más críticos esta semana. El reporte te va a decir exactamente qué reforzar primero.

¿Querés ayuda para diseñar un pipeline de hardening para tu infraestructura? Contactanos para una consultoría inicial gratuita o continuá con el siguiente artículo: IDS/IPS: cómo poner ojos y reflejos en tu red.

¿Querés saber cómo estás parado?

Pedí un diagnóstico de seguridad gratis.

Diagnóstico gratis