Hardening del sistema operativo: desactivar servicios que no se usan, cerrar puertos, aplicar parches, retirar cuentas y software innecesarios, endurecer políticas de contraseña, habilitar logging y monitorización. Marcos como CIS Benchmarks o STIG dan la línea base para Windows, Linux y equipos de red.
Qué es hardening
El hardening o bastionado es el proceso sistemático de reforzar sistemas, aplicaciones, redes e identidades retirando lo innecesario y aplicando configuraciones seguras por defecto. En la práctica significa desactivar servicios y protocolos que nadie usa, aplicar parches críticos, cerrar puertos, acotar permisos, sustituir credenciales y configuraciones "de fábrica", y dejar un rastro auditable. Es defensa proactiva: reducir la superficie de ataque antes de que un atacante o un escáner automatizado la encuentre.
Por qué importa
La mayoría de sistemas llegan configurados para ser fáciles de desplegar, no para ser seguros: decenas de servicios arrancados por defecto, cuentas administrativas con contraseñas conocidas, controles de acceso abiertos y logging mínimo. En esa postura cada vulnerabilidad pública se convierte casi de inmediato en vía de entrada, porque los atacantes escanean en cuanto se publica el CVE. Una máquina bastionada no es invulnerable, pero obliga al atacante a trabajar por cada paso: menos exploits aplicables, menos privilegios que heredar, más ruido que generar. La mayoría de las brechas que acaban en ransomware o exfiltración masiva no arrancan con un zero-day; arrancan con un servicio expuesto, una contraseña por defecto o un protocolo heredado. El hardening es también cumplimiento: ISO 27001 (A.8.9), ENS, NIS2 y DORA lo exigen de forma explícita, y los CIS Benchmarks o las STIG son la referencia técnica más utilizada para demostrarlo.
Puntos clave
Hardening de aplicaciones: retirar módulos por defecto, reforzar la validación de entrada, cambiar credenciales y tokens iniciales, habilitar cabeceras de seguridad HTTP, aplicar actualizaciones y poner delante un WAF con reglas específicas del negocio, no solo las del vendor.
Hardening de red: segmentar por zonas (usuarios, servidores, OT, DMZ), cerrar interfaces de gestión al público, forzar TLS moderno, deshabilitar protocolos heredados (SMBv1, LDAP sin firma, telnet) y controlar el tráfico este-oeste además del norte-sur. Es el complemento natural de segmentación de red y Zero Trust.
Hardening de identidad y cloud: cuentas de servicio con mínimo privilegio, rotación de claves, MFA en consolas cloud, buckets no públicos por defecto, políticas IAM revisadas, deshabilitación de autenticación básica y legacy auth. En entornos cloud suele ser donde más rápido se abre y se cierra la superficie de ataque.
Bastionado reproducible con Infraestructura como Código: las líneas base se escriben como código en herramientas IaC estándar y se aplican a escala, no a mano servidor por servidor. Eso evita la deriva de configuración y permite demostrar en auditoría cuándo, quién y cómo se aplicó.
Es un proceso continuo, no un proyecto: cada vulnerabilidad relevante, cada cambio de arquitectura y cada nueva versión del benchmark implica revisar y recalibrar. Sin monitorización de cumplimiento la postura se degrada en meses.
Ejemplo: Bastionado de un servidor Linux expuesto a Internet
Un servidor Linux recién aprovisionado para publicar una aplicación web llega con SSH en el puerto estándar, un usuario con contraseña, un servidor DNS recursivo encendido, SNMP con community "public", SMB y NFS activos "por si acaso", y el firewall local desactivado para que el equipo de desarrollo pueda depurar. En ese estado, el primer escaneo de Internet lo descubre en horas, y cualquier credencial reutilizada o CVE sin parchear lo convierte en punto de entrada inmediato al segmento interno.
La versión bastionada recorta el perímetro de forma metódica: solo SSH (con clave pública, MFA para administración y jail2ban), HTTP/HTTPS detrás del balanceador, el resto de puertos cerrados por firewall; se retiran DNS, SNMP, SMB, NFS y cualquier paquete no usado; se aplica una línea base CIS para el SO, con SELinux o AppArmor en modo enforcing, permisos POSIX ajustados y logging centralizado hacia el SIEM; se cifran los discos en reposo y se establece un ciclo de parches mensual con ventanas de emergencia para CVEs críticos. El resultado no es un servidor invulnerable, es un servidor que no aparece en los primeros lugares de la cola del atacante y que, cuando algo va mal, deja rastros en los que el SOC puede trabajar.
Errores habituales
- Tratar el hardening como un documento que se redacta una vez y se archiva. Las líneas base envejecen, aparecen nuevos servicios, cambia la versión del SO; sin revisión periódica el cumplimiento del papel no se corresponde con la postura real.
- Aplicar controles solo en producción y dejar entornos de preproducción o laboratorio sin tocar. Son precisamente esos entornos los que suelen conectar con producción, tener credenciales válidas y la menor vigilancia.
- Bastionar solo el SO e ignorar el resto: aplicaciones, bases de datos, middleware, dispositivos de red y cuentas cloud quedan con configuración por defecto porque 'no son nuestro área'. El atacante no respeta esos organigramas.
- Confundir hardening con seguridad total. Un sistema bastionado sigue siendo vulnerable a zero-days, phishing y errores de negocio; solo cierra las puertas fáciles. Requiere convivencia con detección, respuesta y copias de seguridad.
- Excesos que rompen el negocio: bloquear binarios legítimos con reglas AppLocker demasiado estrictas, cerrar puertos que un sistema de pago necesita, inhabilitar protocolos que aún usa el ERP. Cuando el usuario avanzado encuentra un atajo, el hardening se evapora.
Términos relacionados
Servicios relacionados
Este concepto puede tener relación con servicios como:
Preguntas frecuentes
¿Quién debe ser responsable del hardening en una organización?
La responsabilidad tiene que estar repartida pero coordinada. Infraestructura suele ser propietaria del bastionado de sistema operativo y red; desarrollo y DevOps del bastionado de aplicaciones y pipelines; el equipo de identidad y cloud, del de cuentas e IAM; y el CISO define el estándar, mide el cumplimiento y firma las excepciones. La trampa habitual es dejar que cada equipo defina su propio baseline: el resultado es inconsistencia y una auditoría dolorosa. Lo eficaz es un estándar común —basado en CIS, STIG o ENS— que se traduce en plantillas y pipelines reutilizables.
¿Cómo se mantiene el hardening en el tiempo sin que se degrade?
Automatizando la aplicación y la verificación. Las líneas base se codifican como Infraestructura como Código con herramientas IaC estándar y se aplican en cada despliegue, no manualmente. En paralelo, herramientas de compliance-as-code o posture management comparan la realidad contra la política y generan alertas cuando aparecen desviaciones (servicio reactivado, cuenta con más privilegios de los acordados, regla de firewall abierta). Integrado con SIEM y con gestión del cambio, el hardening deja de ser un proyecto y pasa a ser un control operativo.
¿El hardening penaliza el rendimiento o la disponibilidad?
En sistemas modernos el impacto es bajo si se hace con cabeza. Algunas capas —logging muy verboso, cifrado en reposo, inspección TLS— tienen coste y conviene dimensionarlas. El mayor riesgo operativo no suele ser la CPU, es romper una integración que dependía de una configuración insegura (SMBv1, autenticación básica, puerto abierto a toda la red). Por eso se prueba primero en preproducción, se despliega por olas y se documenta qué servicios se han tocado. El riesgo residual de no bastionar siempre supera el coste de hacerlo bien.
¿Hay mucha diferencia entre el hardening de Windows y el de Linux?
Los principios son los mismos: minimizar servicios, aplicar parches, reducir privilegios, proteger credenciales, registrar y monitorizar. Las herramientas cambian: Windows se endurece con Group Policy, AppLocker/WDAC, EDR integrado y políticas de dominio; Linux con firewalld/nftables, SELinux o AppArmor, permisos POSIX y módulos de sudo. CIS Benchmarks y STIG publican guías específicas para cada sistema y versión, de forma que la organización puede auditar el estado real frente al estándar sin reinventar la rueda.